yawetaG wrote on 2020-11-27, 19:54:

1993, since it was released in 1994.

i guess then brute-force attack is a reality, it's complicated, but all permutations of 20 positions until it decodes to 1993. however, maybe someone with more vivid imagination (or some math correlation) can figure it out based on that we know the permutation that gives:

1-913.1.903-

@all, i am very sad 🙁, the adress line decryption looks good for SC55 ROM 's, i am shure, that data line decryption is also good. Loaded the dectypted 3 files stored as one file is now clearly listable - instruments are now recognizeable - and i can hear, that adress-lines are fine. But useing the decompressing lines of NewRisingSun, audio becomes more worse than not decompressed file.

// Decompress the decrypted wave ROMs to yield 18-bit sample data.
// Structure of each (decrypted) 1 MiB wave ROM:
// - Header from $000000-$0003FF;
// - Two packed 4-bit base-2 exponents (i.e. left-shift counts) per byte from $00400 to $7FFF;
// - 8-bit mantissa bytes from $08000 to $FFFFF.
// The packed exponent byte address for each mantissa byte is simply the mantissa byte's address right-shifted by five bits, so that one exponent byte applies to 32 mantissa bytes.
// Within those 32 mantissa bytes, the exponent byte's lower nibble applies to the first 16, the higher nibble to the second 16 mantissa bytes.
std::vector<int16_t> waveData;
for (uint32_t address =0; address <0x300000; address++) waveData.push_back(decryptedWaveROMs[address] <<(decryptedWaveROMs[address >>5 &0x007FFF | address &0x300000] >>(address &0x10? 4: 0) &0x0F) >>2);

Has anybody had succsess with this decompression algo?

mattw wrote on 2020-11-27, 19:59:

... someone with more vivid imagination (or some math correlation) can figure it out....

played manually with trying different permutations and this one:

BITSWAP20(_offset,19,14, 18,12, 5, 16,8,11,15, 7,17,10,6,9, 13, 1, 3, 2, 4, 0)

makes data on address 0x20 to 0x30 for each SC88 ROM chip decode to:

1xpgs_wv0........
21993-10-31......

which looks correct considering the ROMs start with:

1Roland XP-GS    Ver.1.00        

so, definitively SC88 ROMs are almost decrypted as well. I will continue to play with it or took a little more scientific approach in attempt to find the entirely correct permutation.

mattw wrote on 2020-11-27, 20:46:

played manually with trying different permutations and this one: […]
Show full quote

mattw wrote on 2020-11-27, 19:59:

... someone with more vivid imagination (or some math correlation) can figure it out....

played manually with trying different permutations and this one:

BITSWAP20(_offset,19,14, 18,12, 5, 16,8,11,15, 7,17,10,6,9, 13, 1, 3, 2, 4, 0)

makes data on address 0x20 to 0x30 for each SC88 ROM chip decode to:

Copy code to clipboard

1xpgs_wv0........
21993-10-31......

which looks correct considering the ROMs start with:

Copy code to clipboard

1Roland XP-GS    Ver.1.00        

so, definitively SC88 ROMs are almost decrypted as well. I will continue to play with it or took a little more scientific approach in attempt to find the entirely correct permutation.

Well done!!! 😀

Alex-aut wrote on 2020-11-27, 20:51:

Well done!!! 😀

it's a small progress, but it seems I found out first 6 bits of the address line scrambling used on SC88 "13, 1, 3, 2, 4, 0", which means I reduced from 20-bit strong scrambling to 14-bit, which is easier for brute-force, but still is a lot. in any way I guess main point is that SC88 is possible and scrambling is very similar to SC55/MKII.

mattw wrote on 2020-11-27, 21:02:

Alex-aut wrote on 2020-11-27, 20:51:

Well done!!! 😀

it's a small progress, but it seems I found out first 6 bits of the address line scrambling used on SC88 "13, 1, 3, 2, 4, 0", which means I reduced from 20-bit strong scrambling to 14-bit, which is easier for brute-force, but still is a lot. in any way I guess main point is that SC88 is possible and scrambling is very similar to SC55/MKII.

Is it allowed to assume, that useless permutations are such permutations in the sector of mantissa data, where steepness of y= kx+d (straight line) is too steep between two assumed samples? 😀

OK, I made an observation, that probably most of you already did notice, because it's so basic and simple, but I haven't noticed until now:

