Print

[jaimebenlasnow]

Would like some information about how to reproduce this hack or get a bit of something cause we got some real hint with that video so we know that the PCB used is a DLP-TXRX-G USB-to-serial adapter where could it be connected? How could shader crash the kernel or give information?

Some of my hopethesis is that he is connected trough FPGA and that he got booting information or got decrypted information via debug mode also some people are talking about tftp. some dcoument on free60 look promising ...they are talking about hypervisor, change between beta hardware and final hardware, syscall...Everything.The page is there also they are talking about serial port (This is what we are in the little pcb that hangs there is also a serial adapter)

Give us your view about that but not only <i think he crashed the kernel and then he boot of king kong and the we can play downloaded game Yeah>

Thank you!

[HoRnEyDvL]

Nice Info Jaime. Hopefully all this can help us.

[infamous_Q]

hey i'm sure this idea's been beaten to death...but XNA still seems like an idea worth looking into if u ask me, i mean there's gotta be a weakness somewhere. as of now it's not freely available to every 360 user, but i think eventually it will be. as for now tho it may be possible to find a way into the system through xna. *note, i dont know too much about what exactly all the commands in the XNA language can do, but i do know that at this points its quite the sandbox MS has given us.
why?
first off xna allows us to use the ported version of directX, and all the wonderful graphical functions, so if we can use shaders (since we know this may already be a weakness) couldn't we maybe use XNA programming in order to create our own shaders or graphical functions which could exploit the system, lock it up and leave it vulnerable, or maybe even allow us to encorporate a buffer overflow ourselves (although thats a lot less likely since they probably already thought of that).
second, even though xna is a sandbox, could there be a way out? i mean i know they've only given us a special set of commands, but its a programming language right? so maybe there's a way to break it down into more simple commands which we can use to our own goals, and then compile into proper XNA code to be redistributed w/e they allow us.

these are just ideas..so feel free to talk about them, or not talk about them lol.

on the topic of the new kernel development, the system reads the header files right? so could we use what it reads there to create an overflow? that's assuming that we can not only delete values but create new ones too.

again..just ideas, im sure people are already talking about the later ne ways.

[Helliano]

QUOTE(infamous_Q @ Jan 16 2007, 03:56 AM)

hey i'm sure this idea's been beaten to death...but XNA still seems like an idea worth looking into if u ask me, i mean there's gotta be a weakness somewhere. as of now it's not freely available to every 360 user, but i think eventually it will be. as for now tho it may be possible to find a way into the system through xna. *note, i dont know too much about what exactly all the commands in the XNA language can do, but i do know that at this points its quite the sandbox MS has given us.
why?
first off xna allows us to use the ported version of directX, and all the wonderful graphical functions, so if we can use shaders (since we know this may already be a weakness) couldn't we maybe use XNA programming in order to create our own shaders or graphical functions which could exploit the system, lock it up and leave it vulnerable, or maybe even allow us to encorporate a buffer overflow ourselves (although thats a lot less likely since they probably already thought of that).
second, even though xna is a sandbox, could there be a way out? i mean i know they've only given us a special set of commands, but its a programming language right? so maybe there's a way to break it down into more simple commands which we can use to our own goals, and then compile into proper XNA code to be redistributed w/e they allow us.

these are just ideas..so feel free to talk about them, or not talk about them lol.

on the topic of the new kernel development, the system reads the header files right? so could we use what it reads there to create an overflow? that's assuming that we can not only delete values but create new ones too.

again..just ideas, im sure people are already talking about the later ne ways.

The hard thing with creating overflows is that the advisor is monitoring all that and if someone/something is creating buffer overflow the box will go. Daaaaaaa. Off.

[pdr]

QUOTE

well, i tried with splinter cell 2,replaced offline.xbe and online.xbe with a renamed xboxdash.xbe,made an iso with qwix,extracted ss.bin with ss patcher minidvd info pro,assembled all (blank.iso+ss.bin+gsme.iso) burned with clonecd,all fine.


inserted disc in the 360,all goes ok,it boots up to the screen you can choose individual or multiplayer,after choosing any of the options starts loading and then an error message from a blade in the 360..

the interesting part about all of this is:theres no need of a raw iso to be able to boot xbox1 games in the 360,you just need the ss.

This is interesting. Can anyone confirm this?

[HoRnEyDvL]

The xbe wont boot if its not supooerted by the emulator or is black listed the only that we might be able to do is once the hypervisor is cracked & the system is fully hacked we can see what go in each config file for the backwards compatibility files & try make our own to support homebrew.
Why do u think some games arnt supported yet?

