Hacker News Reader

Comment by joshuamcginnis | Hacker News Reader

I mean even more high level than this. If I open a binary, can I just write the new machine code to it directly and not be concerned with recompiling?

View on HN

As long as all the instructions are the same size (or smaller padded with no-operation instructions) then yes. If, however, you do change the size of the application all relocation deltas need to be changed, and all relative jumps and calls need to be recalculated.

There are sometimes tricks that get you around this problem, too: you can sometimes patch in a trampoline, which gives you some flexibility in the instructions you get to use.

An alternate direction rather than your standard jmp/displacement/nop'ing-to-align would be to use Dyninst[1] and live patch in memory[2]. Really though, your standard hex-editor will have facilities to alter all the necessary relatives. If you have access to modify the binary, no need to put in a trampoline (though it's awfully handy when playing CTFs!)

Honestly, do we really need another static analysis tool? Hopper and radare2 have covered the open source gap fairly well. I'd put r2 on near-power-parity of IDA if you invest the time to learn and configure it, which admittedly is an expensive proposition in labor who already knows IDA. It'll take him more days in salary to learn a new platform than just to pay the 5k and get him a IDA/HexRays license.

[1] U of Maryland holds the patent; information here, https://www.google.co.uk/patents/US8510723 [2] https://www.cs.umd.edu/class/fall2005/cmsc714/Lectures/byrd-... Though, I'm sure you've seen it already

>Honestly, do we really need another static analysis tool?

Definitely. IDA Pro is proprietary software and the possibilities of IDAPython are limited. IDA Pro mostly ignores the last two decades of research done in the field of binary program analysis. It still relies on pattern matching compilers instead of using semantics driven methods that have been around for >10ys. While there exist tools like BAP, BitBlaze, Jackstab and Bindead. They are not really usable for people w/o graduate student level understanding of program analysis. This is where Panopticon fits in.

IDA's licensing is also onerous.

i was trying to edit one byte in an ELF, no change in file size and it kept crashing. i read that each section of code is hashed and obviously my byte edit changed the hash. i was pretty out of my depth tbh.

Sometimes code will add additional checks such as hashes to verify that parts of the text section haven't been modified. Should be able to remove those checks, too. Just have to track them all down.

To detect hashes like that, use a debugger that supports memory break points and set a read breakpoint on the instruction you changed. It usually makes it a lot easier to identify where the checksum is calculated.

Yes you can. An executable (using ELFs as an example, most formats are similar) is nothing more than some headers and bytes. The executable code can be modified in any way you please, as long as you're writing valid opcodes (the program will crash if it hits a bad opcode).

That said, it's usually much more complicated to change the size of the executable section (this requires modifying the headers and this tends to be a rather involved process), so usually if people are doing binary patches they are only modifying bytes, not adding or removing them.

Usually. Just make sure the new machine code is the same size as the old.

That said, if the code is signed and there's a signature check - the check will fail if you modify the code.

If the signature is a simple crc/checksum, you could also update the checksum. If it's a cryptographic signature, it might be a lot more difficult.

Or, you also have to modify the check code.

Huh? Isn't that what he said - or did I miss something? How is your check code related comment different from his checksum related statement?

The code that checks the signature. If you can identify all the places that checks the signature and disable that code, then it no longer matters if you are unable to correctly update the signature itself.

I was talking about changing the signature/checksum to match the new code. Corecoder pointed out that sometimes you just need to patch the checksum checking code, and not the checksum itself.

Yes, there's no recompiling that can be done anyway if you only have the binary and no source code. Writing the new machine code would overwrite some code at the start of the function you're modifying, but that doesn't matter if you just want the function to return true or false.

You could edit the binary manually with a hex editor, but some disassemblers like Hopper have a feature where you can type new instructions in assembly and it will assemble and insert them for you. I'm sure IDA pro has something like that as well.

IDA Pro as of 6.9 wasn't designed to act as a hex editor as such it's not the "ideal" but there are tons of scripts[1] that people use[2] to craft it into whatever you want. Likewise, it wasn't really a dynamic analysis tool but the healthy ecosystem kes it feel sorta-kinda powerful with the proper tooling + WinDBG. I'm using a fairly old setup (old dog, new tricks and all that - I stuck with SoftICE as long as I could) so there are likely better solutions out there.

[1] https://github.com/iphelix/ida-patcher/blob/master/idapatche... is what I have in my scripts dir, but I'm sure there are dozens of others out there. That specific Python script has the added benefit of being really approachable for the average user. Check Woodmann or Github or wherever people post their scripts these days if it doesn't meet your needs. [2] IDA's basically turned into emacs, where the real power comes from all of the tooling you can conf into it. A stock 6.9 + HexRays license is worth it just for the free tooling you can find.

Yes, use a hex editor. Not a whole lot different from a gameshark, really.

Reply on news.ycombinator.com