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

Initial SP is 0x80 for 4.04 and 4.05, and 0xC0 for 4.11-4.16 […]
Show full quote

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

This is vulnerable. But so far it is difficult to be simulated. There are 5 references to sub_0c77, are you sure the call is from the last one? Where are the entries of the MPU401 init/reset routines?

georgel wrote on 2023-10-01, 14:23:

This is vulnerable. But so far it is difficult to be simulated. There are 5 references to sub_0c77, are you sure the call is from the last one? Where are the entries of the MPU401 init/reset routines?

Just examine code from 0C9E. It is a quite small. All MPU work is done here. MPU loop addr is 0CB1.
MPU init is done by call from main loop:
054f lcall X0c86

I may go ahead and socket the CT2760 today. Going to run 4.13p3 on it and verify NMI functionality.

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

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

maxtherabbit wrote on 2023-10-01, 16:05:

I may go ahead and socket the CT2760 today. Going to run 4.13p3 on it and verify NMI functionality.

do you have the NMI problem with dumped/decrypted 4.13 or only with the patched 4.13?

[answered]

V0.02 - tested on my SB V4.13 - it works.
Process is slow - wait, it prints every 256 dumped bytes a line on screen and saves in dump.bin. few minutes needed per 256 byte block.

Maelgrum wrote on 2023-10-01, 18:49:

V0.02 - tested on my SB V4.13 - it works.
Process is slow - wait, it prints every 256 dumped bytes a line on screen and saves in dump.bin. few minutes needed per 256 byte block.

Good. Here is the DUMP from my vibra 16c. A block in the end differs from the public one.

I'm assuming that there will be no way to provide any fixes to Sound Blaster Vibras, which do not have a separate DSP chip?

My approach seems to be much more faster:

1-o226,1
2-o226,0
3-i22a
4AA
5-o331,ff
6-o331,3f
7-o22c,fa
8-o22c,1
9-o22c,c4
10-o22c,fa
11-o22c,b8
12-o22c,4
13-o22c,fa
14-o22c,b9
15-o22c,12
16-o22c,fa
17-o22c,bb
18-o22c,0
19-o22c,fa
20-o22c,bc
21-o22c,0
22-o22c,fa
23-o22c,bd
24-o22c,5f
25-o22c,fa
26-o22c,be
27-o22c,0
28-o330,04
29-
30-i 22a
3102
32-i 22a
3304
34-i 22a
3585
36-i 22a
3702
38-i 22a
3900
40

georgel wrote on 2023-10-01, 19:49:

My approach seems to be much more faster:

You used Get copyright string command. Yes, it's much faster, but requires more complex processing in code.

My goal was to proof concept of this attack scheme.
Code is slow, but it works))

Maelgrum wrote on 2023-10-01, 20:05:

You used Get copyright string command. Yes, it's much faster, but requires more complex processing in code. […]
Show full quote

georgel wrote on 2023-10-01, 19:49:

My approach seems to be much more faster:

You used Get copyright string command. Yes, it's much faster, but requires more complex processing in code.

My goal was to proof concept of this attack scheme.
Code is slow, but it works))

Yes, my code uses function E3 and has to be restarted only when zero byte is encountered in firmware. Feel free to use it in your dumper. I guess E3 will be much more easier to find in unknown firmware 😉 Actually it is much simpler to use -- one just have to change two bytes to reflect the starting address of dumping 😉 and fire it once again after previous zero byte address.

Maelgrum wrote on 2023-10-01, 18:49:

V0.02 - tested on my SB V4.13 - it works.
Process is slow - wait, it prints every 256 dumped bytes a line on screen and saves in dump.bin. few minutes needed per 256 byte block.

Fist of all - I want to give a big shout-out to @Maelgrum - thank you for your work on this!

Second of all - it took almost 30 minutes, but the Dump of V4.13 from my CT3990 is now ready and it's exactly the same, i.e. byte-by-byte identical, to the previous public release that was made in hardware. So, 100% the proof-of-concept is now proven. In 30-40 minutes, I will be able to tell about CT3980 as well - if it's the same or not.

Kahenraz wrote on 2023-10-01, 19:44:

I'm assuming that there will be no way to provide any fixes to Sound Blaster Vibras, which do not have a separate DSP chip?

Exactly, no way.

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

Yes, my code uses function E3 and has to be restarted only when zero byte is encountered in firmware. Feel free to use it in your dumper. I guess E3 will be much more easier to find in unknown firmware 😉 Actually it is much simpler to use -- one just have to change two bytes to reflect the starting address of dumping 😉 and fire it once again after previous zero byte address.

