And my all time favorite technique...an army of lawsuit happy lawyers!
An Anti-Reverse Engineering Guide
21–30 of 59 posts
Re: An Anti-Reverse Engineering Guide
#22Impressive 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.
The thing high school students have is time. Time to experiment, time to go deep, without external pressure. Once you are in University or the work force or have dependents, the pressure is on to get results, and you no longer have time.
The irony is that the applied pressure probably doesn't produce a superior result to being left to your own devices.
Re: An Anti-Reverse Engineering Guide
#23Well, 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?
There is the 0-day Scene, those groups which are pretty much closed/private (to name some, CORE, BliZZARD, EMBRACE, HERiTAGE, SSG, DiGERATi..), these are invitation only. And the Web scene groups like FFF, TSRh, RES, who often offer to solve some keygenme/crackme for newcomers to be accepted.
Re: An Anti-Reverse Engineering Guide
#24This 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?
Re: An Anti-Reverse Engineering Guide
#25Well, 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.
I wouldn't say it's dead, there are many shareware software out there. For example, Topic-Starter's PVS-Studio aka PVS-Studio.v4.56.Incl.Keygen-NOY ;)
Re: An Anti-Reverse Engineering Guide
#26This 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?
They absolutely can be. At the time this article was written (2008), VMs weren't as in vogue as they are today, VM-attached debugging wasn't as mature, and the leading "ring-0" / above-the-kernel debugger (SoftICE) had just been discontinued.
Today, there are a host of new measures designed to thwart in-VM debugging, but the playing field differs substantially from the one present when this article was written, and your observation is a good one.
Re: An Anti-Reverse Engineering Guide
#27Earlier 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…
> ...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.
Re: An Anti-Reverse Engineering Guide
#28Earlier 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).
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".
If you read past the title and into the article content, you'll see that he says "In this article, I plan to travel a bit deeper into the interesting world of reverse engineering and explore some more intermediate level techniques for annoying reverse engineers."
He's right - these techniques basically just annoy any mildly competent reverse engineer.
Re: An Anti-Reverse Engineering Guide
#29Earlier quoted context omitted.
Where are you working on reversing?
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?
Re: An Anti-Reverse Engineering Guide
#30Well, 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 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 needs to be protected only in real time.
I do give kudos to DirecTV for managing to create a technology that's less of a sieve than Nagravision (although that might also have to do with DirecTV suing everyone who dared go near their smartcards into oblivion in the early 2000s), but they play a totally different (and, IMO, much easier) game than software protectors do.
As for BD+, with HDCP broken so widely I don't really see a point to breaking it. Scene groups can source movies of equal or greater quality from many other sources, even using decrypted HDMI as a last resort, before needing to care about actually exploiting the BD+ VM.