I love reading about these types of firmware "bugs" fixed by AI in a few minutes with the correct context. I recently patched my LG monitor that had a blinking white LED in standby. Why any designer thinks why yes lets blink this 1 second on 2 seconds off when I go to sleep is deranged.
Well now I can sleep easily because of the same style of patch. I also hit the version refusal but found that you just lie to the upgrade tooling that it's newer and then the version number doesn't change after flashing.
This is a golden age of finally being able to fix all the niggling little bugs in these bits of hardware. So many of them are wide open, the friction of trying to figure out how to get the firmware cracked open, creating a build environment etc was just too huge before. I wonder how long before all these manufacturers start signing and encrypting their updates to stop us fixing their shit?
I did this the old fashioned way on an Acer monitor a while back, eliminating the 10-second logo when turning it on. I ended up dumping the ROM (8051 CPU), writing a disassembler and mapping out enough of the code to patch it, and threw in a strobed backlight mode since I had already decoded other things. It helped that the processor allowed register writes over the DDC channel on VGA, allowing easy testing of the changes before writing any code. I did have to short a jumper inside when flashing the modified code (over DDC). I'd never attempt such a project again due to how long it took, but with AI it would be far more reasonable.
Eh, I learn a ton from just watching Claude tear a piece of code to pieces and working through all the problems and debugging with it. Sure, I could do it myself the long way (beast mode?), but I don't have time to spend an entire day figuring out how to remove the annoying boot logo and delay from a monitor. If I can get Claude to work as my partner and get it done in 15 minutes, then it gets done now, where it didn't before.
Even something like setting up a dev environment for a random embedded processor that I will never once use again in my life. It's easier to get Claude to track down all the files and figure out how to install them and get them running. All these things are just force-multipliers.
Blog author here. That's pretty similar to my thinking on it all now too.
I'm not just lazily telling Claude to find everything for me and then sitting back and relaxing. My brain is still doing work, it's just different work than it was before. Coming up with a good prompt takes effort and good communication skills. I'm still watching what the LLM does and redirecting it if it's going off into the weeds. On larger tasks (not really relevant to this reverse engineering project, admittedly) I'm still making design and architectural decisions.
I've done plenty of these kinds of huge multi-month reverse engineering projects in the past by hand (just see my past blog posts). I have no doubt I could have found this bug myself if I spent enough time digging into it. A majority of the work would have been boilerplate tedious stuff in Ghidra that I already know how to do, and it would have been incredibly boring. I'm enjoying being able to tick off some of these project ideas from my (neverending) list and having some fun while doing it. Also, the older I get, the more painful and tiring it is to stare at the screen for hours and hours.
I completely respect that this approach isn't for everyone though!
hit the version refusal but found that you just lie to the upgrade tooling that it's newer and then the version number doesn't change after flashing.
good for right to repair but man is this not a major vulnerability? we need to start going after tech companies not employing best practices like mutation testing esp with how easy those tests are to write now
Since the monitor I was working on was CRC32ed I could have patched the version numbers forward. For all intents the monitor thought it was upgraded a minor version. It just uses a CONST for the actual version number within the build that I didn't change. It read the version from the zip file name which seemed less smart all things considered.
Damn. I have really enjoyed reading Doug Brown's past reverse-engineering and repair work (e.g., Chumby resuscitation). Shame to see another one fall to brain offloading.
I love reading about these types of firmware "bugs" fixed by AI in a few minutes with the correct context. I recently patched my LG monitor that had a blinking white LED in standby. Why any designer thinks why yes lets blink this 1 second on 2 seconds off when I go to sleep is deranged.
Well now I can sleep easily because of the same style of patch. I also hit the version refusal but found that you just lie to the upgrade tooling that it's newer and then the version number doesn't change after flashing.
This is a golden age of finally being able to fix all the niggling little bugs in these bits of hardware. So many of them are wide open, the friction of trying to figure out how to get the firmware cracked open, creating a build environment etc was just too huge before. I wonder how long before all these manufacturers start signing and encrypting their updates to stop us fixing their shit?
I did this the old fashioned way on an Acer monitor a while back, eliminating the 10-second logo when turning it on. I ended up dumping the ROM (8051 CPU), writing a disassembler and mapping out enough of the code to patch it, and threw in a strobed backlight mode since I had already decoded other things. It helped that the processor allowed register writes over the DDC channel on VGA, allowing easy testing of the changes before writing any code. I did have to short a jumper inside when flashing the modified code (over DDC). I'd never attempt such a project again due to how long it took, but with AI it would be far more reasonable.
And... you learned along the way, unlike the "i outsourced my braining to claude" crowd
Eh, I learn a ton from just watching Claude tear a piece of code to pieces and working through all the problems and debugging with it. Sure, I could do it myself the long way (beast mode?), but I don't have time to spend an entire day figuring out how to remove the annoying boot logo and delay from a monitor. If I can get Claude to work as my partner and get it done in 15 minutes, then it gets done now, where it didn't before.
Even something like setting up a dev environment for a random embedded processor that I will never once use again in my life. It's easier to get Claude to track down all the files and figure out how to install them and get them running. All these things are just force-multipliers.
Blog author here. That's pretty similar to my thinking on it all now too.
I'm not just lazily telling Claude to find everything for me and then sitting back and relaxing. My brain is still doing work, it's just different work than it was before. Coming up with a good prompt takes effort and good communication skills. I'm still watching what the LLM does and redirecting it if it's going off into the weeds. On larger tasks (not really relevant to this reverse engineering project, admittedly) I'm still making design and architectural decisions.
I've done plenty of these kinds of huge multi-month reverse engineering projects in the past by hand (just see my past blog posts). I have no doubt I could have found this bug myself if I spent enough time digging into it. A majority of the work would have been boilerplate tedious stuff in Ghidra that I already know how to do, and it would have been incredibly boring. I'm enjoying being able to tick off some of these project ideas from my (neverending) list and having some fun while doing it. Also, the older I get, the more painful and tiring it is to stare at the screen for hours and hours.
I completely respect that this approach isn't for everyone though!
good for right to repair but man is this not a major vulnerability? we need to start going after tech companies not employing best practices like mutation testing esp with how easy those tests are to write now
Since the monitor I was working on was CRC32ed I could have patched the version numbers forward. For all intents the monitor thought it was upgraded a minor version. It just uses a CONST for the actual version number within the build that I didn't change. It read the version from the zip file name which seemed less smart all things considered.
This is surprisingly good. One of common question when RE is: How do we even read/write firmware.
Damn. I have really enjoyed reading Doug Brown's past reverse-engineering and repair work (e.g., Chumby resuscitation). Shame to see another one fall to brain offloading.