Does this tool exist?

[ewx]

I recently found myself binary-editing a shared library to NOP out some code in order to test a theory about the cause of a crash. In this case I had the source available but this was a quicker approach than rebuilding; in other cases I might not have the source.

What I actually did was read a disassembly, figure out what addresses I needed to change, and then use tweak to edit it.

The ideal tool for the job, though, would have been one that displayed the disassembly and let me drag out a region and replace with it a new sequence of instructions, with an error if they were too long and NOP-filling if they were short, and with warnings if I was disrupting a branch target. You can probably imagine other nice features.

Anyway, does anyone know if such a tool exists?

I think I’ve spent more time reading and writing assembler in the last year than the entire preceding decade. Funny how things turn out.

Comments

[gerald_duck]

Does objdump produce output of sufficient quality to reproduce its input with byte-for-byte accuracy if fed back to the assembler and linker?

If so, augmenting the assembler with an "assemble XYZ instead of ABC, faulting or padding on size mismatches" directive would suffice, and might be a reasonably tidy solution?

[ewx.livejournal.com]

If it doesn’t then that’s arguably a bug in objdump - at least, assuming that assembler->bytes is unambiguous, which I’m not 100% confident is true.

[simont]

On x86, it certainly isn't true; there are many instructions with redundant encodings. (Most notably in cases such as the two general encoding schemas for 'mov register-or-memory, register' and 'mov register, register-or-memory'; a simple 'mov register, register' can be encoded using either.)

One DOS assembler (A86) actually used the redundant encodings to embed a watermark in its output, so that the author could identify and sue people who'd used his assembler without paying the shareware fee.

It's news to me that objdump even produces an output format suitable for feeding back to gas (though it's an obviously useful usage mode). I've only ever used it in the mode which dumps human-readable but not reassemblable output, with annotations and the hex bytes and an address column etc.

[ewx.livejournal.com]

I was assuming that Clive was imagining a bit of processing between the objdump output and the assembler and linker - i.e. that he was talking about the information represented rather than the raw output.

[gerald_duck]

Personally, I'm more doubtful that the linker could be coaxed into giving byte-for-byte reconstitution of the original.

I thought the disassembler had a mode for producing gas-compatible output, but I can't currently find it.

There is, as you note, also the problem of alternate representations of the same instruction.

Despite all of that, it feels as though this is the right general approach, were one implementing such a tool. Augment the disassembler and assembler to allow unambiguous specification of representation; make sure the linker can put things back exactly as they were; provide an "assemble XYZ instead of ABC" assembler directive; make objdump able to spit out a directory full of .s files, plus a linker map, plus a makefile. Easy peasy!

[simont]

For that specialist definition of "easy peasy" which means "just rewrite half your toolchain, with major structural upheaval in several places because the required changes inexplicably turn out not to be trivial ten-line fixes on top of the existing architecture"...

The thing is that a toolchain optimised for doing this sort of thing is fundamentally very different from one designed for building software from source. The latter has to do all that mucking about with symbols and relocations, for instance, whereas the former has a fundamental requirement not to mess with anything on which symbols and relocations depend. To have the same linker be on the one hand capable of laying out an image optimally, and on the other hand capable of laying out an image exactly the same way as the image from which the source was disassembled, just puts stresses on the code that it would do better without.

I think a more specialist tool does make more sense. Don't go through an object file format at all, because there's no advantage to be gained from including one. Just disassemble the image to a single big text file with an explicit address on every instruction (probably not dissimilar to the current 'objdump -d' output). Then the user deletes a few lines in that and replaces them with assembly code of their choice, sans explicit addresses. Now all you need is a customised assembler which outputs an image instead of object format (which is actually easier since the format is typically simpler), and which enforces that all the fixed addresses still present in the disassembly must still be correct during reassembly (padding or giving an error if not).

[gerald_duck]

I don't always explicitly flag sarcasm. :-p

[gerald_duck]

The trouble, however, with doing it the direct way is that the moment such a tool existed people would start asking for new features and most would be pretty hard to accommodate.

The most obvious feature would be adding new code, whether inline or out of line with a trampoline. The moment you want to enlarge an area, the linker must be involved, to sort out all the addresses.

[simont]

But how can you sort out all the addresses, when your image has already lost the metadata that says which other parts of the image need to be updated when you change the location of something? I don't think there's anywhere you can insert out-of-line code with a trampoline, unless you can contrive to find space for it completely outside the existing code and data segments. And that's still not really a job for a full-scale linker.

The nice thing about (hypothetically) doing this in free software is that if people have unreasonable feature requests you just send them back an explanation of the five mutually contradictory acceptance criteria you would apply to any patch purporting to implement the feature, and then they are never heard from again. In the commercial world customers would try to get round your protestations of logical impossibility by saying "surely it will suddenly turn out not to be logically impossible after all if we threaten to take our $100m business elsewhere if you don't do it", which is a pain all round.