Roland DIF-AT: Difference between revisions
| Line 109: | Line 109: | ||
The strings are very interesting indeed. Not just a standard 'version' or 'release date' string - they are command strings! | 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). | 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!]] | [[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]] | ||
===Binwalk / Binvis -=== | ===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 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) | 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) | ||
| Line 232: | Line 232: | ||
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. | 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. | 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 - === | ===High Performance Embedded Workshop -=== | ||
(that's right, I still haven't found Ghidra or Cutter yet) | (that's right, I still haven't found Ghidra or Cutter yet) | ||
<br /> | <br /> | ||