1single chip CM-32P Waverom size: 
2524 288 bytes, that means address 0x0000 to (524 288 -1) =0x7FFFF = 111 1111 1111 1111 1111 or (3 + 4*4) =  19 bits, hence we need BITSWAP19 macro for CM-32P
3
4single chip SC-55/MKII Waverom size: 
51 048 576 bytes, that means address 0x0000 to (1 048 576-1) =0xFFFFF = 1111 1111 1111 1111 1111 or (5*4) =  20 bits, hence we need BITSWAP20 macro for SC-55
6
7single chip SC-88 Waverom size: 
82097152 bytes, that means address 0x0000 to (2097152-1) = 0x1FFFFF= 1 1111 1111 1111 1111 1111 or (1 + 5*4) =  21 bits, hence we need BITSWAP21 macro for SC-88

that allowed me to now have properly descrambled first 0x200 bytes of each SC-88 Waverom - see the attached screenshot - it looks correct, which means first 9 bits {address (0x200 - 1) = 0x1FF and that is 9 bits} of address line scrambling permutation is "8,5,12,7, 13, 1, 3, 2, 4, 0".

my current code is:

#define UNSCRAMBLE_ADDRESS(_offset) \
BITSWAP21(_offset,20, 17,18, 16,9, 10, 11,15,14,19, 6,8,5,12,7, 13, 1, 3, 2, 4, 0)

but only the lower "8,5,12,7, 13, 1, 3, 2, 4, 0" sequence is correct, that's why only first 0x200 bytes are descrambled properly.

@all, i am very sad 🙁, the adress line decryption looks good for SC55 ROM 's, i am shure, that data line decryption is also good. Loaded the dectypted 3 files stored as one file is now clearly listable - instruments are now recognizeable - and i can hear, that adress-lines are fine. But useing the decompressing lines of NewRisingSun, audio becomes more worse than not decompressed file.

Then you must have made an error during copy/paste, because it should sound perfect. Attached find a full program plus its output, with a .WAV header added. Note that there is garbage at the beginning of each 1 MiB which is the wave ROM header and the shift counts.

ok, with small fix "10,5,12,7, 13, 1, 3, 2, 4, 0" - first 0x400 bytes of SC88 Waveroms descramble...the structure is very similar to SC-55. unfortunately, for SC-88 the rest 11 positions in BITSWAP21 will be kind of hard to manually guess as I did so far...

When the bit about address lines came up and service manuals schematics were posted I had a look at the JV35/50 service manual to see whether that would be of any help, since JV35 and JV50 are basically the SC55Mk. II ROM (minus MT32 part) on SC88 hardware.
Unfortunately on that synth the ROM is one 4M chip instead of the 3 separate 1M(?) ROMs on the SC55.

Would that imply it is a higher quality version, since the total ROM size is 25% larger?

yawetaG wrote on 2020-11-27, 22:23:

When the bit about address lines came up and service manuals schematics were posted I had a look at the JV35/50 service manual to see whether that would be of any help, since JV35 and JV50 are basically the SC55Mk. II ROM (minus MT32 part) on SC88 hardware.
Unfortunately on that synth the ROM is one 4M chip instead of the 3 separate 1M(?) ROMs on the SC55.

Would that imply it is a higher quality version, since the total ROM size is 25% larger?

IMHO, no - maybe, when that hardware was made such 4M chip was preferred for some reason such as price, availability, physical space on the board - to place one instead 3 chips, etc. so, last 1MB of it could be empty, i.e. not used.

mattw wrote on 2020-11-27, 22:28:

yawetaG wrote on 2020-11-27, 22:23:

When the bit about address lines came up and service manuals schematics were posted I had a look at the JV35/50 service manual to see whether that would be of any help, since JV35 and JV50 are basically the SC55Mk. II ROM (minus MT32 part) on SC88 hardware.
Unfortunately on that synth the ROM is one 4M chip instead of the 3 separate 1M(?) ROMs on the SC55.

Would that imply it is a higher quality version, since the total ROM size is 25% larger?

IMHO, no - maybe, when that hardware was made such 4M chip was preferred for some reason such as price, availability, physical space on the board - to place one instead 3 chips, etc. so, last 1MB of it could be empty, i.e. not used.

Ah, I figured it out: the SC50 is similar in its hardware configuration: http://www.synfo.nl/servicemanuals/Roland/ROL … RVICE_NOTES.pdf (one wave ROM chip with SC55Mk. II ROM missing MT32 section and SC88-like remaining hardware). Its service notes are dated December 1993, whereas the JV50's are dated February 1994, and SC88 only June 1994. The JV30 service notes date from February 1992 and it also has SC88-like hardware, but with the three SC55 wave ROMs.
So JV50 is actually based on SC50, and the order for hw designs must have been something like SC55, JV30, SC55Mk.II (not entirely sure whether it goes before or after JV30), SC50, JV50 (obvious name is obvious now), SC88... SD35 falls in between SC50 and JV50, but has sequencer, so Roland screwed up the naming of the JV35 (no sequencer) and JV50 (sequencer) 😁

