i am totally stuck, i hope someone will come with some idea about SC55ROM "pcm data address map" and how the PCM samples are addressed - there is nothing there that resembles address 0 to me. So, I saw in MAME:

https://git.redump.net/mame/tree/src/mame/dri … roland_sc55.cpp

IC28 Waverom is mapped to address 0x300000 (or is it that the total size is 0x300000?!), but again I see nothing in "pcm data address map" of SC55ROM that resembles such address - I mean after all we need to have 1MB of PCM samples between address 0x300000 and 0x400000 and thus there has to be many (0x300000 + some_offset) addresses, but I see none. It's too bad IC30 is not dumped and probably it's very hard to be dumped, maybe as hard as what I mentioned here:

Re: Sound Bank rom dumps - how are made?

So, without IC30 we're most likely totally blind regarding what's really going on...

and here:

https://git.redump.net/mame/tree/src/mame/dri … oland_cm32p.cpp

there is UNSCRAMBLE_ADDRESS and UNSCRAMBLE_DATA for CM32P - it seems different than CM32L that we already discussed.

and CM32P is PCM compared to CM32L that is LA-synth. So, at least to me it's the fist time I see how exactly Roland scrambled data in one of their PCM devices.

[EDIT] and here:

https://git.redump.net/mame/tree/src/devices/ … d/rolandpcm.cpp

is another code used for CM-32P.

BTW, anyone, where I can get CM-32P ROM dumps?

[EDIT] never mind, I found it, I am not posting link, because after all it's copyrighted material. I just want to look at it in order MAME code to make more sense to me.

CM-32P scrambling is more sophisticated than VSC, because it changes both the address and the value, while VSC "block2" 2nd layer encryption changes only the address. Interesting that even addresses they change using bit-swapping. So, bit-swapping they really love - use it everywhere.

if i ported the mame code correctly (attached) to see how the indexes (addresses) are changing, the CM-32P scrambling algo on the indexes (addresses) is different than what VSC is doing, but is there bit-swapping that will give this sequence of indexes:

Re: About Roland Virtual Sound Canvas 3

just in case someone is interested in CM-32P samples, I believe I did ported all of the ROM descrambling from MAME - attached.

see decode_sample() function from here:

https://git.redump.net/mame/tree/src/devices/ … d/rolandpcm.cpp

how the samples are converted to playable PCM - it's essentially the same as what I said in previous posts about Yamaha TG100 and SC55 - they are using packed 12-bit samples.

hmm, applying MT-32 bit-swapping to SC55ROM results in really interesting patterns (and they repeat and repeat through the whole data stream) - screenshot attached.

so, maybe bit-swapping of SC55ROM is the same as MT-32, but we have also byte-scrambling, i.e. each byte is on a wrong place like with CM-32P...

"IC23" ROM contains 2 demo songs as well "Jazz Lagoon" - at offset 0x88ac and "Leya's Song" at offset 0xd174 - they are stored as complete MIDI files with header and everything. So, you can just copy the byte sequence and paste it to a file. Also, I found the related portion of "IC23" ROM H8/500 assembler code - it's pasted below. If by any chance the descrambling algorithm is in IC23 (and not in IC30), then we still have a chance ...

1ROM:74A8 ! ---------------------------------------------------------------------------
2ROM:74A8                 mov:i.w #0x88AC:16, r4
3ROM:74AB                 cmp:g.b #0:8, @byte_CF8C:16
4ROM:74B0                 beq     loc_74BF:8
5ROM:74B2                 mov:i.w #0xD174:16, r4
6ROM:74B5                 cmp:g.b #1:8, @byte_CF8C:16
7ROM:74BA                 beq     loc_74BF:8
8ROM:74BC                 mov:i.w #0xF37F:16, r4
9ROM:74BF
10ROM:74BF loc_74BF:                               ! CODE XREF: ROM:74B0j
11ROM:74BF                                         ! ROM:74BAj
12ROM:74BF                 add:g.w #0xC:16, r4
13ROM:74C3                 ldc.b   #4:8, ep
14ROM:74C6                 ! assume ep:4
15ROM:74C6                 mov:g.b @r4+, r0
16ROM:74C8                 mov:g.b r0, @byte_CF8A:16
17ROM:74CC                 mov:g.b @r4+, r0
18ROM:74CE                 mov:g.b r0, @byte_CF8B:16
19ROM:74D2                 ldc.b   #0:8, ep
20ROM:74D5                 ! assume ep:0
21ROM:74D5                 add:g.w #9:16, r4
22ROM:74D9                 mov:g.w r4, @word_CF84:16

