xbox-winfsp hangs when trying to mount a specific disc

[Landcross]

When I try to mount this x360 disc, nothing happens. The cmd window opens and then... nothing. I'm not sure why or what's going on. I tried enabling the debug logs, but either I'm doing something wrong or it already hangs on something before even 1 thing gets logged. This is the only disc (so far) that doesn't seem to work with xbox-winfsp.

[emoose]

Pretty weird disc, couldn't see any XGD/GDFX headers in the normal locations, but hex editor does show some XEX2 headers - the regular ISO9660/UDF part doesn't contain any XEXs neither, just some blade-dash style videos.

Since xbox-winfsp can't find any XGD headers it'd probably try treating it as a FATX device and scan through for FATX partitions, making it seem to hang for a while.

Do you know if any extractor tools are able to work with it at all? There does seem to be an XGD header at 0x89D90000, but that's pretty far away from where it's expected to be, if there are any tools that work with it then it might be interesting to see how they were able to locate that.

E: with header at 0x89D90000 that'd mean base addr for XGD is 0x89D80000, adding the root dir sector taken from the header to that base addr gives you 0xA5EA8800 as offset for the root XGD dir, which seems correct - I don't know why the base would be at 0x89D80000 though, or how anything would even locate it there without needing to scan every sector...

[Masamune3210]

If I'm not mistaken, this disc came out really early in the span of things, so maybe it was just before they had totally nailed down what they wanted the initial disc spec to be? Either that or tooling wasn't completely up to standard yet?

[Landcross]

