S95Sedan wrote on 2023-10-01, 22:24:

Not at a pc right now but will have a look at the 4.12 signetics and 4.13 chip i have later.

Sbdump works only with known 4.13 !
4.12 must be brutforced someday, I hope))

Maelgrum wrote on 2023-10-01, 21:58:

Return addresses of some routines can be readed from stack (as we see on memory dump, locations 0xC1 and 0xC2). Return addresses […]
Show full quote

georgel wrote on 2023-10-01, 21:42:

@Maelgrum what are the plans for bruteforcing now? My rough estimate is about 65536 attempts. Instead of designing code for that I am thinking of some more efficient approach.

Return addresses of some routines can be readed from stack (as we see on memory dump, locations 0xC1 and 0xC2).
Return addresses of MPU loop can be readed also with simple attack.
This can help to make initial guess (if code structure more or less same).
But brutforcing is DANGEROUS!
If some instruction with external memory access on 16 bit bus occurs in code, bus conflict is possible between DSP and bus interface chip.
This can damage card!
Must be done very carefully, in short time, with temperature control, e. t. c.
And with full understanding of risks)))

Bus conflicts are almost never destructive I'll gladly accept the risk

mattw wrote on 2023-10-01, 21:55:

DSP V4.16 is essentially AWE64, right? I don't have any AWE64.

Yes. That DSP version can also be found on SB16 sound cards with the Vibra16XV chip as well.

Maelgrum wrote on 2023-10-01, 22:27:

4.12 must be brutforced someday, I hope))

considering 4.11 is hardware dumped and the success with 4.13, doesn't the brute-force range for 4.12 very small and limited, because they all have essentially the same code-base?

mattw wrote on 2023-10-01, 22:35:

considering 4.11 is hardware dumped and the success with 4.13, doesn't the brute-force range for 4.12 very small and limited, because they all have essentially the same code-base?

In current attack scheme we have 2 return addresses on stack, which can be modified for execution of attack. On each return address, we can modify high or low byte, and high byte is only really usable.
Interrupt vector handlers assumed range is 0x0000-0x05ff (broad assumption).
So we have 12 variants of attack.
Some variants is unusable - infinite loops, jumps to outer space.
Some writes some garbage to x-bus registers.
Some may need different stack structure.
Some may work as is, in existing attack scheme.
But I see chances as high, what some attack succeeds. But it can require some research and experimentation.
May be simple brutforcing using existing attack scheme succeeds - who knows?))
Address range of 'get copyright string' is most likely limited by bounds of 4.11 and 4.13.
So total number of variants is small.

S95Sedan wrote on 2023-10-01, 22:24:

So whats suppose to be in the last section? If its even important.

that was already discussed here:

Re: The Soundblaster DSP project

Gmlb256 wrote on 2023-10-01, 22:30:

SB16 sound cards with the Vibra16XV chip as well.

correct and good information - I found Vibra16XV-based card model CT4170 and indeed it has DSP V4.16, attaching MDUMP for @Maelgrum and here is the log:

1CT4170 (Vibra16XV) log:
2SB Reset: done
3DSP version: 4.16
4Internal memory dump: done
5MPU-401 init: done
6Success!

Maelgrum wrote on 2023-10-01, 22:03:

So it looks unlikely that they use real 4.16.

yes, CMI8330 discussion is settled now, because I found mine - the chip is marked as "CMI8330A" on my card, it doesn't have real DSP, i.e. as you correctly predicted:

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

If they not support memory read command - it is not real 4.16.

your dump tool reports:

1Internal memory dump: failed!

i.e. no memory read command.

So, yeah, it seems DSP V4.16 except AWE64 those Vibra16XV -based card models can be used for an attack option as they have DSP V4.16 and they are much cheaper than AWE64 too.

If you cook something for V4.16 I can use that Vibra16XV (model CT4710) card to test it - even if it's risky and potentially if it can toast the card as I don't really need that card.

