How does one work out the 16-bit key for an RNC archive?

[MethodGit]

I'll admit, it was only because HOL published the key on PushOver's page that I could decrunch the data for that game, but there's no such convenient information for Legacy Of Sorasil. I even consulted the source for the WHDLoad install and it made no reference to it.

So is it an easy thing to work out manually, or fiendishly difficult?

[Galahad/FLT]

Originally Posted by MethodGit

I'll admit, it was only because HOL published the key on PushOver's page that I could decrunch the data for that game, but there's no such convenient information for Legacy Of Sorasil. I even consulted the source for the WHDLoad install and it made no reference to it.

So is it an easy thing to work out manually, or fiendishly difficult?

Er, its the easiest thing in the world.

The RNC depack routine is passed it as a parameter in one of the Data registers (can't remember which one, its been a long time), so simply breakpoint when the RNC depack is called, or simply track back through the code and find something that sticks a big longword into one of the data registers, and that'll be the key.

[MethodGit]

Well, first I noticed how PushOver's EXE does reference its own key during the depack routine, moving #1984 to D5, so I thought there'd be something similar in LoS's executable.

No such luck!

CMPI.L #524E4301,(A0)+
BNE.B (E2)
MOVE.L (A0)+,D0
LEA A(A0),A3
LEA 0(A5,D0.L),A6
MOVE.L (A0)+,D0
LEA 0(A3,D0.L),A4
MOVE.L -E(A3),-(A7)
MOVEQ #0,D0
MOVE.B -2(A3),D0
LEA 0(A6,D0.L),A0
MOVE.L A4,D0
BTST #0,D0
BEQ.B (04)

Skimmed through the rest of the code before and after this and I couldn't find anything that looked like an obvious "move shortword or longword to Dx" instruction. Maybe it could be picking up the key opcodes from a fixed address elsewhere, but then, not knowing the key to begin with, such a thing would be hard to find!

Mind you, with Pushover I'm looking at the routine deep inside an already depacked EXE, whereas the EXE for LoS is itself packed and seemingly key-protected, so that probably explains it.

[StingRay]

The key is $5ED0 and it took me about 30 seconds to find it. I explained in your other threads what to do so I won't repeat myself here.

[MethodGit]

Well that showed me! Perhaps I shouldn't have taken the "find an instruction moving key to data register" suggestion at such face value. The only reference to $5ED0 I could find in the EXE was deep inside one of the RNC chunks within the file. So it's obviously getting its key through a calculation rather than being fed it directly.


EDIT: Hmmm, for some reason ProPack is claiming it to be the wrong key when I try to unpack the file with $5ED0. And XFDDecrunch thinks the EXE isn't even crunched at all.

[StingRay]

Originally Posted by MethodGit

So it's obviously getting its key through a calculation rather than being fed it directly.

That's obviously wrong:

move.w #$5ed0,d0

[MethodGit]

You sure that doesn't appear until after depacking or something? I've looked at the depack routine at the start of the EXE again and at no point does it list a "move.w #$5ed0,d0".

EDIT: Hang on, after unpacking the EXE from the TRZ crack release - which isn't key-protected - I finally discover a couple of references to the above instruction - which was inside a packed RNC chunk to begin with. No wonder I couldn't find it!

Also, without knowing you posted again at the time, I just updated my previous post. In short, that key still won't let me unpack for whatever reason?

[Galahad/FLT]

For a start there are two types of RNC Propack files.

RNC1 and RNC2

Legacy of Sorasil is packed with RNC1 which only uses a WORD size key

RNC2 uses a LONGWORD size key

I don't know why I bothered to check seeing as Stingray already did so, but frankly, I can't understand why you had a problem.

As I suspected, checking any routines that goto the depack routine took me straight to a MOVE.L #$00005ED0,d0 line of code.

The reason they've used a longword is to ensure that the higher word of D0 is clear, could be that they were going to use RNC2 at some point, but opted not to bother, but the code for the RNC Propack depack clearly only uses a word size key, therefore it is RNC1 depack.

[MethodGit]

Aaaah, so I see. I always wondered what differences between RNC1 and RNC2 existed.

BTW, Galahad, do you know if Sorasil's executable ("QuestII") is even unpackable with any tool? This is the command I feed to ProPack:

ProPack u a -k 0x5ed0 QuestII

but it just splutters "WRONG KEY" after a second or so.

[StingRay]

Of course it is unpackable, after all the game must run so it has to depack itself. And if you use the right key you won't get a "WRONG KEY" message either. $5ed0 is the key for the data files, to get the key for the executable you have to look at the decruncher code (as I said so often before) and then you need to find a way to obtain the key. Not very hard. I could give you the key (it's not much different to the key for the data files) but this time I want you to come up with a solution since you have all info you need.

