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?)
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.
https://en.wikipedia.org/wiki/TRON_project
https://www.osnews.com/story/145872/japan-tried-to-build-an-...
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?
I can't tell if any of this gives you more access than the normal http admin interface.
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.
Well now you can point an LLM at it. I’m not sure that gives you anything either, but I’m not sure the hacker ethos makes that a priority.
Sometimes a hack is just cool because it’s a hack.
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.
The same SET USER 640184.571119 command works on my 2012 Brother MFC-9460CDN.
But what do those numbers mean?
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.
The e-zines can make a comeback, there's probably enough content now. phreak2030s: "put the local load in the bearing firmwares". Or something :)
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?)
[1] https://inventor7777.github.io/brother-mfc-commands-list.htm...