Wow, I was searching for something else in my storage and instead of that I found a box full of SB16 cards - I didn't even know I have them. I think the time I found the box couldn't be better, indeed! So, let me sort through them - I guess a lot of V4.13 dumps from un-dumped models are coming later today plus maybe I will find some more V4.16 for the upcoming attack/tests.

V0.03 of sb16dump
Changes: By using codepath from command 0xE3 (get copyright string), dumping must be much faster.
Not tested ))

OK, after making dumps on already, I don't know, maybe close to dozen of V4.13 cards here is summary of the results - in very short it seems there are only 2 variants of V4.13 DSP code (or maybe 3 - see the end of the post both for comments and help):

* Variant A dumped by me from:
- 1 x CT4180 (ViBRA 16C)
- 2 x CT2960 (ViBRA 16C, "SB PRELUDE" - on the sticker/label)

it's the same as what @georgel dumped and posted here:

Re: The Soundblaster DSP project

In other words now we have that same dump from 4 different "ViBRA 16C"-based cards. 3 dumps made by me and 1 made by @georgel. CRC32 hash of Variant A is "1d7bf127" - just so we have some easy way to refer to it.

* Variant B dumped by me from:

- 1 x CT3980 (AWE32)
- 1 x CT3990 (AWE32)
- 1 x CT2910 (that's the model written on the PCB, on the sticker/label it says "CT2911 SBIDE" - maybe that is better precised the exact model)

same as the old hardware dump and what I commented here:

Re: The Soundblaster DSP project

CRC32 hash of Variant B is "e22e9001" - again counting the old hardware dump we now have it confirmed 4 times, 3 times by me and 1 time the old hardware dump.

* Help Needed, please comment:
- 1 x CT2290 (that's the model written on the PCB, on the sticker/label it says "CT2291 SB16IDE" - maybe that is better precised the exact model):

It's Very curious case, as it fails 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

now considering I am using factory cable for the MIDI Loopback:

Re: The Soundblaster DSP project

I am excluding that as possible root cause of the problem and to me it leaves some of the following options - what you think:

1. that card is faulty, even it looks immaculate and in like new condition
2. that model doesn't like MIDI Loopback, i.e. it causes some crash on electrical level on the PCB
3. @Maelgrum Dumper needs something special to make MIDI Loopback work on that model, i.e. it has somehow different DSP V4.13
4. something else?

I guess it will be hard to say until some other user test the exact same model ,i.e. that way at least option 1 will be ruled out and give some idea for option2 as well.

Last, but not least I found 3 more CT4170 (Vibra16XV), i.e. now I have 4 of them and they are all DSP V4.16 - totally sacrificial as I don't need them, i.e. completely dedicating them to be used for DSP V4.16 attack.

Maelgrum wrote on 2023-10-02, 14:56:

dumping must be much faster.

thank you, it might be, but I already dumped all cards I have - except one for which I need your help, because I am not sure what is wrong - see above.

I checked version from vibra 16c (thanks @georgel).
It is a exactly the same fw as published 4.13, but with unused space at top of the ROM filled with 0xFF. (I think its just to speed up MCU programming).
So it is standard plain old 4.13 (no any specific vibra config, pins assignment, e.t.c.)

Maelgrum wrote on 2023-10-02, 15:51:

I checked version from vibra 16c (thanks @georgel).
It is a exactly the same fw as published 4.13, but with unused space at top of the ROM filled with 0xFF. (I think its just to speed up MCU programming).
So it is standard plain old 4.13 (no any specific vibra config, pins assignment, e.t.c.)

yeah, I don't claim by any mean it is different as Functionality, but it's different as byte-sequence.

So far it is no evidence for any _specific_ fw (for different hardware) with same version number.
Looks like fw is compatible with different hardware configurations.

mattw wrote on 2023-10-02, 15:42:

thank you, it might be, but I already dumped all cards I have

Im reading along this thread, because the details are way over my head, but it is still super interesting.
And i have a question.
Why are you so against evolutions of this tool?
Its super neat that different and faster ways are showing up. People get involved with ideas and real progress is being made.

Its like everybody has to stop making phones because the Iphone exists...

If they want to make it faster... Great. Let them make it faster. I really see no rational need to tell them to stop hacking because you are done with something...

Or maybe i just read everything wrong that is happening. In that case just ignore me.

mattw wrote on 2023-10-02, 15:42:

* Help Needed, please comment: - 1 x CT2290 (that's the model written on the PCB, on the sticker/label it says "CT2291 SB16IDE" […]
Show full quote

* Help Needed, please comment:
- 1 x CT2290 (that's the model written on the PCB, on the sticker/label it says "CT2291 SB16IDE" - maybe that is better precised the exact model):

It's Very curious case, as it fails with:

Copy code to clipboard

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

now considering I am using factory cable for the MIDI Loopback:

Re: The Soundblaster DSP project

I am excluding that as possible root cause of the problem and to me it leaves some of the following options - what you think:

1. that card is faulty, even it looks immaculate and in like new condition
2. that model doesn't like MIDI Loopback, i.e. it causes some crash on electrical level on the PCB
3. @Maelgrum Dumper needs something special to make MIDI Loopback work on that model, i.e. it has somehow different DSP V4.13
4. something else?

MPU init is done as described in Creative manual, and if it passes - it must work. Cannot imagine any problems on this side.
If you use cable for loopback - may be cable is too long, or it catches some electromagnetic noise.
Best loopback - is gameport D-SUB connector with pins 12 and 15 connected with soldered wire. Shortest signal path ))

Or may be MIDI IN or MIDI OUT pins is damaged by static.

Maelgrum wrote on 2023-10-02, 15:57:

So far it is no evidence for any _specific_ fw (for different hardware) with same version number.
Looks like fw is compatible with different hardware configurations.

it looks that way, especially after you don't think the failure to dump my CT2290 card with Intel-made V4.13 MCU is not due to FW code difference inside that chip, but something else.

I will try with shorting the pins, but I guess best is some other user here to have the same card and try, because maybe mine is simply broken.

mattw wrote on 2023-10-02, 16:07:

it looks that way, especially after you don't think the failure to dump my CT2290 card with Intel-made V4.13 MCU is not due to FW code difference inside that chip, but something else.

Loopback checking is done before any attack on fw, it must work on any version of fw.

Maelgrum wrote on 2023-10-02, 16:15:

Loopback checking is done before any attack on fw, it must work on any version of fw.

I understand, trying to make test with shorting the pins directly on the PCB with soldering a wire between them, but on the cable I am using and that is confirmed working on all other cards, pin 12 and 15 are not shorted and the pins on the connector are numbered. now I guess the numbering is wrong?!

mattw wrote on 2023-10-02, 16:25:

Maelgrum wrote on 2023-10-02, 16:15:

Loopback checking is done before any attack on fw, it must work on any version of fw.

I understand, trying to make test with shorting the pins directly on the PCB with soldering a wire between them, but on the cable I am using and that is confirmed working on all other cards, pin 12 and 15 are not shorted and the pins on the connector are numbered. now I guess the numbering is wrong?!

Why shorting directly on PCB ?
Most simple way is get DB-15M connector:
and on backside of connector short pins 12 and 15 by wire.

Maelgrum wrote on 2023-10-02, 16:32:

Why shorting directly on PCB ?
Most simple way is get DB-15M connector:

agree, but I don't have DB-15 connector, however I am now baffled, because there is doubt what are Pin 15 and Pin 12, here is Diagram of the Connector:

http://midi.teragonaudio.com/hardware/pc_intfc.htm

yet on the cable I am using and that works on any other SB card, I measured between those 2 pins MOhms resistance?! Another interesting thing is that another user here with that same CT2290 model:

MT-32 SB16 CT2290 NO GO :)

had a problem and needed to try 2 different MIDI cables - only the 2nd one worked. In any way, I don't get what's the case with my current cable - maybe it has some Active components inside and when there is no power the pins are not shorted and hence the MOhms resistance when I measure it out-of-circuit.