Software-Guides‎ > ‎

Reverse engineering

In this section, I intend to eventually talk about some of the reverse engineering/hacking work I've done. And discuss bit about about my methodology and procedure. As of this writing I've reverse engineered ~20 distinct pieces of software and modified around ~200 different versions of the aforementioned software. These fall into a number of different categories with differing approaches to hacking:
  • x86/x64 ASM on multiple OSs
    • In memory dissassembly, debugging, and code modification (IDAPro, GDB+objdump, PE Explorer).
    • Hex editing for quick persistent modifications during testing (Hex Workshop, HexEdit, HxD).
      • Note: HxD can do modification on in-memory executables with attaching a debugger.
    • Instruction pattern matching for permanent final modifications.
      • This is done using a custom unreleased python based framework I wrote.
    • Additional resigning and forging of binary certs if needed (can be interfaced using my py tools).
    • Anti-hacking measures I've seen employed in software:
      • Binary signing.
      • Checksumming of binaries (or subsections of binaries).
      • Checksumming of in-memory code segments.
      • Comparisons of binary and in-memory code.
      • Rewriting in-memory code on the fly to prevent modifications.
      • Loading and running code from non-code segments.
      • Corrupting program state in the event of detection.
        • This is to cause a program to crash or misbehave.
        • or to save corrupt files, etc.
  • CLR IL bytecode (.net platform)
    • Deobfuscation of assemblies (reflexil, de4dot)
    • Analysis of assemblies (.net reflector, ILSpy)
    • Quick test modifications can be done with reflexil.
    • I've employed class & method matching for permanent final modification of assemblies.
      • This can be done by using Mono.Cecil or dnlib.
        • One interesting note about dnlib is that it can be used to unseal and publicize/virtualize classes and methods. This can be potentially useful if you want to extend or interface with an an existing assembly. 
      • On rare occasion I've used pattern matching but this does not work well given that IL code is highly repetitive.
    • Anti-hacking measures I've seen employed in software:
      • Obfuscation.
      • Binary signing.
      • In short, all methods are entirely ineffective. Do not write in .net if you want to secure your binaries.
  • Java bytecode
    • Analysis of assemblies (similar to .net).
    • Instruction pattern matching for permanent final modifications.
      • This may or may not be effective given that jar files are compressed. 
      • An ideal approach would uncompress the class files, apply modifications, then re-compress the files.
    • The tools are generally lackluster here. I haven't needed to deobfuscate anything so I haven't evaluated any deobfuscators for Java bytecode. 
Comments