[HN Gopher] Binary modding a water dispenser to save me from pre...
___________________________________________________________________
Binary modding a water dispenser to save me from pressing a button
(2021)
Author : trinix912
Score : 62 points
Date : 2025-01-09 13:47 UTC (2 days ago)
(HTM) web link (practicapp.com)
(TXT) w3m dump (practicapp.com)
| Evidlo wrote:
| When hacking a firmware like this, why can't you just rebuild the
| whole binary after modifying the decompiled source instead of
| patching a specific section of it?
| beng-nl wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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.
| poincaredisk wrote:
| It won't work. Source code from native code decompilers is:
|
| * not designed to be compiled again. It most likely won't
| compile without serious manual fixing. For example, decompilers
| often insert "pseudo-functions" to denote that something not
| easily representable in C is happening. Like CONCAT(var1, var2)
| may mean that both var1 and var2 are used as a single variable
| obtained by concatenating their bits (in practice: AX is used
| when AH and AL were already determined to be variables).
| Similar intrinsics exist for carry bits, jumps to arbitrary
| pointers, etc. This sometimes means that type inference went
| wrong somewhere, which brings us to...
|
| * not perfect, and not designed to be perfect. Decompiler has
| no idea if a variable on stack is a qword or 8 byte array, it
| can only guess from local usage. In many cases array will be
| incorrectly decompiled as a single variable, or pointer
| parameter as an integer. This is not a huge problem when
| reversing, but catastrophic for decompilation. Automated struct
| identification is even harder, often almost impossible when you
| take unions into account. As a reverse engineer you are
| supposed to fix that interactively during analysis.
|
| * decompilers in general don't decompile global data
| definitions - you interpret memory using a separate view. And
| for a good reason - what may look to the decompiler like three
| consecutive independent variables may actually be an
| (unrecognized) structure that must be kept in the same exact
| layout. Defining them as three independent C variables would
| almost surely not work.
|
| * for firmware in particular the binary may be required to
| follow a specific layout or have other unusual characteristics
| (like volatile memory regions). No decompiler will give you a
| correct linker script to use for recompilation.
|
| These problems are just out of the top of my mind. Worth noting
| that a new and upcoming reversing tool called rev.ng actually
| has working recompilation from C as one of their planned
| features, so we'll see what they come up with (and if they
| succeed).
| GranPC wrote:
| > In the end, it took about 8 hours to get this project finished,
| which was spread out over multiple weeks. Considering that I
| usually fill my bottle once a day, and it takes about 50 seconds
| to do so, this will have a positive return-on-investment after
| only about 1.5 years!
|
| Spoken like a true programmer. :)
___________________________________________________________________
(page generated 2025-01-11 23:00 UTC)