3 ms·

Could also just edit the old binary directly in a pinch?

by Neywiny 9mo ago

bartread 9mo ago
Whilst I disapprove of your use of the word "just", which I am strongly of the opinion should be banned in engineering circles... I have done something similar, albeit in a different context, to fix the behaviour of a poorly performing SQL query embedded in a binary for which the source code was not easily available (as in: it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version and retrofit its changes back to the source - and, yes, this is as bad as you think it is). When I initially suggesting monkey patching the binary there was all manner of screaming and objections from my colleagues but they were eventually forced to concede that it was the pragmatic and sensible thing to do.
- sebazzz 9mo ago
  > it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version When I started at my work, a previous software dev with practices more like a mechanic than a software dev didn't use tags and all binaries deployed to production were always the default version 1.0.0.0 of the C# project templates in Visual Studio. To make matters worse, variants of the software were just copy pasted in CVS with their core code checked in as binaries and not their original C# projects. Fun times finding out what actually ran on production, and patching anything in it!
billforsternz 9mo ago
One of my best rescue jobs involved doing this in 1999, yes that 1999. The client had shuttered their development department years before but was expecting to continue happily supporting and selling their simple enough alarm system products indefinitely. Testing revealed that come 2000 the alarms would just fire continually. Whoops. Fortunately there was one dev PC they'd decided to keep and not touch. Found the offending .c code and the corresponding offending machine code after some disassembly. A little bit of creative assembly language was required to squeeze an extra check in but really no big deal and the day was saved. I remember the client manager being ridiculously happy and grateful.

Could also just edit the old binary directly in a pinch?

by Neywiny 9mo ago

Could also just edit the old binary directly in a pinch?

Whilst I disapprove of your use of the word "just", which I am strongly of the opinion should be banned in engineering circles... I have done something similar, albeit in a different context, to fix the behaviour of a poorly performing SQL query embedded in a binary for which the source code was not easily available (as in: it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version and retrofit its changes back to the source - and, yes, this is as bad as you think it is). When I initially suggesting monkey patching the binary there was all manner of screaming and objections from my colleagues but they were eventually forced to concede that it was the pragmatic and sensible thing to do.

sebazzz 9mo ago
> it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version When I started at my work, a previous software dev with practices more like a mechanic than a software dev didn't use tags and all binaries deployed to production were always the default version 1.0.0.0 of the C# project templates in Visual Studio. To make matters worse, variants of the software were just copy pasted in CVS with their core code checked in as binaries and not their original C# projects. Fun times finding out what actually ran on production, and patching anything in it!

billforsternz 9mo ago

One of my best rescue jobs involved doing this in 1999, yes that 1999. The client had shuttered their development department years before but was expecting to continue happily supporting and selling their simple enough alarm system products indefinitely. Testing revealed that come 2000 the alarms would just fire continually. Whoops. Fortunately there was one dev PC they'd decided to keep and not touch. Found the offending .c code and the corresponding offending machine code after some disassembly. A little bit of creative assembly language was required to squeeze an extra check in but really no big deal and the day was saved. I remember the client manager being ridiculously happy and grateful.