Do Dojo Dan's RNC chunks use any protection?

[MethodGit]

Just a question of interest as I was keen on snooping at all of the game's contents like graphics, modules etc. But it seems attempting to extract any particular chunk off the disk will either make XFDDecrunch bring up the Suspend/Reboot window or ask for a 16-bit key.

I know someone was able to at least find the key for PushOver so I was wondering if anyone knew how to find the key for this game?

[marty]

If you are not able to find the key, try using HackProPack. Or try depack files with GelDecruncher, it sometimes can unpack key locked files

[StingRay]

It's a locked file (i.e. it doesn't use a key) so "normal" decrunchers won't unpack it. Rob Northen supplied a decrunch routine which will unpack these locked files without any problem.
As usual: Rip decruncher and decrunch the data with it. Source attached.

[MethodGit]

Sorry to bump an old topic, but today I've been trying to work this one out again. So far I've:

a) loaded the source into ASM-One and assembled it, but am not sure whether I'm supposed to write a binary (I have no start and end points to go with), an object, or do something else entirely.
b) "ripped the decruncher" by way of copying the small routine from $ on the ADF of Disk 1 into a new file. Trouble is, how else to execute it, and ensure it'll read any RNC files you manually feed it? Have I also got the wrong end of the stick and there is in fact no way of turning the provided source into a simple decruncher program?

One other funny thing I've noticed while messing about, btw. When doing a hardwire on the ADF, I could only find one instance of the "magic key" (xx xx C7 85 xx xx 21 15) on the disk. Yet if I modified this one key, *both* copylocks (yes, the game uses two) in the game code at $1000 will be patched. Disassembling the code as the unpacking process went on, nothing else seemed to happen between unpacking the RNC chunk and jumping straight to $1000, so it doesn't seem like it cloned one copylock at all. And copylocks usually don't compress very well at all so there should've been two such "magic keys" popping out amongst the RNC woodwork on the disk. I guess that's, ummmm, the 'magic' of locked archives for you?

[dlfrsilver]

locked file means that Rob Northen has specifically made a decruncher for the concerned file (if i have understood what sting said).

The said decruncher cannot be used on another RNC compressed file, it's specific to the game. The goal is to not allow the decrunching with the regular RNC propack compressor.

RNC copylock and RNC compression are two different things.

[StingRay]

Originally Posted by MethodGit

Sorry to bump an old topic, but today I've been trying to work this one out again. So far I've:

a) loaded the source into ASM-One and assembled it, but am not sure whether I'm supposed to write a binary (I have no start and end points to go with), an object, or do something else entirely.

The source is really not hard to understand, you may want to have a look at "decbuf" after executing the code. What I somehow don't get, you try to crack copylocked/encrypted games but have problems to understand really simple code that even comes with full source. Try learning some basics, it will make your life much easier when it comes to defeating protections.
The source contains only a few labels outside the actual decruncher, with a bit of thinking you'd have checked these labels and then you would have noticed the decrunched data will be stored in "decbuf".

Originally Posted by MethodGit

b) "ripped the decruncher" by way of copying the small routine from $ on the ADF of Disk 1 into a new file. Trouble is, how else to execute it, and ensure it'll read any RNC files you manually feed it? Have I also got the wrong end of the stick and there is in fact no way of turning the provided source into a simple decruncher program?

The provided source IS the decruncher program... Why did you "rip" the decruncher again if you don't know how it's used anyway? Also, why do you want to use it for ANY RNC files? There are much simpler ways to decrunch normal RNC files and this file, as said, is a locked file, i.e. it needs a special decruncher.

[MethodGit]

Well, I've since figured it'd be a lot easier for me to just breakpoint the beginning and end of the decruncher on the disk itself, so I can determine which RNC chunk is being depacked next, and also save the decrunched data to a file after it's done. Not very difficult with the WinUAE debugger.

Originally Posted by dlfrsilver

RNC copylock and RNC compression are two different things.

This I'm aware of already? If it's in response to my talk about the two copylocks being merged into one when packed, that's just me trying to point out that no other Amiga title I know of does that, and me questioning whether it had anything to do with the locking function.

Unless someone knows better, this may be the only Amiga game to actually lock its RNC data and make it non-unpackable (is that a word?) by conventional means...

[StingRay]

Originally Posted by MethodGit

Well, I've since figured it'd be a lot easier for me to just breakpoint the beginning and end of the decruncher on the disk itself, so I can determine which RNC chunk is being depacked next, and also save the decrunched data to a file after it's done. Not very difficult with the WinUAE debugger.

