Topic: Jimmsta's Audiocd Exploit Delivery Theory (Read 169 times)

jimmsta · « **on:** October 08, 2004, 03:50:00 PM »

jimmsta's AudioCD Exploit Delivery Theory
First Revision written: October 8th, 2004
Special thanks go out to phitch on xbox-scene, for bringing up the idea.

Essentially, the idea of an audio-cd exploit is not new, but has never really been attempted, nor has any thought been given to the possibilty...

The key ideas to note before we begin

In order for this exploit to work, we must have....
- A burned audio cd that can be played on an xbox without mods
- An xbox that does not have mods, or has mods switched off/removed. (modchips or exploits for that matter)
- Some knowledge about audio-cd TOC's (Table of Contents)
- Some form of an audio editor. I use Audacity, since it's OpenSource and free. (http://audacity.sf.net)
- Some knowledge of how the xbox audio encoder works
- Some knowledge of 32bit memory buffers... IE: NUMBERS...

> You will be making 3 cds/images if all goes right
> You will need CDRWin to view the cd TOC.
> You will need some exploits.
-- This is just an idea for Exploit Delivery. it is not a softmod at all. --

Here we go...

1. Make a simple audio file in Audacity... fill it up with, say, 10-30 minutes of random garbage music data.
2. Make an audio cd of this data. Either burn it, or make an image file. I like images better, since you can save some cd's that way.
3. Analyze the (cd or)cd image's TOC using CDRWin (as far as I know that's the only util that has TOC editing/viewing).
4. We must find a way to force the TOC to read as if there was more than a DVD-sized audio track on it. (I think that's something like 1200 Minutes in....)
5. Change the TOC to say that the first track ends after the 1200 minute mark.
6. Make a 2nd cd that contains a copy of PBL, and whatever else you want... burn a cd or image in UDF 1.5/2.0 format.
7. Analyze the second image/cd's TOC. Keep note of how big this track is...

8. Now, it's time to make a FAKE TOC!

We need to make it so the xbox still thinks that it's an audio cd, but we need to force it to read beyond its boundries.

We need to basically MERGE the two cd images into one, and keep it as an audio cd. we MIGHT need to hand-make the new TOC, just
to burn it to a cd to test.

This is the most complicated part of this theoretical idea. It's the most work, and must be done,
unless the oversized TOC would force the xbox into looking over and over at the toc, thus crashing the xbox...

A bunch of things can happen here. If we have a CD that contains a funky TOC, and the xbox still reads it as an audio CD,
but sees it as being 1200minutes long, we might have a really big problem.

9. Turn on an unmodded xbox.
10. place the "audio" cd into the xbox. Go into the "Music" tab.
11. Pray that the CD is recognized as an Audio CD.
12. Try encoding the cd using the xbox.
13. Hope it starts looking for the second track.
14. Hope it accidently loads up the default.xbe on the second track.
15. Success??!?

Please try this, and comment...

jimmsta · « **Reply #1 on:** October 09, 2004, 12:00:00 AM »

^BUMP^

Angerwound · « **Reply #2 on:** October 09, 2004, 12:38:00 AM »

The audio encoder is going to attempt to encode the data found at the offsets recorded in the TOC into .wma files. Even if you somehow changed the TOC of the audio cd. The encoding process would not try and execute any sort of default.xbe. But let's say you somehow got this .xbe to execute. This .xbe would be not signed at all for the kernel to allow it to be launched. The kernel is not patched in any way to allow a habibi signed .xbe to be executed.

This is not possible.

mckenn88 · « **Reply #3 on:** October 09, 2004, 01:06:00 AM »

PedrosPad · « **Reply #4 on:** October 09, 2004, 02:53:00 AM »

All invention begins with imagination.

krayzie · « **Reply #5 on:** October 09, 2004, 04:28:00 AM »

Yeah if only we could cause some overflow to get some code running to change the key...

_name_here_ · « **Reply #6 on:** October 09, 2004, 01:18:00 PM »

YoshiKool · « **Reply #7 on:** October 09, 2004, 01:20:00 PM »

If they could cause a buffer overflow, they could change the key in RAM like (all?) other exploits.

_name_here_ · « **Reply #8 on:** October 10, 2004, 02:40:00 AM »

I forgot the key is stored in the ram on bootup (correct?)
Wouldnt it be possible to "dump" the ram, obtaining the ms private key??

bipolardragon · « **Reply #9 on:** October 10, 2004, 04:33:00 AM »

mcjules · « **Reply #10 on:** October 10, 2004, 04:47:00 AM »

You wont find the private key on the xbox only the public key. This is how asymmetric key cryptography works.

Chicken Scratch Boy · « **Reply #11 on:** October 10, 2004, 09:51:00 AM »

i don't know if this is possible or not.... butyour theory is a bitunder developed...

how exactly do we run unsigned code using the large toc?

jimmsta · « **Reply #12 on:** October 10, 2004, 09:53:00 PM »

'tis a pipe-dream
This is only one of my ideas.

I figure that there's a way to create a buffer-overflow in the wma encoder... and seeing as the wma encoder is not any different from its Windows Media Player encoder, I figure that it may be possible to find a way to exploit it.

Chicken Scratch Boy · « **Reply #13 on:** October 10, 2004, 10:00:00 PM »

uh ok then... say it.

jimmsta · « **Reply #14 on:** October 10, 2004, 11:37:00 PM »

I don't know... fark it... forget I even came out of my shell... MODS, please lock this thread... I'm too tired to try any of my ideas... wait no,... I'm just too lazy. ugh.

I have a feeling that someone will figure something out, but it won't be me.

Author Topic: Jimmsta's Audiocd Exploit Delivery Theory (Read 169 times)