Changes

Jump to navigation Jump to search
932 bytes added ,  Yesterday at 21:22
m
I damaged a lot of traces on the device and gave up on it. However, I learned how to micro-solder and became inspired to continue the repair with reverse engineering techniques. This is my first reverse engineering project, though I have worked on modding and repairing before.
Given the device was already non-responsive (and now damagedfurther) -
===Goals-===
<br />
#De-solder NOR Flash and read firmware.
#Determine and examine / analyse hardware architecture.
#Repair traces, replace ICs. Test.
#Collate information, share research and findings.<br />
===PCB Photos -===
=== Strings - ===Alright we've heard enough about them ; here is the list - '''''strings -n 6 INTEL_HEX_DIF_AT_LH28F400BVE@TSOP48_byte_swapped.bin'''''
{| class="wikitable sortable"
|+
I removed all the strings returned which are over n6 but not really strings - and - There are also two blank strings which the above table has optimised away. These seem to have a function, unclear at present.
You can see how, it does look like corruption in some of the strings, - gaps in the text.  The **Roland xx looks like a boot banner and is called differently in the firmware. I'm sure that's why it has different start and stop markers. Ditto for the early Version string. Interestingly, the early Version is way at the other end of the addresses in the code. This adds to the DFU / Bank swap theory.  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 />[[File:HEW.png|thumb|High Performance Embedded Workshop]]I downloaded HEW from Renesas, which still keeps this available online. Superannuated Software, total 1998 vibes. I love that look though! I managed to load the firmware into it, and yes, it appears to be recognised and loads in just fine. This is a big step, its the first time I'm looking at the disassembly, and it seems like its not badly corrupted (it loads it in) I enter the RAM addresses and sizes and mess about with it for a bit. . .  Ultimately, its not great for RE. It was probably good at the time for developing for the H8, but it's pretty hard to use for RE. I give it up. There was actually some DOS software that I had a crack at too which apparently loaded H8 firmware but I never got it to open the file. 
The **Roland xx is a boot banner and is called differently in the firmware, I'm sure that's why it has different start and stop markers. Ditto for the early Version string. Interestingly, the early Version is way at the other end of the addresses in the code, which adds to the DFU / Bank swap theory.
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, indirect. 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.
83

edits

Navigation menu