[Codetapper]

I can't help but thinking that this thread is another case of some pretty slick tools showing up a lack of knowledge.

Finding the checksums in Player Manager 3 is probably 100 times more difficult than obtaining the key from this game.

Cracking a copylock by wiring a key into the encrypted part of a game would be also be far more difficult.

MethodGit has "achieved" both of the above, yet can't do this basic task?! This shows the tools (Stingray's source code for the crack of PM3) and the ROBD command (in Action Replay 4) are the tools that mean you don't actually require any knowledge of what's actually going on to be able to make something work.

I am guessing that a game that can't be decrypted with the ROBD command (such as Krusty's Fun House) would be an impossible task as you cannot rely on the tool to do the work for you.

Simple deduction would indicate that a compressed game must have the decompressor in it, and therefore the key must be visible there. Therefore the comment about the key only becoming visible after depacking is rather amusing.

There are a number of ways to obtain it but as Stingray says, you need to work some things out for yourself rather than relying on disassembling other people's cracks and WHDLoad installs to do "your" work for you.

Incidentally, why do you need to unpack this game? If it is to crack it yourself, that's a bit of a joke when you haven't been able to even decompress the executable without asking for assistance!

Running score: Legacy Of Sorasil: 1, MethodGit: 0.

[MethodGit]

Originally Posted by StingRay

Of course it is unpackable, after all the game must run so it has to depack itself. And if you use the right key you won't get a "WRONG KEY" message either. $5ed0 is the key for the data files, to get the key for the executable you have to look at the decruncher code (as I said so often before) and then you need to find a way to obtain the key. Not very hard. I could give you the key (it's not much different to the key for the data files) but this time I want you to come up with a solution since you have all info you need.

Well that explains it! I honestly thought it used just the one key for everything on the disk. BTW, just to requote a small part of the above...

