Live data from Hacker News

An Anti-Reverse Engineering Guide

codeproject.com

11–20 of 59 posts

Re: An Anti-Reverse Engineering Guide

#11
post #8

As someone who has decided to do all (or most of) his personal coding in public, I must say the idea of spending time and effort making sure no one reverse engineers your stuff is kind of funny.

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).

To be fair he does say clearly that all of these would be reasonably easy to bypass.

Perhaps he needed a better, but less catchy, title. "Some tricks that will slightly delay reverse-engineering" or "What I know about making reverse engineering a little bit harder than it needs to be".

Re: An Anti-Reverse Engineering Guide

#12

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.

Who are the best 'reversers' out there? I work in bioengineering which is largely a reverse-engineering discipline (i.e. we do a lot of tweaking natural organisms that we didn't design) -- just curious if there are overlapping ways of thinking / general approaches. Anyone do serious CS research on reverse engineering methodologies?

Re: An Anti-Reverse Engineering Guide

#13

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 date within the first month). Also, there are several DRM schemes deployed in production today that are acknowledged by those in the field as quite effective, namely BD+ and DirecTV's scheme. Indeed, as far as I know there hasn't been a break in DirecTV for over half a decade.

As far as malware goes, virtualization obfuscators are the current state of the art. They are a fundemental advancement in packing. Up until virtualization obfuscators, all other packers had the weakness where at some point the unprotected program would end up in memory. This weakness is easily exploitable (ala VxClass, see Recon 2010 for an easily digestible talk). Virtualization obfuscators are still beatable with manual reverse engineering (see Rolles WOOT 2009) and some effort has been made to automate the process (see Wenke Lee's group at Oakland 2009). But when a packing scheme forces you to hire reverse engineers who know what symbolic execution is, you know that you've substantially raised the bar.

Re: An Anti-Reverse Engineering Guide

#14
post #12

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.

Who are the best 'reversers' out there? I work in bioengineering which is largely a reverse-engineering discipline (i.e. we do a lot of tweaking natural organisms that we didn't design) -- just curious if there are overlapping ways of thinking / general approaches. Anyone do serious CS research on reverse engineering methodologies?

I've been out of touch and out of practice for years now, so I'm curious to know the answer to this question. I was fascinated with reverse engineering back when Fravia[1] hadn't yet completely moved away from cracking to "search lore".

[1] http://en.wikipedia.org/wiki/Fravia

Re: An Anti-Reverse Engineering Guide

#15

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.

Where are you working on reversing?

Re: An Anti-Reverse Engineering Guide

#16
post #8

As someone who has decided to do all (or most of) his personal coding in public, I must say the idea of spending time and effort making sure no one reverse engineers your stuff is kind of funny.

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.

Re: An Anti-Reverse Engineering Guide

#17

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…

  > ...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...

Re: An Anti-Reverse Engineering Guide

#18

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…

To add to the 'quite effective' schemes: Cinavia. It adds watermarks to the audio in movies and is resilient enough to be maintained even when a cam-rip is done of a movie. Brilliant scheme, and the patent application (US7369677) is really well written. There hasn't been a break yet, but it'll come eventually.

Re: An Anti-Reverse Engineering Guide

#19
post #15

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.

Where are you working on reversing?

antivirus company, malware analysis

Re: An Anti-Reverse Engineering Guide

#20

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…

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 those new games with draconian DRMs/Spyware which require internet connection. Or they buy the game and then download NODVD/cracked.exe

Post reply on HN