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

31–40 of 59 posts

Re: An Anti-Reverse Engineering Guide

#31

Post by reitzensteinm »

bri3d wrote: post #27
Estragon wrote: post #17

Earlier quoted context omitted.

> ...as far as I know there hasn't been a break in DirecTV > for over half a decade. Curious what you think of this commercial software which claims to break DirecTV's DRM. (I have no means to evaluate it, google found it for me.) http://drm-removal.com/features/DirecTV-Save-Download-Captur...

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.

Re: An Anti-Reverse Engineering Guide

#32

Post by bri3d »

tptacek wrote: post #7
mwexler wrote: post #3

Impressive article by a current high school senior; I wish I wrote at this level in high school! Note that it is from 2008.

There is something about high school seniors and low-level code like this. From numerous observations over the last 15 years or so. I think it might be because your first 5 years in the profession serves in part to teach you what technical issues to be "scared" of, and high school kids haven't learned that yet.

I entirely agree - as a high schooler, I was very, very good at reversing.

It's helped me a lot professionally, actually - I'm much faster at debugging compiled languages than my coworkers are, and the mental patterns I developed while peeling away the layers of control flow in disassembly map very well to understanding large code bases even when I do have the source.

I think it's mostly a function of time rather than being scared, though - learning how to reverse takes quite a while, and once you've got a professional job where reversing seems entirely irrelevant (and even potentially dangerous), it's hard to justify taking the time to learn how.

Re: An Anti-Reverse Engineering Guide

#33

Post by conductor »

kdb1 wrote: post #29
conductor wrote: post #19

Earlier quoted context omitted.

antivirus company, malware analysis

Sorry to go off topic, but I have to ask. How did you get involved in that industry? Malware analysis seems like something I'd love to do. If you don't mind, could you share any tips or career advice you would give to someone who might want to pursue a career in malware analysis/antivirus industry?

Well, in my case I was enjoying unpacking protected software (just for fun, I wasn't distributing cracked software, just writing tutorials on how to bypass protections and releasing tools/unpackers/unprotectors for common types of protectors). Then somebody contacted me and offered the job.

What you can do? I would start from tuts4you.com, teach x86 assembly language, download a degugger and/or disassembler and dig something or follow tutorials.

Re: An Anti-Reverse Engineering Guide

#34

Post by kdb1 »

conductor wrote: post #33
kdb1 wrote: post #29

Earlier quoted context omitted.

Sorry to go off topic, but I have to ask. How did you get involved in that industry? Malware analysis seems like something I'd love to do. If you don't mind, could you share any tips or career advice you would give to someone who might want to pursue a career in malware analysis/antivirus industry?

Well, in my case I was enjoying unpacking protected software (just for fun, I wasn't distributing cracked software, just writing tutorials on how to bypass protections and releasing tools/unpackers/unprotectors for common types of protectors). Then somebody contacted me and offered the job. What you can do? I would start from tuts4you.com, teach x86 assembly language, download a degugger and/or disassembler and dig s…

Thanks for your reply. I guess I tend to shy away from things like tuts4u and crackmes.de because it seems questionable legally, although I haven't looked into it much. I mostly "reverse" my own code in gdb just to understand whats going on in the assembly. These types of things are hard to show in a resume, so I'm not really sure how to make myself an attractive job candidate to some of these antivirus companies.

Re: An Anti-Reverse Engineering Guide

#35

Post by tptacek »

bri3d wrote: post #30
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…

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…

I have a very little bit of insight into how DirecTV's modern cards are implemented, and the fundamental technique does not rely on hardware --- in other words, if you had already been outfitted with a lab that could decap and image chips well enough to generate simulators, the fundamental technique involved would still be expensive to unwind.

BD+ has produced multiple titles which, during their new release window, had no high-quality HD rips torrented. But that's besides the point: if antidebugging and antireversing is such a lost cause, it stands to reason that BD+ should be completely broken by now. But, of course, it is not.

Re: An Anti-Reverse Engineering Guide

#36

Post by tptacek »

conductor wrote: post #20
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…

I'm speaking of software right now, not TV/BD+. I beleive 99.99% of those who pirate will never buy a game just because they don't want to wait several days (or weeks, very rare). DRM only harasses those who don't pirate. >> Starcraft 2 sold 75% of total copies told to date within the first month. And who says that without the DRM it would be lower? Maybe it would be even higher! Many techy people just don't buy thos…

BD+ is a software issue. The incremental breaks in BD+ are delivered in the form of updates to Slysoft AnyDVD.

Re: An Anti-Reverse Engineering Guide

#37

Post by jcr »

Gazk wrote: post #16
marshray wrote: post #8

Earlier quoted context omitted.

I agree. It seems like a big waste of time and energy. I suspect most of these techniques are defeated in one fell swoop by debugging the process from kernel mode and/or under virtualization. At best, you're only going to delay reversers who aren't as experienced as this high school senior (and can't find articles on codeproject.com).

I think its a better deterrent to just release software updates often. Of course you need to give the user a compelling reason to want to update.

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 multiple release versions of some software is actually straight forward. The "dumb" (but useful) way to do it is by finger-printing all of the subroutines in the old disassembly, and then using the fingerprints to identify the similar routines in the new disassembly (IDB2PAT). The "smart" way to do it is the graph theoretic approach of Halvar Flake.

Anyone in the Anti-Virus or compatibility industries can confirm both the capacity and the need to maintain disassemblies across multiple versions of software.

Pumping out a relentless stream of new versions of your software is no longer a deterrent, and hasn't been for over a decade.

Re: An Anti-Reverse Engineering Guide

#38

Post by conductor »

kdb1 wrote: post #34
conductor wrote: post #33

Earlier quoted context omitted.

Well, in my case I was enjoying unpacking protected software (just for fun, I wasn't distributing cracked software, just writing tutorials on how to bypass protections and releasing tools/unpackers/unprotectors for common types of protectors). Then somebody contacted me and offered the job. What you can do? I would start from tuts4you.com, teach x86 assembly language, download a degugger and/or disassembler and dig s…

Thanks for your reply. I guess I tend to shy away from things like tuts4u and crackmes.de because it seems questionable legally, although I haven't looked into it much. I mostly "reverse" my own code in gdb just to understand whats going on in the assembly. These types of things are hard to show in a resume, so I'm not really sure how to make myself an attractive job candidate to some of these antivirus companies.

I don't see anything illegal in disassembling shareware or any other type of software. Compare it with disassembling your smartphone/alarm clock/hand watch/.. to find out how it works. Why should it be illegal?

Re: An Anti-Reverse Engineering Guide

#39

Post by tptacek »

timsally wrote: post #13
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.

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.

Re: An Anti-Reverse Engineering Guide

#40

Post by DanBC »

conductor wrote: post #38
kdb1 wrote: post #34

Earlier quoted context omitted.

Thanks for your reply. I guess I tend to shy away from things like tuts4u and crackmes.de because it seems questionable legally, although I haven't looked into it much. I mostly "reverse" my own code in gdb just to understand whats going on in the assembly. These types of things are hard to show in a resume, so I'm not really sure how to make myself an attractive job candidate to some of these antivirus companies.

I don't see anything illegal in disassembling shareware or any other type of software. Compare it with disassembling your smartphone/alarm clock/hand watch/.. to find out how it works. Why should it be illegal?

"circumventing a copyright protection mechanism"? (or whatever the wording is in various laws.)
Post reply on HN