Stack buffer overflow with syntax parsing?
written by Daniel Wang, 1 July 2002
Possibly worth pursuing? I heard on some BBS (I forgot where it was) hackers discussing how to screw the XBox ala IIS-style with a buffer overrun in the stack parse. Apparently the XBox uses parseflags/parseheaders, but it prevents attacks by placing this in a predictable location (the front or back), writing the checkteam or hash, as well as the block and sector size of each part; the XBox does not begin parsing until a certain header size or flag is reached, then it only parses if the size and stuff is correct. This investigation only takes a bit of time and UFS discs but I don't have my XBox and equipment in yet. It would be really nice if we could chipwall a few chips and start really hacking!
For those of you who don't know, a parsing flag is a very flexible technology that uses something that is either not present in normal data or escaped, and used to control parsing stack sector fields. For example, in a GET/POST string the GET command comes first, then we use ? and & lines. E.g: http://cgi.imahacker.com/stupidcgi?foo=bar&spam;=eggs&123=DEF This tells stupidcgi that Foo=Bar and Spam=Eggd and 123=DEF. One way of attacking this is to try to make the ? or & occur naturally in data, or in the case of escapes, there can only be so many layers so you can make the escape character appear "accidentally".
A size header means that a piece of data in a predictable space (usually the front) acts as an index to tell everybody where you can find the data (offset) and just how big it is (so you know where it ends). For example, a string of 0124 might mean that there first field is null, the second field is one byte long, the second field is two bytes long and the third field, 4.
Even more restrictive than the size header, is the block header where everything has to be a certain size. Most secure because it just parses the block of data and translates the fields. For example, a header might have to be exactly 64 bytes long, the type of data must be in the first 6 bytes, then the second field MUST be a bit longer, etc.
#> Syntax parsing flags, either in header or in the Chipsets.
Unfortunately with the substructures M$ got smart and used sizes instead of flags, which means they will use flags on the shipset parse coms, which would be the smart thing to do, because M$ knows it will be a moot point as you can always relace the BIOS instead of the other chips.
#> "size of image header (usually 178h)".... To-do #1:: Change this to something Really Really Big, say we give it the bird and tell it it's FFFFFFFF
#> Check where it's keeping it's memory? Also, on chipwalling, is the Memory chip a removable DIMM or is it as I assume heated in? If it's a DIMM get a DIMM sniffer. Or, you might try playing around with the DeBug pins.
#> Try the DVD/UFS'? Well, If anyone can help me get more info on this, we might try the following attacks. The preliminary stage is burning a DVD-RW or CD-R (UFS/ACFS structure), and trying different things like changing the signature size. Possibly the XBox has heder size protection or uses variable signature keys but I assume it uses a modulo somewhere so it doesn't get too big, then maybe the Chip will modulo any extra bits that get left in. For a sniffer, we can use a socket clamp and just clip the chips, for the chipwall we will have to snip the chips and install an extra intercept layer between the XBox Chipsets. I know a kid who didn't know how to solder, he simply stripped the tracks off of the board and stuck a stickycable on it, then later he used a razor and cut the sticky and the tracks, inserted an FPGA onboard codewall.
#> Chipwall might work. To explore this, someone might need to set up a chipwall/codewall or at least a sniffer, but a chipwall will be best since we can not only sniff but we can mangle the headers in-transit. The XBox does not use smart chips or have any sort of chip open protection so I'm assuming the internal chipset communications is not encrypted or easy to get.
#> Mangle the headers
1. Dump the DVDs onto a image and grab the plaintext headers, the headers are not DMCA covered.
2. Try different discs and undestand the Disc header, study more on the individual XBE headers and tree headers.
3. See if there are any flags to play with, if the XBox sends a set number of rawblocks then most of this is doomed, sometimes M$ will limit the header structure to say 64KB, but there might be eatra devflags we can screw like $104, base address for image.
If we can mangle the header to let extra data in that the chips won't expect, set up chipwall or sniffer and:
4. Change the certificate model in the structure and substructures, like changing the cert size.
..... Toy around with the other structures until we find a nice fat juicy bug that is difficult to patch.
#> Mangle the sizes a bit... Thanks to Robin Hood, Andrew de Quincey and Lucien Murray-Pitts we now know there's where they keep the header stuff. Since the header is not signed (they would either have to find crypto collisions or so the dirty work of ignoring the signature block) we can try these:
$104 Base address for image ***Must be changed along with PAYLOAD***
$108, $10C, $110 Sizes of headers and images ***PAYLOAD***
$11C Section count ID
$124, $128 Init flags and entry point address, thanks to RH we know it is XORed with the disc, session or master pubkeys.
$140;$174 More crap that goes with the structure, apparently instead of using flags to figure out sizes M$ puts in Sizes, makes our job a lot harder but still either will work.
