xboxscene.org forums

Pages: [1] 2

Author Topic: Image Viewer  (Read 1097 times)

K.Raikkonen-McLaren

  • Archived User
  • Newbie
  • *
  • Posts: 1
Image Viewer
« on: November 19, 2005, 09:02:00 PM »

Howdy,

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.
Logged

1nick9

  • Archived User
  • Sr. Member
  • *
  • Posts: 264
Image Viewer
« Reply #1 on: November 19, 2005, 09:48:00 PM »

would b good but i think m$ would hav done all they can to prevent this
Logged

toolwerx

  • Archived User
  • Newbie
  • *
  • Posts: 41
Image Viewer
« Reply #2 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.
Logged

BlueCELL

  • Archived User
  • Full Member
  • *
  • Posts: 203
Image Viewer
« Reply #3 on: November 20, 2005, 11:01:00 AM »

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.
Logged

Entropy42

  • Archived User
  • Newbie
  • *
  • Posts: 6
Image Viewer
« Reply #4 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.
Logged

johnstark

  • Archived User
  • Newbie
  • *
  • Posts: 2
Image Viewer
« Reply #5 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.
Logged

rasmithuk

  • Archived User
  • Newbie
  • *
  • Posts: 29
Image Viewer
« Reply #6 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.
Logged

krakerx

  • Archived User
  • Newbie
  • *
  • Posts: 7
Image Viewer
« Reply #7 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
Logged

ImOkRuOk

  • Archived User
  • Full Member
  • *
  • Posts: 116
Image Viewer
« Reply #8 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.....
Logged

steblublu

  • Archived User
  • Jr. Member
  • *
  • Posts: 55
Image Viewer
« Reply #9 on: November 23, 2005, 09:31:00 AM »

[forum lag/double post.   delete me!]
Logged

d0wnlab

  • Archived User
  • Sr. Member
  • *
  • Posts: 326
Image Viewer
« Reply #10 on: November 23, 2005, 10:57:00 AM »

QUOTE(steblublu @ Nov 23 2005, 11:35 AM)
secure hashing is done on memory units.
Logged

shakaru

  • Archived User
  • Full Member
  • *
  • Posts: 128
Image Viewer
« Reply #11 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.
Logged

PVNick

  • Archived User
  • Newbie
  • *
  • Posts: 4
Image Viewer
« Reply #12 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.
Logged

Dameon

  • Archived User
  • Newbie
  • *
  • Posts: 17
Image Viewer
« Reply #13 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.
Logged

lordvader129

  • Archived User
  • Hero Member
  • *
  • Posts: 5860
Image Viewer
« Reply #14 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
Logged
Pages: [1] 2