Tuesday, April 8, 2014

Prevent reverse engineering of DLLs

Problem

What are the best practices to prevent reverse engineering of DLLs?

Solution

Why do people want to reverse engineer a DLL?
  1. Hacking/Cracking/Cheating - This is pretty easy actually. You just need to defeat the multiple anti circumvention measures. Without getting caught. The penalties for getting caught are high. DMCA violations, getting CD KEY banned from game, lawsuits... Any good debugger will do. Wikipedia has a good article on Windows debuggers. Some are free, some are not. Be sure to enable all anti circumvention measures and hack with your network disabled.
  2. Professional research - If you work for anti-virus company, you may be researching on some virus, and its needed then
  3. Beginners learning - For the craze of learning
  4. Competitor knowledge - Your competitor and your competition have done something, that you have not or you have done differently.
  5. Legacy DLL - Understanding working of legacy dll's where documentation is not available

Antivirus authors likely have automated the Windows API (which could take years) to look for stuff that is common in malicious code. Tools that are under $100 are usually not very automated, so you'll use your brain alot.
There are lots of free tools to do so...
How to prevent reverse engineering of DLLs?
Best practices include the following:
  • Use obfuscators. As per wikipedia, obfuscation is the deliberate act of creating obfuscated code, i.e. source or machine code that is difficult for humans to understand.
  • Do not store any data (string, etc) in open form. Always compress or encode it.
  • Use a static link so there is no DLL to attack.
  • Strip all symbols.
  • Use a .DEF file and an import library to have anonymous exports known only by their export ids.
  • Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
  • Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
  • Use anti-debugging techniques borrowed from the malware world to prevent reverse
    engineering (Note that this will likely get you false positives from AV tools).
  • Use protectors.

Reference

0 comments:

Post a Comment