Just a quick update here, I decided to poke around at this again. I'm busy with two other projects at the moment ("Nakoruru" and "Cool Cool Toon"), but would love to work on this on the side.
When
megavolt85 said...
megavolt85 wrote:you only see what the developers of DreamMovie have allowed to see
the real executable file is hidden, the funny thing is that it is writed on the KATANA SDK, and all the WINCE files are for a diversion

...he wasn't kidding! Inspecting
DCVCD.EXE inside of Ghidra yielded nothing of interest, and so far neither has
1ST_READ.BIN. Now, it's clear that
IP.BIN calls
1ST_READ.BIN on boot, so obviously it's part of the chain. However, I started thinking that there might be yet another executable containing instructions used by this application.
That being said, I decided to launch DreamMovie in NullDC, then take a look at the instructions inside the debugger. I took a string of bytes as they appeared in the debugger, then did a global search through of all files on the DreamMovie disc. No matter how many byte-strings I searched, the only file I found a match in (besides
IP.BIN) is
MSL.OUT.
In the screenshot above, we can see address
0x8c04707a holds the 2-byte instruction "12 d4". So, as described above, I did a search of all the game's files for the byte-string
12d4ec34415228222489425338231e8b50e01fa0c604, which I found!
With the above byte-string starting at
0x4087A and seeing it start at
0x8c04707a inside NullDC's debugger, a simple calculation can be performed to determine this executable's base address...
From there, I loaded
MSL.OUT into Ghidra with the calculated base address of
0x8C006800 and confirmed that I was seeing the same instructions at
0x8c04707a that I saw inside NullDC's debugger...
As I started poking around,
all sorts of interesting things were found...
This is just a
VERY VERY early start. I may end up using a logic analyzer and a MAPLE breakout board to see if it can give me any clues as to what parts of the code refence data sent by the IR receiver dongle, though I'm not sure yet. I also found one reference to the MAPLE base address (
0xA05F6C00) inside
MSL.OUT's code, but I haven't had time to trace much further. It's probably just something standard.
I'm a little under the weather today, so hopefully when my mind becomes less foggy, I can take another look at all of this and have a "eureka" moment
