Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Anti-Reverse Engineering Guide

codeproject.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: An Anti-Reverse Engineering Guide

#51

Post by timsally »

tptacek wrote: post #39
timsally wrote: post #13

Earlier quoted context omitted.

It is true the techniques in the article are nothing new. However, this comment is a knee jerk reaction and largely misleading. The notion that something being crackable is a failure is incorrect. The time a protection scheme needs to hold up varies depending on the industry, but the economics of DRM to not require it to last forever. For video games it's a month or two (Starcraft 2 sold 75% of total copies told to d…

Rolf Rolles' paper is a pretty fun read: http://static.usenix.org/event/woot09/tech/full_papers/rolle... In fairness, symbolic execution and theorem proving was a future direction for him; this paper is mostly compiler theoretic.

Haha yeah that paper is how I got started reversing VM based schemes. A short paper that does use symbolic execution and theorem proving is BinHunt, although it's a blatant ripoff of Halvar published 4 years later. Their only claimed contributions are (1) symbolic execution and theorem proving for basic block equivalence and (2) backtracking for their maximum common subgraph isomorphism algorithm (in contrast to Halvar who I believe used direction instruction comparison for basic block equivalence and a greedy subgraph algorithm). These could be meaningful contributions but they provide no data to prove that that the posited accuracy increase of symbolic execution and backtracking is worth the large performance hit.

Re: An Anti-Reverse Engineering Guide

#52

Post by jcr »

dfc wrote: post #45
jcr wrote: post #37

Earlier quoted context omitted.

In the old days (80's and early/mid 90's) where people would distribute small and simple patches to disable protections (i.e. "crack" executable files), a fast release cycle for the software thwarted the simple cracks. This situation did not last long. The crackers started using more sophisticated patching techniques, like search-string-patching and key generators. The task of maintaining on-going disassembly across…

In the 80s/90s where software companies able to develop, test and distribute updates as efficiently as the warez community?

I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.

Re: An Anti-Reverse Engineering Guide

#53

Post by dfc »

jcr wrote: post #52
dfc wrote: post #45

Earlier quoted context omitted.

In the 80s/90s where software companies able to develop, test and distribute updates as efficiently as the warez community?

I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.

I'm sorry I did not mean to be unfair. I was curious if the companies were able to distribute updates pre-broadband. I can remember downloading the twenty something floppies for os2 over a dialup.

Re: An Anti-Reverse Engineering Guide

#54

Post by bri3d »

joezydeco wrote: post #49
bri3d wrote: post #30

Earlier quoted context omitted.

I'm not sure DirecTV's scheme is entirely relevant, because it revolves around protected hardware rather than protected software. The idea behind DirecTV is that the crypto code runs entirely in hardware the user can never see, heavily protected physically - a protection method which isn't possible for software on most modern x86 machines. Plus, satellite providers have a distinct advantage in that their content need…

"Plus, satellite providers have a distinct advantage in that their content needs to be protected only in real time." I could be wrong here, and it's been a while since I missed with Echostar/Dish hardware, but DVR recordings are stored on the hard drive in raw, encrypted form and then played back through the decryption hardware.

Yet another mistake Dish made - IMO, every iteration of Nagravision is end-to-end pretty poorly implemented.

At any rate, I was speaking more to the practical aspects than the technical ones. In the eyes of a DRM writer, a game needs to be protected for at least a few weeks (launch purchase window), and once it's cracked once, it's pretty much the end - the game is in the wild, and the damage is done, because what's being pirated is the game itself.

On the flip side, what satellite providers are protecting isn't really the content - it's the ability to display the content in at a certain point of presence as a stream. Public exhibition (bars, clubs) and live PPV fights are the big game for satellite encryption, not Joe Public (or Joe Pirate) watching his shows. They'll be available to pirates immediately after they're aired through other means (stations, screeners, stripping HDCP off of HDMI) anyway.