And dump no more then 256 bytes per attack run.
I already knew about this output variant, it was just not needed yet.
But next version can be with this update))

mattw wrote on 2023-10-01, 20:11:

Maelgrum wrote on 2023-10-01, 18:49:

V0.02 - tested on my SB V4.13 - it works.
Process is slow - wait, it prints every 256 dumped bytes a line on screen and saves in dump.bin. few minutes needed per 256 byte block.

Fist of all - I want to give a big shout-out to @Maelgrum - thank you for your work on this!

Thanks mattw! It took some time, but finally it's done. I am happy))
And this attack scheme opens a way to crack 4.16, most interesting task.
Big thanks to you all, for testing my various attempts.
PS. Problem in previous dumper was not in attack scheme, but in buggy MPU realization on SB. It just fails to initialize second time, after SB reset.

Maelgrum wrote on 2023-10-01, 20:25:

And dump no more then 256 bytes per attack run. I already knew about this output variant, it was just not needed yet. But next […]
Show full quote

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

Yes, my code uses function E3 and has to be restarted only when zero byte is encountered in firmware. Feel free to use it in your dumper. I guess E3 will be much more easier to find in unknown firmware 😉 Actually it is much simpler to use -- one just have to change two bytes to reflect the starting address of dumping 😉 and fire it once again after previous zero byte address.

And dump no more then 256 bytes per attack run.
I already knew about this output variant, it was just not needed yet.
But next version can be with this update))

Well, 256 times less number of "attacks" as you call them than your current solution. The attack is only one to me - to get the firmware. But zero bytes appear more frequently in programming code so the 256 byte limit is hardly reachable. Looking forward to 4.16 firmware dumping. What was the bug with the firmware that prevented init after hard reset with your code? My code restarts properly. When you stress on Creative's bugs remember that this exploit is 100% based on other pioneers of dumping that had no access to firmware image at all. You would have done nothing without access to actual firmware.

georgel wrote on 2023-10-01, 20:39:

Maelgrum wrote on 2023-10-01, 20:25:

And dump no more then 256 bytes per attack run. I already knew about this output variant, it was just not needed yet. But next […]
Show full quote

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

Yes, my code uses function E3 and has to be restarted only when zero byte is encountered in firmware. Feel free to use it in your dumper. I guess E3 will be much more easier to find in unknown firmware 😉 Actually it is much simpler to use -- one just have to change two bytes to reflect the starting address of dumping 😉 and fire it once again after previous zero byte address.

And dump no more then 256 bytes per attack run.
I already knew about this output variant, it was just not needed yet.
But next version can be with this update))

Well, 256 times less number of "attacks" as you call them than your current solution. The attack is only one to me - to get the firmware. But zero bytes appear more frequently in programming code so the 256 byte limit is hardly reachable. Looking forward to 4.16 firmware dumping. What was the bug with the firmware that prevented init after hard reset with your code?

I got 2 bytes per run)) so get copyright string can be 128 times faster at most.

Problem was:
Reset
FF to MPU
FE from MPU
3F to MPU
FE from MPU
All ok so far, but later:
Reset
FF to MPU
No answer

I finished making dump on CT3980 and now it's confirmed:

CT3980 DSP V4.13 is IDentical to CT3990 DSP V4.13 is IDentical to the old public release posted here:

Re: The Soundblaster DSP project

Maelgrum wrote on 2023-10-01, 20:45:

I got 2 bytes per run)) so get copyright string can be 128 times faster at most. […]
Show full quote

georgel wrote on 2023-10-01, 20:39:

Maelgrum wrote on 2023-10-01, 20:25:

And dump no more then 256 bytes per attack run.
I already knew about this output variant, it was just not needed yet.
But next version can be with this update))

Well, 256 times less number of "attacks" as you call them than your current solution. The attack is only one to me - to get the firmware. But zero bytes appear more frequently in programming code so the 256 byte limit is hardly reachable. Looking forward to 4.16 firmware dumping. What was the bug with the firmware that prevented init after hard reset with your code?

I got 2 bytes per run)) so get copyright string can be 128 times faster at most.

Problem was:
Reset
FF to MPU
FE from MPU
3F to MPU
FE from MPU
All ok so far, but later:
Reset
FF to MPU
No answer

First you should read 22a to unlock the main loop.