Live data from Hacker News

An Anti-Reverse Engineering Guide

codeproject.com

1–10 of 59 posts

Re: An Anti-Reverse Engineering Guide

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

Re: An Anti-Reverse Engineering Guide

#5

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.

Re: An Anti-Reverse Engineering Guide

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

Re: An Anti-Reverse Engineering Guide

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

Re: An Anti-Reverse Engineering Guide

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

This has a lot to do with the time the article was written. 2008 was a time where ring0 had gone out of fashion (SoftIce dead, nothing usable to replace it), and virtual machines weren't quite that common yet for debugging.

Today you'll find lots of anti-VM tricks, and if you go a few more years back, lots of ring0/SoftIce tricks.

That said, they are what they are, tricks. Good protections can't simply rely on tricks, which simply temporarily inconvenience whoever is not aware of them.

Re: An Anti-Reverse Engineering Guide

#10
post #7
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 certainly did my lowest level stuff (building PC ISA hardware from scratch) in high school. Mainly it was out of necessity as I didn't have the money for the real hardware. Other folks I've known who have gotten into ASM in high school did so for game cracking/cheating/modding, also a form of necessity.

Any* sane professional development organization is going to try to minimize the amount of time their developers spend writing ASM by hand. There's almost always a higher level tool that's more productive.

* Actually, I worked at a place where the main DOS product had been hand written entirely in x86 ASM. The sanity of continuing such a practice into the 90's is an open question. Rumor had it that even the Windows versions of Wordperfect were written in ASM.

Post reply on HN