Print

[digisatman]

QUOTE (mkjones @ May 6 2004, 08:50 AM)

Hmm, is anyone else starting to get sceptical about this? If the reset on eject can never be fixed (it could become the new clock loop) for most users this will be unusable, especially for users wishing to watch a few movies from disk in Media Player. As I used to before I got my large HD. Sure, placing the disk in while the exploit loads would work, if you do it before you get the M$ Dash disk error that is... Also, it would make DVD2XBOX unusable. So anyone upgrading a HD using softmods (as I have) wouldnt be able to back up their games Also, I reolized if I made some kind of memory card package I couldnt get it hosted anywhere becase it would contain origional M$ dash files and xbins dont allow that kind of thing, so for noobs and people without FTP access this is a no go Then I wonderd if removeing the Live! dash was a good idea. Sure for people who will never use live this is a great idea, but we can use live with the audio hack, I have never tried it but have read a few posts of people who have, can anyone elaborate? I mean, I would feel pretty safe running live with the audio hack on, but not this? Like the fonts, its too big a change of the xbox operating system, dont you think? IMO The audio hack is a great stepping stone into softmodding.... I would always reccomend the Audio hack over this, the only loss is in game music and Morden got around that in some way. I mean, its safe, leaves your C drive clean and has little chance of causing Error 21. For people like me and some other used to softmodding this could be great, but IMO it still doesnt beat the Audio hack for safety and simplicity I mean, I stuck with Mordens for months before I started messing around with the MA fonts and making font/audio switch code to combat the clock loop etc... And finally making my own packages... I look back and if I had to 'start' with this hack, It would blow my mind? Its WAY more complex than just FTPing some fonts or an st.db file over.. You have to know what you are doing.. Anyway.. I plan on virginizing my xbox at the weekend and trying this, see what its like. I guess its just like pressing "PHEONIX" in the MA fonts, as I do anyway, but I always like to tinker My point? Well, if you are a noob! stick with the audio hack.. That is until this becomes more useable and works properly.. Or, if you are happy with your set up, dont jump ship just yet..

i can easily host any of your packages, i asked you before but didnt get a response.

Lemme know, i can even create a website for you.

Regards

[ldots]

QUOTE (Code-X)

Any one want me to make a simple patcher app, that would add the probe code and change the 7 bytes.

I would hold my horses until this exploit is more mature. But for a future release a pathcher would be nice. Seems that many people are concerned about this hexing of Bert. Remember this hexing is only needed for tuning Bert for different prelive dash versions - the exploit is still in a development phase! The are only a limited number of prelive dashes, and once the optimal address and value dwords (0x40,0x44) have been found for each dash one could distribute this exploit with a number of berts for each prelive dash - Bert is small! Or make a small "Bert generator" that pathes the two dwords for your specific dash. This is the reason Rmenhal encouraged us to post the two dwords for each dash version as we find them.

With respect to hosting a future package. Xbins could host this package without the prelive dash, and with a Bert generator, this would be noob-friendly. I'm quite sure a package with a dash could be hosted elsewhere. Slayers is being downloaded frequently!

IMHO this would be the best hack availabe if the final issues are resolved. The audio hack is great yes. But lets face it. The reason the font hack is still popular is that people are lazy and dont like typing the button-combo. This hack would have the safety of the audio hack, but the ease of use of the font hack. And using this with live (even the dashboard live functions) should not be more difficult than using a font/audio switcher now. Simply have Evox, or another dash, rename some fonts like you do with present audio/font switchers but also rename/replace xonlinedash.xbe