Interesting...

Originally Posted by MethodGit

Unless someone knows better, this may be the only Amiga game to actually lock its RNC data and make it non-unpackable (is that a word?) by conventional means...

Any data which has been crunched can be decrunched again (as long as it isn't corrupt/destroyed etc) as otherwise it wouldn't make much sense to crunch the data in the first place, would it?

[dlfrsilver]

Originally Posted by MethodGit

Well, I've since figured it'd be a lot easier for me to just breakpoint the beginning and end of the decruncher on the disk itself, so I can determine which RNC chunk is being depacked next, and also save the decrunched data to a file after it's done. Not very difficult with the WinUAE debugger.

This I'm aware of already? If it's in response to my talk about the two copylocks being merged into one when packed, that's just me trying to point out that no other Amiga title I know of does that, and me questioning whether it had anything to do with the locking function.

Unless someone knows better, this may be the only Amiga game to actually lock its RNC data and make it non-unpackable (is that a word?) by conventional means...

ok....Pssst.... someone is telling me in the ears that chaos engine use a locked RNC propack file which holds the RNC copylock routine....
And someone else says that many games from Rob use Locked files

[Codetapper]

Originally Posted by MethodGit

One other funny thing I've noticed while messing about, btw. When doing a hardwire on the ADF, I could only find one instance of the "magic key" (xx xx C7 85 xx xx 21 15) on the disk. Yet if I modified this one key, *both* copylocks (yes, the game uses two) in the game code at $1000 will be patched.

What is this "hardwire the ADF" stuff? Do you look through a COMPRESSED file and alter bytes that match the copylock key in the vague hope that if it depacks, the huffman table etc will still match perfectly and you'll have a working crack?

I can't tell what on earth you are doing. Every other cracker loads the file, patches the end of the decruncher to return to their code, lets the file depack, and alters the copylock. And a few less skilled guys depack the whole file and repack it.

I really can't tell what on earth you are doing. The game is probably relocating itself (thus 2 copies appear in memory) or that the same run of bytes are used so it unpacks twice. Without looking (or caring enough to look) I can only guess, but if you're doing what I suspect you are, your "ADF hardwiring" is pure lunacy. (And that would explain why so little of it works!)

[MethodGit]

Originally Posted by Codetapper

What is this "hardwire the ADF" stuff? Do you look through a COMPRESSED file and alter bytes that match the copylock key in the vague hope that if it depacks, the huffman table etc will still match perfectly and you'll have a working crack?

"Magic key" and "copylock key" are NOT the same thing.

Look, go check out any Flashtro tutorial on copylocks. Specifically any one which involves ARIV (the grey AR). After enabling ROBD and disassembling through the game's code, you'll come across a pattern like this (example taken from Bubble & Squeak AGA):

That first instruction, MOVEM.L D2-D7/A0-A3,-(A7), is more or less where the important section begins. Flashtro chose to start lower down than that (indicated by the green number) but I found it preferable to start right at that MOVEM.L instruction, input "MOVE.L #(copylockkey),D0" then BRA straight to the end of that routine. I then take notes of the new encrypted values I made in the process. The 8-byte-long hex part of the copylock beginning with that MOVEM.L usually reads out something like "EC 9C C7 85 98 9C 21 15" or "A8 B2 C7 85 DC B2 21 15" (it varies with each game, but basically if you find "C7 85" and "21 15" in close vicinity to one another then it's the bit you want).

If you've ever compared any RNC file to its depacked equivalent, you may or may not have noticed that the middle/main core of a copylock is so encrypted that it's barely/hardly(?) compressable compared to everything else around it. Hence, the values I look for are more or less visible through an RNC file/chunk. I've since found it way quicker - when I want to recrack a fresh copy of a game - to just load an ADF through a hex editor, find the values I want, and edit them that way (If the game uses AmigaDOS checksums, then I just use DiskMonTools and take note of the new checksum for that track). Certainly beats firing up ARIII or whatever, loading the tracks manually and slowly, searching & modding, then saving the tracks back just as slowly.

So for instance, by finding "EC 9C C7 85 98 9C 21 15" in MIG-29 Fulcrum's executable, and changing it to "84 47 80 A1 6D 5F E0 E3", the game is being told to "MOVE.L #78D4C924,D0" then "BRA" to the end of that routine. And this still works even if you do it inside an RNC archive because the bytes of that section more or less remain unchanged during the depacking process, so you're not corrupting anything at all! I've tested this over and over with several dozen games and all of them passed with flying colours (the ones which don't implement extra trickery at least, and those that do need different methods anyway), with everything running as it should, copylocks being passed instantly with no reading track 0 needed etc.

To summarize, the methods I've been implementing all this time WORK. You do things your own way, and I do things my own way. You use real Amigas, I use WinUAE. That's fair enough to understand. End of story.

I might as well add btw (assuming you give a damn at all): last year I learnt a new way of dealing with copylocks that doesn't involve any ARs at all, but instead a combination of an encrypted copylock and decrypted copylock saved to individual files (for comparison purposes and to find the section I want to modify when I come across it), CopylockDecoder, long, slow periods of studying the actual decryption routine through the WinUAE debugger and see it swap good and bad values in and out all the time, and numerous XOR calcuations (and the notes to go with them). This has been a significant boost to my knowledge as it has helped me finally learn how to correctly hardwire those games which gave me so much aggro in the past (Alien 3, Krusty, Photon Storm, Steg the Slug etc). And even then I had to be more clever (and willing to spend more time watching decryption) with something like SAS Combat Simulator which CopylockDecoder simply keeled over with!

I can't tell what on earth you are doing. Every other cracker loads the file, patches the end of the decruncher to return to their code, lets the file depack, and alters the copylock.

This method I do implement on certain games that usually give difficulty any other way (e.g. Assassin, Wolfchild, Rodland, Doodlebug).

And a few less skilled guys depack the whole file and repack it.

That's how I originally started off doing things before trying other ways. But it doesn't always work if a particular game's decruncher implements some kind of checksum check or other which causes a guru during depacking (Rodland, Doodlebug, Cyberpunks, Chaos Engine 1+2).

I really can't tell what on earth you are doing. The game is probably relocating itself (thus 2 copies appear in memory) or that the same run of bytes are used so it unpacks twice. Without looking (or caring enough to look) I can only guess, but if you're doing what I suspect you are, your "ADF hardwiring" is pure lunacy. (And that would explain why so little of it works!)

See, that's the problem. Without actually checking it out, you always assume I'm screwing something up no matter what the game or the situation. Way to jump to conclusions!

[Codetapper]

The method you are using (which I showed Rob from the Flashtro tutorials and you've copied off his tutorials) relies on the game code being completely unpacked in an ADF. How do you deal with any game that compresses or obfuscates the files on the disk if you can't rely on other people's tools like XFDDecrunch to unpack them?

A game like Viz which uses a variant of Bytekiller with the headers stripped off would surely be impossible for you to crack this way because you can't get at the unpacked data. The Codemasters phone in system have a compressed section inside a slightly obfuscated file too. Stuff like Jimmy White's or Archer Maclean's Pool run extra code that will be skipped with the hardwire trick.

And any game which has a checksum run over the copylock would detect your modification. I'm curious to know how you are checking these games that "passed with flying colours" for checksums? Please enlighten us.

[MethodGit]

Originally Posted by Codetapper

The method you are using (which I showed Rob from the Flashtro tutorials and you've copied off his tutorials) relies on the game code being completely unpacked in an ADF. How do you deal with any game that compresses or obfuscates the files on the disk if you can't rely on other people's tools like XFDDecrunch to unpack them?

Perhaps a better example would be the Dragonstone tutorial. That uses locked RNC-packed data all over the shop *and* implements a sneaky trick or two (such as a checksum against the bootblock), yet Rob found that it was still possible to hardwire the copylocks inside all of those archives without any unpacking or repacking required. Same thing with Imploder-crunched files as well, that cruncher can't compress copylocks very well either. Only PowerPacker manages to obfuscate copylock code better, but even then if you do a comparison check between the original PP archive and your new PP archive, chances are the difference will still be only 8 bytes or more, making it easy to note down the new (compressed) values for future use.

A game like Viz which uses a variant of Bytekiller with the headers stripped off would surely be impossible for you to crack this way because you can't get at the unpacked data.

Viz is an MFM game, hence I'm not even touching it.

The Codemasters phone in system have a compressed section inside a slightly obfuscated file too.

You mean the Imploder or PowerPacker compressed chunks with a renamed header (CHFI or CHFC), inside the "VC" file? The old AmigaPatchList by Mark Knibbs first educated me about those things. And XFDDecrunch can already detect and unpack 'CHFI' files as is, while all it takes to unpack CHFC ones is to rename the header to PP20.

And any game which has a checksum run over the copylock would detect your modification. I'm curious to know how you are checking these games that "passed with flying colours" for checksums? Please enlighten us.

Let me know which games do such a trick with comparing a checksum against the whole copylock and I'll see if I have anything to say on the matter.