(it's not much different to the key for the data files)

Care to explain how $BE1A is "not much different" from $5ED0?

(Yes, I found the key in the end. Mainly by inserting a BRA loop at the start of the routine, booting the disk, getting rid of the loop, then keeping an eye on the debugger and noting down any shortwords in the data registers that may look like keys. And eventually I whittled the small list down to one. Success!)

Originally Posted by Codetapper

I can't help but thinking that this thread is another case of some pretty slick tools showing up a lack of knowledge.

Finding the checksums in Player Manager 3 is probably 100 times more difficult than obtaining the key from this game.

Don't you mean Premier Manager 3? [/offtopic]

Simple deduction would indicate that a compressed game must have the decompressor in it, and therefore the key must be visible there. Therefore the comment about the key only becoming visible after depacking is rather amusing.

Not so simple when you're dealing with a game that plays about with two different depacking keys, and doesn't even reveal the first one of them within the executable itself (and the second one is hidden inside the chunk you're trying to unpack in the first place!).

[StingRay]

Originally Posted by MethodGit

Care to explain how $BE1A is "not much different" from $5ED0?

Second digit in both keys is $E. Rest was for you to find out anyway and I don't think I have to explain anything seeing how often I already did that!

Originally Posted by MethodGit

(Yes, I found the key in the end. Mainly by inserting a BRA loop at the start of the routine, booting the disk, getting rid of the loop, then keeping an eye on the debugger and noting down any shortwords in the data registers that may look like keys. And eventually I whittled the small list down to one. Success!)

A much easier and logical way would have been to disassemble the decruncher and look for an obvious instruction that uses the key.

Originally Posted by MethodGit

Not so simple when you're dealing with a game that plays about with two different depacking keys, and doesn't even reveal the first one of them within the executable itself (and the second one is hidden inside the chunk you're trying to unpack in the first place!).

Finding the keys is an extremely simple task, there's nothing even remotely hard about it! And what the fact that several keys have been used has to do with the difficulty is beyond me anyway.

[MethodGit]

Originally Posted by StingRay

A much easier and logical way would have been to disassemble the decruncher and look for an obvious instruction that uses the key.

And disassemble the decruncher I did. Comb through it over and over I did. Find an "obvious instruction" I did not. If there was any such thing, it was inside the archive!

Anyhoo, I mainly wanted to post in here again to report another troublesome game, but this time I'm getting strange results.

Overlord is pretty obviously hiding away a copylock within its executable, but I wanted to take a closer look at the file anyway. I quickly discover it's another file that doesn't want to unpack so easily. Fine, I go away and do what I did with Sorasil and note down as many different four-digit values in the data registers as I can find.

Now here's where it all goes rather pear-shaped. That or I'm not using the right tools.

XFDDecrunch - as with Sorasil - can't even detect that the exe is compressed. A quick WRipping the RNC chunk out of it later though, and I get the "enter 16-bit key" prompt. So far so good. Except it gurus the whole system regardless of what key I feed it.

ProPack seems to report no problem with the exe, except - erm - the file it outputs doesn't appear to be all that decompressed to me. If anything, all it did was recreate the file without the decruncher routine at the start of it. Flummoxed, I try the same command again on the new file ("pp u a OVERLORD.RNC"). This time it replaces it with a 20-byte file. Oh dear.
So I try feeding it the RNC chunk I took out with WRip. At least it can detect that it's key-locked! Okay, so I try feeding it a key........ instead of giving me the "WRONG KEY" error though, it takes a few seconds appearing to unpack it, and then reports "UNPACKED DATA CRC ERROR". I take a look at the file it sent to the Recycle Bin (that's WinUAE+ClassicWB for you! ) and I noticed the tool had somehow expanded the file to over 2Mb before ditching it.

Does anyone know if any other RNC-unpacking tool exists out there - perhaps something that doesn't keel over and die over a bloody executable such as this one? I'm unable to tell if I have the right key already because these two don't tell me if I'm wrong!

[Codetapper]

Firstly let me state that it's dangerous to simply assume the file is a standard RNC encrypted file and expect a tool to do your work for you. The programmer could make a tiny change somewhere in the routine, insert a longword somewhere and alter the decruncher by a few bytes and you would never be able to decrypt it.

But you don't need to worry about this. The decruncher is in the code, so it's possible to patch around it. Remember all the other threads you have started where people tell you to patch around the decruncher? This is exactly the same. If you intercept it after it's run, you can then alter memory to your heart's content.

I had a quick look at SPS 1312 and there's another method too. You need to read something about AmigaDOS files, hunks etc to understand it.

If you really wish to get at the file (presumably so "you" can "crack it") then in WinUAE it's a pretty simple task to intercept the decruncher at a couple of vital points. First you grab the decrunched data, and save that. Then you grab the RELOC32 table (again very simple to see where that is), bolt them together and bingo, you have the game.

You have to do it this way as if you simply grabbed the data after it's fully depacked and relocated itself, it will only run from a specific memory address which is very lame.

[MethodGit]

Originally Posted by Codetapper

Firstly let me state that it's dangerous to simply assume the file is a standard RNC encrypted file and expect a tool to do your work for you. The programmer could make a tiny change somewhere in the routine, insert a longword somewhere and alter the decruncher by a few bytes and you would never be able to decrypt it.

So this is different from, say, locking a file against decrunching (ala Dojo Dan)? Still, it sounds sneaky. So this game in particular isn't necessarily requesting a standard key (if indeed any key)?

But you don't need to worry about this. The decruncher is in the code, so it's possible to patch around it. Remember all the other threads you have started where people tell you to patch around the decruncher? This is exactly the same. If you intercept it after it's run, you can then alter memory to your heart's content.

That does sound like fun - it's what i try and do within NDOS disks after all. I just wish there was plenty of room within the executable to add my own code without taking it to an external file or the bootblock....

I had a quick look at SPS 1312 and there's another method too. You need to read something about AmigaDOS files, hunks etc to understand it.

You mean like what your Football Manager World Cup Edition tutorial was covering?

If you really wish to get at the file (presumably so "you" can "crack it") then in WinUAE it's a pretty simple task to intercept the decruncher at a couple of vital points. First you grab the decrunched data, and save that. Then you grab the RELOC32 table (again very simple to see where that is), bolt them together and bingo, you have the game.

You have to do it this way as if you simply grabbed the data after it's fully depacked and relocated itself, it will only run from a specific memory address which is very lame.

I'll admit I've never looked into the relocation table before. Does it usually come right after the decrunch routine?

[Codetapper]

Originally Posted by MethodGit

So this is different from, say, locking a file against decrunching (ala Dojo Dan)? Still, it sounds sneaky. So this game in particular isn't necessarily requesting a standard key (if indeed any key)?

It could be anything. They could add a fake longword after the length of the RNC section and make the decruncher skip that longword in any number of ways. Then it's no longer RNC so ProPack won't unpack it. It might well be RNC but the point is you shouldn't assume it is.

That does sound like fun - it's what i try and do within NDOS disks after all. I just wish there was plenty of room within the executable to add my own code without taking it to an external file or the bootblock....

You didn't manage it with the Treasure Island Dizzy crack, that was a perfect candidate. You don't need extra room in the executable, after all what kind of cracker says "sorry this can't be cracked as there's no spare room in the exe!". I haven't seen that on many Fairlight releases!

You mean like what your Football Manager World Cup Edition tutorial was covering?

Yep that's one way of doing it.

I'll admit I've never looked into the relocation table before. Does it usually come right after the decrunch routine?

No, the packed and encrypted data will have the game which consists of the game code hunk and the reloc32 hunk. You often can't get to the relocation table without depacking the file first.

Why don't you read something about AmigaDos file hunks and experiment a little rather than wanting me to give away the answers? Like Stingray does, you'll learn nothing if I just tell you how to do it.

BTW what is this for? Why do you need to decrunch this game so badly? If it's just to wire yet another copylock key in I'm not going to be impressed.

[MethodGit]

Well, from looking at some other Rowan titles, it's now obvious this was an intentional trick adopted by the company starting with v1.03D (revision 1993/04/05) of Reach For The Skies (the Ministry crack is dated 1992/11/05 but is repacked in a traditional Imploder format, and rather poorly at that as it won't run on 512k/512k setups (post-relocation packing is not a good idea!), so whether it was introduced any earlier than 1993 is down to whether someone with a 1992 original can confirm it or not. Now shut up MG!).

The one flaw with their means of protecting Overlord and Dawn Patrol, btw, is that I'm still free to hardwire the file regardless (magic line still visible, huzzah!), though I'm sure everyone will consider this "lame" anyway. From looking at a few cracks of DP and RFTS however, I've gotten a better understanding of what CT was talking about - altering the executables to squeeze some code in between the decruncher and the RNC chunk, though this requires a significant rebuild of the executable itself to make possible. Another thing I've discovered is that the copylock in OL and DP will only activate in the first place if the game is run in "floppy mode" (with the -f parameter). "Smart Alecs" assuming they can get round the protection by removing the parameter from the startup-sequence will be disappointed to discover that the disk requests will not pop up outside of this mode, resulting in an unplayable game.

So all in all, not something to shout about, just that nosey parkers won't be able to inspect the contents of both the executable and the hard-disk installer program straight off. Only RTFS needs a bit more work to crack due to it using manual protection.

Can someone help me on Tomb Raider 1 RNC2 Compression

[Lonewolf10]

Originally Posted by COOL12345

Can someone help me on Tomb Raider 1 RNC2 Compression

Why? What are you hoping to gain?

TR1 is an amazing game, and in my opinion still the best TR game released.


Regards,
Lonewolf10