Topic: Kernel/dash Versions For Reference (Read 632 times)

BCfosheezy · « **Reply #15 on:** November 29, 2005, 02:57:00 PM »

QUOTE(atomiX @ Nov 29 2005, 02:13 PM)

The connection to live itself is not encrypted but the actual data is. This is all assuming that all data is transfered like the marketplace content is. I haven't sniffed my live trafic since I don't have any hubs laying around but I'm sure some have already.

As for packet manipulation, I'm not sure I get where you're going. Transfering our own data to the HD by spoofing LIVE?

Well yeah. I know it's a totally different thing but for example xbc and xlink. They intercept a packet sent from a known mac, encapsulate it for transmission over the internet and send it. Well I'm not proposing that we add another layer or do anything other than intercept the packet and manipulate it for whatever purpose. I honestly don't have enough knowledge to know what that could lead to if it indeed proved possible but if things went well it could possibly be of use.

Well anyways I know u knew that and that's not the question you asked after reading your post again. You were asking if this was about writing to the hd by spoofing live and the answer is yes. I rationalized that if it was storing the gamer card information on the hd and since you can update it via your computer on xbox.com that some data was sent to the 360 to make it reflect that change. I theorized that if an individual intercepted that packet destined for the 360 and manipulated it that there's a possibility they could at the very least change their motto just for proof that they actually did this. If that were possible there is a chance that something else could be placed inside this folder instead of overwriting whatever configuration it is currently overwriting.

BCfosheezy · « **Reply #16 on:** November 29, 2005, 08:40:00 PM »

I just thought I'd add this from a XeDK screenshot just to confirm what we already know.

I borrowed this pic from poiygon who got this at zero hour.
Here's the original thread: http://forums.xbox-s...howtopic=464528

Here's probably the best pic that shows the version of the rom on the flash and the version of the xdk:PIC

lordvader129 · « **Reply #17 on:** December 01, 2005, 10:42:00 AM »

of course theres authentication, as if the system is gonna accept soemthing as critical as a kernel update just because its comes in on the right port

we've never been able to spoof Live with an xbox1, and i think its reasonable to assume 360 will have some sort of beefed-up handshake process because of the additional critical updates being delivered this way (kernel updates for example)

lordvader129 · « **Reply #18 on:** December 01, 2005, 12:56:00 PM »

QUOTE

are the backup kernel programed or hardcoded
in some chip on the 360?

my guess would be hardcoded, but we probably wont know until the second kernel update via Live

QUOTE

If its hardcoded the next question, is it replacable

doubtful, remember all these critical components on the processor itself, would be next to impossible for anyone to remove and replace components

QUOTE

and if its programmed, can we reprogram it ?

if this is the case then yeah, im sure we can figure a way to program it, however my worries still lie with hypervisor, if we program both the backup and the primary kernel they will both fail hash and signature checks, so the hypervisor will just throw the whole system into a reflashing loop and you wont be able to do anything with the system

QUOTE

One other question, the backup
kernal in the box, is it encrypted, compressed, both or plain code

it will definately be encrypted, i would say not compressed though, theres not much to compress on it, and its likely so small they wouldnt risk corruption just say to a couple kb

BCfosheezy · « **Reply #19 on:** December 01, 2005, 01:34:00 PM »

The hypervisor is something I'm going to have to do a lot of research on to post intelligently. This just hit me though. Any altered or homebrew code obviously fails the security checks. Once we figure out exactly how it works it may be possible to use a signed MS executable as a static application. Let me explain. No matter what piece of code we try to run, we force the hypervisor to see the signed app and then once checks are passed switch over to our manipulated code seemlessly so the hypervisor was never aware that it was executing any code other than the signed MS code. This in itself does not seem possible knowing that the hypervisor is actually what software sees as executing the code and the actual thing doing the switching is the very thing we are trying to fool. It's just an ignorant idea I had.

Monoxboogie · « **Reply #20 on:** December 01, 2005, 09:28:00 PM »

atomiX - Sniff the data going from live without a hub. Look into ettercap. It allows for arp cache poisoning, whereby the target of the poison is fooled to think that the node running the poison is the switch, and the switch is fooled into thinking the person running the poisoning is the one who was poisoned. It's called a man in the middle attack.

I'd do it...but I don't have an Xbox to poke at.

Though the data from live may be encrypted, to my knowledge, we have as of yet to even suck down the encrypted contents of the TSOP. With a large transmission from live, we may be able to pull out the data that contains a kernel update, and at least be able to toy around with the encrypted bios...at least to see it's structure, and begin looking for weaknesses in it's crypt. We can't even do that without the encrypted BIOS, though.

Monoxboogie · « **Reply #21 on:** December 05, 2005, 12:31:00 PM »

QUOTE(ryan_the_leach @ Dec 5 2005, 09:04 AM)

but if this "switching" was done by external hardware?

It doesn't matter. ARP packets are broadcast across the network, and as such, it creates a race condition if a program is able to spoof a header. Google for ARP Poisoning if you wish to understand the underlying workings of it (good), or take a cisco course (better).

Grim187 · « **Reply #22 on:** December 13, 2005, 03:38:00 AM »

QUOTE

[email protected]

^Decrypted with hex editor

QUOTE

° xam.xex
xboxkrnl.exe

^found befor a big chunck of encrypted txt

BCfosheezy · « **Reply #23 on:** December 13, 2005, 08:44:00 AM »

QUOTE(defnator @ Dec 13 2005, 09:46 AM)

and what can we do with this insteresting line?

