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