[mr_spoon]

QUOTE(jaimebenlasnow @ Jan 19 2007, 06:11 PM)

It's a precaution mesure just in case it work but don't even think about it it's not even on the architecture...Powerpc

maybe there's more to it than meets the eye eh!


spoon

[vax11780]

QUOTE(mr_spoon @ Jan 19 2007, 06:38 AM)

Why are the games blacklisted in the first place if you can't cause a buffer overflow?

What games are blacklisted, as opposed to not being supported?

VAX

[Millenia1x]

i'm pretty sure mechassault is blacklisted

it was pretty much the main exploited game to date

[jaimebenlasnow]

Think splinter doesn't work and the 007 thing don't work too but they are not blacklisted they are just not supported

[HoRnEyDvL]

By black listed im not just talking about xbe's im also talking about the kiosk disk etc.

[vax11780]

QUOTE(jaimebenlasnow @ Jan 23 2007, 09:15 AM)

Well not sure they will always release a patch cause once you know how the system works it will be much easier to hack or decrypted the update to view what's inside of that update and then we could modify it to not check the signature of the update...But don't think of that in a short future cause it will not be easy to crackdown that system

This is basically what happened with the PSP. The original firmware (1.0JP) was easily cracked or maybe not even encrypted (if forget which.) Then it was just a matter of stepping through the code watching what it did to the system update and duplicating the steps to decrypt the new firmware. A few carefully chosen patches and voila! the new firmware is loaded from the memory stick with new exploits added.

VAX

[jaimebenlasnow]

But you guys out there will think this is possible well try to decrypt SHA-1 and then talk to us...But there's also something on the flash thing that could help us:

QUOTE

The layout of the flash by Garyopa:

I was doing some work on the 16mb NAND dumps containing the dashboard, kernal, etc.

Here is my original notes, which I sent to "Robinsod" and he has done some amazing things since.

Plus "Probutus" has released a program which can extract the files from a 16mb NAND dump.

I wanted to be the first to start a TOPIC on this new section, and lets keep this topic updated,
on the format of the 16mb NAND and the layout of each section and the block headers, so maybe
in the end we can get to work on decompressing and undecoding each section and hopefully get
the point of truely understanding the internal working of your x360 console, etc.

-------------------------------------------------------------------------------------------------------------
The 16mb NAND flash is not completely encrypted, it basically is a Microsoft compressed ROMDISK system.

It contains a small header, then a "encrypted" loader, and then a number of stored files in a "compact flash"
file system, these files match byte for byte the updated files in the "system_update", and are basically the dashboard files in stored signed Microsoft X360-XEX2 file format.
 
First a 4K header always the same, nothing special.
 
Then we have a 28,672 byte chunk of code starting at >1000, which looks encrypted and for the SMC,
but for some reason it is interchangable between systems, even tho it is different on each dump.
 
Then we have two small chunks with headers of CB and CD, whick look like start-up code for the CPU,
also different in every dump, and first CB is sometimes 26,080 bytes long and on other dumps it is 25,056 bytes long (why?, Pal, Core, more info on the dumps are needed first), and the second CD is always 22,256 bytes long.
 
Next we have the main kernal with a header of CE, which is the brain behind the dashboard,
and is always 352,368 bytes long.
 
The last two sections CF and CG are patchs or updates to the main kernal.
Sometimes there is none (factory fresh, no games played or live updates),
so the flash will have no CF and CG chunks, then first two appear (most likely from game discs),
and then more appear (most likely from live updates).

But the CF and CG always appear in chunks of two, and never see more than four in total so far.

The first CF is always 17,600 bytes long and the second CG is always 47,936 bytes long.
 
The CF chunk has a 32 byte headers on the front of it.
(I guess to tell the system where to patch into the main chunk)
 
The CB, CD, CE chunks only have 16 byte headers in them.
 
These headers contain length of the chunk plus a memory starting address for the CPU,
plus a build value/version like "1888", etc.
 
The CE chunk also has at the end a 6 byte CRC checksum, whereas the others don't.
 
640K FIXED COMMON BIOS PART (1/2)
-----------------------------------------------------------
>000000 = 4K COPYRIGHT HEADER
>001000 = SMC encrypted code --- Southbridge code, always starts here.
>008000 = "CB" encrypted code --  Bootup cpu code, always starts here.
>00E5E0 = "CD" encrypted code --  Sometimes starts at this address: >0E1E0
>013CD0 = "CE" encrypted code --  Sometiems starts at this address: >138D0
>06C000 = "CF" kernal original    ---  Base x360 kernal, always starts here.
>0704C0 = "CG" kernal original   --- THIS four parts are still encrypted as same as the rest above.
>07C000 = "CF" kernal live ver   ---  JUST the two parts are the "BASE" shipped factory version.
>0804C0 = "CG" kernal live ver   --- And the bottom two are the same until updated by "LIVE"!!
 
