May 28, 2015, 09:00:21 *
Welcome, Guest. Please login or register.

Login with username, password and session length
   Home   Help Search Login Register  
Pages: 1 ... 8 9 [10]
 on: March 18, 2015, 18:52:24 
Started by Asle - Last post by rogue
You're welcome, and I'm happy to hear the tool gets some serious action right away. Smiley

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)?

 on: March 18, 2015, 17:05:12 
Started by Asle - Last post by Asle
and upon further tests, I confirm the 's' function does save from memory (i.e. all 4 first bytes of each sample is cleared).
So, double kuddos for this decrypting tool !

On my way throughout all the UP musicdisks now. yeah !

 on: March 17, 2015, 22:35:12 
Started by Asle - Last post by Asle
man, this was crazy !
wow. very impressive.

OK, so, it compiles and works greatly Smiley. I just changed one line in the source:

/*strncat(outname, modbuf, sizeof(outname));*/
strncat(outname, name, sizeof(outname));

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

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 Wink

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


 on: March 17, 2015, 00:34:06 
Started by Asle - Last post by rogue
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. Smiley 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.

4005acb8: 48e7 7ff0 41f0 0800 43f1 MVMLE.L #$7ff0,-(A7)
4005acbc: 41f0 0800 43f1 0800 45f9 LEA.L (A0, D0.L*1, $00) == $400cc6e1,A0
4005acc0: 43f1 0800 45f9 4005 f350 LEA.L (A1, D0.L*1, $00) == $400cc6e1,A1
4005acc4: 45f9 4005 f350 47f9 4005 LEA.L $4005f350,A2
4005acca: 47f9 4005 f394 7227 740d LEA.L $4005f394,A3
4005acd0: 7227 740d 760d 2e00 1821 MOVE.L #$00000027,D1
4005acd2: 740d 760d 2e00 1821 1a32 MOVE.L #$0000000d,D2
4005acd4: 760d 2e00 1821 1a32 1800 MOVE.L #$0000000d,D3
4005acd6: 2e00 1821 1a32 1800 1433 MOVE.L D0,D7
4005acd8: 1821 1a32 1800 1433 2800 MOVE.B -(A1),D4
4005acda: 1a32 1800 1433 2800 bb04 MOVE.B (A2, D1.L*1, $00) == $400cc6e1,D5
4005acde: 1433 2800 bb04 1633 3800 MOVE.B (A3, D2.L*1, $00) == $5008cef1,D2
4005ace2: bb04 1633 3800 1104 b902 EOR.B D5,D4
4005ace4: 1633 3800 1104 b902 b903 MOVE.B (A3, D3.L*1, $00) == $40069001,D3
4005ace8: 1104 b902 b903 0202 003f MOVE.B D4,-(A0)
4005acea: b902 b903 0202 003f e40b EOR.B D4,D2
4005acec: b903 0202 003f e40b 1202 EOR.B D4,D3
4005acee: 0202 003f e40b 1202 b701 AND.B #$3f,D2
4005acf2: e40b 1202 b701 5387 66dc LSR.B #$00000002,D3
4005acf4: 1202 b701 5387 66dc 43f9 MOVE.B D2,D1
4005acf6: b701 5387 66dc 43f9 4005 EOR.B D3,D1
4005acf8: 5387 66dc 43f9 4005 f348 SUB.L #$00000001,D7
4005acfa: 66dc 43f9 4005 f348 7200 BNE.B #$ffffffffffffffdc == 4005acd8 (TRUE)
4005acfc: 43f9 4005 f348 7200 740d LEA.L $4005f348,A1
4005ad02: 7200 740d 760d 7800 7a00 MOVE.L #$00000000,D1
4005ad04: 740d 760d 7800 7a00 7c00 MOVE.L #$0000000d,D2
4005ad06: 760d 7800 7a00 7c00 5380 MOVE.L #$0000000d,D3
4005ad08: 7800 7a00 7c00 5380 1c10 MOVE.L #$00000000,D4
4005ad0a: 7a00 7c00 5380 1c10 1e06 MOVE.L #$00000000,D5
4005ad0c: 7c00 5380 1c10 1e06 ccf1 MOVE.L #$00000000,D6
4005ad0e: 5380 1c10 1e06 ccf1 4800 SUB.L #$00000001,D0
4005ad10: 1c10 1e06 ccf1 4800 da06 MOVE.B (A0),D6
4005ad12: 1e06 ccf1 4800 da06 1c32 MOVE.B D6,D7
4005ad14: ccf1 4800 da06 1c32 1800 MULU.W (A1, D4.L*1, $00) == $400d67f4,D6
4005ad18: da06 1c32 1800 5404 bd07 ADD.B D6,D5
4005ad1a: 1c32 1800 5404 bd07 10c7 MOVE.B (A2, D1.L*1, $00) == $400cc6e1,D6
4005ad1e: 5404 bd07 10c7 0204 0006 ADD.B #$00000002,D4
4005ad20: bd07 10c7 0204 0006 1433 EOR.B D6,D7
4005ad22: 10c7 0204 0006 1433 2800 MOVE.B D7,(A0)+
4005ad24: 0204 0006 1433 2800 7c00 AND.B #$06,D4
4005ad28: 1433 2800 7c00 1633 3800 MOVE.B (A3, D2.L*1, $00) == $5008cef1,D2
4005ad2c: 7c00 1633 3800 bf02 bf03 MOVE.L #$00000000,D6
4005ad2e: 1633 3800 bf02 bf03 0202 MOVE.B (A3, D3.L*1, $00) == $40069001,D3
4005ad32: bf02 bf03 0202 003f e40b EOR.B D7,D2
4005ad34: bf03 0202 003f e40b 1202 EOR.B D7,D3
4005ad36: 0202 003f e40b 1202 b701 AND.B #$3f,D2
4005ad3a: e40b 1202 b701 5380 66cc LSR.B #$00000002,D3
4005ad3c: 1202 b701 5380 66cc 7001 MOVE.B D2,D1
4005ad3e: b701 5380 66cc 7001 ba10 EOR.B D3,D1
4005ad40: 5380 66cc 7001 ba10 6702 SUB.L #$00000001,D0
4005ad42: 66cc 7001 ba10 6702 7000 BNE.B #$ffffffffffffffcc == 4005ad10 (TRUE)
4005ad44: 7001 ba10 6702 7000 4cdf MOVE.L #$00000001,D0
4005ad46: ba10 6702 7000 4cdf 0ffe CMP.B (A0),D5
4005ad48: 6702 7000 4cdf 0ffe 4e75 BEQ.B #$00000002 == 4005ad4c (FALSE)
4005ad4a: 7000 4cdf 0ffe 4e75 4e71 MOVE.L #$00000000,D0
4005ad4c: 4cdf 0ffe 4e75 4e71 4eb9 MVMEL.L #$0ffe,(A7)+
4005ad50: 4e75 4e71 4eb9 4005 f3e8 RTS.L

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:
./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. Smiley

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. Smiley

 on: March 15, 2015, 11:07:09 
