Ripping problems

Fellas,

I am sorry you are having issues w/ the rip. If I can get a few of my friends on to read what you have done maybe they can help (50/50).

If one of you would like to do a write up of where things stand now I can send it as a question to one of them (which he said he was up for answering any questions that he can).

Monk

 

Thats very kind of you, monkfish. Fingers crossed your friend can help. You'll need to get a message from familyguy, legit or hian I'd say. They're the guys doing the cracking.

Yakumo

 

hian could give the most technical answer among us three. I'm nowhere near as good as him at reverse engineering this stuff. All I could do was to notice that this game is really unusual, and contacted some people.

 

FYI the IP.BIN looks pretty much like the one from the SDK KATANA\Utl\Dev\GDWorkshop\SoakTest\ip_hda.bin

As for the 1ST_READ.BIN, it is just weird in general as are 8 bit vram writes, barely legible TOC and no reference to CD001 Whatever magic is in the SYSTEM-DISC 2 avoids all of the weirdness though.

If all goes to plan I'll be incredibly skint but coming home with a 5.24 tomorrow, but given as there is a Nandos a stonethrow away from the train station I'm still trying to wangle a trip there as part of the deal lol

It has been a busy week though and my mum returns tomorrow from an 8 week trip away looking after my Granmda who recently had an operation on her cancer so I may be busy for another few days too.

 

Is the 1ST_READ.BIN contained in the file (geist_bootbin&bootsector.zip) that was posted with this thread scrambled or descrambled?

Thanks.

 

Well upon looking at it the only thing we can say is it is strange, but as the files are posted several pages back feel free to see for yourself. If ASSEMbler gets the new rotary and dip switches he needs for his 5.24's (all of his are broken) it may be possible to hook the box to the VNC box and using GD Workshop, create a new project with the extracted files, writing a new IP.BIN, IP0000.BIN (with IP Maker) and a less weird 1ST_READ.BIN along the way.

It has been a long time since I played with GD Workshop so I'm going to have to relearn a lot of things which is not helped by the fact the 166Mhz laptop I'm using only has a 2Gb HDD and seems to hate my mouse (Damn you Windows 98 SE!)

 

@LeGIT: First, you shall not bitch about Win98SE, the best OS made by windows so far. Also, end of the possible OS-war in this thread.
Second, I don't think you can modify a compiled binary even with the SDK. What the SDK could be used to, though, is to build up a GD-M image of the game and launch it on the DevKit and debug the booting process with the DevKit itself.

@AltRN8: The bootbin is as on original disc (unmodified). I'd assume it's scrambled then.

Free INFO on ip.bin hacking:
As part of the Mil-CD **ORIGINAL/GENUINE** boot method the bootbin is unscrambled and the gd-rom is locked, this way the weird music dreamcast mil-cds have to get their executable in a single file and can't access the gd-rom for anything else than reading GDDA tracks.

The hacked Mil-CD exploit adds a rescrambling step and a gd-rom unlock step to the original mil-cd bootstraps, making it possible to launch scrambled binaries (aka games) with access to other files than the bootbin (levels, music, textures, etc.).

Cheers,

FG

 

haha FG I got the mouse sorted in the end. As good as 98 SE is, it can still be a pain in the arse (though I prefer Win XP - there I said it )

I wasn't meaning editing the binaries BTW I mean writing/compiling an entirely new 1ST_READ.BIN. Obviously it is possible to write one with the kit, but writing a new one from scratch to make this work... eugh... probably doable but could take a fuckload of time, but time is on our side. Not that I'd want that task though!

As you say GD-M is an option and naturally I did intend to mean testing via that too as it is part and parcel with GD Workshop (damn thy briefness) but given as Geist has a lot of files and GD Workshop seems to ahbore adding multple files at a time, it could take some poor bastard a very long time indeed to create the project to even begin testing which means I'd probably be that bastard given the mediocre task haha.

 

Hey Legit

Just a quick one for you: I have tried replying to your PM's but system says your mailbox is full and won't take anymore mail!

feel free to delete this after you get it sorted

Cheers!

 

No idea what the problem is with my PM's - I got 25 this week the last being on Wednesday. I tried disabling them and applying then reapplying, maybe it did the trick.

