Print

[Midri]

devz3ro thats somthing I personaly have never thought of... I'm sure others have... But I personaly want to look into this...

[triggernum5]

From what I understand, the hacked portion of st.db resides primarily in the header..  This region of the file would be created by the dash in the normal fashion even if an audio cd could be developed that was capable of forming exploitable tracks..

[Kthulu]

i thought about this too before rmenhal posted the st.db, but i figured if it were possible you guys would have already thought of it.  it would be great if this were possible, but i doubt it is.  even if this magic cd track can be crafted, won't there be ROE issues to this...when you eject the dvd+r to insert the cd+r(w)?  unless you can put the cd track on the dvd+r...

[JimmyGoon]

QUOTE (Kthulu @ Oct 6 2004, 05:45 PM)

i thought about this too before rmenhal posted the st.db, but i figured if it were possible you guys would have already thought of it.  it would be great if this were possible, but i doubt it is.  even if this magic cd track can be crafted, won't there be ROE issues to this...when you eject the dvd+r to insert the cd+r(w)?  unless you can put the cd track on the dvd+r...

The point would just be to get the hacked st.db file on there to (at exploit exec) load up a UDE_INSTALLER.xbe or something.

[Kthulu]

QUOTE (JimmyGoon @ Oct 6 2004, 11:46 AM)

The point would just be to get the hacked st.db file on there to (at exploit exec) load up a UDE_INSTALLER.xbe or something.

i have no idea why you quoted my post in yours.  it says nothing that addresses the points i raised in my post.  we're talking about getting the st.db on the hdd from dvd/cd without having to use a game-save hack and ftp it in.  i DO understand how an audio exploit works

[JimmyGoon]

I thought that you were under the impression that this disc was going to be used everytime to do any homebrew.... thats kinda exactly what your post said.

I was just explaining that I thought it was a jumpstart to boot something off the CD .... such as a UDE installer...

If that was the case then.... .what part of it would suffer from ROE??

[triggernum5]

Yea, kthulu you mentioned the ROE issue..  But the point made was that ROE is acceptable for an exploit designed solely to gain ftp access..  With ftp you could then install a more suitable exploit..  Just eliminates the need to hunt down an exploitable game and a mem card or hotswap..  Too bad its just a pipe dream (at the moment anyways)

[eh.]

(I guess the creation of a hacked st.db might theoretically be possible via the stock box's dash instead though eh? )

[mckenn88]

if u used the st.db youd cut off anyone with a 5659+ dash from using it.

[eh.]

[eh.]

QUOTE (wrayal @ Oct 6 2004, 01:54 PM - mostly)

Don't think you guys have said this already, but I suggested this earlier in this thread and the oracle himslef (rmenhal ) said it would not be possible. However, that may have only applied to my specific suggestion

I think this linked post directly relates and (as per devz3ro) hope that rmenhal will have an opportunity to confirm (regarding the st.db created just for the 5680 dash) eh.

[Kthulu]

QUOTE (eh. @ Oct 6 2004, 01:32 PM)

I think his point was that (since it'd be a stock box) a bootable 5680 dvd+r would need to gain the initial access and as soon as it did ROE/J would be on, so you wouldn't be able to swap it for a cd-r(w) eh. (I guess the creation of a hacked st.db might theoretically be possible via the stock box's dash instead though eh? )

yes, this was exactly my point.  thank you eh.

[Kthulu]

and my own limited experiences with programing when i say that i don't think this is possible.  here's why:

when you rip an audio track to the hdd using ms dash, the audio track has no bearing whatsoever on what's written into the st.db file.  the audio track is simply converted to wma and stored on the hdd in the music directory.  the dash then records this location (~path~\filename) in the st.db along with whatever 'naming' data the user entered from the on-screen keyboard.  so it wouldn't really matter what you embedded in the audio track on the cd.  garbage track in, garbage wma out.

i can't say for sure that's how it works cause i don't work for MS and i ain't about to try to analyze about a million lines of hex, but doesn't that seem like the only logical way for the dash to handle the ripping of audio tracks?

[Kthulu]

however, a new approach just occurred to me...(but i think even this was suggested before)...

i'm not familiar with the technical details of the format of an audio track on cd.  do the *.cdda files on a music cd have something like headers in them?  like a header that describes the whereabouts(location) and size of the audio track it's embedded in?  if so, perhaps (instead of trying to cook up a malformed audio track that cooks up 'malformed' st.db file)...perhaps an audio track could be cooked up with a malformed header that causes execution of CODE embedded in the audio track...something like the JPEG exploit (or font exploits?), but with an audio track instead...

of course, even if this is possible, the ROE would still be an issue if you're trying to boot from dvd+r then swap it for a cdr(w)...unless you can make mixed/hybrid dvd+r disc that has the audio track on it...and the dash will recognize it...

[PedrosPad]

QUOTE (Kthulu @ Oct 7 2004, 03:09 AM)

when you rip an audio track to the hdd using ms dash, the audio track has no bearing whatsoever on what's written into the st.db file.  the audio track is simply converted to wma and stored on the hdd in the music directory.  the dash then records this location (~path~\filename) in the st.db along with whatever 'naming' data the user entered from the on-screen keyboard.  so it wouldn't really matter what you embedded in the audio track on the cd.  garbage track in, garbage wma out.

Well described Kthulu.  That's exactly how I understand it.
(PS. I suspect that the length of the track also makes it into the ST.DB).