What's interesting about demo songs on many hardware units is that the synth often does not output MIDI data while playing back the songs, even if ostensibly the songs are stored as MIDI data in ROM - probably a form of copy protection. I guess it will be the same on the Virtual Sound Canvas.

I followed the code in VSC.DLL and it seems to me the 2nd layer decryption is removed in _WriteWaveBuf() function, which calls VSC.VXD. So, it seems to me the 2nd layer decryption is done in the VXD. I cannot find any other tool that is capable to show "Device Descriptor Block" (DDB) of VXD and its "Service Table" except VXDasm:

http://jls.chez.com/vxdasm.html

Unfortunately, it's long gone, i.e. all the links to it are dead, even using the web-archives of the website. that's huge obstacle at the moment. my idea was to write some small client that is capable to hook to the VXD and do the decryption using similar idea to this one:

http://ivanlef0u.fr/repo/madchat/vxdevl/vdat/tumisc71.htm

It's the first time I meet with VXD and maybe there are other options, but I just don't know them...

[EDIT] actually, this:

https://www.hex-rays.com/products/ida/support … orials/idc/vxd/

helps a little, i.e. it allows immediately to identify that the "VXD ID number" of VSC.VXD is 0x392E and based on that (with simple search for 0x392e) to find the corresponding code in VSC.DLL:

1cseg01:2E56 loc_2E56:                               ; CODE XREF: _LoadVxD+57j
2cseg01:2E56                 push    392Eh
3cseg01:2E59                 call    sub_2E9A
4cseg01:2E5C                 add     sp, 2
5cseg01:2E5F                 mov     word ptr _VscVxdAPI, ax
6cseg01:2E62                 mov     word ptr _VscVxdAPI+2, dx
7cseg01:2E66                 mov     ax, dx
8cseg01:2E68                 or      ax, word ptr _VscVxdAPI
9cseg01:2E6C                 jz      short loc_2E74
10cseg01:2E6E                 mov     ax, 1
11cseg01:2E71                 leave
12cseg01:2E72                 retn

Interesting, very interesting I did the simplest patch possible - just remove the 2 calls to _WriteWaveBuf() function (which calls the VSC.VXD) in VSC.DLL:

1E8 75 FC --> 90 90 90
2E8 BE FB --> 90 90 90

and the whole Soundbank remained encrypted in RAM dump, i.e. it's the same as the file on the HDD. So, it seems I was wrong and not only the 2nd layer decryption, but the 1st layer as well, is done in the VXD. I wonder considering 1st layer decryption is so simple if I can find the code where that is done in the VXD, because at least 1st layer algo is known.

BTW, maybe the above solves what I suggested here:

Re: About Roland Virtual Sound Canvas 3

and maybe the above patch allows to use unencrypted Soundbanks, because their on-load decryption is disabled. TODO: try that, because it's very convenient to use unencrypted Soundbanks.

hmm, I am not sure if I am on the right track, i.e. if removing the 2 calls to _WriteWaveBuf() removes the on-load decryption or messes-up something else that causes no on-load decryption, because in the VXD the only place I can find something that resembles 1st layer decryption is very complicated assembler code that is using MMX instructions. Also, I cannot find anything that looks like 1st layer decryption in the VXD from VSC 1.x. So, I guess I need to re-do the above experiment, but using VSC 1.x and see what will happen.

