georgel wrote on 2023-09-29, 20:19:

Maelgrum wrote on 2023-09-29, 20:14:

Look at my post describing technique. AAttack path is via MPU Uart receiving routine. It has memory write to arbitrary locatio […]
Show full quote

georgel wrote on 2023-09-29, 19:58:

I had some time to reverse DSP 4.13 function FA that writes a byte to any address in MCS51 RAM. I must disappoint you that after the actual write at program address 0B44 MOV @R0,A this function returns to the main loop around program address 053D only via jumps and not using any RET instruction therefore it is not possible to divert program execution by modifying the stack.

Look at my post describing technique.
AAttack path is via MPU Uart receiving routine.
It has memory write to arbitrary location and RET.

Which SB function number is that? Why would it need to write to any location?

No function - it is not a command, routine is polled constantly from main loop by CALL.
Midi UART has buffer (64 or 128 bytes) where incoming MIDI bytes are stored.

Maelgrum wrote on 2023-09-29, 20:24:

georgel wrote on 2023-09-29, 20:19:

Maelgrum wrote on 2023-09-29, 20:14:

Look at my post describing technique.
AAttack path is via MPU Uart receiving routine.
It has memory write to arbitrary location and RET.

Which SB function number is that? Why would it need to write to any location?

No function - it is not a command, routine is polled constantly from main loop by CALL.
Midi UART has buffer (64 or 128 bytes) where incoming MIDI bytes are stored.

Which is the address of that CALL in 4.13? Does it have to be enabled previously by SB functions?

georgel wrote on 2023-09-29, 20:30:

Which is the address of that CALL in 4.13? Does it have to be enabled previously by SB functions?

Main loop code:
X0552: lcall X0c9e

Routine for injection:
X0c7d: mov @r1,a
inc r1
dec r4
cjne r1,#0c0h,X0c85
mov r1,#40h
X0c85: ret

Register R1 can be set via memory write command.

To enable midi processing you shold init MPU-401 properly by issuing RESET and UART MODE MPU-401 commands.

I will examine the UART routine. But at first glance it seems it fills the buffer byte by byte and RETs after each byte. So only high or low byte of the pushed return address can be overwritten.

georgel wrote on 2023-09-29, 22:02:

I will examine the UART routine. But at first glance it seems it fills the buffer byte by byte and RETs after each byte. So only high or low byte of the pushed return address can be overwritten.

Exactly. But it's enough.
High byte can be altered in range 0..5

Maelgrum wrote on 2023-09-29, 22:18:

georgel wrote on 2023-09-29, 22:02:

I will examine the UART routine. But at first glance it seems it fills the buffer byte by byte and RETs after each byte. So only high or low byte of the pushed return address can be overwritten.

Exactly. But it's enough.
High byte can be altered in range 0..5

Why in that range? Which one is high from your point of view -- their location in RAM or their position in the address for jumping? Selecting of only one byte of address is not enough to jump to a precise location anyway.

Maelgrum wrote on 2023-09-27, 14:52:

If you have information about some other method, it is very interesting.

after over 10 years ago, I did not find anything, but I tried to remember and here it is what I remember:

