Ripping problems

Strange. I have tested Eledorado Gate 4 no less than a dozen times last time.
Now I re-tested it and yes it "works". (The various protections kicks in later in game and they won't crash the game, just limited your progress - but these are not the point here. Pls refer to Hyk-EG4.nfo if you are interested)
Anyway, so this point is irrelevance now... Sorry for confusing you.

Edit:
---------------------------------------------------------------------------
Now more testing shows what is "works" and "not work". My record was just not detailed enough and confuses even myself.

NullDC 1.6:
with raw .cdi and .gdi, you will be stuck at the main menu of the game. Button A will not take you to the game proper.
with x:\ (.nrg or .cdi) Button A will let you proceed

NullDC 1.03:
Nothing works. All stuck at the main menu
--------------------------------------------------------------------------------

Nettou Golf uses a few protections. One of them is to check the LBA of 1st_read.bin - If it is not close to 1G, it will crash. If you defeat this protection ( change offset 0xac224 in 1st_read.bin from 0389 to 03a0 ), it will work in NullDC but other protections will prevent it from booting in retail DC

 

the problem is the 1st_read.bin or the ip.bin? if is the ip.bin i can give you of system shock 2.

 

Hard to tell at this stage.

I just found an interesting thing about the IP.BIN:
In Dragon Blood, there is a file "RELEASE.ELF"
Inside it, I can find what I believe to be an IP.BIN and 1st_read.bin embedded.
The Hearder part of the IP.BIN looks exactly the same as the one from Geist Force:
"SEGA' instead of CRC, 5 digit peripheral string, exactly the same date and "Not out of the office" notice.
So this maybe just a "standard" sample IP.BIn from some dev kit.

 

I've not been clear enough, the CD001 I'm talking about is not the one from the session TOC, it's the one found in almost every katana 1st_read.bin.

For those who might want to know:
Usually, 8 bytes before this CD001 string there's an integer in big endian that represents the starting sector of session2 in physical address (hd area on a retail GD-ROM) 45150 or 0x5EB00000 by defaults. This is the value usually patched by binhack.

@ pato
The problem is either ip.bin (bootsector), 1st_read.bin (bootbin), both or either. But another ip.bin wouldn't help. If the ip.bin is the problem, it'd be because of an unknown bootstrap that the mil-cd hacked bootstrap (srambling/unscrambling stuff then gd-rom reset) doesn't take care of or can't replace. Thanks for the suggestion though, we need suggestions!

I've contacted the guy who cracked Nettou Golf, we'll see if he can (or want to) help us!

Cheers guys,

FG

 

Have you checked the gd-r dump to see if the iso9660 header has some other system identifier value? It would seem likely the CD001 in the 1st_read.bin is the iso9660 system identifier its looking when trying to setup the iso9660 filesystem.

nullDC may just be ignoring the system identifier and always using the first iso9660 filesystem as part of its emulation.

-ack

 

I think I did it... CD001 is my bitch!

6E B0 00 00 - 01 00 00 00?

HDR-0008 Geist Force only has one mention of an 001 / 30 30 31 - and guess what? I spotted it has an 6E B0 near it too, sort of, except it is E6 0B (reversed digits) however the remainder is non-standard. I decided to ignore this as the 001 could be anything but the disc number and there are stupid number of two pair possibilities.

Following a similar train of thought however I started to search for 6E B0. Naturally this 2 digit string is quite common, so I expanded my search to 6E B0 00. This reveals only a handful of results in the 1ST_READ.BIN's I am checking.

I started to compare this new 6E B0 00 search string in the 1ST_READ.BIN of the following 3 track Sega first party Dreamcast games:

HDR-0001 Sonic Adventure
HDR-0002 Virtua Fighter 3tb
HDR-0003 Blue Stinger
HDR-0006 Net Golf
HDR-0007 The House of the Dead 2
HDR-0015 Atsumare Guru Guru Onsen
HDR-0019 Akihabara Dennou Gumi Pata Pies
HDR-0020 Dynamite Deka 2 (Dynamite Cop)
HDR-0029 Space Channel 5
HDR-0045 Virtua Striker ver.2000.1
HDR-0063 Samba De Amigo
HDR-0080 18 Wheeler American Pro Trucker
HDR-0081 Virtua Athlete 2k
HDR-0100 F335 Challenge Passione Rossa
HDR-0118 Outtrigger
HDR-0129 Phantasy Star Online
HDR-0165 Sonic Adventure 2
HDR-0168 Guru Guru Onsen 2
HDR-0172 Candy Stripe
HDR-0178 Rez
HDR-1234 K-Project (Well to be anal it is Vibe as no floating people)

Now the one thing I have noticed is that the majority of these 68 B0 00 strings in games are proceeded by F6, making them F6 6E B0 00 etc. The ONLY time the proceeding bytes change is the string directly before CD001 where it becomes 0C 6E B0 00 etc or 8C 6E B0 00, but basically anything except F6 ie. XX 6E B0 00.

Why is all this relevant you may ask? HDR-0008 Geist Force only has three 6E B0 00 strings. The first of which is what I've seen as the standard F6 6E B0 00. The other two are 0C 6E B0 00. Now compared to the other games two of these strings is certainly a little odd, but then again Geist Force initially boots into a debug menu before you get to the title screen, so I initilly assumied (due to not VNC for the more detailed crash log) that one string is for each, however as Outtrigger follows a similar pattern (and is copy protected) it is possible the first string is part of copy protection, or nothing and the second string is the true value we need.

HDR-003 Blue Stinger, HDR-0063 Samba De Amigo, HDR-0165 Sonic Adventure 2 and HDR-0045 Virtua Striker ver.2000.1's 1ST_READ.BIN is a little different in that it only has the one 6E B0 00 string so it is hard to go wrong, but it is not so unusual as the other games only have a couple of 6E B0 00 hits and only one non-F6 6E B0 00 hit anyway which is always 6E B0 00 00 01 00 00 00 followed by CD001.

----------------------------------------------------------------------------------

HDR-008 Geist Force instances are:

34 E3 6F 26 - 4F 0B 00 F6 - 6E B0 00 BC - C0 00 D0 00 - A8 00 80 00
A8 0E 22 0C - 04 11 22 0C - 6E B0 00 00 - 60 58 34 0C - C4 0F 23 0C
00 F8 09 00 - 04 11 22 0C - 6E B0 00 00 - 3C 17 22 0C - E0 87 34 0C

----------------------------------------------------------------------------------

HDR-0080 18 Wheeler American Pro Trucker is a little different to the other games, but similar to HDR-0008 Geist Force in that it is proceeded by F6 in most instances but something else on not one but TWO occasions, with both occasions being 0C's detailed below

5E B0 00 00 - C0 04 13 0C - 6E B0 00 00 - 60 00 13 0C - 20 00 13 0C
80 13 13 0C - 20 1A 13 0C - 6E B0 00 00 - 01 00 00 00 - 43 44 30 30 31

----------------------------------------------------------------------------------

HDR-0100 F335 Challenge Passione Rossa is also similar to HDR-008 Geist Force in that it is proceeded by F6 in most instances but something else on not one but TWO occasions, with both occasions being 0C's detailed below:

B8 42 27 0C - 20 F8 0D 0C - 6E B0 00 00 - 00 F4 0D 0C - C0 F3 0D 0C
C0 05 0E 0C - 40 0C 0E 0C - 6E B0 00 00 - 01 00 00 00 - 43 44 30 30 31

Also note: HDR-0100 F335 Challenge Passione Rossa doesn't have a single 5E B0 00 00 reference in the 1ST_READ.BIN

----------------------------------------------------------------------------------

HDR-0118 Outtrigger is also similar to HDR-008 Geist Force in that it is proceeded by F6 in most instances but something else on not one but TWO occasions, with both occasions being 0C's detailed below:

5E B0 00 00 - C0 96 15 0C - 6E B0 00 00 - 60 92 15 0C - 20 92 15 0C
80 A5 15 0C - 20 AC 15 0C - 6E B0 00 00 - 01 00 00 00 - 43 44 30 30 31

----------------------------------------------------------------------------------

Given the fact the address spaces are so close together and so prominent one would assume that my debug and title theory could be correct. Given numerical order one would assume the first value is the debug menu and the second is the title menu. It is however more likely the first could be copy protection and the second the string we need. Or it could all just be a bunch of bullshit and Geist uses a completely different set of strings altogether but it is not likely to be just a coincidence!

My money though is on 6E B0 00 00 - 60 58 34 0C being protection based or unrelated and following the other precedents, 6E B0 00 00 - 3C 17 22 0C being the value we need and the following digits an alternate CD001 or something else, but it hasn't been patched in the self boot pack becuse the pack looks for 6E B0 00 00 - 01 00 00 00?

It is worth patching for 6E B0 00 00 - 3C 17 22 0C purely to see if it makes any form of difference, but if there is other protection or problems, possibly not. I do not know what those new values should be nor do I have the time to fuck about to find them (I have to go out today) but no doubt Family Guy will know what to do with this new information, though it could still amount to nothing. I am willing to bet if it doesn't single handedly fix our issue it is part of the problem though which will give us clues elsewhere too!

EDIT: I will update with more compared games as I go along, I want to get this info out there now as I discovered this several hours go, it just takes so much time testing and editing the rest for my precedents and presumptions to be 100% correct!

 

that was over my head.... lets hope this leads to something

 

Awesome finds LeGIt let's hope it finally cracks it.

However after reading all of that:

 

@ Legit:

I was talking about the binhack integer, which is 5E B0 00 00 == 45150.
Often there's also 45000 and 45166 integers, 6E B0 00 00 == 45166 ; C8 AF 00 00 == 45000.

binhack32 (binhack clone I wrote) looks for CD001 and patch the value 8bytes before it. I don't know how original binhack find the offset to hack but it's the same result.

I hope we'll figure this out.

FG

[EDIT]

Also, since we're making a 45000LBA backup, the LBA-related stuff should not matters. It's weird that it is not there, but we should not have to change these value anyway since we're making the backup at 45000LBA...

@ ackmed, you can look for yourself in the binaries if you want, I've attached the bootbin and bootsector. It was already posted by ASSEMbler so I just zipped it and posted them together.

 

Peter, is this the 1st_read.bin and ip.bin for geist? Very strange 1st_read.bin, 3 mb.

 

Yes it is, and yes it's weird.

 

FG I know of AFC8, AFD8 nd I'm also aware of the 150 sector offset (or whatever you want to call it) B05E, B06E, I'm just not used to seeing them in other forms - but I also know you meant that, it just inspired me elswhere as we know it doesn't just die on the TOC but it can emulate fine to 45,166 - I figure the reason why it works in Daemontools is because the emulation can either pretend it is standard ISO 9660 or sort of mod chip / bypass the check altogether.

Padus DiscJuggler works because it can understand the Dreamcast-modified ISO 9660 file system so it can present the file system in the .cdi - the other apps don't really care about the quirks of the Dreamcast, they look for a standard ISO 9660 which is why they tend to fail.

The problem with Geist is that is is not even attempting to advertise itself as Dreamcast modified ISO 9660 let alone standard (as far as we can tell), so without emulation it fails on direct injection. It is for this reason why your IP.HAK got us to boot, but now it is the 1ST_READ.BIN which is causing the next problem s it dies after the licence screen, hence why I'm so focused on 45,166.

I will extend my hex values and re-evaluate my theory but I'm pretty sure I'm starting to get my head around it, but my brother is leaing for London soon so he just invited hmself around so I am somewhat preoccupied at present.

 

But if the game will be selftboot, the selfboot ip.bin must be created with selfboot scripts, well i ve replaced the UNKOWN UI with SEGA ENTERPRISES, but i don´t know if is going to do something

http://hotfile.com/dl/115331930/8a16ac2/1ST_READ.zip.html

i think is the only decent host server that i can upload something, after my videocard capacitor have blown up i can´t upload nothing, nor even in the forum

 

@LEGiT

My ip.hak made you boot because I've hacked it to add the Mil-CD exploit bootstraps and the size of bootbin. When you used binhack, the program couldn't find the right LBA references in the bootbin (8bytes before CD001 in bootbin, not iso header) and aborted before hacking the bootsector (ip.hak). The hacked bootsector actually got no LBA references in it.

@pato

I don't think that's the issue, but it's worth trying once we can VNC again in a machine with the files.

FG

 

just remembered something, the xVI32 detected more than 100 times the UNKNOWN UI, and the strange size of the file, lets hope there was no duplication like ecco the dolhpin 2.

 

This isnt really what I was talking about. Have you looked at the iso9660 filesystem on the raw gd-r dump to see if it has a non-standard system identifier (ie not CD001)?.

Your binhack32 searches for "CD001", then modifies the bytes before it to switch is the sector value. The code that is using these values is likely going to the sector and looking for an iso9660 filesystem that has a system identifier of CD001. CD001 isnt in the geist 1ST_READ.BIN, as has been noted, so that would point to the code looking for some other system identifier value.

When the ripped iso file was created its just going to have the standard value of CD001 as its system identifier.

-ack

 

Alas ackmed gets what I was trying to do I think. My search was for a co-relation between the ISO 9660 file system's CD001 and Geist.

As other games have their CD001, they were a good place to start to learn how to find it, which is the 6E B0 00 00 - 01 00 00 00 - 43 44 30 30 31 string. It is basiclly saying the data starts at 45,166 and it is ISO 9660 (well if you include the other crap it does!) and it is the data which is now the problem.

Now as Geist has no CD001 I was looking for either a place to park it or the scrambled equivalent. If Geist has it, it doesn't start at 45,166 as everyone else does, but if it does, it takes a different form.

I still can't extend and re-evaluate my values yet, as I said I need to entertain my brother who decided to invite himself round, but as he is my brother and he is moving hundreds of miles way I need to make time for him. I will resume my conquest later.

FYI trashing 43 44 30 30 31 in the 1ST_READ.BIN of retail games kills them too.

 

I understand what you meant now, you think that maybe the CD001 identifier of the iso files system of the HD area might be something else, just as the CD001 isn't in the bootbin? I haven't though about that, it could be it. Maybe the few first sectors of track03.iso could be of help (or VNC) ...

Yeah, real life is a time killer, I'm playing with lasers and liquid helium right now, so I don't have much time playing with Geist binaries ... Fun though ...

 

45166 was read in twice then 45173 (root). This is suspicious! 45166 is normally accessed once and then root can be accessed

It would be a good idea to compare how 45166 from GDR and .nrg differs although I don't think hard written data will get pass NullDC but not retail DC.

I will try to find where 45166 is first accessed, what it does and ways to bypass it. I will need real files to test out when/if I found it.

 

I guess a VNC access with any wanted tools is ok?