4 ms·

Decompilation is primarily intended to be consumed by humans, I.e. to make the assembly more understandable because it’s written in functions, ifs, and for loop

Decompilation is primarily intended to be consumed by humans, I.e. to make the assembly more understandable because it’s written in functions, ifs, and for loops; it’ll likely not compile at all and if it does not to the original firmware. I don’t believe it’s typically an explicit goal of decompilation to be that high fidelity (ie allow recompilation). It’s probably possible to hack the source to compile to byte-for-byte the same firmware if desired with a little patience. Other than that, you’d be right :-)

pockmarked19 2y ago
Correct, though you can essentially edit the 'decompiled' code directly at low level (then put it back into a binary), and for some languages this is even tolerable e.g. languages which compile to CIL. OP didn't do this, because as they said: "I don’t like writing assembly". Although what they did is arguably harder...which maybe was the point! After all they could've just hooked up an MCU to proxy the button press for a given duration, which would've taken a lot less time.
- NobodyNada 2y ago
  You can edit disassembled code in your decompiler, though I'm not aware of a decompiler that lets you edit decompiled code. And editing a disassembly is tricky because you need to make sure your patch is exactly the same size as the original code, otherwise the addresses won't line up. The usual approach for a non-trivial patch is exactly what the OP did here: put your patch somewhere in free space, and replace the original sequence of instructions with a jump to your patch.
  - poincaredisk 2y ago
    >though I'm not aware of a decompiler that lets you edit decompiled code DnSpy lets you do this (that's why I was careful to prefix decompilers with "native"in my answer). You can edit snippets of decompiled C# code directly inside. But vm based runtimes are much easier to decompile/recompile, and it still may not work in the end. Though programs compiled to intermediate code are in general very different to analyze, so that's kind of nitpicking.
    - Karliss 2y ago
      For C# and Java sure. Those are relatively easy to decompile and the decompilers are quite reliable. With exception of features like generator functions and lambdas most of the languages map 1:1 from source to bytecode, type information is mostly maintained. With C and C++ things are a lot harder.

pockmarked19 2y ago

Correct, though you can essentially edit the 'decompiled' code directly at low level (then put it back into a binary), and for some languages this is even tolerable e.g. languages which compile to CIL. OP didn't do this, because as they said: "I don’t like writing assembly". Although what they did is arguably harder...which maybe was the point! After all they could've just hooked up an MCU to proxy the button press for a given duration, which would've taken a lot less time.

NobodyNada 2y ago
You can edit disassembled code in your decompiler, though I'm not aware of a decompiler that lets you edit decompiled code. And editing a disassembly is tricky because you need to make sure your patch is exactly the same size as the original code, otherwise the addresses won't line up. The usual approach for a non-trivial patch is exactly what the OP did here: put your patch somewhere in free space, and replace the original sequence of instructions with a jump to your patch.
- poincaredisk 2y ago
  >though I'm not aware of a decompiler that lets you edit decompiled code DnSpy lets you do this (that's why I was careful to prefix decompilers with "native"in my answer). You can edit snippets of decompiled C# code directly inside. But vm based runtimes are much easier to decompile/recompile, and it still may not work in the end. Though programs compiled to intermediate code are in general very different to analyze, so that's kind of nitpicking.
  - Karliss 2y ago
    For C# and Java sure. Those are relatively easy to decompile and the decompilers are quite reliable. With exception of features like generator functions and lambdas most of the languages map 1:1 from source to bytecode, type information is mostly maintained. With C and C++ things are a lot harder.