Kernel/dash Versions For Reference, Since Live Automatically Updates Options

[lordvader129]

MS allowing the system to communicate with the outside even more than the Xbox

the only reason MS is allowing that is because

the core of the hardware is protected beyond anything seen before.

MS is confident that any outside attacks can and will be blocked in the processor core, and they are justified in their confidence

i think we have to wait til MS starts sending more stuff out through Live, if 360 hasnt been cracked in a year they might start getting lazy and leave a hole somewhere

[atomiX]

For sure. Although they were smart enough this time to allow the updating of the kernel through live. This might turn out to be a cat and mouse game like it is with the PSP at the moment unless a hardware workaround is found which is independant of the kernel or somply forces the backup kernel to be loaded. There might be some interesting tricks working around the backup kernel. We'd have to know how it handles a bad fllash and kernel checking. Some have speculated that if a hacked kernel is found in memory, the backup kernel might be loaded to replace it.

[lordvader129]

Some have speculated that if a hacked kernel is found in memory, the backup kernel might be loaded to replace it.

hmm, id say if a hacked kernel is put into memory the primary kernel would be loaded to replace it

if a hacked kernel were somehow programmed onto the processor in place of the primary then the backup would be loaded to replace it


if we find a software exploit on the backup kernel then we might be able to trick an updated xbox into loading the backup by programming a bogus hacked kernel over the primary

this however assumes 2 things

1: we'll find a software exploit on the older kernel
2: we'll be able to reprogram the primary without an official update from Live

personally i fear that any attempt to load a hacked kernel via either PBL/nkpatcher-type software or a modchip device will simply result in a reload of the retail kernel from either the primary or backup roms

we might have go about modchip a totally different way, like with saturn, i believe that chip physically intercepted the signal from the cd drive and reported a false media type, this type of hack on the 360 will at least allow playing signed backups, but not homebrew apps, but it would be a start

[BCfosheezy]

Like you said, it doesn't really matter but according to what I see, they posted first. Lets not dwell on this though. As its been said before, this is yet another possible way to exploit the system. With MS allowing the system to communicate with the outside even more than the Xbox, it opens up more possibilities but we still have to remind ourselves that the core of the hardware is protected beyond anything seen before. They said the first Xbox was unhackable, yet it was able to run unsigned code within months. I'm confident the same will happen here...maybe not as fast but will nonetheless.

K... I'm wrong.

At any rate I'm at work but this crazy thought hit me and it's probably stupid but I'd like to know. You can change your motto (for example) online from xbox.com. Your xbox updates when it's connected to live. Does this display when you're not connected to live? Tons of "ifs" start now. If so is this transmission cleartext or encrypted?(pretty sure everything from live is encrypted) If we could manipulate the packets we could in theory gain access to wherever these live settings are stored. Even if this is this case it would still be impossible to execute due to the hypervisor but it could possibly be a way to store data on the hdd? I dont know. I'm sure this is stupid but I wanted throw it out there.

[atomiX]

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?

[BCfosheezy]

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.

This post has been edited by BCfosheezy: Nov 29 2005, 11:18 PM

[BCfosheezy]

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-scene.com/index.php?showtopic=464528

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

This post has been edited by BCfosheezy: Nov 30 2005, 04:45 AM

[bobhinkle1]

Isn't there a way to fake traffic from what the xbox thinks is xboxlive and send it a kernel. obviously not a good image and see if it writes it, if it does and then does it write the backup kernel or just the successfully installed kernel? We have traffic sniffers and data from xboxlive. is there an authentication process before the xbox begins downloading the new kernel updates?

[lordvader129]

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)

[Transmeta]

And, i think that the kernel would be downloaded completly, then
checked, then decrypted, then checked again and then finaly the one
on the 360 updated .

The big question is... are the backup kernel programed or hardcoded
in some chip on the 360? If its hardcoded the next question, is it replacable,
and if its programmed, can we reprogram it ? One other question, the backup
kernal in the box, is it encrypted, compressed, both or plain code

Soooo many questions, but the 360 just get out on the market

This post has been edited by Transmeta: Dec 1 2005, 07:53 PM

[lordvader129]

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

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

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

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

[Transmeta]

lordvader129..

What do u think about the dashboard, is it the same thing there:
hardcoded original and then a update somewere else ??

And the big one, the hypervisor, what triggers it, are
there something waiting for it to leve an okey, and can
we freze the hypervisor, by that i mean letting it go in to
some sort of numb state unabel to "panicing" and stop the system, or
place something else "after" it just giving the system ok all the time.

If the hypervisor are triggerd by hardware interupts or something like that,
then we maybe can eleminate the hypervisor "hart beat".

Ideas ideas and spoofing

[BCfosheezy]

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.

[atomiX]

Nothing is really ignorant at this stage. We have to keep in mind that anything can be reverse-engineered. Since the hypervisor most likely checks everything being run (executables and kernel), then if a flaw in the hypervisor is found that allowed shadowing the kernel's and executable's checksum so that it is always verifying the valid key that was shadowed in while running a hacked kernel somewhere else in memory, it might be a way to run unsigned code. Although, I suppose something like this is extremely trivial and most likely would have been thought of by MS.

I'm not familiar how the 360 CPU/hypervisor works so there might be plenty of flaws in my logic. Would it be possible to run a hacked kernel while feeding the address of the actual retail or backup kernel on flash to the hypervisor instead of the address of the hacked kernel in memory we'd want to run? I haven't looked into it but I assume the 360 would have some type of protected memory. I'm not really familiar with the concept but I assume this would hinder any memory manipulation without the consent of the hypervisor. Any comments on this?

[Monoxboogie]

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.