XBOX XDK Beta 2 - Can we fix it?

[stuntpenguin]

Well, I took a little time off from the internet to practice my "don't be petty asshole" skills. Didn't get very far.

Anyway, picked up a couple broken DVTn's on ebay. Paid at / above going price for working kits but whatever, I like to gamble and I'm a sucker for boxed goods.

Of the two broken kits I picked up, I've decided to open one. It has no rubber footie pads. It has no stickers covering the other two screws. I can safely open this kit without being destructive. Upon opening this kit, I find that the disc drive has a green sticker on it labeled "bad". Cool. This can easily be fixed.

At this point, I want to image the hard drive. I have a beaglebone black which I rig up to dump the eeprom of a retail console. I use some test clips to connect directly to the eeprom - no soldering involved. After some trial and error, the dump goes off without a hitch. I do the same to the dev kit, only this time I make use of the LPC header. For this process, I only had to wire up SCL, SDA, and GND. The old program eeprog did a good job dumping and and I was able to xxd -r the output of xxd to get it back to my host machine.

I had sniffed the i2c traffic with a Salae Logic device on my retail console and dumped that eeprom before, but the same did not work with the broken dev kit. It does not boot to the point where the eeprom is read. I 've begun to wonder if an eeprom could be the payload to some vuln / exploit. The serial number is a null terminated ascii string. I don't think there is a whole lot of room to work here as it is followed by a checksum of sorts. I need to dig deeper. If the stars align, the eeprom could be a vector leading to 1.6 (or really any version assuming some undiscovered bug hasn't changed) softmodding.

End rant.

This kit is super cool. "Bad" sticker on the disc drive. "Q7E1" sticker on the motherboard with a little arrow pointing to some SMD. I'm assuming this is pointing to component with a "Q7E1" silkscreen next to it. The controller ports weren't plugged in when I opened it... as you may know, the controller ports have a male connector. The motherboard on this kit also has a male connector. There's no way they can connect.

I plan on posting some pictures / videos soon. For now I have to image the hard drive. Testing with an old adapter I had on a retail console's hard drive did not go well... I let out the magic smoke (on the adapter maybe) . I have the key, but I'm waiting on some components for my computer. I guess they got rid of IDE haha. I'm big on preservation so I'll be making the contents public in whatever way I can.

Hoping to grab the bios out of high mem once I have this thing going. Might try to clip it if I get super schizo. Hope y'all can enjoy the journey and maybe give some tips.


Some vid

Other file is too large to upload but its in the vid.

 

[JustAnyone]

Quite a long and interesting read, i think i might have a solution for eeprom reading
https://github.com/grimdoomer/PiPROM or https://github.com/Ryzee119/ArduinoProm


Also, this part:

as you may know, the controller ports have a male connector. The motherboard on this kit also has a male connector. There's no way they can connect

1.0 xbox motherboard had usb daughter board mounted on mainboard, and looks like it is missing here?

 

[GoTeamScotch]

Congrats on the purchase! Definitely let us know if there's any interesting goodies on there. Any idea what studio they came from?

Of the two broken kits I picked up, I've decided to open one. It has no rubber footie pads. It has no stickers covering the other two screws.

My old DVT4 didn't have stickers so I recreated them in Photoshop using another DVT I had as a reference (download print-ready files here). The person I sold it to works at a professional printer shop and I work as a graphics designer, so they printed some high quality replacement stickers that came out looking pretty sharp. Here's an example of before and after (even matching the silver/mylar sticker). PM me if you want to arrange a set.

I can safely open this kit without being destructive.

Keep in mind, these DVT units are getting pretty old these days. If the clock capacitor isn't leaking yet, then it will eventually. I get that breaking the seals on your other unit is like a crime, but letting the capacitor leak and ruin the motherboard seems like a step in the wrong direction if you're going for preservation. Others may disagree. Both of my DVTs were experiencing leaking clock caps, but I caught it in time to avoid permanent damage. So, you might be better off opening your other one too and servicing it. If you don't want to break the seals, take a hairdryer and heat the stickers to loosen the adhesive to lessen damage to the label during a peel.

If you have trouble dumping the eeprom, Grimdoomer's PiProm tool works very well, like JustAnyone mentioned.

And if you're trying to dump your EEPROM just to access your HDD, the HDD key on dev/debug units is just 32 zeroes. If you have a spare hard modded Xbox, you can set your eeprom HDD key to all zeroes, then drop the dev kit HDD in there and use a boot disc to load into UnleashX (etc) to unlock the drive. You could also unlock it with a PC, but modern PCs often have trouble sending ATA security commands.

I 've begun to wonder if an eeprom could be the payload to some vuln / exploit. The serial number is a null terminated ascii string. I don't think there is a whole lot of room to work here as it is followed by a checksum of sorts. I need to dig deeper. If the stars align, the eeprom could be a vector leading to 1.6 (or really any version assuming some undiscovered bug hasn't changed) softmodding.

I'm not sure what you're getting at. If a person has the ability to change their eeprom and take advantage of some exploit method, then they might as well just grab their HDD key and install a softmod (which is already possible on all Xbox revisions). Unless I'm missing something.

Remember that the boot process for debug/dvt units is different from retail, so a vulnerability that exists in dev/debug boards because of the way they handle eeprom data may not transfer over to retail boards.

The controller ports weren't plugged in when I opened it... as you may know, the controller ports have a male connector. The motherboard on this kit also has a male connector. There's no way they can connect.

The last guy who was inside didn't plug the USB daughter board back in. These are standard on v1.0 motherboards (including dev/debug) but aren't present on later versions. You can grab one from a retail motherboard and swap it in. I have many spares if you need one.

For now I have to image the hard drive. Testing with an old adapter I had on a retail console's hard drive did not go well... I let out the magic smoke (on the adapter maybe) . I have the key, but I'm waiting on some components for my computer.

I imaged my kits with a USB 3 / IDE adapter and made an image of the drive with linux using dd. If you're looking for a good PCI card, I use this card in my tower and it works very well: https://www.amazon.com/dp/B000YAX13Y

Once you have your HDD image, explore the image with FATXplorer and check for deleted files with FATXTools.

 

[GoTeamScotch]

Responses to your video-

1. 4:50 - The TSOP chip on debug/development kit Xboxes holds a 1MB debug BIOS that is a 512KB BIOS duplicated twice. It's 2x512kb, not 4x256kb (different than retail units). If you try to split the TSOP, make sure you're only splitting it in half and not into 4 parts. My DVT console was fragging and I tried splitting the TSOP, but it didn't help at all. My TSOP was corrupted and it couldn't even be fixed by removing it and hooking it up to an external programmer. It had to be replaced with a similar donor chip from a retail Xbox (flashed with the debug BIOS). To check if your TSOP chip is busted, try flashing the debug bios to a modchip and using that. If it boots, then your TSOP needs to be re-flashed or replaced. And be aware that you can't use modchips like Xblast, Matrix, or Chameleon to fix the TSOP like you can with retail units.
2. 6:50 - The Q7E1 sticker is pointing to a repair and it wasn't uncommon for last-minute fixes to be done to boards before they left the factory in the early production days. My debug kit, for example, had a bodge-job done to it (see here, notice the resistor). But your DVD drive having a "bad" sticker on it makes me think it was either sent back in to Msft for repair or the last guy who was working on your unit (like an at-home repair) left those stickers. Hopefully the last guy knew what he was doing.
3. 7:15 - That's Kapton tape, aka thermal tape. It protects components from high-heat while you're working around them with a hot air rework station. Whoever did that Q7E1 job probably put thermal tape on the MCPX to protect it from heat while they were working in the area. Just a guess.

 

[stuntpenguin]

Quite a long and interesting read, i think i might have a solution for eeprom reading
https://github.com/grimdoomer/PiPROM or https://github.com/Ryzee119/ArduinoProm


Also, this part:

1.0 xbox motherboard had usb daughter board mounted on mainboard, and looks like it is missing here?

I actually did get the eeprom read out with a beaglebone black and a linux utility called eeprog. I know almost nothing about hardware design. Should have probably dug a little deeper and verified that it was okay to raw dog the eeprom.

I totally forgot about that daughterboard. Haven't seen one in a while. They're usually adhered to the chassis, right? Mine doesn't have that. I've got a load of consoles sitting around. Maybe I can borrow one from another console.

My old DVT4 didn't have stickers so I recreated them in Photoshop using another DVT I had as a reference (download print-ready files here). The person I sold it to works at a professional printer shop and I work as a graphics designer, so they printed some high quality replacement stickers that came out looking pretty sharp. Here's an example of before and after (even matching the silver/mylar sticker). PM me if you want to arrange a set.

I think that's super cool! I don't mess with aftermarket / homemade stickers though. It doesn't quite sit right with my spirit of preservation. I'm not saying it's wrong or anything. It's a type of preservation in its own right. I just don't feel comfortable with it. I'd rather practice my skills lifting the original stickers with heat and accompanying the box with a note saying that the console has indeed been opened. I've done this with some debugs. The results are okay-ish, not perfect by any means.

Keep in mind, these DVT units are getting pretty old these days. If the clock capacitor isn't leaking yet, then it will eventually. I get that breaking the seals on your other unit is like a crime, but letting the capacitor leak and ruin the motherboard seems like a step in the wrong direction if you're going for preservation. Others may disagree. Both of my DVTs were experiencing leaking clock caps, but I caught it in time to avoid permanent damage. So, you might be better off opening your other one too and servicing it. If you don't want to break the seals, take a hairdryer and heat the stickers to loosen the adhesive to lessen damage to the label during a peel.

If you have trouble dumping the eeprom, Grimdoomer's PiProm tool works very well, like JustAnyone mentioned.

And if you're trying to dump your EEPROM just to access your HDD, the HDD key on dev/debug units is just 32 zeroes. If you have a spare hard modded Xbox, you can set your eeprom HDD key to all zeroes, then drop the dev kit HDD in there and use a boot disc to load into UnleashX (etc) to unlock the drive. You could also unlock it with a PC, but modern PCs often have trouble sending ATA security commands.

I will get to the clock cap eventually. That is something I am confident desoldering. I have done it to a handful of consoles.

As noted above, I have the eeprom now. I don't plan on dropping this hard drive in another console. I can get at it just fine now. I imaged some drives some time ago, I'm sure I can do it again. It is good to know that modern computers might have trouble sending those commands. I had written a really crude in-box (run on console, network based) hard drive imager a while back in the AG days. That was before I had any real formal software development schooling / experience. I hope no one has tried to use that extensively. Think it was called XBDD, playing on the name of the tool dd.

I'm sticking with imaging this under Linux with the tool dd for now. It gives me an opportunity to carve out deleted XBEs and such.

If these commands can't be recognized by the target drive properly the issue has to fall in to some sub-issue like shitty hardware, poorly developed drivers, errata in the spec that has been since fixed by most vendors, etc. I have plenty of consoles to test on. I'm willing to take the time to find a modern card that is up to the task.

I'm not sure what you're getting at. If a person has the ability to change their eeprom and take advantage of some exploit method, then they might as well just grab their HDD key and install a softmod (which is already possible on all Xbox revisions). Unless I'm missing something.

Remember that the boot process for debug/dvt units is different from retail, so a vulnerability that exists in dev/debug boards because of the way they handle eeprom data may not transfer over to retail boards.

Gotcha. I'm a little behind the times. I was under the impression that 1.6 boxes couldn't be softmodded because there is no writable flash. Can 1.6 boxes be softmodded? Do they exploit some resource used by the dashboard? I'm spewing off thoughts here, but if a 1.6 softmod relies on some resource used by the retail drive, the softmod would disappear with the hard drive. Swapping hard drives would not be easy. An eeprom based exploit would live on the motherboard. Idk. rambling here.

To put this is layman's terms, I want to be able to put three clips on the eeprom. From here, the eeprom gets flashed with a payload. The payload bypasses signature checking, and now unsigned software can run on the box. This is highly unlikely because there are only 256 bytes to work with on the eeprom. The payload exploiting some vulnerability might occur near the end of this 256 bytes and we've got significantly less code that can do anything useful. Pipe dream. The more I think about this, the less feasible it becomes.

I guess I want to know if 1.6's can be softmodded.

The last guy who was inside didn't plug the USB daughter board back in. These are standard on v1.0 motherboards (including dev/debug) but aren't present on later versions. You can grab one from a retail motherboard and swap it in. I have many spares if you need one.

Ah I see. I vaguely remember this. It's missing in my console. Maybe the daughterboard was never adhered to the chassis. I should have one around.

and check for deleted files with FATXTools.

Have not seen this one. Will give it a look.

To check if your TSOP chip is busted, try flashing the debug bios to a modchip and using that. If it boots, then your TSOP needs to be re-flashed or replaced. And be aware that you can't use modchips like Xblast, Matrix, or Chameleon to fix the TSOP like you can with retail units.

Didn't know dev / debug bios were larger. Makes sense. I've got an Xecuter 3 sitting around. What specifically makes these chips not work?

A lot of my questions and comments are very direct. I don't mean to sound like a jerk when I ask questions. I feel that it's best to be concise and leave little room for error by asking the whys and hows. I'm super grateful for the discussion here. Even if I haven't addressed something, I've read it several times. Feel free to reiterate something if you feel that I've missed it.


Noticing that I probably posted this in the wrong board. My bad.

 

[Dink]

Hi, I have recovered many builds with FATXtools in the past. It is a very effective tool at spotting deleted content from XDK images. Though, if you have any plans on releasing any content you do find, make sure to release the HDD image with the content. This can allow anyone to have a more thorough look through the HDD and spot anything that may have been overlooked or manually recover files that may be fragmented in some way.

 

[GoTeamScotch]

I was under the impression that 1.6 boxes couldn't be softmodded because there is no writable flash. Can 1.6 boxes be softmodded? Do they exploit some resource used by the dashboard?

You're thinking of TSOP flashing. Version 1.6 consoles cannot be TSOP-flashed. Msft caught on and changed the board layout to prevent this hacking method. 1.6 boards can, however, be softmodded (all boards, 1.0 - 1.6 can be). The most common softmod method is gamesave exploits to gain access, then using font exploits to make the mod permanent across reboots.

Didn't know dev / debug bios were larger. Makes sense. I've got an Xecuter 3 sitting around. What specifically makes these chips not work?

To clarify, I am unsure if Xecuter 3 chips specifically do or do not work. I know that Xenium chips (and clones like OpenXenium) do not work because the XeniumOS is designed for the MCPX v3 chip found in retail consoles, not the MCPX v2 found in dev/debug consoles. Xecuter 3 chips also have an OS available on them that you can boot up into, just like XeniumOS, but I'm not sure how early that OS loads and whether it is also designed for a particular version of the MCPX or not. Xecuter 3 chips also supported physical bank-select switches, which may help bypass the OS from booting up at all (getting around any incompatibility with MCPX versions). I would be curious to see what you find out there.

Here's a more technical explanation:

The XeniumOS is coded for a retail console which uses the hidden ROM code stored in an X3 version of the MCPX which decrypts the 2BL section of the BIOS with a retail key, not the X2 version installed on Debug consoles which has the bootloader in the BIOS image itself. You can only boot a debug BIOS that is coded to work with the X2 MCPX that has no hidden ROM (code section) in the MCPX X2 but stored in the TSOP flash memory chip on the motherboard.
(source)

More discussion on this topic here.

Simple Aladdin chips won't work because they only have a 256kb flash chip (too small). If you have a hard time finding a chip, I still have my DuoX2 that I could part with. It still has the debug BIOS flashed to it too.

 

[stuntpenguin]

Though, if you have any plans on releasing any content you do find, make sure to release the HDD image with the content. This can allow anyone to have a more thorough look through the HDD and spot anything that may have been overlooked or manually recover files that may be fragmented in some way.

Unless I find some kind of holy grail, I'll make whatever public. I'll be sure to include the hard drive image in any capacity the rules permit.

I would be curious to see what you find out there.

Thanks for the info. I'll be sure to post my findings. I seem to have lost the connector with green, gray, and red wires. Perhaps its still attached to an old board somewhere. According to the installation docs, two of those wires are for hdd and network status indicators. The third is documented has having the following function: For those that don't know D0 is used to switch between your Xbox bios and modchip bios - sending a ground signal to the D0 line forces the Xbox to boot from the LPC port. I'm sure I can make do some other way.

Still twiddling my thumbs while I wait for the pci-e card to come in the mail.

 

[JustAnyone]

grounding d0 point is also a common practice - this makes console always boot from lpc bus

EDIT: If i were you though, i would not try doing this with rare modchip such as xecuter 3 honestly

 

[GoTeamScotch]

With any modchip, including an X3, you'll need to ground D0. This is the only method to have the Xbox boot from the LPC port instead of its on-board TSOP chip.

You can either attach a wire to the top or bottom of the motherboard. The top point is much smaller and more susceptible to damage. I recommend soldering a wire up to the bottom D0 point and running the wire over the side of the motherboard and connecting it to the modchip's D0 pad (or just connect your wire to ground to make it permanently/always boot from LPC).

D0 top point (not recommended):



D0 bottom point:



But yeah, I'm not totally sure if the X3 will work with your dvt, especially if you don't have the bank-select board.

 

[stuntpenguin]

i would not try doing this with rare modchip such as xecuter 3 honestly

I knew this was a rare chip but never bothered to look in to it. Some local guy installed mine back when OG Xbox was a current gen console. I've seen absurd asking prices but haven't looked in to what they actually sell for. Either way, I'm holding mine. I just want it. Not as an investment or anything.

I recommend soldering a wire up to the bottom D0 point and running the wire over the side of the motherboard and connecting it to the modchip's D0 pad (or just connect your wire to ground to make it permanently/always boot from LPC).

I understand that a modchip might be my best option to get this thing booted. I want to do as little soldering as possible to keep this kit in pristine condition. That might not be an option. I've seen some contraptions which are 3D printed and utilize pogo pins to make connection with pads on boards. This comes to mind. I'm not sure I can find pogo pins so small. This is exactly the kind of project that gets me going though. I'm willing to look in to it.

Got tired of waiting for my pci-e card to show up in the mail. Ran down to Micro Center and got a cheap USB to IDE adapter. Don't worry, I'm testing on a retail drive. I'm not impressed. The connector fits the pins but not the plastic housing. It leaves room to bend the pins when plugging in or removing. smartctl hangs when even checking to to if its locked. I've got a few pull requests ready the smartctl maintainers. There should not be an indefinite hang for this scenario.

We should be able to issue all ATA commands from any controller. Someone missed something or did not follow specification.

Edit:
Unlocked, dumped twice, compared hashes, compressed to a nice 75MB and backed up plenty of times. I'm not going to dig through the image right now, but I'll get it to whoever wants it after I have. A super quick look doesn't reveal anything interesting.

I was able to use smartmontools for xbox under Ubuntu with relative ease.

 

[stuntpenguin]

I'm not going to bother doing any more looking at this kit's hard drive contents. Looks boring to me.

Do not post any pirated content of any kind, this includes retail roms.

All Rockstar Games/Take-Two owned content is strictly forbidden. (Includes Codemasters from Jan 2021)
All Activision games for PS3/XBOX 360 are banned from being shared here as of January 2020.

When sharing a file, please ensure the details are as complete as possible (build date, system etc...).

Source code "leaks" are no longer permitted to be posted on OG. The only exclusion to this is source code released by the original developers. (I.e Doom 3 is fine) Linking to news is fine but no download links.

These are the rules that concern me. I'm sure there are a few unwritten laws as well. There doesn't look to be anything fun on this drive. Maybe it has a neato dash revision, but I can't say for certain. I have no interest in determining that at this time. I will do my best do get an image of the flash for posterity. If I don't get explicit permission to post this dump, message me. We can talk off-site.

Edit:

I got impatent and grabbed a USB <-> IDE adapter locally. This adapter didn't work. Surely it can send ATA commands. This happened under Linux with no additional drivers. Maybe this is something that can be fixed....

 

[Damien]

You're more than welcome to share nand/hdd dumps and the likes here. Although they're best in the prototypes section. Long as it's not T2 related. The codemasters thing was scrapped as EA ended up buying them last I heard. I'll amend that.

 

[stuntpenguin]

You're more than welcome to share nand/hdd dumps and the likes here. Although they're best in the prototypes section. Long as it's not T2 related. The codemasters thing was scrapped as EA ended up buying them last I heard. I'll amend that.

Thanks! Noted. A quick look only indicates dashboard and xdk demos.

Find download here