5 ms·

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 engi

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.

marshray 15y ago
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).
- pbsd 15y ago
  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.
- DanBC 15y ago
  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".
  - jonl 15y ago
    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.
    - ChuckMcM 15y ago
      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.
      - tptacek 15y ago
        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).
- Gazk 15y ago
  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.
  - jcr 15y ago
    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.
    - dfc 15y ago
      In the 80s/90s where software companies able to develop, test and distribute updates as efficiently as the warez community?
      - jcr 15y ago
        I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.
        dfc 15y ago
        I'm sorry I did not mean to be unfair. I was curious if the companies were able to distribute updates pre-broadband. I can remember downloading the twenty something floppies for os2 over a dialup.

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.

marshray 15y ago

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

pbsd 15y ago
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.
DanBC 15y ago
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".
- jonl 15y ago
  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.
  - ChuckMcM 15y ago
    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.
    - tptacek 15y ago
      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).
Gazk 15y ago
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.
- jcr 15y ago
  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.
  - dfc 15y ago
    In the 80s/90s where software companies able to develop, test and distribute updates as efficiently as the warez community?
    - jcr 15y ago
      I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.
      - dfc 15y ago
        I'm sorry I did not mean to be unfair. I was curious if the companies were able to distribute updates pre-broadband. I can remember downloading the twenty something floppies for os2 over a dialup.