I've been messing around with the May 2001 recovery and got it to boot as far as an AGP card check in a virtual machine. It looks for the capabilities of the card but I decided it wouldn't be worth it to bypass this check as it probably wouldn't be able to display anything. The kernel debugger did make a reference to a piece of kernel source code and a specific line though *** Assertion failed: DbgVendorID != PCI_INVALID_VENDORID *** Source File: d:\xboxmay\private\ntos\halx\i386\pcispace.c, line 355 This matches up to the exact line where this error would occur with the leaked 2003 kernel comments and all. Looking at the iso a little more I have found that the iso is 214mb and the extracted files only add up to 148mb. Granted there is probably some padding in there, I believe there are more files we could extract. The pdb symbols file is loaded from a mythical d:\xboxmayf\... folder. Poking around the iso file in a hex editor led me to find 5 pieces of code with comments corresponding to the alpha dashboard. I'm thinking that the missing files could be compressed or archived in some kind of way that makes them not easily findable with a hex editor. There is a reference to zlib in the iso hex edit but this may or may not be relevant. Maybe the files were hidden with something similar to the mkisofs -hidden option. Thoughts? It'd be cool to stumble across the alpha kernel source, or at least some of it.
What about looking in memory via WinHex or CheatEngine while the vm is running? If the code is actually looking for pcispace.c, it must be accessing it, thus loading its contents into memory. Correct me if I'm wrong, but this should be doable and atleast tell you if you're dealing with source code or not. I suppose you've already searched for hidden folders, haven't you? Also, try to access the cdrom under a non-Windows OS, maybe it could reveal more infos. Ultimately, run zlib unpacker in D:\ to see if something's compressed. Let's hope there's no encrypted data there. EDIT Is the disk image available somewhere?
There is a mega link about half way down this page that has it http://www.betaarchive.com/forum/viewtopic.php?t=33215 I tried taking a dump of my vmware memory via task manager->right click process but I didn't find much. I wonder if I dumped the right process though... it probably opens a new process to run the vm in. I haven't tried changing any view hidden folder options but I don't think that would work since I can't find the files in a hex editor looking at the iso. I think the el torito boot image mounts and decompresses a virtual disc drive. I haven't looked at it too much but as of now I know that the el torito boot image looks for xboxrom.bin (a non hidden file) or some file like that and won't boot if it's not found. I guess for now I'll try looking at vmware's other processes (if it has any) when I get time. I've thought about changing all the known files to be zero'd out in the iso to look at what's left in a process of elimination, but there are 1000+ files and I don't really have time for that Edit: Looking through the dump it appears to have a lot of potential error's it could throw along with the corresponding code and file where it would be found in the source (Just snippets). This probably has to do with the debugger. Maybe references to certain points of potential error are hard coded into the debugger. I didn't see any line numbers though which makes me wonder how it knows. Also using iso buster to find missing files via their signature comes up with a bunch of stuff including a couple arc (archive) files. It won't let me extract them with the trial version but I'll do some manual extracting
Looking through the debug monitor file, it appears that it uses something called "codeview debugging". This looks promising because the wiki page on codeview says that the codeview debugger is capable of showing "the currently debugged code in its source code context." That might explain why it's capable of finding the exact line of a the pcispace source file where the error occurred. edit: Okay so pdb files contain file names, and relevant line numbers and their respective source which explains a lot. So this is basically busted if I can find the pdb in the iso. However, if the pdb is "hidden" it would be probable to think that the source is hidden as well. double edit: I'm an idiot. Found the "missing" files in TDATA and they're nothing special. The code I found was more likely script files. They didn't really look like C anyway. On a side note, i've found that it shouldn't be too hard to remove the embeded XDVDFS image which contains all the files and replace it with a modified one that will boot on actual alpha kits and franken-alphas. Up to this point I've had to patch files with the requirement that I don't add or remove any bytes as not to mess up the file index. Now I can add or remove entire sections of assembly if I feel so inclined.