Finally, Rmenhal has done/is doing an amazing job. He succeeded where many others have failed. But it's not black magic. He didn't stumble upon some magic way of hexing bert and the hexing is not random, afon :-). He rewrote the fonts to suit this new setup, something that requires an understanding of the font hack and knowledge of assembler, but the techniques are the same as in the original font hack. To my understanding Bert makes a buffer overflow and utilizes this to overwrite the SEH (Structured Exception Handler) address with a pointer to the memory space where ernie is loaded. When an exception is made due to the messed up memory (made by berts overflow) the "landingzone" of Ernie catches this and performs a series of jumbs until the actual exploit code of ernie is reached, which patch in the public key and launches an xbe. The bytes in Bert that needs tuning for each dash, set up the address and pointer to the SEH. Someone with a deeper understanding of this please expand on this if needed... (I'm still learning )

digisatman (an others). For an understanding of the basic concepts of this exploit did you read the first post on this thread?

[mkjones]

the mods dont mind posting links to files but you cant link to RC4s or copyrighted stuff like dashboard files.

This is why tHc is not on xbins, as its a hack of the M$ dash.

Anyhow, I am sure we can work something out when this is ready to use

Also, dont need a website, I have enuf already

You are free to host anything I produce you can download stuff from the threads in my sig....

Back on topic
Has everyone using this experienced a reset-on-eject? Or are some kernals imune??

[devz3ro]

. I would really like to see this succeed, so I am suggesting to bring these conversations / discussions amongst yourselves into a real-time chat environment.

On EFnet /join #xbox-exploits

This is a unofficial (not ran by us or affiliated in anyway with this website, but is great for discussion) xbox exploit IRC (Internet Relay Chat) channel.

For those who have no idea how to get into this channel, visit http://chat.xs4all.nl/

Once here, click on EFnet, then enter a nickname (alais) of your choice, then #xbox-exploits as the channel you want to join and connect.

I believe, while reading your progress, the stage is set for all users contributing to put your heads together; discussing matters without the delay of posting and waiting for a reply would return optimal results.

Think about it.

-devz3ro

http://sh0x.tk/

[Angerwound]

MKJones, I have tested this on two boxes and experienced the ROJ. The ROJ will be there on every kernel to my knowledge there is no immune system.

[mkjones]

QUOTE (Angerwound @ May 6 2004, 02:42 PM)

MKJones, I have tested this on two boxes and experienced the ROJ. The ROJ will be there on every kernel to my knowledge there is no immune system.

Check Just wonderd if it was an M$ afterthought

[afon]

QUOTE

He didn't stumble upon some magic way of hexing bert and the hexing is not random, afon :-). He rewrote the fonts to suit this new setup, something that requires an understanding of the font hack and knowledge of assembler, but the techniques are the same as in the original font hack

Sounds like I came off a bit n00bish. What I meant was: How did he figure out that the St.DB corruption edited bert to his advantage. And even if he did find that out, how the hell did he find out the exact offsets?
Also: Rhemnal must be quite familiar with the xbox BIOS. Because from what I and apparently Pedros Pad were told, the sandbox doesnt allow this kind of overflow to be taken advantage of (If even executed). So, despite some VERY smart people saying this wasnt possible, he made it happen. Impressive.

Now lets cover some issues:

ROJ;
Ah yes, reset on eject. My fear here (As I assume many others is) is that the MCPX has been told not to allow ejecting (like during gameplay). If it is, there is NO, I repeat, NO WAY TO CHANGE THIS (without a hacked bios [not bfm] or resetting). If ROJ is unavoidable:
Were still able to play backups from HDD, CD/DVD, etc. We just:
1.Eject tray
2.Put in backup/unsigned code
3.execute exploit
4.press in drive/close drive via the eject button
5.execute code.

This doesnt seem that bad, but still requires mucho worko.
Ever wonderd why 007 cant play DVD backups? This could be the same dealio.


Sandbox now litterbox;
When Pedros Pad was talking about the sandbox, and how the dashboard ALWAYS launchs applications after itself into it, he stated the limitations of it. It seemed that overflowing an application in the sandbox was impossible. Does this mean that we could be wrong about alot of other things, too? I think someone needs to see whats going on in memory after this double-dash overflow (Just to see whats all going on).


Hexing etc;
EDIT: Just thought about it, and since the dash has allready been launched, the SEH would be different if different code was launched. I still have a shred of hope that there may be some way around this, but i doubt it.

New Kernals
Has anyone tried to launch the easter-egg XBE inside of the XIP on the new kernal? It would interesting to know if the new dash still has that. Maybe we could find something wrong with that. Who knows? The lack of digging in the new kernal is kinda...weak.

[ldots]

QUOTE (afon)

How did he figure out that the St.DB corruption edited bert to his advantage. And even if he did find that out, how the hell did he find out the exact offsets?

Missing your point here? Where is the ST.DB corruption used to edit bert? The only thing the audio hack is used for is patching in the public key and doing nothing else (besides leaving a door open for accessing the xbox). This allows us to run the habibi signed hexed onlinedash that has been edited to jump into rmenhal's probe.bin code that has been embedded. This code is what edits bert. Where exactly this probe.bin gets the correct offsets from is a bit unclear to me. But the strategy is clever. The memory is untouched (besides the key having been replaced) so the memory can be examined in an almost untouched state with the kernel loaded and everything. In fact I see from the probe.bin code that he searches for the start of the kernel and the PE header to find the kernel exports. Is the addres to the SEH extracted from these kernel exports? I speak of you in third person Rmenhal, but feel free to join the discussion  

QUOTE (afon)

My fear here (As I assume many others is) is that the MCPX has been told not to allow ejecting (like during gameplay). If it is, there is NO, I repeat, NO WAY TO CHANGE THIS

Believe you are right, as stated earlier :

QUOTE (ldots @ May 5 2004 @  02:49 PM)

But I mean, dont you think we have to prevent this flag from being set - once it is set it cannot be reverted?

And to comment on some statements that have been made on the ROJ. It's not just a kernel issue. Whether the ROJ is being set depends (also?) on the security flags in the xbe-header. Reloading dash 4920 as xonlinedash does not enable ROJ. Running dash 4034/3944 does. Running xbedumped 4034/3944 does not.
To return to Rmenhal's tests. ROJ is not enabled when the blinking led is reached in the custom made xonlinedash (old dash). Still seems most likely to me that it has never been enabled at this point. Why would the dash enabled ROJ and then disable it at a later state? Then again...
But how could one disable ROJ before it is enabled. We would have to be able to execute code to manipulate the kernel -> we would have to get to bert'n'ernie to do this -> we have allready seen that when running bert'n'ernie ROJ is enabled, isn't it?

[afon]

LOL, i read the readme wrong.

QUOTE

It seems that sometimes after returning from     the audio stuff, the memory block for Ernie gets allocated from a     different place than usually (because of Dashboard or memory corruption     caused by the audio hack, I don't know)

I thought that thats how it was changed.  I get it now..Clever.

[debeautar]

Would it be possible to run a hacked dash as e:/default.xbe, that would a) unlock the reset-on-eject problem and be able to launch Pheonix, like that one hack whose name I'm slipping on? Or is this not a possibility? (the one that says "Pheonix" on the live tab... that one)

Maybe it's too late, and I've had far too many doritos.

Yeah

[afon]

QUOTE (zorxd @ May 7 2004, 03:20 PM)

you mean a third dash?   but isn't the resetoneject enabled as soon as we launch the second dash? I don't think it's going to work that would still be interesting if it works we would have to hex edit that third dash to load other fonts (like .xft instead of xtf) and we will have to make the xft fonts launch something else than e:\default.xbe edit : I tested it and it doesn't work pbl didn't launch but I have been able to run an habbi signed version of the 4817 dash (launched by the second set of fonts) and the reset on eject was on, and it rebooted when I press the eject button, not when the tray is half-way open

Once an ROJ flag has been set, it cant be unset.   Third dashing wouldnt work.

[debeautar]

Thanks for trying. Shows ya how much I know.

Sorry for wasting your time.

[YoshiKool]

w00t! Just tried it now... 5 tries and no reboots, if it helps anyone.... bing

Kernel 4034\Dash 4920\Dash2 4034
I have the audio exploit already installed on the 4920 dash (audio_sl_audio-key.zip)
Copied 4034 xboxdash.xbe over to the xodash folder
Renamed xodash\xonlinedash.xbe to xonlinedash.xbe.bak
Renamed xodash\xboxdash.xbe to xonlinedash.xbe
Tested it by clicking XBOX LIVE on the 4920 dash - works
Renamed XBox Book.xtf to XBox Book.xtf.bak
Renamed XBox.xtf to XBox.xtf.bak
Transferred rmenhal's bert.xtf and ernie.xtf
Tested it again - no audio CD in, works, boots my habibi signed E:\default.xbe (pbl 1.4)

YAY Never works with audio cd in, but thats not important anyway
If i ever need no-resetoneject i have the audio exploit
Strange how it resets halfway out though. Never seen that happen before... and if i try to eject inside the real xonlinedash.xbe it doesn't reset.

weird. well... big thanks to everyone

[BluhDeBluh]

QUOTE (YoshiKool @ May 8 2004, 01:21 PM)

Strange how it resets halfway out though. Never seen that happen before... and if i try to eject inside the real xonlinedash.xbe it doesn't reset.

It also resets halfway out when you use the GameSave exploit.

[rmenhal]

QUOTE (ldots @ May 6 2004, 11:07 PM)

In fact I see from the probe.bin code that he searches for the start of the kernel and the PE header to find the kernel exports. Is the addres to the SEH extracted from these kernel exports?

The code for finding kernel exports is pretty much copied over from dayX. Finding exports this way makes the code Dashboard version independent. Otherwise you could just use the image thunk table at memory offset 0x12000 (like in ST.DB.)

The address to the SEH comes from the Thread Information Block (TIB aka Thread Environment Block aka TEB) of the thread executing probe.bin. It's the same thread that loads both bert and ernie, overwrites the SEH pointer and somewhere along the path causes the exception. I checked that.

The first dword of a thread's TIB contains an address of an exception list. It's a (singly) linked list of pointers to the thread's current SEHs. Google for it. The segment register fs contains a selector that points to the beginning of the TIB. At the beginning of probe.asm you see the instruction "push dword [fs:0]". This pushes the address of the first member of the exception list to the stack. Then probe adds 4 to get the address of the pointer of the SEH we want to overwrite. Actually there seems to be a small bug in probe.asm: the instruction should be "add dword [esp],byte 4" instead of "add [esp],byte 4". In this case it doesn't matter however (I remember the least significant byte always being 0x3C).

The register eax contains an address to the memory block allocated for ernie. Add 0x18 to this and that's where the landing zone starts. You have to look at Dashboard's code to see this. The jump point to probe.bin is actually right after the call that reads ernie to memory. The call right before that allocates ernie's memory. You could change the jump point after that. I originally planned putting probe in a special ernieprobe.xtf. That's why the jump point is at an inelegant position now (could have changed it easily, but I forgot.)

QUOTE

But how could one disable ROJ before it is enabled. We would have to be able to execute code to manipulate the kernel -> we would have to get to bert'n'ernie to do this -> we have allready seen that when running bert'n'ernie ROJ is enabled, isn't it?

I would be very surprised if the XBE that's being loaded had any control over the 0x80000000 media type flag. So I think ROJ is enabled all the way through the second Dash and probably the only way to fix the ROJ issue is to either find some new serious hole in the XBE loader or find a way to disable ROJ after it's been enabled. Finding that entirely new hole would very probably make Double Dash unnecessary, though, and is very unlikely. And finding a way to disable the hardware ROJ...