15200K VARIABLE FILE STORAGE AREA
---------------------------------
(Always start at location :A0000)
(But can vary at anytime/updated)
(Think of like a 15MB Hard Drive)
>0A0000 = mfgbootlauncher.xex
>0AC000 = xam.xex
>1D8000 = bootanim.xex
>23C000 = hud.xex
>25C000 = signin.xex
>268000 = friends.xex
>284000 = vk.xex
>2A0000 = updater.xex
>2A8000 = feedback.xex
>2BC000 = deviceselector.xex
>2C4000 = voicemail.xex
>2DC000 = minimediaplayer.xex
>2E8000 = marketplace.xex
>30C000 = quickchat.xex
>314000 = gamerprofile.xex
>328000 = createprofile.xex
>5F8000 = ximedic.xex
>688000 = dash.xex
>904000 = hudiskin.xex
>924000 = (xex2 file)
>928000 = (xex2 file)
>930000 = (xex2 file)
>934000 = (xex2 file)
>A18000 = (xex2 file)
>A1C000 = (xex2 file)
>A20000 = (xex2 file)
>A2C000 = (xex2 file)
>A34000 = (xex2 file)
>A38000 = (xex2 file)
>A3C000 = (xex2 file)
>A48000 = (xex2 file)
>A4C000 = (xex2 file)
>A50000 = (xex2 file)
>A54000 = (xex2 file)
>A58000 = (xex2 file)
>A5C000 = (xex2 file)
>A64000 = (xex2 file)
>A68000 = (xex2 file)
>AB8000 = (xex2 file)
>AC8000 = (xex2 file)
>ACC000 = (xex2 file)
>AD4000 = (xex2 file)
>AD8000 = (xex2 file)
>BBC000 = (xex2 file)
>BC0000 = (xex2 file)
>BC4000 = (xex2 file)
>BD0000 = (xex2 file)
>BD4000 = (xex2 file)
>BDC000 = (xex2 file)
>BE0000 = (xex2 file)
>BEC000 = (xex2 file)
>BF0000 = (xex2 file)
>BF4000 = (xex2 file)
>BF8000 = (xex2 file)
>BFC000 = (xex2 file)
>C00000 = (xex2 file)
>C04000 = (xex2 file)
>C08000 = (xex2 file)
>C58000 = (xex2 file)
>C7C000 = (xex2 file)
>C84000 = (xex2 file)
>C8C000 = (xex2 file)
>C90000 = (xex2 file)
>E58000 = (xex2 file)
>E5C000 = (xex2 file)
>E64000 = (xex2 file)
>E74000 = (xex2 file)
>E7C000 = (xex2 file)
>E84000 = (xex2 file)
>E88000 = (xex2 file)
>E98000 = (xex2 file)
>E9C000 = (xex2 file)
>EA0000 = (xex2 file)
>EA8000 = (xex2 file)
>EB0000 = (xex2 file)
>EB4000 = (xex2 file)
>EBC000 = (xex2 file)
>EC8000 = (xex2 file)
>F38000 = (xex2 file)
>F3C000 = Flash   LAYOUT (1/4)
>F3C200 = Filename TABLE (1/4)
        - mfgbootlauncher.xex
        - xam.xex
        - bootanim.xex
        - hud.xex
        - signin.xex
        - friends.xex
        - vk.xex
        - updater.xex
        - feedback.xex
        - deviceselector.xex
        - voicemail.xex
        - minimediaplayer.xex
        - marketplace.xex
        - quickchat.xex
        - gamerprofile.xex
        - createprofile.xex
>F3C400 = Flash   LAYOUT (2/4)
>F3C600 = Filename TABLE (2/4)
        - xenonjklatin.xtt
        - xenonclatin.xtt
        - ximedic.xex
        - dash.xex
        - huduiskin.xex
        - sysupdate.xexp1
        - aac.xexp1
        - bootanim.xexp1
        - createprofile.xexp1
        - dash.xexp1
        - deviceselector.xexp1
        - feedback.xexp1
        - friends.xexp1
        - gamerprofile.xexp1
        - hud.xexp1
        - huduiskin.xexp1