That's why I think the satellite game is easier - not technically, but practically. As a satellite TV provider, even if your DRM can be removed post facto, the benefit to the pirate is greatly diminished (and the downside to you, as well).

Re: An Anti-Reverse Engineering Guide

#55

Post by jcr »

dfc wrote: post #53
jcr wrote: post #52

Earlier quoted context omitted.

I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.

I'm sorry I did not mean to be unfair. I was curious if the companies were able to distribute updates pre-broadband. I can remember downloading the twenty something floppies for os2 over a dialup.

At one point in time, software companies sent updates on magnetic tape through the postal mail. One of the most clever hacks I've read about was when a group doing penetration testing mailed a fake (back doored) update tape to the target.

When it comes to the efficiency of distribution, it's best to think of it in terms of the constraints and requirements.

Without a way to duplicate and distribute their products to customers, software companies could not exist, so the capacity to duplicate and the ability to distribute are both requirements.

Those very same duplication and distribution methods used by the company can also be used by others to further (re)distribute additional copies.

The difference is, the software companies are operating under the constraint of needing to make a living by selling copies of their products, so there's really no way to make a fair comparison on the efficiency of the methods used by the companies versus those people making additional copies. You're essentially comparing farmers to chefs; one produces food, while the other prepares the food.

Re: An Anti-Reverse Engineering Guide

#56

Post by tonyedgecombe »

jdangu wrote: post #5
conductor wrote: post #2

Well, nothing new. If it runs, it can be cracked. I say it as a reverser (legal) with more than 10 years of exp. So, instead of investing money/time into the protection mechanisms, it's better to use the resources to improve your software. Yet well-thought custom protection (i.e. not ASProtect, Armadillo, etc..) can be harder, but it's all the same crackable.

Nowadays, those techniques are mostly used by malware/viruses. Downloadable try-before-you-buy is dead.

No, my business is continuing to grow year on year. People seem to love installing my dead software on their dead PC's running that dead operating system Windows and they are quite happy to pay me for it.

Re: An Anti-Reverse Engineering Guide

#57

Post by xtracto »

jdangu wrote: post #5
conductor wrote: post #2

Well, nothing new. If it runs, it can be cracked. I say it as a reverser (legal) with more than 10 years of exp. So, instead of investing money/time into the protection mechanisms, it's better to use the resources to improve your software. Yet well-thought custom protection (i.e. not ASProtect, Armadillo, etc..) can be harder, but it's all the same crackable.

Nowadays, those techniques are mostly used by malware/viruses. Downloadable try-before-you-buy is dead.

Tell that to the WinRar developer.

Re: An Anti-Reverse Engineering Guide

#58

Post by Tipzntrix »

DrJokepu wrote: post #24

This is probably a very naive question but can't any of these measures be easily bypassed by running the observed software in a VM like KVM and just attaching a debugger like GDB directly to the VM?

What about the timer-based approach that he mentions? It seems that regardless of how you debug through a VM, it will still take additional time, unless you are altering the processor clock somehow.

Re: An Anti-Reverse Engineering Guide

#59

Post by bri3d »

reitzensteinm wrote: post #31
bri3d wrote: post #27

Earlier quoted context omitted.

Note the instructions. It's just capturing the video stream via analog source, as far as I can tell. I believe your comment's parent was referring to their over-the-air stream DRM (i.e. the stream to the dish receiver), which hasn't been publicly broken.

And since cracking follows the path of least resistance, it's likely that the DRM would have been cracked if that was the only way to get at the content. This is a case of deadbolted door, window left open.

I agree with you there - all HD video DRM is "deadbolted door, window left open" at this point since HDCP is fully opened (both by the ability to clone or purchase the HDCP hardware from a real TV and by the leaking of the HDCP master keys).

There's still some incentive to crack video DRM, since ripping through HDMI requires a re-encode and degrades quality, but the approach is good enough that the payoff is reduced substantially.

Post reply on HN