Post by: K.Raikkonen-McLaren on November 19, 2005, 09:02:00 PM
I dont own an Xbox 360 yet so I cant test. But, because the Xbox has the ability to view images/music/videos. Shouldnt we be able to create a buffer overflow and execute our own code without having the need for a chip?
Similiar to what happend to the PSP.
Post by: 1nick9 on November 19, 2005, 09:48:00 PM
Post by: toolwerx on November 20, 2005, 01:44:00 AM
QUOTE
Yes, there are additional safeguards in place that will help prevent Xbox 360 from being modified. Stack memory, for instance, is non-executable, which makes buffer overrun issues more difficult to exploit.
they already thought of such attacks.
Post by: BlueCELL on November 20, 2005, 11:01:00 AM
Post by: Entropy42 on November 20, 2005, 11:45:00 PM
QUOTE(BlueCELL @ Nov 20 2005, 02:08 PM)
Yeah, you have to keep in mind that MS is a software gaint. They certainly know alot more of the Software part than Sony w/ the PSP.
-
Title: Image Viewer
Post by: johnstark on November 21, 2005, 02:13:00 AM
-
Post by: johnstark on November 21, 2005, 02:13:00 AM
QUOTE(trey85stang @ Nov 21 2005, 07:20 AM)
thats like saying cows know a lot about the milk business.
-
Title: Image Viewer
Post by: rasmithuk on November 21, 2005, 07:30:00 AM
-
Post by: rasmithuk on November 21, 2005, 07:30:00 AM
QUOTE(Entropy42 @ Nov 21 2005, 04:52 AM)
And yet the constant security holes found in their software indicate that they still don't comprehend buffer overflow attacks.
-
Title: Image Viewer
Post by: krakerx on November 23, 2005, 12:38:00 AM
-
I don't know, I think when it comes to Micro$oft, anything is possible. Look at all thier "best" OSs, with every OS release, they said "This is the safest, and most secure version of Windows available." They've been saying that since Win95, they praised the fact for WinMe [which was by far the biggest piece of crap], even saying the same about WinXP, its the reason that WinVista is taking so long to hit the streets. They should just do the smart thing, and follow suite with everybody else, and use a *nix based OS, make it easier on everyone
-
Title: Image Viewer
Post by: ImOkRuOk on November 23, 2005, 03:31:00 AM
-
... has to be one of the most assinine things i've ever read ... how about we just stick to topic.....
-
Title: Image Viewer
Post by: steblublu on November 23, 2005, 09:31:00 AM
-
[forum lag/double post. delete me!]
-
Title: Image Viewer
Post by: d0wnlab on November 23, 2005, 10:57:00 AM
-
Post by: krakerx on November 23, 2005, 12:38:00 AM
Post by: ImOkRuOk on November 23, 2005, 03:31:00 AM
Post by: steblublu on November 23, 2005, 09:31:00 AM
Post by: d0wnlab on November 23, 2005, 10:57:00 AM
QUOTE(steblublu @ Nov 23 2005, 11:35 AM)
secure hashing is done on memory units.
-
Title: Image Viewer
Post by: shakaru on November 23, 2005, 08:27:00 PM
-
Post by: shakaru on November 23, 2005, 08:27:00 PM
QUOTE(d0wnlab @ Nov 23 2005, 07:04 PM)
He's talking about giving the image viewer a custom crafted image, I'm guessing either streamed over the net or (I guess) a digital camera. In either case, there is no secure hashing being done and if there is, so what? The image is what it says it is. The xbox360 has the capability to load pictures to it and view them.. we don't need to try to break the security of the storage device it is stored on.
-
Title: Image Viewer
Post by: PVNick on November 26, 2005, 12:40:00 AM
-
I don't know if any of you are aware of this, but Windows XP already has stack buffer overflow protection built in (at least SP2, I forget about the bare install); however, you still see overflow attacks. Stack overflows arent the only types of memory corruption. The one that I think we would be most likely to see in X-Box 360 is heap overruns, which overflows heap structures. The reason I think this is likely is because of the facts that while stack buffers have a fixed size, heap structures are created and destroyed on the go, meaning they have dynamic sizes, just like file contents. Therefore, my prediction is that if you were to find a locally exploitable buffer overflow in the X360, it would most likely be in some sort of file format.
-
Title: Image Viewer
Post by: Dameon on November 26, 2005, 11:26:00 AM
-
What details do we have about the buffer overflow protection on the Xbox? Is it nothing more than stack pages marked as non-executable? (NX bit?)
If that is the case, then our job is certainly a tad more difficult. But as a reminder, non-executable stack does not mean that we can't have buffer overflows. The memory is still corrupted, return addresses can still be overwritten, it's just that any shellcode cannot execute. The common workaround for this has been to jump to a widely available and statically located library/system call, or at the very least an address in the executable that is known to be a useful function, and include your parameters on the stack. As an example, on a windows machine with buffer overflow protection, you can overwrite the return address to point to ShellExecute and slap a string on the stack to run whatever command you wish.
Some information on available API calls on the X-360 would be great, perhaps a little peek at the import table on an available executable. Surely there's a single command to launch an XBE/XEX, but the question is does it have to be local? Can you pass it a remote URL?
In our case though, a single command isn't enough. Call it a longshot, but what if we could hijack two consecutive return addresses? The first jumps to a pre-existing routine to copy a chunk of memory to another location (Such as memcpy, you don't get more standard than that) while the second jumps to said new location, in effect relocating our shellcode to an executable codepage. That would take some careful stack manipulation and debugging abilities that we don't have at this point...unless someone has a dev kit. It also assumes a lot, for one thing that the heap is executable or the code pages are writable, both of which are doubtful.
Just putting it out there.
-
Title: Image Viewer
Post by: lordvader129 on November 26, 2005, 05:34:00 PM
-
even if you did manage an overflow, where would you take it from there?
on xbox the overflow was used to patch the private signing key in RAm to a known value, so we could sign our own xbes to run
based on reading xbox-linux's overview of the security, all comparitive values are stored in non-volatile memory on the CPU die, meaning you probably wont be able to patch the key
-
Title: Image Viewer
Post by: Dameon on November 26, 2005, 05:58:00 PM
-
One step at a time. Being able to execute code on a virgin box is inherently useful. Security has no doubt been stepped up, meaning it just takes a different approach once there.
-
Title: Image Viewer
Post by: PVNick on November 27, 2005, 01:03:00 AM
-
I agree with Dameon. Besides, if one could get unsigned code running on the 360, that would be the spark needed to get everyone to turn their attention to hacking.
-
Title: Image Viewer
Post by: BlueCELL on November 27, 2005, 09:39:00 AM
-
The scariest thing I've read is that all calls reside solely inside the cpu itself. The cpu apparently contains its own ram for this purpose. I'm doubtful of much until somebody with access to some hefty equipment cracks open the chip. This is similar to the way ATA security (HDD locking) works. While not feasible for the common man, this can be hacked.
As for exploitation after that, this is MS people. Most likely a hilariously simple alteration to a presently common attack will work. Images do seem the logical approach though, so they probably spent 95% of their time securing that. Luckily enough though I missed out on one of these early defective machines so its all pure speculation at this point.
Yeah, your right. They wasted so much time/money to secure the curcits and shit and they left other "software" bugs open
BlueCELL
-
Title: Image Viewer
Post by: BiMP on November 28, 2005, 11:30:00 AM
-
If the USB 2.0 ports are read-only, then why not trying to make an adapter to use the memory unit ports. Aren't they based on USB structure? I see five prongs on my memory card, it may be silimar to Xbox 1 where it would be 4 USB connections and a 'yellow wire' to identify what the product is.
-
Title: Image Viewer
Post by: Dameon on November 29, 2005, 09:23:00 PM
-
Traffic always must be bidirectional at some point for USB. Even if the device is stopped/disconnected after negotiation, a quick glance at the USB standard indicates that there is plenty of room for error at that critical stage.
Also, I noticed on the free60 wiki that one of the peripherals hooked up to a computer advertises a rather interesting interface, "Xbox Security Method 1, Version 1.00, © 2005 MS Corporation. All rights reserved".
http://www.free60.or...n#Linux_support
Could that be our culprit for peripheral authentication?
-
Title: Image Viewer
Post by: holydemon on December 05, 2005, 09:13:00 AM
-
Cows aren't in the milk business you dumbass... cows make milk naturally, they know nothing about it.
MS makes software by choice. They study it, they master it (at least moreso than sony).
Your analogy just plain sucks
well that new compiler is lack of use...MS really has been letting go but we might be able to do that buffer overflow...it will be hard as hell though
Post by: PVNick on November 26, 2005, 12:40:00 AM
Post by: Dameon on November 26, 2005, 11:26:00 AM
If that is the case, then our job is certainly a tad more difficult. But as a reminder, non-executable stack does not mean that we can't have buffer overflows. The memory is still corrupted, return addresses can still be overwritten, it's just that any shellcode cannot execute. The common workaround for this has been to jump to a widely available and statically located library/system call, or at the very least an address in the executable that is known to be a useful function, and include your parameters on the stack. As an example, on a windows machine with buffer overflow protection, you can overwrite the return address to point to ShellExecute and slap a string on the stack to run whatever command you wish.
Some information on available API calls on the X-360 would be great, perhaps a little peek at the import table on an available executable. Surely there's a single command to launch an XBE/XEX, but the question is does it have to be local? Can you pass it a remote URL?
In our case though, a single command isn't enough. Call it a longshot, but what if we could hijack two consecutive return addresses? The first jumps to a pre-existing routine to copy a chunk of memory to another location (Such as memcpy, you don't get more standard than that) while the second jumps to said new location, in effect relocating our shellcode to an executable codepage. That would take some careful stack manipulation and debugging abilities that we don't have at this point...unless someone has a dev kit. It also assumes a lot, for one thing that the heap is executable or the code pages are writable, both of which are doubtful.
Just putting it out there.
Post by: lordvader129 on November 26, 2005, 05:34:00 PM
on xbox the overflow was used to patch the private signing key in RAm to a known value, so we could sign our own xbes to run
based on reading xbox-linux's overview of the security, all comparitive values are stored in non-volatile memory on the CPU die, meaning you probably wont be able to patch the key
Post by: Dameon on November 26, 2005, 05:58:00 PM
Post by: PVNick on November 27, 2005, 01:03:00 AM
Post by: BlueCELL on November 27, 2005, 09:39:00 AM
QUOTE(globe_guyx @ Nov 27 2005, 03:07 PM) 
The scariest thing I've read is that all calls reside solely inside the cpu itself. The cpu apparently contains its own ram for this purpose. I'm doubtful of much until somebody with access to some hefty equipment cracks open the chip. This is similar to the way ATA security (HDD locking) works. While not feasible for the common man, this can be hacked.
As for exploitation after that, this is MS people. Most likely a hilariously simple alteration to a presently common attack will work. Images do seem the logical approach though, so they probably spent 95% of their time securing that. Luckily enough though I missed out on one of these early defective machines so its all pure speculation at this point.
Yeah, your right. They wasted so much time/money to secure the curcits and shit and they left other "software" bugs open
BlueCELL
Post by: BiMP on November 28, 2005, 11:30:00 AM
Post by: Dameon on November 29, 2005, 09:23:00 PM
Also, I noticed on the free60 wiki that one of the peripherals hooked up to a computer advertises a rather interesting interface, "Xbox Security Method 1, Version 1.00, © 2005 MS Corporation. All rights reserved".
http://www.free60.or...n#Linux_support
Could that be our culprit for peripheral authentication?
Post by: holydemon on December 05, 2005, 09:13:00 AM
QUOTE(johnstark @ Nov 21 2005, 10:20 AM)
Cows aren't in the milk business you dumbass... cows make milk naturally, they know nothing about it.
MS makes software by choice. They study it, they master it (at least moreso than sony).
Your analogy just plain sucks
well that new compiler is lack of use...MS really has been letting go but we might be able to do that buffer overflow...it will be hard as hell though