Having trouble decrunching the data from this exe...

[MethodGit]

Attached is the executable "jimmy.exe" from Jimmy's Fantastic Journey.

Looking at the file it appears to use Imploded data inside. I've extracted the chunk with WRip but XFDDecrunch complains that the data is corrupt and won't unpack it. I've tried looking closely at the header and determining the packed and unpacked sizes it notes but I still haven't been able to extract it successfully. It's either a "corrupt data" or "buffer truncated" error depending on how much data I've ripped.

I know for a fact it can be unpacked somehow because the exe from the Crest cracked version has countless binary modifications to it - a clear sign that it was repacked and injected back into the exe. I wonder how they did it?

[marty]

Hello MethodGit!

A very good advice would be; Don't try decrunch the file. When doing cracks, you will run into lots of diffrent crunchers. Some are very common, and some and custom or some might be common, but with few mods, so it can not be decrunched anymore.
Trust me, its a waste of time.
You should rather disassemble the file, find the decrucher, and hook a call end end of it, too call your patch, when file is decrunched.
This is from my experience, far the best way. You will run into key-locked ProPack files,
ByteKiller routines with no header, files with fake headers, etc.
Don't decrunch, patch!

[MethodGit]

Originally Posted by marty

You will run into key-locked ProPack files,

Does that explain why some RNC chunks extracted with WRip won't unpack as XFD complains that they're corrupt?

ByteKiller routines with no header,

I only know of PowerMonger as one such game that does this, and Amiga Patch List helps you deal with that in great detail.

files with fake headers, etc.

You mean like ATN!, CHFI, CHFC, MICK etc? XFD can detect the format for many of those as it is (and if not I just have to check this page), and when repacking I simply change the header back to how the game sees it.

Don't decrunch, patch!

Thanks for that - I'm just determining which games can be cracked both the soft and hard way. I think JFJ was only hard-cracked, mind you.

[Asman]

Originally Posted by MethodGit

I'm just determining which games can be cracked both the soft and hard way. I think JFJ was only hard-cracked, mind you.

I don't catch with hard and soft way. Could you explain a bit more. Thank you.

[Codetapper]

MethodGit: Just trust us on this one and stop arguing. You will not be able to decrunch every file with XFDDecrunch to alter it. Patch the end of the decrunching routine and you will be able to do anything you wish.

For your info, a headerless file wouldn't have the PP20, IMP!, RNC etc identifier at the start so it just appears to be a random stream of data.

[MethodGit]

Originally Posted by Asman

I don't catch with hard and soft way. Could you explain a bit more. Thank you.

Soft = alter specific routines in memory only, like what a bootblock patch does.

Hard = find the routine in a file and alter it directly (i.e. permanently).


And yes, I'm aware some formats can't be decrunched by any program or be repacked. Then I'll go around it via memory-patching. I am a fan of and do collect both soft and hard hacks!


BTW, can anyone confirm whether the Imploded data in this exe can actually be extracted or not?

[Codetapper]

Yes of course it can be extracted since the game does that.

[MethodGit]

Originally Posted by Codetapper

Yes of course it can be extracted since the game does that.

And obviously Crest were somehow able to extract it since they modified the data inside of it. This is what I'm talking about.

[Codetapper]

Why are you assuming it is imploder data? Just because it has IMP! in the file doesn't mean anything. The coders probably put that in thinking lamers would guess it's imploder data and wouldn't be able to decrunch it, and they're right!

[MethodGit]

Well so far I've renamed the header to PP20, RNC and Ice! and neither of those have worked so far. (XFD seemed to confuse the PP20 header with Pack-Ice for some odd reason.)

Here's Crest's exe for comparison. Something has to explain that massive chunk of difference in data. I highly doubt a simple manual check needed several gazillion bytes changing to defeat it either.

[StingRay]

Originally Posted by MethodGit

Well so far I've renamed the header to PP20, RNC and Ice! and neither of those have worked so far. (XFD seemed to confuse the PP20 header with Pack-Ice for some odd reason.)

