Reading through this thread is to the technically knowledgeable but non
technically trained very very fascinating to a layman. Just the back and forth
what have we here, I know this I know that what can we try etc.
Very good work gentleman!
Here, i do initialization of MPU, and then read memory dump.
In second byte of dump, we must see 0x40
My test system is ready - I cannot believe everything went so smooth - no problems at all while building it and thus it took no time. So, now I can test for you in literally seconds - one more time 2 different AWE32 cards for testing here - CT3980 and CT3990 both with DSP V4.13 (Intel-made MCU chip on both of them) - in fact between the CT3980 and CT3990 the big change happened in the hardware design when they replace 2 discrete chips with one big that (supposedly) integrates them both. Also, as I posted here:
Tried with my D-SUB Midi cable Loopback disconnected just to convince myself it really talks to the card and the loopback is good, indeed in such case it failed with:
Not uploading MDUMP1.BIN and MDUMP2.BIN, because they are byte by byte identical (and consistent every time from power-on to Dump) with what I already posted here:
Changed attack vector, now dumper only tries to read first 2 bytes, just for testing.
Ok, will try it in a few minutes and will come back with results. Which code in FW responds to MPU ports accesses, how are they fed to/from the DSP?
Code loop starting at 0x0CB1 does all MPU work.
Code uses x-bus registers:
0 - read: command/data port (2xC on PC side) -not used in MPU exchange
1 - read: MPU-401 data register
2 - read: MPU-401 state register
2 - write: MPU-401 data register
Last edited by Maelgrum on 2023-10-01, 12:10. Edited 1 time in total.
Maelgrumwrote on 2023-10-01, 12:01:Code loop starting at 0x0CB1 does all MPU work.
Code uses x-bus registers:
0 - read: command/data port (2xC on PC side)
1 - read […] Show full quote
Changed attack vector, now dumper only tries to read first 2 bytes, just for testing.
Ok, will try it in a few minutes and will come back with results. Which code in FW responds to MPU ports accesses, how are they fed to/from the DSP?
Code loop starting at 0x0CB1 does all MPU work.
Code uses x-bus registers:
0 - read: command/data port (2xC on PC side)
1 - read: MPU-401 data register
2 - read: MPU-401 state register
- write: MPU-401 data register
Does x-bus stand for MCS51 external memory space?
The actual byte is saved at sub_C77 according to my research...
it's the least I can do. What I can do from my side is to install socket, flash new Unprotected MCU and try your idea of Loopback, but using MOVC - that at least will confirm we can patch RAM code in the DSP. Currently with Protected MCU, MOVC is blocked and maybe what fails is how you attemp to patch the memory, but we cannot really confirm that.
Does x-bus stand for MCS51 external memory space?
The actual byte is saved at sub_C77 according to my research...
'x-bus' is interface on '51-52 MCU for accessing external memory.
On SB - this external memory is registers inside Bus Interface and Control chip.
Access is made via MOVX @R0,A and MOVX A,@R0:
mov r0,#16h
mov a,#4
movx @r0,a
This is write to x-register #16 byte with value 0x04
it's the least I can do. What I can do from my side is to install socket, flash new Unprotected MCU and try your idea of Loopback, but using MOVC - that at least will confirm we can patch RAM code in the DSP. Currently with Protected MCU, MOVC is blocked and maybe what fails is how you attemp to patch the memory, but we cannot really confirm that.
There are is no external code memory on SB, so you cannot patch code and execute code.
The only memory present is 256 bytes of internal data memory.
All i do is changing (and preparing) some bytes in and near stack memory to divert execution flow. But code you must use is existing SB ROM code.
So only attack way is changing return adress in stack, direct execution flow to other piece of rom code to do something unintended.
Diverting execution flow into middle of interrupt handler is most promising.
There are is no external code memory on SB, so you cannot patch code and execute code.
The only memory present is 256 bytes of internal data memory.
it's much more complicated than my simple thinking expects. I hope you can figure it out. Now I read the datasheet of Intel N87C52 MCU that is most likely the Intel-made MCU chip on my AWE32 DSP V4.13 cards and the protection bits do a lot:
MOVC instructions executed from external program memory are disabled from fetching code bytes from internal memory, external execution is disabled. Internal data RAM is not accessible
[EDIT] in any case I don't think two V4.13 DSP FWs from two different card models are the same, because MDUMP after Power-ON with your Dumper on my CT3990 is always the same, i.e. the memory is always init to the same state, but it's not the same between CT3990 and CT3980 (no matter the 2 cards has the exact same Intel-made MCU chip) - I don't see why if those two V4.13 DSP FWs are the same they initialize the memory after Power-ON to different state on those 2 different card models, but always to the same state on the same card model.
[EDIT] in any case I don't think two V4.13 DSP FWs from two different card models are the same, because MDUMP after Power-ON with your Dumper on my CT3990 is always the same, i.e. the memory is always init to the same state, but it's not the same between CT3990 and CT3980 (no matter the 2 cards has the exact same Intel-made MCU chip) - I don't see why if those two V4.13 DSP FWs are the same they initialize the memory after Power-ON to different state on those 2 different card models, but always to the same state on the same card model.
In SB fw, there is no memory initialization at Reset vector.
So it can be any value, until written.
2 bytes in memory dump is interesting - at position 0xC1 and 0xC2 - it is return address of some routine, on known 4.13 is must be 0x31 and 0x0B.
If this is valid - then fw is same as previously dumped with high probability.
Maelgrumwrote on 2023-10-01, 13:15:In SB fw, there is no memory initialization at Reset vector.
So it can be any value, until written.
2 bytes in memory dump is in […] Show full quote
[EDIT] in any case I don't think two V4.13 DSP FWs from two different card models are the same, because MDUMP after Power-ON with your Dumper on my CT3990 is always the same, i.e. the memory is always init to the same state, but it's not the same between CT3990 and CT3980 (no matter the 2 cards has the exact same Intel-made MCU chip) - I don't see why if those two V4.13 DSP FWs are the same they initialize the memory after Power-ON to different state on those 2 different card models, but always to the same state on the same card model.
In SB fw, there is no memory initialization at Reset vector.
So it can be any value, until written.
2 bytes in memory dump is interesting - at position 0xC1 and 0xC2 - it is return address of some routine, on known 4.13 is must be 0x31 and 0x0B.
If this is valid - then fw is same as previously dumped with high probability.
What SP are you assuming upon MIDI byte transfer? I will try now the latest attempt of yours.
2 bytes in memory dump is interesting - at position 0xC1 and 0xC2 - it is return address of some routine, on known 4.13 is must be 0x31 and 0x0B.
If this is valid - then fw is same as previously dumped with high probability.
on both CT3990 and CT3980 in my Dumps - it's 0x310B on offset 0xC1. also, now looking more carefully the only difference between CT3990 and CT3980 MDUMP is 0xFF vs 0x00 - I mean it seems not accessed and not written values as you said (like offset 0xC1), on CT3980 for some reason are init to 0xFF and on CT3990 are init to 0x00 - still strange, what could cause memory be init to all 0xFF on CT3990 after power-on and to 0x00 on CT3990, assuming FW code is the same, maybe different MCU chip even both look the same Intel made chip from outside?
2 bytes in memory dump is interesting - at position 0xC1 and 0xC2 - it is return address of some routine, on known 4.13 is must be 0x31 and 0x0B.
If this is valid - then fw is same as previously dumped with high probability.
on both CT3990 and CT3980 in my Dumps - it's 0x310B on offset 0xC1. also, now looking more carefully the only difference between CT3990 and CT3980 MDUMP is 0xFF vs 0x00 - I mean it seems not accessed and not written values as you said (like offset 0xC1), on CT3980 for some reason are init to 0xFF and on CT3990 are init to 0x00 - still strange, what could cause memory be init to all 0xFF on CT3990 after power-on and to 0x00 on CT3990, assuming FW code is the same, maybe different MCU chip even both look the same Intel made chip from outside?
sbdump fills 0x40-0xFF area with 0x00 and 0xFF before dumping, just to clear things up. Without clearing, it can be some meaningless random values.
sbdump fills 0x40-0xFF area with 0x00 and 0xFF before dumping, just to clear things up. Without clearing, it can be some meaningless random values.
I see, then the only difference between MDUMP on CT3990 and CT3980 is memory offset 0x27 - it has value of 0x20 on CT3980 and 0x00 on CT3990 consistently. BTW, tested your latest "penetration test" - got exact same result as @georgel .