Well basically nothing at all. There's nothing wrong with finding and sharing information though because the #1 key to manipulating anything is first knowing how it works. We really don't know very much about the 360 so any gathering of information about it brings us a step closer.... albeit much smaller than a baby step but it still brings us closer.

PS2MXBOX · « **Reply #24 on:** December 13, 2005, 04:06:00 PM »

yeah i also found that .exe "executable" line in a xex.
P.s. ive found it in multiple xex's now

now let me ask this, how did that xbox->pc->internet tunneling thing work? did you have to have a modded xbox? if not, is it possible to connect to xbox live via that process and extract incoming data and packets to your pc that way? just a thought

also, i recommend that if you have a pc and can use the iso xtracter (there is no extracter for the mac yet) to extract the xex and look at them with a hex editor. this is what ive found in some xex's

d:\xenonfre\main\core\private\tools\cert\demofixer\obj\xbox\demofixer.pdb

J:\defualt.xex\Device\CdRom0..XLNI_DASH_ARCADEXLNI_DET_MEDIA..OK .OKOKOK..OKU.x.OK.Aceptar [This game does not support pal 50 please change your display setting to pal 60. To change your setting in System select Console Settings Display

MS XBOX MEDIA_DVD_LAYOUT_TOOL_SIG

InterestedHacker · « **Reply #25 on:** December 14, 2005, 06:50:00 AM »

QUOTE(PS2MXBOX @ Dec 14 2005, 01:13 AM)

yeah i also found that .exe "executable" line in a xex.
P.s. ive found it in multiple xex's now
now let me ask this, how did that xbox->pc->internet tunneling thing work? did you have to have a modded xbox? if not, is it possible to connect to xbox live via that process and extract incoming data and packets to your pc that way? just a thought
also, i recommend that if you have a pc and can use the iso xtracter (there is no extracter for the mac yet) to extract the xex and look at them with a hex editor. this is what ive found in some xex's

d:\xenonfre\main\core\private\tools\cert\demofixer\obj\xbox\demofixer.pdb

J:\defualt.xex\Device\CdRom0..XLNI_DASH_ARCADEXLNI_DET_MEDIA..OK .OKOKOK..OKU.x.OK.Aceptar [This game does not support pal 50 please change your display setting to pal 60. To change your setting in System select Console Settings Display

MS XBOX MEDIA_DVD_LAYOUT_TOOL_SIG

This line is particularly interesting:-

d:\xenonfre\main\core\private\tools\cert\demofixer\obj\xbox\demofixer.pdb

Now, assuming that's on the DVD Drive (D: ?) then, it looks to be refering to a certificate / certification process? Maybe someone should take a look at demofixer.pdb if they can. I wonder if it's process that adds a certificate into the system to allow the demo to run?

lordvader129 · « **Reply #26 on:** December 14, 2005, 09:27:00 AM »

QUOTE(Darren101 @ Dec 14 2005, 09:54 AM)

From what I hear, the xbox360 can run signed .xex files from a burned cd.....

so can xbox1, thats nothing new

the problem is the flash updater will likely fail a media check from a cd-r (it would probably be signed to run off HD only)

also the bios would likely fail a signature check, or a hash check/checksum

i seriously doubt we are gonna make a cd-r that you just pop in and it mods your 360

lordvader129 · « **Reply #27 on:** December 14, 2005, 01:32:00 PM »

QUOTE(Darren101 @ Dec 14 2005, 10:52 AM)

Still, if we could get the bios/kernel, it could help us with hacking the xbox360.....
Edit: Spelling Mistakes

yes it would, the trouble is finding a way to load the hacked/modifed kernel, but thats why we're here, lol

enixn · « **Reply #28 on:** December 23, 2005, 12:43:00 AM »

hey i gotta question, when .xex's are signed with the private key, it only references the integrity of the .xex itself, right?...or does it also hash all the content files (that the .xex would load) too?....I dont think this would be the case though because then you have a 4+ gig game and its not gonna hash all of it. So all this means is that we cant modify the .xex without breaking the checksum.....but on the emulation profile update, there is no media check (rather its lenient) But there is only 1 file (the xex)...M$ prolly knew this so included all content into the xex itself so that it would all be checksummed. So, if we could find a signed xex that references some external file, and is signed for lenient media checks, it might be possible to get the xex to load something user created...But then they probably havent made such an xex yet. Bah, wtf i cant sleep right now and i have no idea what i'm talking about

shakaru · « **Reply #29 on:** December 23, 2005, 01:07:00 AM »

QUOTE(enixn @ Dec 23 2005, 08:50 AM)

hey i gotta question, when .xex's are signed with the private key, it only references the integrity of the .xex itself, right?...or does it also hash all the content files (that the .xex would load) too?....I dont think this would be the case though because then you have a 4+ gig game and its not gonna hash all of it. So all this means is that we cant modify the .xex without breaking the checksum.....but on the emulation profile update, there is no media check (rather its lenient) But there is only 1 file (the xex)...M$ prolly knew this so included all content into the xex itself so that it would all be checksummed. So, if we could find a signed xex that references some external file, and is signed for lenient media checks, it might be possible to get the xex to load something user created...But then they probably havent made such an xex yet. Bah, wtf i cant sleep right now and i have no idea what i'm talking about

Well, (depending on what encryption is used) it should be done in two parts. Digital Signiture, and hashing. Xbox used a combination of SHA1 for hashing and RSA1024 for its digital signiture. If the contents of a file have been altered, the SHA1 check fails. The RSA check is to make sure its real aproved code its self.

Author Topic: Kernel/dash Versions For Reference (Read 632 times)