>F3C800 = Flash   LAYOUT (3/4)
>F3CA00 = Filename TABLE (3/4)
        - marketplace.xexp1
        - mfgbootlauncher.xexp1
        - minimediaplayer.xexp1
        - quickchat.xexp1
        - signin.xexp1
        - updater.xexp1
        - vk.xexp1
        - voicemail.xexp1
        - xam.xexp1
        - XenonCLatin.xttp1
        - ximedic.xexp1
        - sysupdate.xexp2
        - acc.xexp2
        - bootanim.xexp2
        - createprofile.xexp2
        - dash.xexp2
>F3CC00 = Flash   LAYOUT (4/4)
>F3CE00 = Filename TABLE (4/4)
        - deviceselector.xexp2
        - feedback.xexp2
        - friends.xexp2
        - gamerprofile.xexp2
        - hud.xexp2
        - huduiskin.xexp2
        - marketplace.xexp2
        - mfgbootlauncher.xexp2
        - minimediaplayer.xexp2
        - quickchat.xexp2
        - signin.xexp2
        - updater.xexp2
        - vk.xexp2
        - voicemail.xexp2
        - xam.xexp2
        - XenonCLatin.xttp2
>F3D200 - ximedic.xexp2 (ENTRY)
 
544K FIXED COMMON BIOS AREA (2/2)
---------------------------------
>F78000 - SETTINGS
>F78600 - ZERO
>F7C000 - TABLE
>F7C200 - SETTINGS
>F7C600 - ZERO
>F80000 - 512K EMPTY SPACE
 
Little tidbit, what is the "paddnu" at the end of the flash section, starting at >F7C000, it is different on
all dumps of the flashrom.

It is a checksum of the stored files?

Would like to dump the flashrom on original untouch system, then update the dashboard,
and see if "numbers" at >F7C000 changes.

Another quote on the file system

QUOTE

Locating the directory block:
A dump with the 16 bytes sparse data is needed for this. Scan the first page of every block for the
following pattern:

ww ww vv 00 00 FF 00 00 xx xx 00 00 yy yy yy yy

ww is the block number, vv is an incremental version number, xx needs to be 0 and yy is the ECC/EDC.

Format of the directory block:
Page 0, 2, 4, 6 contain information about the usage of every block in the flash. This information is
encoded as a 16 bit value. I am uncertain about the meaning of the highest bit. Usually all blocks
of a deleted file have this bit set. Without the highest bit the values are pretty trivial:
0x0000-0x03FF: This is the next block in a file (e.g. block 0x28 has a value of 0x29)
0x1FFB: This is a reserved block (the first 39 blocks and the last 4 blocks have this value)
0x1FFE: This is a free block (this also includes the directory block)
0x1FFF: This is the last block of a file

The odd pages contain the filenames, the starting block, the length and an unknown 32
bit value (guess: file type and version). If the first byte of the filename is 0x05 the file
is marked as deleted.

The interesting question now is: Why are the last 64 KB marked as reserved?

Well there is more in this post but if someone is interested in kernel hacking well go check that out

[infamous_Q]

hmmm...not being a hardware coder you can pretty much ignore this post if u think its referring to the previous post, especially since i barley understood ne of it lol.

on the topic if the update discs. are they just one file? if not they're all signed right? like nothing could be done to alter some of the files? im sure i'll get flamed for it..but meh.
but what about a hotswap? SUPER risky clearly since it's updating the kernel. im not quite sure how it acts when you insert the disk. but assuming it lets you decide whether to install it right then or not...what if the signature gets read on the first attempt only? would it be possible to hotswap something in (assuming it just skipped the signature check since it'd already been read once) and then have it run our own kernel update?

then again not only is this serious speculation, but what exactly could we achiever through updating the kernel to w/e we want? mind you thats also a quick way to get band assuming that MS can read the contents of the current kernel rather than just the version numbers to check for an update.

This post has been edited by infamous_Q: Jan 26 2007, 02:58 AM

[No_Name]

I dont know how the update is compiled, but if its one single file you wont be able to edit it as you would break the sig, but then if its not the updater would run first, again it would be signed and then it would introduce the update to the system, its at this point that I would see the update being pull off the disk, checked and the run/no run call is made.


I am not trying to shoot down ideas here, but pointing out the holes in the idea. I have a IT background but I am no security expert but if I can see holes in your idea I am sure the security heads has looked at the obvious attack points and came up with way to try and attack it and prevent those attacks.

I think its a dead end idea and my instinst is that you would kill the system trying it unless you knew exactly what you where doing and how the system will react to having a hijacked update appear.

This post has been edited by No_Name: Jan 26 2007, 08:58 PM