The interesting part to me in there is seeing a TRON kernel in the wild.
In the 80's TRON was Japan's bet for the future of operating systems, but it just lived on as an embedded kernel in cars, printers and other industrial applications.
But what are the things you would want from a printer that is already quite reliable, not DRM'd, and presumably compatible with all the devices you want to use it with?
As far as I can tell, it doesn't. The web interface is like 90s website but it does have a million suboptions. None of these seem like it needed any hacking. I am not sure about the Debug ones. I'll have to check. I wouldn't be surprised if there was an available api listening with the same commands available. If not that would be the useful outcome from work like this. A CLI that implements these.
Now if you could use to allow firmware downgrades when the installed firmware doesn't, that would be useful too. I disabled updates on mine at a version that already allows it. I bought it a few weeks ago but luckily it didn't come with the latest "I don't like your ink chip" firmware.
Great write up and reverse engineering of firmware! I hope to see Epson MFC inkjet printers to have similar discovery too (perhaps it literally a prompt away with a link to this article).
I was digging around an epson receipt printers firmware recently; got as far as discovering http endpoints (hardcoded auth) to remotely enable ssh (but not login), and some other diagnostic access. They seem fairly well put together.
This is a really cool little project. Also, the title gave me a strong hit of like mid 2000's internet "hacking" content that I tore through when I was in high school.
This piece had potential but IMO was a bit disappointing. The entire thing could be summarized as:
1. "I used AI to download and analyze a firmware image, and found a way to unlock DEBUG mode."
2. "I didn't actually explore the DEBUG mode at all, but here are the commands the AI found for me (link)"
I'd love for the author to at least put in a little real effort, explore some of these debug commands, and tell us why they are interesting.
As this is - I find it to be very minimum-effort, AI-assisted blog-slop. Sorry!
(Now for the link[1] to the actual (unexplored) debug-commands... It has really weird casing of the descriptions in the "behaviour"-column. Does anyone know why that is?)
In the 80's TRON was Japan's bet for the future of operating systems, but it just lived on as an embedded kernel in cars, printers and other industrial applications.
https://en.wikipedia.org/wiki/TRON_project
https://www.osnews.com/story/145872/japan-tried-to-build-an-...
Sometimes a hack is just cool because it’s a hack.
Now if you could use to allow firmware downgrades when the installed firmware doesn't, that would be useful too. I disabled updates on mine at a version that already allows it. I bought it a few weeks ago but luckily it didn't come with the latest "I don't like your ink chip" firmware.
1. "I used AI to download and analyze a firmware image, and found a way to unlock DEBUG mode."
2. "I didn't actually explore the DEBUG mode at all, but here are the commands the AI found for me (link)"
I'd love for the author to at least put in a little real effort, explore some of these debug commands, and tell us why they are interesting.
As this is - I find it to be very minimum-effort, AI-assisted blog-slop. Sorry!
(Now for the link[1] to the actual (unexplored) debug-commands... It has really weird casing of the descriptions in the "behaviour"-column. Does anyone know why that is?)
[1] https://inventor7777.github.io/brother-mfc-commands-list.htm...