Gripshift progress

[dkr]

Hey,
Gripshift seems to be quite a bugger to rip, but if it can be successfully re-packed, it will be 110mb(with music).

So far I've realised the following:

The obvious one, I'll include here anyway, is base.pak. It's 650mb and contains a buttload of {. It doesn't appear to need to stay at this size. I've managed to make the game boot with it at 108bytes.
The game, in some way, requires the files to be at appropriate LBA addresses (my knowledge in LBA stuff is very limited). To get a re-pack to work, even without anything taken out, I had to use the original LBA addresses. The only way I could get a re-packed ISO of the game to load was to put ifhandle.prx at LBA 357800 (and of course the rest of the files following it), which means that if you rip the base.pak file, you will just have a heap of whitespace in its place.
The ISO contains duplicate files with the same name, but difference case. This means that when you extract it to any windows-based filesystem, they will overwrite themselves and we will have lost files. You can get around this by either mounting the ISO and copying direct from there (doesn't work with UMDGEN), or extracting the 12 or so duplicates to different folders and manually dragging them in to UMDGEN.
The dirfile.txt file is required for a re-pack of the ISO to work. I'm not sure exactly what this means, but I'm pretty sure it means that the game works off this file. So if you actually want to make the game smaller, it can be assumed that you need to change the first column (these are obviously the LBA addresses).


So far I've been able to use UMDGEN to re-pack it at exactly the size it is supposed to be, with base.pak as only 108 bytes, but this means that there's just a heap of whitespace between the end of base.pak and the start of ifhandle.prx..

Attached is FileList.txt. The following is what I did to re-pack the ISO at the original size. Import FileList.txt in to UMDGEN to get your files in the right order. Once they're in the right order, you have to right click on ICON0.PNG (in layout mode) and put it at LBA 22331. Then put base.pak (can be any size..) at LBA 25000. Then put ifhandle.prx at LBA 357800.

Attached is also a modified dirfile.txt. This was my attempt at making the ISO smaller. This is for my 108 byte base.pak file, which fits in 1 LBA block (forgive my lack of actual LBA-related terminology). It didn't work, but I think it's in the right direction.

I'm not sure if anyone else has figured out this much/more. Any help would be appreciated.

EDIT: seems it doesn't get past the intro at all.. i'll still leave this post here in case anyone wants the info but i think i'll give up.

[OblivionX]

its impossible. We tried this a few months back, i changed all the lba values, rebuilt the table to match them and done everything I could think of. It just doesnt work. The good news is aparantly like most other psp titles, it sucks.

[dkr]

gripshift is an awesome game, i've been playing it heaps.

[Mr_X01]

anyone tried the new euro version? does it have the same size extracted and is ripping impossible too?
I mean, i guess it's the same problem, but who knows?... :rolleyes:

[TheBiGW]

I would guess it has the exact same problem. Don't think anyone who tried the last time has the heart to try again :)

[popcs0x0f]

I also had no luck yet ...
after going into race mode it seems to load forever,
but I noticed that my lba values are wrong.

dkr,

the CRC32 value of your dirfile.txt is corrupt.

I think the program is using the dirfile.txt with correct values

The file contains
a) starting LBA of the file,
b) the size of the file in bytes
c) a CRC32 sum and
d) the filename

so the lba values from the dirfile.txt should match the one on the iso.

I just compared the dirfile.txt from the my ULUS-10040 version with yours.

I think yours dirfile.txt is corrupt.
your printf function for the CRC32 value does sometimes fail.


use a grep and search above file for "+" sign.

e.g. findstr /N "+" dirfile.txt

line 194 the CRC32 should be
3875811 and not
3.88E+15

you will also notice that the size of the file will be smaller with the correct values.

here are the corrupt entries in the beginning you find the line number:

194:28939 864 3.88E+15 data/cmn/base/ui/keyboard/g_vk_highlight.gim
413:31350 4452 9.53E+64 data/cmn/base/ui/models/Biggs_Arm.gim
459:32895 14180 8.36E+12 data/cmn/base/tracks/BOMB_RUN.gmo
508:33233 33260 6.38E+10 data/cmn/base/tracks/DREADLOOPS.gmo
814:35742 5532 4.55E+169 data/cmn/desert/gamebits/p_1x1_tree_2.gmo
1009:37167 6388 8.55E+212 data/cmn/ice/gamebits/p_1x1_rock_1.gmo
1065:37640 23356 5.03E+89 data/cmn/ice/gamebits/p_aircraftHangar.gim
1646:42222 23216 2.41E+05 data/cmn/horror/gamebits/r_Start_Hor01.gim
2298:53789 132376 4.90E+10 data/cmn/base/ui/concept_art/Concept_27.gim



I also noticed that line 15 is missing a 0 in the beginning of the CRC32.
e.g. your file shows
8018353 and not
08018353

maybe the are more bugs ..., sorry


Interesting is that the CRC for the base.pak is 0 (it does just contain the "{" character).

Not sure if the CRC32 is used at all, if so the program could check the integrity of the specified file to see if someone modified it.

Why CRC32 ?
The boot.bin does reference a: "CRC %08x is wrong for %s"