After some faffing about I got the emulation to finally work in GD Workshop for Bomberman Online. It took couople of hours to defrag and chkdsk /r but in the end I swopped out my SCSI card which did the trick - I guess it was a transfer rate issue. Still, it wouldn't have hurt much to give the drive a good seeing to, just a shame it isn't as nice as my old 36Z15 Hopefully now I'm getting som more practic with the tools on my end ASSEMbler can set up a box on the VNC machine on his end to speed things up.

If you fancy some practice with GD Workshop etc in the meantime FG, I could perhaps arrange for some VNC love on the 166Mhz laptop but not right now it has been a busy day already. It's debtable how much difference the tools will mke though as CodeScape looks like the nullDC debugger, just with more cowbell. It is however an lot esier to to stop and start the CPU when debugging without crashing like on nullDC.

 

I've asked my brother to see if he still has any contacts from when he was in the industry. He knew a few guys that programmed retail Dreamcast games back in the UK. He hasn't kept in touch he said but he'll try to find out what he can. He also want to see this game make it out.

Yakumo

 

FYI the 1ST_READ.BIN check in question is for a Kamui demo which is simply a case of converting a premade ELF to BIN and renaming it (I wonder if there is a tool to convert BIN back to ELF to run through CodeScape without the rest of the Geist files) so it is not very helpful, but it basically describes the .CDI 'symptoms', though perhaps there is a different cause.

I'll do some more digging but now my mum is back she is throwing all kinds of crap out, half of it which is mine and useful so I have to keep an eye on her so she doesn't bin another 6 Dreamcasts + BBA again!

EDIT: Also I tried running the posted 1ST_READ.BIN on my GD-M. I had to tick to pad out the track, which put the 1ST_READ.BIN at LBA 547342, just as in the GD-R.

The log is as follows:

It could be going back to 45016 twice for whatever reason. Bomberman Online goes back to the TOC 45016 (once) then 45020 (once) then loads the game data. Because I don't have the MIFFVIEWER.MINI or the title/debug screen files I can't comapre thoroughly with other games as none of the other games I tested do this. F355 Challenge has more weirdness in common with HDR-008 Geist Force IMO, I'll burn one of my last few CD-R and give it a twirl.

EDIT some more: I burned the F355 binaries to import on the 166Mhz laptop to the 5.24, even though it has the similar weirdness of 2x 6E B0 00 before CD001 (though HDR-0008 Geist Force technically has no CD001, not in the 1ST_READ.BIN anyway), the same deal as with Bomberman in that it only re-reads 45016 once after the 1ST_READ.BIN, not twice then moves onto 45020, then onto the game files.

 

That is exactly where I said it is suspicious that 45166 is being accessed twice (45166=45016+150) and tried to bypass although I don't have high hope in such a simple hack.

Again, I don't think something hard written on the GDR will fool NullDC to bypass the protection. It should be something like unknown GD commands/hardware properties thats not emulated properly by NullDC

Hope you have better luck with debugging in GD workshop.

 

hehe I know it is just seeing it via another method both confirmed it and looked strange in of itself

I ninjad a handful of files with consent to get me to the title menu (as the file names are ambiguous), then stripped back to the bare minimum needed to load the debug menu only - as expected the 1ST_READ.BIN refuses to function without the MIFFIEWER.MINI and a handful of fonts, though if other files and folders are present it will load additional files but if they are not present it will get to the menu without them. The only way to be sure of what will load and when is to ninja the whole game, but as trustyworthy as I am, especially given as I've already lost a few $k to the project, I don't want another Propellor Arena on my hands (no offence to ServiceGames and Belokk intended).

At the same token I don't think I'm the best man for the job - I'll get there but it will just take me longer. I'm hoping for ASSEMbler's permission to release the files to get people to the debug menu only, perhaps with the additional loaded files so people will be able to do more thorough testing on their end too.

That said I have a FYI for you too - with the exact same files as testing in NullDC and on a retail Dreamcast via HKT-06 GD-R, the debug window shown at the bottom left hand side of the screen is not present when ran on a HKT-0120 5.24 Dev.Box

As for the actual debugging proper I'm yet to start, a lot of my time today has been spent so far on testing and preparing the additional files to release as a pack to get people to point where they can run the tests themselves I'm just finishing off preparing 2 versions of the pack - one with the bare minimim of MIFFVIEWER.MINI and the 4 required fonts to get people to the debug only and a second pack with the additional files which are loaded, though only the first pack should be needed. I may still have to have the laborious task of creating dummy files yet so the LBA positions are the same though perhaps that would be taking it to the extreme!

