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!

Maelgrum wrote on 2023-09-30, 19:19:

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:

Re: The Soundblaster DSP project

I have stock D-SUB MIDI cable for the Loopback - presumably original Creative one as it was in one of those AWE32 original box.

So, I use the Dumper from this post and made dumps - see the attachment (the file-names are self-explanatory which one from which card is dumped) :

1SB Reset: done
2DSP version: 4.13
3MPU-401 init: done
4Internal memory dump: done
5Success!

maybe interesting, but not only 2nd, but 3rd byte as well is always 0x40. Anyway, when you want something else tested - just let me know.

Changed attack vector, now dumper only tries to read first 2 bytes, just for testing.

Maelgrum wrote on 2023-10-01, 11:35:

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?

Maelgrum wrote on 2023-10-01, 11:35:

Changed attack vector, now dumper only tries to read first 2 bytes, just for testing.

on CT3990 it failed as follows:

1SB Reset: done
2DSP version: 4.13
3MPU-401 init: done
4Internal memory dump: done
5MPU-401 loopback check: done
6Attack started
7ERROR: Dump failed

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:

1SB Reset: done
2DSP version: 4.13
3MPU-401 init: done
4Internal memory dump: done
5MPU-401 loopback check: failed!
6ERROR: Midi loopback not present

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:

Re: The Soundblaster DSP project

Here is the similar result on my SB.

georgel wrote on 2023-10-01, 11:54:

Maelgrum wrote on 2023-10-01, 11:35:

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

Thanks for testing, mattw and georgel !
Seems that i need to debug it myself on real SB.

Maelgrum wrote 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

georgel wrote on 2023-10-01, 11:54:

Maelgrum wrote on 2023-10-01, 11:35:

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...

Maelgrum wrote on 2023-10-01, 12:07:

Thanks for testing, mattw and georgel !

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.

georgel wrote on 2023-10-01, 12:11:

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

mattw wrote on 2023-10-01, 12:27:

Maelgrum wrote on 2023-10-01, 12:07:

Thanks for testing, mattw and georgel !

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.

Maelgrum wrote on 2023-10-01, 12:34:

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.

Another try - this is only a penetration test, tries to write 0xEE byte to memory location 0x88.

mattw wrote on 2023-10-01, 12:43:

[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.

Maelgrum wrote 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

mattw wrote on 2023-10-01, 12:43:

[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.

Maelgrum wrote on 2023-10-01, 13:15:

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?

georgel wrote on 2023-10-01, 13:34:

What SP are you assuming upon MIDI byte transfer? I will try now the latest attempt of yours.

Initial SP is 0x80 for 4.04 and 4.05, and 0xC0 for 4.11-4.16

So after first call:
0552 LCALL 0c9E

stack will be:
C2 - 05 <-- SP
C1 - 55
C0 - xx

After second call
0CFD LCALL 0c77
0d00 CLR RI

stack will be:
C4 - 0D <-- SP
C3 - 00
C2 - 05
C1 - 55
C0 - xx

mattw wrote on 2023-10-01, 13:44:

Maelgrum wrote on 2023-10-01, 13:15:

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.

Maelgrum wrote on 2023-10-01, 13:51:

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 .