Anyone able to make a SC50 ROM dump? I'm really curious whether the excess space is empty or not.

finally, I got understanding why I was manually able to guess first 10 bits of SC88 address line scrambling almost without effort, I just wasn't able to define what I am actually doing and why it's so efficient and I am able to do it by hand, i.e. that it doesn't obviously require (22*21*20*19*18*17*16*15*14*13) = 2 346 549 004 800 tries as you would assume on a first glance.

Actually it requires (22 + 21 + 20 + 19 + 18 + 17 + 16 + 15 + 14) = 162 tries at best and here is why:

in very short, because when you try to guess bit N and you already know bit0 to bit (N-1) , then you don't care for bits (N+1) to 22 (or whatever is the number of address lines).

To make it clear, let me take as example the 2 sequences I posted in above posts:

1* "5,12,7, 13, 1, 3, 2, 4, 0" --> that is sequence of 9 bits and it descrambles first block of 1 1111 1111 = 1FF bytes correctly, at this point you're at Step9 of the algorithm
2* what we actually do to solve for N=10, i.e. do on Step 10 of the algorithm:
3we try "X, 5,12,7, 13, 1, 3, 2, 4, 0", where X = {numbers between 0 and 21 without the numbers (5,12,7, 13, 1, 3, 2, 4, 0), i.e. that are 22-9=13 options in total}
4* we find that "10,5,12,7, 13, 1, 3, 2, 4, 0"  descrambles first block of 11 1111 1111 = 3FF bytes correctly, i.e. our answer is X = 10, but we find it with only 13 tries at best

So, realizing the above makes the algorithm to brute-force 22-bit address line scrambling from (22 factorial = 22*21*20.....*3*2*1), which is "gazillions" to something actually very small: 22 steps and on each step S we have (22 -S) options at best to try. It's still timorous, but it's really much better. Most importantly gave me an answer, why I was able to do first 10-bits manually and that fast by hand.

I have an SD-35, it is an SC-55 minus MT-32 functions as well. Anything you want me to dump?

mattw wrote on 2020-11-27, 21:59:

OK, I made an observation, that probably most of you already did notice, because it's so basic and simple, but I haven't noticed […]
Show full quote

OK, I made an observation, that probably most of you already did notice, because it's so basic and simple, but I haven't noticed until now:

Copy code to clipboard

1single chip CM-32P Waverom size: 
2524 288 bytes, that means address 0x0000 to (524 288 -1) =0x7FFFF = 111 1111 1111 1111 1111 or (3 + 4*4) =  19 bits, hence we need BITSWAP19 macro for CM-32P
3
4single chip SC-55/MKII Waverom size: 
51 048 576 bytes, that means address 0x0000 to (1 048 576-1) =0xFFFFF = 1111 1111 1111 1111 1111 or (5*4) =  20 bits, hence we need BITSWAP20 macro for SC-55
6
7single chip SC-88 Waverom size: 
82097152 bytes, that means address 0x0000 to (2097152-1) = 0x1FFFFF= 1 1111 1111 1111 1111 1111 or (1 + 5*4) =  21 bits, hence we need BITSWAP21 macro for SC-88

that allowed me to now have properly descrambled first 0x200 bytes of each SC-88 Waverom - see the attached screenshot - it looks correct, which means first 9 bits {address (0x200 - 1) = 0x1FF and that is 9 bits} of address line scrambling permutation is "8,5,12,7, 13, 1, 3, 2, 4, 0".

my current code is:

#define UNSCRAMBLE_ADDRESS(_offset) \
BITSWAP21(_offset,20, 17,18, 16,9, 10, 11,15,14,19, 6,8,5,12,7, 13, 1, 3, 2, 4, 0)

but only the lower "8,5,12,7, 13, 1, 3, 2, 4, 0" sequence is correct, that's why only first 0x200 bytes are descrambled properly.

Please mattw, allow me to note, that SC88 needs only 20 bit of adressing, because used chip is hardwired in word modus. The adress-bit A0 in this case is used as the data_15 line.
The SC88 used ROM 'S can be configured in byte- as well in word mode. In the schematic the ROM's are used in word-mode.

NewRisingSun wrote on 2020-11-27, 22:12:

