Home > Vulnerability Assessment / Vulnerability Management, Vulnerability Research > Liability of Reverse Engineering Security Vulnerability Research?

Liability of Reverse Engineering Security Vulnerability Research?

Eula(Ed.: Wow, some really great comments came out of this question.  I did a crappy job framing the query but there exists a cohesiveness to both the comments and private emails I have received that shows there is confusion in both terminology and execution of reverse engineering. 

I suppose the entire issue of reverse engineering legality can just be washed away by what appeared to me as logical and I stated in the first place — there is no implied violation of an EULA or IP if one didn’t agree to it in the first place (duh!) but I wanted to make sure that my supposition was correct.]

I have a question that hopefully someone can answer for me in a straightforward manner.  It  popped into my mind yesterday in an unrelated matter and perhaps it’s one of those obvious questions, but I’m not convinced I’ve ever seen an obvious answer.

If I as an individual or as a representative of a company that performs vulnerability research and assurance engages in reverse engineering of a product that is covered by patent/IP protection and/or EULA’s that expressly forbids reverse engineering, how would I deflect liability for violating these tenets if I disclose that I have indeed engaged in reverse engineering?

HID and Cisco have both shown that when backed into a corner, they will litigate and the researcher and/or company is forced to either back down or defend (usually the former.) (Ed:. Poor examples as these do not really fall into the same camp as the example I give below.)

Do you folks who do this for a living (or own/manage a company that does) simply count on the understanding that if one can show "purity" of non-malicious motivation that nothing bad will occur?

It’s painfully clear that the slippery slope of full-disclosure plays into this, but help me understand how
the principle of the act (finding vulnerability and telling the company/world about it) outweighs the liability involved.

Do people argue that if you don’t purchase the equipment you’re not covered under the EULA?  I’m trying to rationalize this.  How does one side-step the law in these cases without playing Russian Roulette?

Here’s an example of what I mean.  If you watch this video, the researchers that demonstrated the
Cisco NAC attack @ Black Hat clearly articulate the methods they used to reverse engineer Cisco’s products.

I’m not looking for a debate on the up/downside of full disclosure, but
more specifically the mechanics of the process used to identify that a
vulnerability exists in the first place — especially if reverse
engineering is used.

Perhaps this is a naive question or an uncomfortable one to answer, but I’m really interested.



  1. May 8th, 2007 at 09:33 | #1

    Your question as phrased shows maybe a slight ignorance of what the various IP protection mechanisms do and do not help with. Copyright, trademarks and patents do NOT protect you from reverse-engineering from a legal standpoint. Patents do quite the opposite, since they require you to publish your methods.
    Contracts can potentially help, as could the DMCA which creates a new class of protection for some works. The DMCA has been invoked a number of times, but I believe all those cases related to security research have been shot down (even though they made Skylarov suffer for about a year.) The DMCA is designed to give teeth to technical protection mechanisms around copyrighted works, but even it has an explicit research exemption.
    Which leaves contracts, and the question of whether a EULA, click-through agreement or shrinkwrap license is a valid contract. It's my understanding that these have never been well-tested in court. There have been quite a few cases where the vendor has threatened to sue over violation of a EULA, but the vendor has backed down rather than take it to court. For example, many larger software vendors forbid "unauthorized reviews", but magazines reviews routinely ignore that.
    There are often ways to get binaries that fall outside of the usual way you "agree" to a EULA. For example, for a Black Hat presentation a few years ago, I RE'd a Microsoft tool having to do with Terminal Services scripting and testing. I used that information to create TSGrinder, a tool for brute-forcing TS logins. If you received the binaries through the Server Resource Kit, you theoretically agreed to something by breaking a paper seal on the CD. In my case, Microsoft made the same binaries available via anonymous FTP with no agreement whatsoever.
    But ultimately, the vast majority of reverse engineers seem to believe that EULAs have no or limited enforcement capability. You can claim whatever you like in a EULA or similar. By reading this comment, you agree to give me a million dollars. But that doesn't mean a Judge will enforce it. Until courts repeatedly and painfully enforce EULAs, it seems quite safe to perform this kind of research.

  2. May 8th, 2007 at 09:42 | #2

    Undoubtedly my post shows ignorance and to a degree I phrased some of it intentionally. Your post is very helpful. Others have contacted me privately via email expressing some of the same comments, but i really appreciate the color added here.
    (I'm not a lawyer, I just play one on the Internet)

  3. May 8th, 2007 at 11:49 | #3

    I think the best folks to contact are probably the Center for Internet and Society at Stanford http://cyberlaw.stanford.edu/ or the EFF.
    In general I believe the all of the cases of suit against vulnerability disclosure have come in cases where the individual had specifically signed an NDA or other sort of agreement rather than just agreed to a EULA. In all of the cases I can recall where the plaintiff relied on the EULA the case was tossed as the EULA being non-enforceable in these cases.
    The EFF has a page on EULAs http://www.eff.org/wp/eula.php that has links to a lot of other supporting materials.
    Dan Bernstein has a little page related to this as well – http://cr.yp.to/softwarelaw.html.
    See also this relatively recent blog item from Jennifer Grannick – http://www.granick.com/blog/?p=559
    Looks like you're probably safe if you're in NY 🙂

  4. May 8th, 2007 at 22:51 | #4

    I posted on my blog my answer to this question: http://erratasec.blogspot.com/2007/05/liability-o
    The upshot is this: reverse-engineering is broadly protected by law, is legal, is ethical, and is largely free from liability. There are only a couple wrinkles to this, namely in the area of copyright piracy and EULA contracts.

  5. May 9th, 2007 at 04:34 | #5

    Thanks, Robert. Again, I did a crappy job of framing the question, but the responses did a much better job of painting the corner cases without going down the rabbit hole of minutia.
    Thanks very much for your post, it did an excellent job of summarizing things.

  1. No trackbacks yet.