83
edits
Changes
Jump to navigation
Jump to search
m
→Binwalk / Binvis -
The strings are very interesting indeed. Not just a standard 'version' or 'release date' string - they are command strings!
As this device has no screen, a low level diagnostic routine is inferred from their discovery. Looking closely at the last string or two, I was worried that it might be corrupted as there are some missing letters in the string - (ADAT Sync port di onnected and Dectected rather than Detected).
[[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]]
===Binwalk / Binvis -===
I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it. First I used [https://github.com/ReFirmLabs/binwalk Binwalk], which I think is more suited to SOC work. Anyway Binwalk was able to provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption (or possibly I'm defining that the incorrect way around)
When I finally load the firmware (I still haven't at this point) I spend ages looking for what calls these strings. It is very difficult to navigate the firmware. Basically zero xrefs. One or two strings can be discovered, which have a different call system to the diagnostic strings (the ones I'm most interested in) especially because I have to repair so many subsystems.
I don't know at this point that these diagnostic strings are highly likely to be called by the Monitor Version 1.00, which is highly likely a Machine Language diagnostic tool which must operate over UART.
=== High Performance Embedded Workshop - ===
(that's right, I still haven't found Ghidra or Cutter yet)
<br />