Not too surprising since it's not crunched with any of the mentioned crunchers. Decrunching the data is easy if you know how, obviously, you need the decrunch routine and this must be somehwere in the executable as otherwise the game wouldn't be able to decrunch its own data. Thus, if you locate the decrunch routine and understand its parameters (just check how it's called in the game code) you can decrunch the data easily. I have attached a source which will decrunch both packed data files and I used exactly the approach I described to do that.

[MethodGit]

Well thanks for this! I suppose I need to run this through ASM-One or any other assembler to make a program out of it?


And I take it that those IMP! headers in the exe are actually a load of fibs then?

[StingRay]

Originally Posted by MethodGit

Well thanks for this! I suppose I need to run this through ASM-One or any other assembler to make a program out of it?

Any assembler that supports the new Motorola syntax should work. If you're using ASM-One you can easily look at the decrunched data with "h.lbuf" (buf2 if you want to look at the 2nd buffer) or "n.buf" (for ascii dump). You can also easily save the decrunched data with ASM-One's "wb" (w.rite b.inary command) and look at it with any tool you like.

Originally Posted by MethodGit

And I take it that those IMP! headers in the exe are actually a load of fibs then?

They are fake, yes. Just done so it couldn't be decrunched with the "normal" decrunchers.

[MethodGit]

Once again, thank you! I must admit though.......... while I was waiting for some help at the time, I decided to try and see if I could work around it with (you guessed it) a boot patch. My code to date:

7000C = BSR     000700C0
700C0 = LEA     000000C0,A0
700C6 = LEA     70100(PC),A1
700CA = MOVE.W  #200,D7
700CE = MOVE.B  (A1)+,(A0)+
700D0 = DBF     D7,000700CE
700D4 = LEA     7004C(PC),A1
700D8 = RTS

70100 = ADDA.L  #92,A1
70106 = MOVE.L  #4E714E71,(A1)
7010C = SUBA.L  #92,A1
70112 = ADDA.L  #B8,A1
70118 = MOVE.L  #4E714E71,(A1)
7011E = SUBA.L  #B8,A1
70124 = JMP     (A1)

Next, editing Jimmy.exe was necessary, to add a JSR C0.S instruction close to the start of the file. However, the one convenient spot to place it (see screenshot) seems to be bookended by important functions on both sides. Ironically enough, I've come the closest to success from leaving out the "MOVE.W #F00,00DFF180" instruction anyway - the result is that the attract mode (upon appearing for the first time) looks screwed up and not really getting anywhere, but as soon as I start the game everything looks fine again, and when I quit back out, the attract mode is fixed up also. In comparison, attempting to transfer either the aforementioned MOVE.W or alternatively "DBF D7,0003011A" to the patch area at 100 has resulted in a guru just as the protection screen is supposed to come up (or - in the case of my patch - not come up ). If there's anyway in which I could get around this or generally improve my code all round, do let me know. Thankie.

[StingRay]

Originally Posted by MethodGit

70100 = ADDA.L  #92,A1
70106 = MOVE.L  #4E714E71,(A1)
7010C = SUBA.L  #92,A1
70112 = ADDA.L  #B8,A1
70118 = MOVE.L  #4E714E71,(A1)
7011E = SUBA.L  #B8,A1
70124 = JMP     (A1)

A tip: Instead of these "add/sub" orgies which will significantly bloat the code you could either use something like:

lea    92(a1),a2
move.l #$4e714e71(a2)

or

move.l #$4e714e71,92(a1)

Originally Posted by MethodGit

Next, editing Jimmy.exe was necessary, to add a JSR C0.S instruction close to the start of the file. However, the one convenient spot to place it (see screenshot) seems to be bookended by important functions on both sides. Ironically enough, I've come the closest to success from leaving out the "MOVE.W #F00,00DFF180" instruction anyway

That's quite a dirty solution since that code is called when an error occurs (out of memory, library could not be opened).

Originally Posted by MethodGit

In comparison, attempting to transfer either the aforementioned MOVE.W or alternatively "DBF D7,0003011A" to the patch area at 100 has resulted in a guru just as the protection screen is supposed to come up (or - in the case of my patch - not come up ). If there's anyway in which I could get around this or generally improve my code all round, do let me know.

No wonder, the dbf instruction contains the branch distance which will change once you add code there so you'll face a crash. Also, the dbf instruction only works in a distance of 16bit, if you call it from $100, the distance would be MUCH too large!
I'd place the patch at the beginning of the loop, i.e. I'd replace the move.l (a5),d0 instruction with a jmp $c0.w. And in your patch code you'll have to add the code that's executed in the original executable of course.
I.e. your patch would look like this:

.loop	move.l	(a5),d0
	add.l	d1,(a1,d0.w)
	addq.w	#4,a5
	dbf	d7,.loop

; a1: start of decrunched data
; patch it
    ...

; let's go
     jmp    (a1)

Edit: Also, read about LoadSeg, that way you would not need any of these dirty low memory hacks. What you'd do is this:
- load the executable using LoadSeg (dos.library)
- before starting it you install your patches
- start the just loaded executable

[Codetapper]

For a LoadSeg example without modifying files, have a look at Football Manager: World Cup Edition on Flashtro. Just ignore the copylock stuff!

[zenox98]

V nice example, Codetapper. Many thanks