Hmm, I tried a couple random (Windows-based) XGD tools but couldn't quickly find any that seems to work with this disc. They all report it not being an XGD/Xbox disc. Maybe there are tools on an actual xbox console that would work, but I'm not able to test that out :(

[emoose]

Ah darn, I tried looking into some XGD tool code too but seems pretty much everything uses the same static offsets that we're looking in.
My guess is maybe the included videos increased the video partition size, making them shift the XGD portion to later on in the disc (most game discs use pretty much the same video partition between them, which maybe explains those static XGD offsets)
Not sure if any other demo-discs with videos included have the same issue though, maybe this was only an issue early on like @Masamune3210 suggested, and later discs might have moved the XGD header to before video partition instead.

Unfortunately video partition size doesn't seem to be accurate and oversteps where XGD header is located, so don't think that can be relied on to locate it.
Tried checking in kernel to see how that seeks to headers, kinda seems it might be relying on the DVD drive itself to handle it though, with some kind of seek-to-game-data command sent to the drive maybe.

Only other hint I've seen toward locating it is inside the PFI data of the disc, https://xboxdevwiki.net/Xbox_Game_Disc mentions PFI contains "Starting Physical Sector Number of Data Area" at least.
Seems PFI is stored somewhere outside of the dumped area though, IIRC X360 game dumps would either include PFI/SS/DMI as seperate files next to the ISO, or include the data inside the ISO itself in some unused sectors for the modded drive firmware to access.
Unfortunately doesn't seem the PFI was included with the dump I checked, redump lists a CRC for it but wasn't able to find data for that.

Maybe worth looking into PFI of some game dumps though, probably not too hard to find one with it included.
If that "Starting Physical Sector" number matches with one of the sectors we check for XGD at (0 / 0x4100 / 0x1FB20 / 0x30600) then it might be useful to add some PFI reading code to this, either embedded or from a separate file.

[Masamune3210]

If I'm not mistaken the DVD firmware handles it, the console just asks the DVD drive to open the partitions that it needs when it needs them, so you are probably correct in that assumption

[Landcross]

This is so far the only disc I ran in to that has this issue (and it might even actually be the only known one, but don't quote me on that). So, I'm not sure implementing the whole PFI thing (if the hypothesis is even correct) is worth it for only one disc. Though, on the other hand at the moment I personally have no way of accessing the XGD files on this disc haha.

I was able to fetch the PFI file for this disc so feel free to poke around with that: download.

[emoose]

Yeah it probably is overkill for just one disc lol, would be nice to have it documented how that stuff works though - wouldn't be surprised if some site like xboxhacker already had it all laid out already really (I think there might be a mirror site of that somewhere but don't have the URL at hand, doesn't seem indexed by any search engines though...)

Thanks for the upload, do you happen to have the SS/DMI data for that disc as well? The PFI seems pretty barebones actually, but that xbox dev wiki does seem to mention there might be another PFI inside the SS data.

I'd guess since burned discs would only consist of ISO data+PFI+SS+DMI then the way it locates XGD must be inside one of them, otherwise I can't see how modded firmwares would have been able to find it.

[Landcross]

Yeah, I have the DMI/SS as well. Here ya go :)

[emoose]

Thanks, just had a look at it and does seem like SS/PFI might be linked with the XGD sector, at least some of the values do seem to make sense:

With the XGD data at 0x89D80000, that would be sector 0x113B00 (0x800 byte sectors) - inside the SS.bin there's a value at 0x4 which is 0x143B00, seems very close to our XGD sector number, just 0x30000 away.
Looking at PFI.bin, the value at 0x4 there is 0x30000, exactly the difference between them...

Not entirely sure about it but seems like these could be sector numbers on the disc itself, AFAIK discs do have a lead-in at the start containing some sectors that don't get included in the data section.
PFI's 0x30000 could be the "physical" sector of the start of the data, and SS's 0x143B00 is the "physical" sector of the start of the XGD section, to find the sector number in the data itself we just take away the data start sector from the XGD sector, giving us 0x113B00 😸

Don't actually know for sure if those are actually linked together like that though, maybe it's just always 0x30000 sectors for lead-in and the data inside PFI is just coincidental, would need to check some more discs to be sure.

E: aha sweet, checked some random SS/PFI from https://abgx360.hadzz.com/verified.php?f=pressings&q=10607AEA and from that I get a sector of 0x1FB20 for XGD, which is one of the ones listed in the post above 🎉

(also forgot that xboxdevwiki did mention PFI 0x5-0x8 was "Starting Physical Sector Number of Data Area", so seems the 0x30000 value in PFI is involved with it)

Probably wouldn't be too difficult to get something together that could try checking for embedded PFI/SS and work out the XGD offset from it, maybe something to look into at some point...
For now I guess we can just hardcode the offset for trial disc & add some comment about how to find the offset, in case someone finds any other weird discs in future.

[Landcross]

Nice research work!

If you want to add it, it'd be cool if you could add support for this disc to xbox-winfsp. Whether that's through the combined iso (although I'm not sure how to create a combined iso with pfi/ss) support or just a hardcoded exception for this disc, either way is fine with me.

[emoose]

abgx360 seems to be able to merge SS/PFI/DMI, used to be the main tool to use with games on modded firmware, doesn't seem to like working with the trial disk ISO though sadly :(

Since it's open source I had a look how those get merged in there, and I don't really get it... so SS/PFI is needed to locate the XGD header, but abgx merges in the SS/PFI to the 4 sectors just before XGD starts - wtf? catch-22?
They could read the XGD sector from SS/PFI first and then patch it to the right location I guess (abgx doesn't, just uses the static offsets we already know), but how would modded firmware have been able to locate it? guess they must have hardcoded the XGD offsets in the firmware or something, can't really see any other way.
(maybe would be interesting if someone with modded firmware could try burning a merged ISO of it and see if it actually runs or not, if there's any tools that could actually merge it properly anyway...)

Don't know why they couldn't put it in one of the unused sectors near the beginning, I'm not a hacked firmware writer though, maybe would have required more code to be added or something.

Well that makes trying to read from embedded SS/PFI kinda pointless now, if we need to know the correct XGD offset in order to find the SS/PFI, then we wouldn't even need the SS/PFI in the first place... just wish I found this out before I wrote the code for it 😄
Reading SS/PFI externally would still be able to help things like trial disk work though, maybe something to look into...

[emoose]

Added the offset for this disks XGD in commit above, I don't have winfsp setup right now though so haven't tried it myself yet.

If you'd like to test it build can be found at https://github.com/emoose/xbox-winfsp/suites/9325560534/artifacts/438224073

[Landcross]

First of all, I just realized that I completely forgot to reply here. If I remember correctly, I did download and (successfully) test the above build at the time, but it seems like I forgot to report on the results 😶 Sorry for that.

Secondly, I have ran into another instance of Winfsp completely not doing anything. If I download any GoD game and convert the .xcp file into a decrypted .xup file (which is supposed to be an STFS file and it indeed starts with the PIRS 'magic') using the tool 'Xbox Live Marketplace for PC' and then try to open that file with winfsp nothing happens.

I'm not sure however whether this tool just does something wrong/weird with the decryption/conversion to STFS or whether there's something wrong on the Winfsp side. Since there's no log or anything whatsoever I'm not sure... :/