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

41–50 of 59 posts

Re: An Anti-Reverse Engineering Guide

#41

Post by kdb1 »

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?

Copyright laws seem to be so strict these days, its tough to tell.

Re: An Anti-Reverse Engineering Guide

#42

Post by josephcooney »

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.

What method do you use to distribute commercial desktop software?

Re: An Anti-Reverse Engineering Guide

#43

Post by ChuckMcM »

jonl wrote: post #28
DanBC wrote: post #11

Earlier quoted context omitted.

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.

Of course there is the 'knowing you're being reverse engineered and doing something else'. I don't doubt for a minute people who write sensitive code, be it malware or DVD decoders, might simply act differently if they thought a debugger was involved, not so much as not act at all. Some of these techniques could be used there.

That being said, the more interesting thing is poking around in the inner bits of the machine and seeing how it comes together. Highly recommended for anyone serious about wanting to know how the machine does what it does.

If you want to practice on code that is easily obtained I suggest you poke around the World of Warcraft rootkit code that it uses to prevent people from cheating at WoW.

Re: An Anti-Reverse Engineering Guide

#44

Post by tptacek »

ChuckMcM wrote: post #43
jonl wrote: post #28

Earlier quoted context omitted.

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.

Of course there is the 'knowing you're being reverse engineered and doing something else'. I don't doubt for a minute people who write sensitive code, be it malware or DVD decoders, might simply act differently if they thought a debugger was involved, not so much as not act at all. Some of these techniques could be used there. That being said, the more interesting thing is poking around in the inner bits of the machi…

Detecting debuggers and altering behavior is so much the oldest trick in the book that it is actually covered in depth in this Codeproject article (Codeproject is often unusually well written, and so is this article, but be clear that this is really basic stuff he's talking about).

Re: An Anti-Reverse Engineering Guide

#45

Post by dfc »

jcr wrote: post #37
Gazk wrote: post #16

Earlier quoted context omitted.

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…

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

Re: An Anti-Reverse Engineering Guide

#46

Post by dfc »

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…

Breaking DRM is not the only relevant aspect of the video game industry. Punkbuster and other anticheat daemons need to work for the lifetime of the game.

I do not know a lot about reversing but I was always under the impression that nothing was impenetrable and most schemes were easily defeated. In light of this I am always puzzled by the relative efficacy of punkbuster and related daemons.

Re: An Anti-Reverse Engineering Guide

#47

Post by mfdoom »

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.

Crackme's are written expressly for the purpose of cracking. They are not copyright protected in any way. There is no question legally.

They are a great way to learn techniques, and to help develop more advanced techniques by choosing progressively more difficult crackmes to tackle.

Also a lot of crackmes will contain solutions from other reversers, so even if you fail you can read the walkthrough and learn from others solutions.

Many antivirus companies will rely on your actual knowledge of RE, they will give you some tests and dont soly rely on your resume/experience in the field. They are all well aware how hard it is to find (and keep) good reversers.

Re: An Anti-Reverse Engineering Guide

#48

Post by mfdoom »

jrkelly wrote: post #12
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.

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 have talked about this with a friend of mine a few times. We have attempted to formulate a 'theory of reverse engineering' a few times but so far nothing concrete has come of it.

My personal experience is that RE is as much a mindset as it is a deep well of technical knowledge. Without the crucial knowledge of the axioms of the framework you are reversing, you can often do nothing but guess. Without a strong understanding of the "RE methodology", even with the technical knowledge you stand a good chance of getting sidetracked or bogged in minutia. My personal belief is that although the subjects are different, the methodology is the same. I have no proof to back this up, it is just my belief based on experience.

To answer your first question, the 'best' reverser's are often the silent, faceless crackers/hackers: they hunger for knowledge and are scattered all around the world, in basements, bedrooms and studios.

Many move to anti-virus firms, or DRM/software protection companies. Others are hired by government agencies. Some move into hacking, bug and exploit discovery. A rare few move into academic research, like my friend Mr. Rolles.

Re: An Anti-Reverse Engineering Guide

#49

Post by joezydeco »

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…

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

Re: An Anti-Reverse Engineering Guide

#50

Post by RolfRolles »

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…

Being a reverse engineer who knows what symbolic execution is, is a lonely occupation :( http://www.openrce.org/blog/view/2049/[video]_Semi-Automated...
Post reply on HN