Question: Is the algo custom, or a know algo?

[bmmcwhirt]

I have forked this project and am working on updating the code to current Python 10, 11, 12 standards as well as using Sphinx documentation.

I am curious as to the actual algorithm being used and if it's custom, or a know named algorithm?

I am no cryptanalyst and my math skills are less than they should be. It looks like there is some bit shifting going on and some modules. Possibly crating some obscure XOR?

My end-goal is to try to port OpenRX to the device.

-=[KB9YEN]=-

[cr]

Ohai, it is lovely to see some movement around the project.

The on-disk firmware encryption is like nothing I have seen before, so I'd confidently say it is not related to any standard algorithm. If I had to describe it, I'd call it a linear map with position-based IV, but it is likely something proprietary. The linear property is what it allowed me to break it. It's definitely no streaming cipher and as such there's no xor involved anywhere.

To put an OpenRX image through the official firmware flasher, the challenges ahead will be to implement the flashing protocol (should be relatively easy, see flash_update_protocol.md) and to reverse-engineer the specifics of how the firmware segments are being transferred and then handled by the firmware. The goal would be to implement a flasher that can flash any blob of arbitrary binary data to any memory location.

I haven't looked into any of the latter beyond what's in the md file. I'd start with comparing the data from the decrypted (or encrypted?) firmware segments with what's being transferred on the wire during an update. That's a bit of a project, but perhaps someone else out there has already travelled that road?

[cr]

Are you already familiar with Travis' work?

https://kk4vcz.com/posts/th-d74-firmware/

[bmmcwhirt]

I am. It's what led me to your project. He did an amazing job at detailing how to reverse engineer the code once decrypted. The two of you have done some amazing work and have my thanks.

The fact that the TH-D74 has the AMBE chip, I'm hoping will allow minor modifications to OpenRTX to use that and not implement OpenAMBE or one of the other variants, leaving room for M17.

With the TH-D75 coming, eventually, I'm torn. I don't really want to give Kenwood my money because of their Cartman(South Park) "screw you guys I'm going home" attitude of ripping down every version of the firmware. At the same time I'm tempted to grab one and send your way to see if you can make any progress with the new version. I don't think I have a way to contact bunnie, Andrew Huang, as I'm sure he could dump the firmware from it in no time.

[cr]

I'm happy to take a look at the D75 firmware updater when the first one becomes available. The devices seem very similar, so I don't anticipate bigger changes in the tooling. I won't need a device for the initial investigation of that. Sending a pcap of the firmware update my way would be preferable and work just a s well as sending one of those terribly overpriced radios.

For in-situ extraction of firmware from the hardware, I think you should get in touch with @travisgoodspeed. If he isn't up for it himself at the moment, at least he knows the right people.

[bmmcwhirt]

I will. I ordered some M17 TNC/Modems from Lilygo. Getting M17 on the THD74 is my biggest motivation for putting OpenRTX on the device. I looked at getting a second one, but since someone was able to reverse engineer the firmware encoding the prices have sky-rocketed.

I hope to have the THD74-Tools updated to working in Py10-12 this weekend at which point I will push them into my repo. Once I do I will give you access to look at it and decide if you want me to do a pull request or leave it as a separate fork.

I'm considering adding a console UI to it. When I talk to Travis I'll ask him about also including some of his work to create a de-compiled firmware.

[cr]

I'm wondering which changes you need for py3.10+. I just tested firmware extraction (of 1.10E) and device comm with 3.10 and 3.12, everything seems to run just fine. setup.py was just missing an explicit dependency for setuptools, can't say since when that's required. I just pushed my current local changes, which are mostly cosmetic and will take care of that, but is there anything else that you need in this regard?