Maelgrum wrote on 2023-10-03, 20:52:

Can anyone test V0.05 on 4.04/4.05 ?

Yes I can

maxtherabbit wrote on 2023-10-03, 20:56:

Bro I'm pretty sure you are the only one here who cares about the padding bytes

so be it, what can I say - count me as an advanced stage of OCD.

mattw wrote on 2023-10-03, 20:52:

BTW, may I suggest to add CRC32(8K) for integrated as well and write, for example: ViBRA16C known padding case […]
Show full quote

BTW, may I suggest to add CRC32(8K) for integrated as well and write, for example:
ViBRA16C known padding case

Copy code to clipboard

1CRC32 (8k): 1D7BF127(known padding)

or
CT2502 known padding case

Copy code to clipboard

1CRC32 (8k): A38CBCB2(known padding)

because currently we know 2 types of padding to 2K. IMHO, it's better in terms of completeness, also in weird cases when random bytes flip like in @DerBaum when reading the padding.

I think what calculating and comparing CRC from floating bus is bad idea )) Any value can be on bus, and it depends on many factors.
But i can print padding value.

sb16dump V0.06
Padding information added per @mattw request

Maelgrum wrote on 2023-10-03, 21:00:

I think what calculating and comparing CRC from floating bus is bad idea )) Any value can be on bus, and it depends on many factors.
But i can print padding value.

do it as you see fit - as i said - it's just a suggestion. Currently, we know "0xFF" and "0xFC" as padding - so maybe print "unknown padding" if it's neither of those 2 known ones.

[EDIT] we were writing at the same time - thank you for the latest version, that I think suffice.

sb16dump V0.07
Fixed bug in V4.05 experimental support

sb16dump V0.08
Experimental support added for V4.11

I just can not get reliable results from my ct3600. I think it is broken. *really sad nerd noises*
I have cleaned the isa slots, the card edge connector, have cleaned the card itself and checked all pins of the main ic for loose pins (wich are fine).

And it sometimes gives a proper crc, but most of the time generates a new crc, and sometimes gives just the error i have shown before.

the rar contains all of the files it created. just in case anybody wants to know how it looks ...

Please have a look at 533B7D78.413 from the rar compared to the DSP_413I.BIN ...
It looks like the bytes are shifted . There is a 0x30 missing at 0x10c BUT there is a 0x00 at 0x141 making up for the missing byte so the rest doesnt shift?
So wierd.

DerBaum wrote on 2023-10-03, 21:34:

I just can not get reliable results from my ct3600. I think it is broken. *really sad nerd noises*

Try this (for V4.13).
Is something changed ?

Maelgrum wrote on 2023-10-03, 21:48:

Try this (for V4.13).
Is something changed ?

will test and report back 🫡

DerBaum wrote on 2023-10-03, 22:02:

Maelgrum wrote on 2023-10-03, 21:48:

Try this (for V4.13).
Is something changed ?

will test and report back 🫡

Looked at you dumps - it seems that sometimes,very rarely, a situation arises when one byte is simply lost from bytestream.
I cannot understand why. ISA cycle too fast ? or too slow ? Some card problems ?
This can be fixed by special algo, with multiple readings from same locations and majoritary voting on that is correct.
But it will slowdown dumping for all users.
And writing this algorithm may take some time.

Is this problem arises with other cards ? Do other users have this problem?

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

Looked at you dumps - it seems that sometimes,very rarely, a situation arises when one byte is simply lost from bytestream. I c […]
Show full quote

DerBaum wrote on 2023-10-03, 22:02:

Maelgrum wrote on 2023-10-03, 21:48:

Try this (for V4.13).
Is something changed ?

will test and report back 🫡

Looked at you dumps - it seems that sometimes,very rarely, a situation arises when one byte is simply lost from bytestream.
I cannot understand why. ISA cycle too fast ? or too slow ? Some card problems ?
This can be fixed by special algo, with multiple readings from same locations and majoritary voting on that is correct.
But it will slowdown dumping for all users.
And writing this algorithm may take some time.

Is this problem arises with other cards ? Do other users have this problem?

Until now i think my ct3600 card is the only one that acts up. Am i the only one who tested a CT3600? Did anybody test a card more then once?

I have now changed the system from a 5x86 133mhz sbc testbench where i test all my cards to a regular pc with a pentium 200 mmx.
I also used the version wich i should use. and it still produces new crcs. but i think it returns with a good crc more often then before...

will post a rar with the dumps later after i ran about 30 tests.

@DerBaum : how you shorted Pin12 and Pin15: could it be some interference with the MIDI Interface? as the weirdness I had with CT2290 and my MIDI cable that works with any other card except with CT2290. even though, I am not sure if the dump data are transmitted over that short or it's used only for the initial injecting the attack 'payload'.

mattw wrote on 2023-10-03, 22:34:

@DerBaum : how you shorted Pin12 and Pin15: could it be some interference with the MIDI Interface? as the weirdness I had with CT2290 and my MIDI cable that works with any other card except with CT2290.

This cannot be a problem in this case.
Тhe attack is successful, but (very very rarely) first byte is missing from recieved bytestream. All following bytes are correct. Bytestream is recieved via SB data port, not via MPU port, not passing in any way via MIDI cable or short.

Waiting for feedback about V4.04, 4.05, 4.11 )))
If dumping works, then we covered ALL known fw, and can move to crack unknown ))

I now have dumped the probably faulty ct3600 for about a hour. each dump took about 1 minute and 30 seconds.
around 40 to 50 tries.
this is the result:

Maelgrum wrote on 2023-10-03, 23:02:

Waiting for feedback about V4.04, 4.05, 4.11 )))
If dumping works, then we covered ALL known fw, and can move to crack unknown ))

Heres 4.04 and 4.05 done.
Both came out as known.

Maybe a minor thing but they show as 4.4 and 4.5 early in the log but 4.04 and 4.05 at the end.
Might confuse people in the future if they run it.

DerBaum wrote on 2023-10-03, 23:44:

I now have dumped the probably faulty ct3600 for about a hour. each dump took about 1 minute and 30 seconds. around 40 to 50 tri […]
Show full quote

I now have dumped the probably faulty ct3600 for about a hour. each dump took about 1 minute and 30 seconds.
around 40 to 50 tries.
this is the result:

xdump.rar

Why we need to dump known fw ? To make sure what fw is same as previously known.
This is done - many times successful dumps are done, saved, and passes CRC check.
So in CT3600 is definetely old known 4.13.

S95Sedan wrote on 2023-10-03, 23:48:

they show as 4.4 and 4.5 early in the log

it's very small bug, "%d" in the code needs to be changed to "%02d"...

S95Sedan wrote on 2023-10-03, 23:48:

Heres 4.04 and 4.05 done. Both came out as known. […]
Show full quote

Maelgrum wrote on 2023-10-03, 23:02:

Waiting for feedback about V4.04, 4.05, 4.11 )))
If dumping works, then we covered ALL known fw, and can move to crack unknown ))

Heres 4.04 and 4.05 done.
Both came out as known.

Maybe a minor thing but they show as 4.4 and 4.5 early in the log but 4.04 and 4.05 at the end.
Might confuse people in the future if they run it.

Thanks for testing, S95Sedan !
4.04 and 4.05 is done ! ))