mattw wrote on 2020-10-19, 19:30:

TODO: try that, because it's very convenient to use unencrypted Soundbanks.

disappointment - no, there is no sound with unencrypted bank and the patch. So, it's more destructive than I expected 🙁

Until now, I was using Win98, because even 16MB RAM are enough and that makes "RAM dumps" compact and easy to search - that was essential until figure out how to obtain decrypted SoundBank from the RAM dump. However, at this point, I start to think that now holds me back, because things like VSC.VXD are really hard to work with for reverse-engineering - at least it's hard to me. So, I think it's time to switch to WinXP and try to understand more, but this time using VSC.SYS - I already determined ExAllocatePoolWithTag() function is called in VSC.SYS with Tag of 0x206B6444. Maybe, I can use that with SoftICE to break on that memory allocation and trace the execution from there. I think that's really good idea, but it will take me a lot of time to setup - for one, I've never used SoftICE and have no idea at the moment how to set breakpoints when particular driver, like VSC.SYS, calls ExAllocatePoolWithTag(). How hard or easy that to be done is unknown to me at the moment, but it has to be possible.

OK, switching to WinXP was very fruitful , here are the key points:

* 64MB RAM are enough, performance is not great, but who needs performance when understanding assembler code to reverse-engineer requires hours of scratching your head. it's good compromise though, because 64MB still makes RAM dumps feasible (if such are needed), even at the moment I see no point of RAM dumps, because using Win98 and RAM dumps I already have decrypted copies of all the Soundbanks. So, what is the main open question is the actual scrambling algorithm, because that can gives ideas for the SC55 Waverom scrambling.

* with several (actually many) trial and errors, I determined only 3 files are required: "Vsc32Cnf.exe", "vscapi.dll" and "vsc.sys"

* from here on it was very easy to determine several very important findings:

1"Vsc32Cnf.exe" calls function CSynth::LoadWaveTable() from "vscapi.dll", then
2
3using DeviceIoControl() 2 calls to "vsc.sys" are made:
4
5IOCTL_VSC_LOAD_WAVE_TABLE
6IOCTL_VSC_INITSYNTH

I bet all the decryption is done in IOCTL_VSC_LOAD_WAVE_TABLE, but it really narrows down where to look. Another (even easier) option is the decryption is done in CSynth::LoadWaveTable(), before it calls IOCTL_VSC_LOAD_WAVE_TABLE via DeviceIoControl(), but that is less likely.

oh, boy, SoftICE requires specific VGA driver to work and it fails in my WinXP setup, works in my Win98 setup, but there I am lost, because of the VXD use.

hmm, I wonder how hard would be to make fake vsc.sys that exports IOCTL_VSC_LOAD_WAVE_TABLE and IOCTL_VSC_INITSYNTH and that way dump what data "vscapi.dll" passes when those are called.

Unbelievable, I think I finally cracked the 2nd layer encryption, i.e. the byte shuffling VSC is doing. I am still struggling to translate the corresponding assembler code to properly working C code to fully confirm the success, but I am very positive this time I really did it. Maybe, in few hours or tomorrow I will be able to release proof-of-concept working code, i.e. new version of "vscdec". I still cannot believe with my small brain I went thus far...

"vscdecv4.c" - the code in C that can fully decrypt any VSC Soundbank is attached. Enjoy!

it removes all the encryptions - 1st and 2nd layer one and all the sounds are playable PCM data - in the next days when my free time allows I will make small tool that writes (or extracts) each sound to a playable WAV file.

P.S. it's also very nice that's my 100th post here 😀

Awesome work!

cyclone3d wrote on 2020-10-21, 23:44:

Awesome work!

thanks, now if we crack SC55 Waverom byte scrambling, we can make real SC55 Soundbank for VSC. Unfortunately, with SC55 ROM we have almost no clue, because there is very good chance the scrambling algorithm is in IC30 of SC55, which is not dumped, because no one knows how to dump it. However, as I mentioned before if it's in IC23, then there is real hope.