* it was PCIe controller with build-in 8051 controller and ROM that processes HDA commands (that's Intel High-Def Audio), i.e. in case of SB, we can think of those as the DSP commands

* what was the entry point of the attack was that when EEPROM with magic header is attached the ROM reads it and self-modifies the HDA command processing tables with the content of the ROM, i.e. it uses the EEPROM content as patch to the ROM code.

* I supplied ROM that has HDA command that is supposed to read and return one byte, but instead change its code:

1MOV DPTR, <initial ROM address>
2MOV R0, <RAM address to store>
3MOV R7, <numbe of bytes to read>
4
5MYLOOP:
6MOVC A, @A+DPTR
7MOV @R0, A
8INC DPTR
9INC RO
10DJNZ R7, MYLOOP

* then I wrote very small tool that calls the patched HDA command and read from 0 to 8K, i.e. dump the 8K of the ROM.

So, I think it's a lot of what you already have in mind with addition that maybe on SB the entry point is much harder plus maybe protection prevents to use MOVC.

@S95Sedan

I believe you misunderstood me about the "pin-assignment", I meant not in hardware, but in software, i.e. in 8051-ROM, you can have the same ROM version but depending on the PCB layout customize the ROM different pins of the uC to do different job.

georgel wrote on 2023-09-30, 01:44:

Maelgrum wrote on 2023-09-29, 22:18:

georgel wrote on 2023-09-29, 22:02:

I will examine the UART routine. But at first glance it seems it fills the buffer byte by byte and RETs after each byte. So only high or low byte of the pushed return address can be overwritten.

Exactly. But it's enough.
High byte can be altered in range 0..5

Why in that range? Which one is high from your point of view -- their location in RAM or their position in the address for jumping? Selecting of only one byte of address is not enough to jump to a precise location anyway.

We need to jump into middle of interrupt handler.
Handlers is located at 0x0000-0x0500 range.
We don't need precise location, just into middle of handler, so sequence of POPs and RETI will be executed eventually.
High byte - is high byte of return address.

mattw wrote on 2023-09-30, 10:48:

* I supplied ROM that has HDA command that is supposed to read and return one byte, but instead change its code:
* then I wrote very small tool that calls the patched HDA command and read from 0 to 8K, i.e. dump the 8K of the ROM.

So, I think it's a lot of what you already have in mind with addition that maybe on SB the entry point is much harder plus maybe protection prevents to use MOVC.

Thank you, mattw, for describing nice attack on HDA.

On SB, we dont have external code RAM, so can use only fixed code in main ROM as codebase for attack.
And main (WANTED) target is V4.16 fw, embedded in large chip, so only sofware attacks are possible (no external hardware, external code RAM, EA pin control e.t.c). Decapping chip and take a dump from visual image is may be possible, but quite difficult.

Maelgrum wrote on 2023-09-30, 14:12:

Thank you, mattw, for describing nice attack on HDA.

no problem, you're welcomed, if I had luck, I will even find the original source code in some of my old HDDs if someone need it (so far I looked few HDDs without luck).

Maelgrum wrote on 2023-09-30, 14:12:

On SB, we dont have external code RAM, so can use only fixed code in main ROM as codebase for attack.
And main (WANTED) target is V4.16 fw, embedded in large chip, so only sofware attacks are possible (no external hardware, external code RAM, EA pin control e.t.c). Decapping chip and take a dump from visual image is may be possible, but quite difficult.

A lot of constraints - at least on a first glance it doesn't look it would be very simple task. However, I think it's still of interest we be able to make dumps of older ones as well, because as we discussed for example V4.13 from one SB model to another could be not the same as far as pin-assignments are concerned. In fact do you know (or anyone else knows) the dumps available here from what exact model SB were made?

mattw wrote on 2023-09-30, 14:18:

A lot of constraints - at least on a first glance it doesn't look it would be very simple task.

It is not simple task, but it looks possible.

mattw wrote on 2023-09-30, 14:18:

However, I think it's still of interest we be able to make dumps of older ones as well, because as we discussed for example V4.13 from one SB model to another could be not the same as far as pin-assignments are concerned. In fact do you know (or anyone else knows) the dumps available here from what exact model SB were made?

Currently, i am writing PC side software to dump known V4.13, as proof of concept, and to test theory that all V4.13 are same.

CMI8330 reports V4.16, probably they dumped it back then.

Maelgrum wrote on 2023-09-30, 14:26:

Currently, i am writing PC side software to dump known V4.13, as proof of concept, and to test theory that all V4.13 are same.

that's great, I need to dig up the several SB cards I have in my storage. In the meantime I was education myself how 8051/52 dumps are made with decaping the chip:

http://caps0ff.blogspot.com/2019/12/dump-dece … and-lasers.html

very interesting - with laser beam they switch the transistors that are the protection bits and read it with a programmer.

Can someone test this on real sound blaster 16 / AWE ? (SB base must be 0x220 and MPU - 0x330, DSP 4.05-4.16 or 4.13 patched)
It is some preliminary code, to check initialization and dump contents of internal SB RAM. Sources included.
Produces 3 output files.

Here's the output from one of my CT2230s running 4.13 patch3

mattw wrote on 2023-09-30, 10:52:

@S95Sedan

I believe you misunderstood me about the "pin-assignment", I meant not in hardware, but in software, i.e. in 8051-ROM, you can have the same ROM version but depending on the PCB layout customize the ROM different pins of the uC to do different job.

Sure but thats an easy check? Dump both a SB16 and AWE32 and compare the dumps.
Though i dumped mine way back (before it was decrypted) and it came out the same (hex wise) to what was already dumped.

Maelgrum wrote on 2023-09-30, 18:20:

Can someone test this on real sound blaster 16 / AWE ?
It is some preliminary code, to check initialization and dump contents of internal SB RAM. Sources included.
Produces 3 output files.

CT1730, v404
CT2750 v411
CT3900 v413
(All original roms)

maxtherabbit wrote on 2023-09-30, 18:44:

Here's the output from one of my CT2230s running 4.13 patch3

RAM dump looks good, thank you maxtherabbit !

And here is a CT2760 running stock 4.12

Here is a dump from the AWE64 CT4520, DSP v4.16.

Edit: Added LOG.TXT.