Anyhow the version of the pack whether it is the bare minimum or additionally loaded files and dummied or not will depend entirely on ASSEMbler's consent, but my hope is that if such a pack were released, people will be able to test at home as and when but at the same time won't compromise the main game as they will lack the game data to do a ninja release.

EDIT: it took me about 6-7 hours to prepare the release with a couple of distractions, including manually dummying the game data files and writing a new sorttxt.txt.

That is 6-7 hours I could have spent debugging myself and maybe getting nowhere, but once the files are out, with dozens of people each working 6-7 hours the man hours will add up exponentially and the game will be cracked that much sooner.

The pack is about 1mb packed but about 600+Mb unpacked so please be aware of this. I can confirm with the majority of the game data stripped away that my dummied release behaves in exactly the same manner as the full release on the VNC box. I have not included the additional files which load in the debug menu, but in the unlikely event they are needed, they can be added after a couple of hours work and testing.

I don't think ASSEMbler will have a huge problem allowing me to post the dummied release given as basically only the debug menu functions (though the file directories and sizes may constitute small spoilers), but I would prefer to run it by him first and he is offline at present.

 

Geist Force Bare Necessities

EDIT some more: ASSEMbler came online and granted consent to post the dummy which took me several hours to make -_- (I will merginate later)

Basically the pack contains the 1ST_READ.BIN, MIFFVIEWER.MINI and the 4 font files required to load the debug menu. It also contains the directories dummied to the original names and sizes so as not to give the game away but put everything in it's place so everyone has the correct experience etc. Lastly I rewrote the original sorttxt.txt from the 1700+ entries to my dummied files and the original IP.BIN is included as well as FG's IP.hak

There are 5 'preloaded' files I was tempted to add but neglected to do so as they do not have any major bearing on the particular problems were are experiencing, but with another 2-3 hours of editing and testing they can be added at a later date, if necessary.

Without these 5 'preloaded' files though you will still be able to replicate the errors we are having on the VNC box and for those of you without VNC access, you can work on and test the files on your own machine in your own time - it will basically increase access to the relevant files without compromising the game security ala Propellor Arena.

Just to be clear, the game has been stripped down to the bare essentials to load into the debug menu only, the rest of the game has been dummied/faked and if you try to load the game beyond the debug menu it will crash as there is no data

If you compile the pack and mount the SelfBoot.nrg on Daemontools then load into nullDC via X:\ the .nrg will boot.

If you rip X:\ into a .cdi via Padus DiscJuggler and mount the .cdi onto X:\ then load X:\ in nullDC it will boot.

If you load the .cdi directly into nullDC it will crash after the licence screen just as the debug menu is due to appear - these are the same symptoms we experience with the real McCoy and which the dummied version accurately replicates.

Also to be clear, the debug window in the bottom left of the screen does not appear when ran on a Set 5.24!

Geist Force Bare Necessities.rar 984.78 Kb (Warning - will extract to 600+ Mb!)

Happy debugging!

 

Good Stuff LeGIT, I hope this will ease the cracking of this game. I'll be extremely insanely very pretty busy in the next months because of real life, so I won't be able to work on this a lot sadly. I'll still be available for questions on some stuff though, mainly the mil-cd/gd-r/gd-rom formats or SelfBoot techniques if needed.

Cheers,

FG

 

Thanks LeGIt I've been wanting to see if I can help with this effort but felt hamstrung without access to more of the game. This should totally do it.

I thought of one idea regarding the debug menu. Have you looked at the serial output on a debug unit to see if the game is redirecting the debug menu output to a serial port when launched from the devkit?

This wouldn't necessarily be related to the problem but could rule out a possible red herring.

*Polishes off SH-4 Programming Manual*

 

ok
i am going to pass this to some1 that can really crack this shit
more news soon

 

A dozen people debugging 7 hours each would get a lot more work done in the same amount of time than one person. This is the reason I spent several hours making the pack instead of debugging as a dozen heads are better than one, right?

I hadn't considered this, but alas I butchered pretty much all of my RS232 cables for internal mods on my Dreamcasts as I was too much of a cheapskate to just buy new heads. Luckily I did find a partially butchered female to female which should do the trick, but I'm on my first few days using a Set 5.24 after a several year absence so not sure where to begin with this idea just yet It is getting late now so perhaps it is something I'll have to look into tomorrow.

That's the spirit

 

I did this about a month ago, it's a really hard one trust me.