@all, i am very sad 🙁, the adress line decryption looks good for SC55 ROM 's, i am shure, that data line decryption is also good. Loaded the dectypted 3 files stored as one file is now clearly listable - instruments are now recognizeable - and i can hear, that adress-lines are fine. But useing the decompressing lines of NewRisingSun, audio becomes more worse than not decompressed file.

Then you must have made an error during copy/paste, because it should sound perfect. Attached find a full program plus its output, with a .WAV header added. Note that there is garbage at the beginning of each 1 MiB which is the wave ROM header and the shift counts.

Tank You so much!!! 😀

appiah4 wrote on 2020-11-28, 10:39:

I have an SD-35, it is an SC-55 minus MT-32 functions as well. Anything you want me to dump?

If it has the single wave ROM instead of multiple chips, a dump of that?

Alex-aut wrote on 2020-11-28, 10:43:

Please mattw, allow me to note, that SC88 needs only 20 bit of adressing, because used chip is hardwired in word modus. The adress-bit A0 in this case is used as the data_15 line.
The SC88 used ROM 'S can be configured in byte- as well in word mode. In the schematic the ROM's are used in word-mode.

I see, the question is if that fact can be used to further speed-up guessing of the address line scrambling - after first 10 bits the difficulty for me comes from the increasingly bigger and bigger block to verify if that block makes senses not and if it looks descrambled or not, actually each step the block doubles. so, it's exponential.

I looked at bit 11 and bit 12 and the only sequences that kind of look potentially possible based on the structure of the data is:

"14,6,10,5,12,7, 13, 1, 3, 2, 4, 0"
or
"6,14,10,5,12,7, 13, 1, 3, 2, 4, 0"

but as I said the blocks to verify just becomes bigger and bigger to be able to make fast conclusions.

in any way, I have no SC88 to sniff the address lines with logic probes, as @kitrinx did with SC-55. So, I cannot do much more, but my point was to show that SC-88 Waverom is almost hacked and data value bit shuffling is the same as SC-55/MKII and first 10 bits of address line scrambling are "10,5,12,7, 13, 1, 3, 2, 4, 0". And also to explain, why figuring our first 10 bits address line scrambling is even manually possible.

Actually, maybe someone based on the above information can find the descrambling assembler code in the Control ROM, if it's done there and figure out the rest even without SC-88 hardware and logic probles.

mattw wrote on 2020-11-28, 08:48:

finally, I got understanding why I was manually able to guess first 10 bits of SC88 address line scrambling almost without effor […]
Show full quote

finally, I got understanding why I was manually able to guess first 10 bits of SC88 address line scrambling almost without effort, I just wasn't able to define what I am actually doing and why it's so efficient and I am able to do it by hand, i.e. that it doesn't obviously require (22*21*20*19*18*17*16*15*14*13) = 2 346 549 004 800 tries as you would assume on a first glance.

Actually it requires (22 + 21 + 20 + 19 + 18 + 17 + 16 + 15 + 14) = 162 tries at best and here is why:

in very short, because when you try to guess bit N and you already know bit0 to bit (N-1) , then you don't care for bits (N+1) to 22 (or whatever is the number of address lines).

To make it clear, let me take as example the 2 sequences I posted in above posts:

Copy code to clipboard

1* "5,12,7, 13, 1, 3, 2, 4, 0" --> that is sequence of 9 bits and it descrambles first block of 1 1111 1111 = 1FF bytes correctly, at this point you're at Step9 of the algorithm
2* what we actually do to solve for N=10, i.e. do on Step 10 of the algorithm:
3we try "X, 5,12,7, 13, 1, 3, 2, 4, 0", where X = {numbers between 0 and 21 without the numbers (5,12,7, 13, 1, 3, 2, 4, 0), i.e. that are 22-9=13 options in total}
4* we find that "10,5,12,7, 13, 1, 3, 2, 4, 0"  descrambles first block of 11 1111 1111 = 3FF bytes correctly, i.e. our answer is X = 10, but we find it with only 13 tries at best

So, realizing the above makes the algorithm to brute-force 22-bit address line scrambling from (22 factorial = 22*21*20.....*3*2*1), which is "gazillions" to something actually very small: 22 steps and on each step S we have (22 -S) options at best to try. It's still timorous, but it's really much better. Most importantly gave me an answer, why I was able to do first 10-bits manually and that fast by hand.

mattw 😀 your commends are a pleasure but you did'nt lift your secrete in terms of trying the N nth bit, on which pattern do you recognize, that N (in your case '10' as the next bit is the correct bit. what is the trick, that you know, that THIS x is the correct bit ? That would also be wortrh of an explanation 😀

@mattw, you hopefully will not give up in the last few meters fore the goal ?:-)