First, I can't even the damn things . Now, there's apparently an option, when running, to save the music being played. Even so, the musics are stored in sub-directories. However, they are encrypted. It's obviously a key, however, it's kind of a changing key. Anyway, tried several times and went nowhere. The one I've been looking after several time is this one : http://www.uprough.net/releases/UP-LP005.LHA

Ah, more encrypted mods! This is excellent news, it has been a while...

What kind of problems exactly you had? I took a look at this and created a new UAE A4000 instance. First I did a fresh install of Workbench 3.1 on a harddisk image file. I then copied C= installer from Aminet into C: and ran the provided install script. (Man, the post-2000 musicdisk world is different from what it used to be - where is the track loader, for instance? What, no lack of memory allocation? No decompression to fixed memory address? Heck you can even exit these ones!)

The installer seems to be a bit broken, you need to manually fix some file protection settings once the install is complete:

Code:

protect EP:start +sprotect EP:prefs +sprotect EP:EP +e

After that you can run "start". I got a warning message

Code:

Couldn't find the file "ENV:sys/ahi/prefs"!

but this does not seem to matter. In the prefs you need to select a screenmode and EP dir (for this particular one it should be EP:EPs/blowme!morehitsforkids. Save the prefs and click Start, and the musicdisk runs just fine for me. And it can save the modules if you press "s".

I guess the authors realized the futility of encryption - after all there are people like us in the world. We could of course crack it just for sport, but I am sure manually saving the modules is more efficient. Or maybe even asking the authors for originals.

I suggest you make sure you are using a harddisk image file (UAE can use the host OS disk but AmigaOS will likely get confused by the different file protection/permission bits, remember AmigaDOS is pretty unique with this). Then just use the provided install script with the manual fixes and save the modules manually. If you need my .uaerc I can send it to you but it will need to be adapted for you.

As for the actual encryption: I don't really know, but it seems to include some kind of compression as the encrypted mods are smaller than originals. Or perhaps it is just a different way of storing the pattern data.

The 'save' feature saves from memory or converts from disk ? I'd say from memory since it saves the "current" music.

Hmm. I wonder - if you can't tell the difference, does it really, really matter? I will show you that in this case they are the same, but as you probably won't believe me without seeing the disk rip decoder yourself, we will go the hard way. So, let us begin.

I was able to locate the decryption (or perhaps just descrambling or decoding) code with UAE by using breakpoints to intercept dos.library Read() calls and examining what happens next in the code. This turned out to be both easy and fruitful, as the program immediately decodes the file after loading. With disassembler I saw a call to subroutine that does some odd bit fiddling with the loaded data. It looked promising so I ran it to completion and the end result was decoded file in the same memory location. Yay! Below is the decoder for your viewing pleasure. It is called with the address of loaded data in registers a0 and a1, and the length of the loaded data in d0.

As you can see the code refers to a decoding key at address $4005f350 (attached as file 4005f350). In the same spirit as the venerable Confusion music disk, the key is just program code, not really a separate key at all. But this time the algorithm is much more complex than just basic XOR. I am not sure about the length of the key. Since it is indexed with a byte offset both from beginning and offset 0x44, the total offset should never be more than 0x143. I just dumped 512 bytes of memory and that seems to be enough. Since the key is part of EP code, it is the same for all disks.

Also, there is a small table used for multiplications at $4005f348 (attached as file 4005f348). Based on this saved information, it is possible to write a decoder even without understanding the decoder function at all. Just extract the code and run it on input data using the key and table. I wrote a simple C language emulator for the disassembly above and a CLI frontend to load files, call the decoder and save decoder file. (Attached as unuprough.c, key.h and Makefile). Again, just build it and run it on the encoded module files like this:

Code:

make./unuprough module01.up module02.up ...

The output file name is generated by concatenating strings "mod." and whatever is in the beginning of the decoded file. This works for Protracker mods, but some modules are in different format (AHX at least, perhaps others) and these files will get random file names. Perhaps it is better to decode them one at time and rename the random name manually.

Now that we can decode the disk rips, we can also verify that the files obtained by the "s" command are identical.

P.S. in my earlier message I made a mistake - the encoded file is not shorter than the original, instead it is always 1 byte longer.P.P.S. I think I just learned something about myself... I'll throw myself at any crazy impulse challenge you post here... and really enjoy that.

The reason is because some of those files are actually AHX. Their title is actually at the end .

I haven't have time to try your trick to run this from wb yet, so I can't really test. However, in the LP004, there are musics by our own Curt Cool. I compared his original with the depacked version and they are identical.

When reading the decoding func, it looked really crazy. But then, you managed to pull it off. There's indeed no real need to understand this.

I'm out of words to actually say anything meaningful. A mere "thank you", at least, is the best I can utter for now

Now, I'll dig into those disks and report if I stubble on anything suspicious.

You're welcome, and I'm happy to hear the tool gets some serious action right away.

But I'm confused about the 's' function now. I ran my tool on one of the encrypted modules and got one file, then saved the same module with 's' command. I did bit-by-bit comparison and the files were identical. Or did I just manage to pick a module which is not affected by clearing the first 4 bytes (and shouldn't that be 2 bytes if we are talking about the repeat info)?

OK, I assumed the files we stored here were the result of 's'. Maybe not.My example is UP-LP003. I had to update three musics by Skope from this musicdisk. The list is in today's additions.Those three were memory rips. If you're still set up and can run this, are you willing to try the 's' there ? Still didn't get around installing wb 3.1 yet

Note that the decrypting tool works on everything (text, raw picture, etc.). This is _very_ useful to retrieve the production text for example. So, if only for that, it great

I saved all the modules of up-ep003 with 's' key and the compared to files decrypted with the tool. Each of the 5 modules was identical. Maybe the old AMP files were obtained from some other source, or maybe ripped with something like ProWizard from memory?

Now I'm confused. why would someone perform a memory rip if this 's' feature saves the file without the four first bytes of each sample cleared ?Another thing that is unsettling. UP-EP001 has musics by Ronny. I retrieved these musics from Up-Rough website a while ago. All were memory rips.All this is rather confusing.

Still, I'm glad for this remarkable tool. 14 musicdisks handled so far. I updated some musics on AMP. Got 3 more "chip music disks" to go. Audit traces of said updates are coming shortly.

@Axxy, identical size is not enough. you should perform a binary file comparison. As for your sources, I'm afraid I can't help

@Axxy, identical size is not enough. you should perform a binary file comparison. As for your sources, I'm afraid I can't help

Mine are identical except "def chaos filter" has slight variations in the file. Seems strange I had only those 3 as the others, "freshly 2000" is datestamped 2013 and I didn't have welcome003... Must have found a download for them somewhere, as I obviously didn't rip them back then.

well, Up Rough _does_ provide the MODs for various musicdisks on their website. The link to those is generally close to the musicdisk link itself. Though, they more easily link to MP3 version. Maybe you got your version from their website ?

And I'm done with all Up Rough musicdisks.That includes all LP and EP series.Several additions/updates were made to AMP because of that. So, in case I didn't make it clear, thanks a lot for your tool ! it helped a lot !

I must say I do miss the good old days and hacking with UAE is like a time machine. And it also help make my tiny contribution to the awesome AMP. Now, I go back optimizing my 68000 mandelbrot code, see you again in next music disk!