Started by Axxy - Last post by Asle
bah. It's my mistake. Same guy indeed.
I've merged both authors under Idle but kept the "dupes". Aside the email address added, there are other changes applied, so ...

Thank you for pointing out the problem. I didn't notice it when Idle sent me all his musics.


 on: March 14, 2015, 21:08:29 
Started by Axxy - Last post by deus-ex
Hi Axxy,

I agree, it strongly appears so. On MODLAND we already had threee of THB's modules stored under the alias "Idle". Moment22.mod holds credits for Thomas Biorkman, avaicomtry.mod and clairvoyancy.mod both refer to biorkman'92. The following three modules stored on MODLAND, 18-thb-rave.mod, almost there.mod and mind correlation.mod, show "By" while the versions stored on AMP show "thb'93".

Very well spotted. Smiley

 on: March 14, 2015, 15:47:26 
Started by Axxy - Last post by Axxy
Are these two musicians the same person?

 on: March 12, 2015, 21:48:55 
Started by deus-ex - Last post by deus-ex
Hello again Javier,

nice find. Thank you for sharing the results of your investigations, much appreciated.


Hey Buddy, I hope you're doing well. Smiley

For the AMP record:

Handle    : Trackman
Real Name : Daniel Alcala Alcocer
Country   : Spain
Ex.Handles: n/a
Groups    : Klymax

 on: March 12, 2015, 18:45:39 
Started by Asle - Last post by Asle
hum. Right. So .. first, thanks for this feedback Smiley
About the setup thing, I had not figured it out, so, that's helpful.

However, I had in mind this encryption, of course.
The 'save' feature saves from memory or converts from disk ? I'd say from memory since it saves the "current" music.

The result files _are_ something for which we are, of course, very grateful Smiley. It's my extremist side which takes over Wink

Thanks for your thorough reply ! Very appreciated.


 on: March 12, 2015, 18:40:06 
Started by deus-ex - Last post by Asle

 Not being 100% sure, here. I believe AMP's version comes from Almost all "JCL" musics were added at the same time, so it must have been from a common source.
 This music is not listed anymore under you nick Smiley AMP doesn't know any Mr. Alcala (yet).

Thanks for telling us about the mistake.

Pages: 1 ... 8 9 [10]
Powered by SMF | SMF © 2013, Simple Machines