looking into a zlib distribution (the compressing engine of zip) shows a crc32.c which generates a crc32.h

looking in Gripshift
offset 0x02a5da8 in boot.bin shows the start of that table

do a quick hex search for hex value 96 30 07 77 and you will find it at 0x02a5dac

below is an extract of the zlib121 version

/* crc32.h -- tables for rapid CRC calculation
* Generated automatically by crc32.c
*/

local const unsigned long FAR crc_table[TBLS][256] =
{
{
0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,
0x706af48fUL, 0xe963a535UL, 0x9e6495a3UL, 0x0edb8832UL, 0x79dcb8a4UL,
0xe0d5e91eUL, 0x97d2d988UL, 0x09b64c2bUL, 0x7eb17cbdUL, 0xe7b82d07UL,

...



popcs0x0f

[TheBiGW]

Wow dude hats off to you - you found something none of us found when we first looked at this.

[Loco001]

thanks for the contributions. lol at my ability to use excel at 5am.

also, are you very sure they're crc32 values? i used a couple of different programs that do crc32 checks and they all came up giving completely different values to what dirfile says (but the same as each other, so i know the programs are ok).. including 0xbc552278 for base.pak. also how would they get the crc value for dirfile.txt? it would change once the crc was put in there. sorry if these questions are stupid, i've not had much experience with ripping or crc.

i did some tests and found that neither the crc or file size parts of the base.pak line in filedir.txt need to be correct to run the game. not sure what this means exactly.


the game doesnt use the crc checksums. and also its impossible to write the correct crc of the dirfile into the dirfile itself witohout changing the crc again..see what i mean?

[dkr]

yes i do, hence why i was asking the question. so if they're not crc's, what are they?

[Loco001]

they are some kind of checksums but they aren´t needed for the game.

[infinity2005]

Setting every checksum to 0 bypasses it if i remember rightly.

[Loco001]

there isnt any problem with the checksums or so, i perfectly rebuilt the iso and let everything up to the dummy at the same lba and blabla...doesnt work

[Spirax]

Interesting is that the CRC for the base.pak is 0 (it does just contain the "{" character).

Not sure if the CRC32 is used at all, if so the program could check the integrity of the specified file to see if someone modified it.

Why CRC32 ?
The boot.bin does reference a: "CRC %08x is wrong for %s"

looking into a zlib distribution (the compressing engine of zip) shows a crc32.c which generates a crc32.h

looking in Gripshift
offset 0x02a5da8 in boot.bin shows the start of that table

do a quick hex search for hex value 96 30 07 77 and you will find it at 0x02a5dac

below is an extract of the zlib121 version

/* crc32.h -- tables for rapid CRC calculation
* Generated automatically by crc32.c
*/

local const unsigned long FAR crc_table[TBLS][256] =
{
{
0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,
0x706af48fUL, 0xe963a535UL, 0x9e6495a3UL, 0x0edb8832UL, 0x79dcb8a4UL,
0xe0d5e91eUL, 0x97d2d988UL, 0x09b64c2bUL, 0x7eb17cbdUL, 0xe7b82d07UL,

...
popcs0x0f

Hello, I am from Spain, and this is my first post on this forum.

I have been able to rebuild de iso, but I have been unable to remove the base.pak yet.
The CRC32 is used to read and save to the MS, I have delete the table on the boot.bin and after rebuild and load iso, give me the error data saved corrupted when try to continue the previous saved game.

the crc or signal on the dirfile is not used by himself, this mean we can modify the lbas of the files but not the size or the signal of the files and the iso will work.
the main problem is that the base pak is not loaded as file :-(
this mean that the boot.bin is going to the disk to the lba 25000 for the size &H28A00000 directly, doesn't matter if you delete the base.pak form the dirfile.

In order to read the lba, on the boot.bin they are using this instruction set:
ori a2,zero,25000
editing the boot.bin with a hex editor and the lba is on the positions &H12350C and &H12350D
in order to give the size they are using the instruction set:
lui a3,0x28a0
this lui put the last 16bits to 0
so the value will be &H28a00000
this value are on the positions &123518 and &H123519
I have tryed whit a file of 65537 bytes using &H0001 values but I have been unable to load the iso when I have changed the size of the base.pak file
At the moment I don't have enougth time to continue whit this, but if anyone can found this info useful to continue and arraive to a good port... will be welcome for the rest of us :-)

Regards
Spirax
PD:sorry for the mistakes with the English

[KingofKingz]

ok, i got this game, but it doesnt load at all!

after dumping the umd, i got a 853 mb iso.

I tried umd emu with copy load and direct load, but without success!

What did you guys do to load the full umd dump?

thx in advance!

[steve-efnet]

I has this iso of gripshift, it was 789mb, i compressed it with dax creator and now i have a fully functioning 75mb iso.dax you load it with daxziso loader and it works fine.

[Combustolux]

I has this iso of gripshift, it was 789mb, i compressed it with dax creator and now i have a fully functioning 75mb iso.dax you load it with daxziso loader and it works fine.

lol i was just about to post that anyways here's dax 0.61 if you dont know where to get it...
btw run it with mphgl direct load and make sure you have a firmware 2.0 or 2.5 dumped (i wont help with this part lol)