I am having no end of trouble getting an Xbox kernel to compile. I have used 3 virtual machines and my xp laptop and got nowhere. I keep getting a geni386.c no found error. I found a supposed working build environment on BA that the uploader had sorted the problem on. Still failing. I have tried with the tools provided in the kernel source, tried with vc98 and vs2003, have used numerous combinations of ddk packages and have just about given up. Has anyone here managed to get the damn thing to compile yet? I'm about to dump the vm's I setup for it and clear it off my laptop to free up some pace if I cant get a working build environment setup. Not being able to compile a working image is causing problems for reverse engineering xbox live. Any help will be greatly appreciated
Found this posted on BA. Ok, so it's actually simpler than I thought to fix the build process. Dependencies: Windows Server 2003 SP1 DDK, xboxkrnl source code, Windows 2000/XP. Install the DDK, put all the xbox code into a folder on the C drive called XBOX. Edit setenv.bat with the appropriate path to the newly installed ddk's x86\bin folder. Open a command prompt, navigate to the xbox\private\ntos directory, type 'setenv c:', then type rebuildall. You should end up with a fully compiled xboxkrnl/xboxrom.bin file. I have yet to test the compiled rom, but it appears that it fully compiled without any real errors. EDIT2: I'm uploading a sane build environment to the FTP now, so others can take a stab at the code. I wrote a readme file for it so you can easily figure out what changed between the version already on the server. Namely, I added some missing include files, and updated some of the XDK dependencies. This seems to fulfill the requirements in order to build the bios/kernel. I also included the Server 2003 SP1 DDK (albeit stripped down to bare essentials), and configured the batch scripts that setup the build environment to point to the copy of the DDK included in the package. Link for the impatient: https://drive.google.com/file/d/0B_DC7Oz95HMLTm94Y1B5YWhQSmc/edit?usp=sharing I still need to test the compiled kernel on an xbox, but seeing as it compiles, I'd have to guess that it is fully functional. - posted on BA
Thats the environment I downloaded yesterday. Supposedly had the geni386 build error sorted. In the build log it is looking for the source files in \nt\public\blah blah instead of \xbox\public\.... There's no reference to \nt\ in any of the source files apart from in comments. I used a symlink to link \nt to \xbox, but it's a bit flakey. It solves that error, but the compiled kernel fails to boot fully, and when I added code in the boot process to change the LED colour, it did nothing. I guess it isn't compiling my code and is just using the prebuilt files included in the package.
If this idea is completely stupid don't flame me, I have very limited knowledge of programming... but couldn't you use one of the modded bios from Team-Xecuter and decompile it and edit the kernel, then recompile? Or are they separate?
I'd have to modify it in assembly/hex. Thats way beyond me for the moment. The work I need to do to replace the Live authentication will be impractical to do in assembly. I may try installing Win 2000 and using that if I can find my copy of it.
I have a working build environment at last. I've added both code to change led colour and also force infinate reboots when it starts looking for a dash to load. Both work fine. It still wont load any dashboards or games. The only thing it will boot is the XDK recovery disc. Now I have a known working env, I'm going to try and build it again, and this time note down how I got it working. I think most of it was a symlink and adding more directories to the user path variable.
This leaked code is shite. Builds fine, makes a booting image, but cant load anything of use. I've tried on 2 consoles with modchips and as BFM on a 3rd. One of my consoles is now a brick with a HDD locked to a key that doesnt exist. I can get the XDK recovery disc to start up, the hexens disc and Xebian/GentooX to work. Nothing from HDD will run at all, I just get the generic error 13. Changes I make to the source get compiled in. I tried by adding a hardware reset into the kernel just before it looks for a dash to load, and it resets. I changed the LED colour at the same point too, that works, but it instantly becomes a nice flashy blinky mess and shits out error 13. When I can I will upload my build environment with updated setenv batch file , but unless this can be made to boot there's no chance of an open xbox live. Below is the setenv.bat I tweaked. You also need to create a symlink from \xbox called \nt for geni386 to build properly. @echo off if "%1"=="" goto error :good echo Setting up environment variables SET BASEDIR=%1\XBOX SET NTMAKEENV=%1\xbox\public\oak\bin SET _NTTREE=%1\XBOX path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%1\WINDDK\3790.1830\bin\x86;%1\xbox\tools;%1\xbox\private\idw;%1\xbox\private\oak\bin; %1\xbox\public\sdk\inc\crt; %1\xbox\public\sdk\inc echo Done! goto done :error echo Usage: setenv (driveletter): echo Like "setenv F:" :done
What build have you tried? The only one I've run across is the "Barnabas-2084" build. I will do my best to try and track down a complete one.
Barnabas something, kernel version 1.00.4400 I just flashed a stock bios to a console and put a totally stock dashboard on it from my v1.6 and it runs fine. The annoying thing is I've downloaded several copies of the source claiming to be "working, just type make after setenv", and they dont. All I can think of is comment out some of the error handlers and replace them with while(1); to see where exactly the problems are coming from. At least I have the latest dash on a console, so there should be no version problems.
ToXZiN has just inspired me to check something. I got an evo-x cd to boot using my kernel image, and it can't read the HDD properly. The C partition is apparently a single 700 meg evox.ini file when viewed over FTP, and E: contains only an empty TDATA directory apparently. I'm wondering if the kernels partition table is up it's own arse. More investigation is required me thinks. Considering build 4400 was never an actual released kernel, this source tree could contain prototype code that never made it into the final build, or they were trying something out (possibly different partitioning) that failed. Maybe whoever leaked it is a complete arse hole and broke it, I don't know.
Just an FYI, the xbox live authentication code is NOT part of the kernel image. It is part of the xonline library which is an inline library all xbox live titles are compiled against. The code you see in the Barnabas source is simply to build the xonline library. It does not exist anywhere in the kernel at all.
The Live protocol is implemented on the application side, but from what I (and others) have found, the keys and Kerberos side of it all are handled by the kernel. The decrypted EEPROM data that isn't required after initial boot is wiped from memory. It makes no sense to put such security-critical code in the hands of developers. There's always the chance of a development kit being leaked by a 3rd party, but an entire kernel tree should never get out in the wild.
The kerberos code is all inline and part of the xonline library. The source code is never in the hands of the developers. They get the intermediate library files to compile against. Open up any kernel image with symbols from any SDK/recovery and you will not find a single kerberos or ASN1 function in them. Open up a xbl game executable with the xbox flirt and you will see the kerberos and ASN1 functions in the xonline segment. NOTHING for xbox live is in the kernel except for the raw encryption keys which are used elsewhere on the console. Like I said before, the code you see in the kernel source is to build the xonline library. Just because the code you see is part of the "kernel source" does not mean it is part of the kernel. The source tree is for the entire operating system, including the SDK and IDE.
I found this rather interesting and I'm wondering why someone hasn't done this before. http://www.emuxtras.net/forum/viewtopic.php?f=8&t=3164&start=10
It's more complicated than that. Title servers were used for keeping ping times and latency down I believe. Back in the day, we didn't have the bandwidth on a home connection to keep 16+ players in sync. Live also requires authentication, if the game can't sign in or there is no account, it drops back to the xonlinedash for diagnostics and account management. I have looked into what TheFallen93 has said. I've done keyword searches for Live, xonline and various other terms through out the ntos source folders, there's nothing beyond the online keys and eeprom decryption. Changing the key generation in the kernel so that it's a more simple computation on the unit serial will give us a starting point for getting a Kerberos authentication. The other option is to use exactly the same key generation as Microsoft, and require each user of the service to run a custom application that securely sends the decrypted EEPROM contents to the server, so we can run un-modified kernels. Having to use a minimally-modified kernel that offers nothing more than running unsigned XBE's and connecting to Live again isn't too appealing. By using the original keys, any console with any BIOS can connect with nothing more than a custom DNS entry in network settings, even totally stock if the EEPROM contents can be retrieved using a custom payload in a gamesave hack. IIRC, at least the 007 AUF hack loads EVO-x and that can be used to backup the EEPROM and copy it using FTP. I'm having no luck with getting a custom kernel build to work properly. I have a ROM that boots to a dash, will play games and mostly works, except the networking in the MS dash. Both the Live dash, and the network settings in the "normal" dash lock up with the little spinney loading thing at the bottom of the screen stopped. I also can't get it to boot from media for some reason. I've converted a few other images to BFM using XBtool, so I know I am doing it right, but I just get a black screen, and it reboots when eject is pressed. I found a few files in the source have been copied to blah.blah.bak, and the non .bak copies are slightly newer. This is why it refused to load anything that read the HDD. fatx.h was one such file, I never looked for the change, but I was seeing a 700 MB evox.ini file over FTP and everything else was empty. I restored the older copy and it booted straight up after a compile. I can only guess that the leaked code was possibly modified to prevent it from "just working", or it was an experimental build with changes that never made it into the production consoles. Either way, it seems no one who distributes the build environment as "tested and fully working" has ever been arsed to actually flash and try and run the compiled kernel. I did get a copy from someone on here, I'm not talking about you, you have been very helpful in trying to get this working
Np man. I just wish I knew more about programming and things of that nature. I've been modding and hacking xboxes for over a decade, but unfortunately I never took the time to learn C or any other language that would have helped us more. Keep working on it man and if you need any help, just give me a shout!
My experience in programming is mostly embedded C for micro-controllers. Operating system kernels, C++ and (beyond Visual Basic) graphical programming are things I have only recently started working with. I took the network support route in college instead of programming. Not a clue why as I was better at programming than networking, but at the time there seemed to be more need for network engineers than programmers. Network engineers can't have fights with french loaves on spinny office chairs and use compiling as the excuse. Even the xbox kernel at a massive 256Kb including the 2bl takes about 5 minutes to compile. Can't have a full on bakery conflict in that time, but it's enough time to have a quickie with Wendy in the stationary closet. DISCLAIMER: I DO NOT KNOW A WENDY, NOR HAVE I EVER HAD A QUICKIE WITH ONE IN A ROOM FULL OF PAPER AND STAPLES (I may very well have had the chance though if I had gone into programming) That is my tip of the year. If you want to have a quickie with a Wendy in amongst a pile of tree slices and photocopier consumables, become a programmer.
And now, something totally un-related to brief encounters with Wendy. I'm rummaging through the crypt and xonline library source looking for the last function used to generate the encryption keys before the kerberos data is actually encrypted. I aim to change it to pass on a known result and then I will use the custom library in the XDK to build an application that will attempt to connect to Live, but end up at my KRB server. I'm wondering if it will be possible to replace the library in game XBE's as long as the length is byte perfect.
