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

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?

Check Just wonderd if it was an M$ afterthought

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.

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

Believe you are right, as stated earlier :

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?

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

no dude, you simply eject the tray, then place the game on the tray, then launch the hack. while the hack is being launched, the tray is still open. when your dashboard loads, u can just push the tray in and it'll work like normal. so you can still play backup DVDs and you can still backup with dvd2xbox. there wont be an MS disc error because you dont actually put the disc in.

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.

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

No. I made a mistake in 2) as I explained in the update of my posting. If the old dash has 0x80000000 media type, then reset-on-eject is not enabled at any point. If 0x80000000 is not set, then reset-on-eject is enabled during the blinking led and all the way through the second Dash. Forget about those experiments of mine. They're not useful at all.

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

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

Naaa, doesn't look too good does it?

But remember everybody, this exploit is still very usefull (and safe) if you are not going to eject the DVD drive all the time.

You sure are very knowledgeable about the kernel and the details about the font hack though. How about digging into improving the Mech fonts

I think it goes like this. Suppose you're running the vanilla MS kernel. There's a flag inside the kernel that tells it whether reset-on-eject is enabled or not. The flag gets cleared when ROJ is enabled. When you push the eject button, the PIC will interrupt the kernel and tell it that the button has been pressed. The kernel will then check the flag and if it's clear, it will reset the system. It doesn't really matter whether the hardware ROJ is enabled or not (it's enabled, though.)

Now suppose you're running a patched kernel (from PBL). It's been patched against this behaviour. So when you push the eject button and the PIC interrupts the kernel, the kernel will just send the usual proper response message and the eject tray message. The tray ejects, but halfway through the hardware ROJ kicks in and resets the system. The kernel doesn't get to have any say in the matter.

I played a bit with this system. The message that's first sent back to the PIC after the interrupt is command 0x0D with data byte 0x04. This will actually stop some sort of automatic reset. If you don't send this, the system resets. This is different from reset-on-eject. A sort of "kernel dead? -> reset". I changed this message to one with data byte 0x02. In some xbox-linux developer meeting this was called "shutdown in progress". I'd call it "delayed power off". If the hardware ROJ is enabled and as a response to tray button press interrupt you send this and then the eject tray message, the tray will eject all the way and back in, but the system will then power off. So the system works a bit longer and it overrides the hardware ROJ. But the box powers off, so it's not helpful at all. It would be nice, if there was a way to make the time delay (a lot) longer somehow. Sending more of those 0x0D with 0x02 messages don't help.

I've got the same problem as you. I can load the old dash but after I load ernie and bert and try it I get the red light and error 21.

How did you fix it?

Different question - I'm confused as to how this works, how come you don't need to rename ernie and bert? Does the old dash just go by the font file extension and not the file name?

someone correct me if i'm wrong ... but error 21 seems to be a file error most of the time. the box is looking to find some file it needs to continue running/execute, and the file is not found or if it is, it isn't what it is expecting.

i ran into error 21 while installing a bigger hard drive and helping test Idots new hard drive util. the drive was prepped and locked with the appropriate password but wouldn't boot properly. i guessed i wasn't properly copying the files to the drive properly. so i ended up ghosting the drive and fixed the problem.

originally i didn't have a signed default.xbe in "e:". i then placed a signed evoxdash but that didn't work either. finally after reading the instructions again, i put a signed PBL loader and then everything was fine.

If you can boot the old dash you are half way there. Yes, the font files are boot by extensions as far as I know because you've always had to just rename the others and place bert and ernie in the folder. Secondly, your getting an error 21 is my guess because your e:\default.xbe is not either signed or there. If it is booting to an error 21 after the placing of the fonts then the fonts are doing there job and attemptng to load a file( you default.xbe ) but hitting the error because they are not there. Good Luck.

I have the contents of Signed_Phoenix_Bios_Loader_V1.3 unzipped onto e:\ which includes xboxrom.bin, evoxdash.xbe and evox.ini.

I also copied the evox files to c:\ as I'm not sure if they should be there or on e:

Apart from renaming the original fonts and copying bert and ernie have I missed anything?

[EDIT]

Okay all working now, think it was incorrect version of PBL as suggested.

I'm still confused about getting this to work on Live... which isn't surprising since im such a noob at all this
If i try to play a game on live its just going to update my dash from 4920 right? Do i need to be running the audio exploit if i want to play Live?

It only updates your dash when there's an update available, at which point you need 007/MA/SC to get it back to 4920. This shites on the audio exploit so much it's not funny. Kudos devz3ro.

If I understand, you have the catfish fonts within your ORIGINAL DASH's font DIR?
If this is so, replace with completely original fonts and then install the Double Dash as explained. The entire technique is based upon booting an original unmodified fonts/dashboard.

Could you please post the steps you have taken to install the pre-live dash? You shouldn't see the setup Live account at all if you replaced your xonlindash.xbe with the xboxdash.xbe of the pre-live. You should be somewhere between an Error 21 or booting dashboard.

i am using a 1.5 or 1,6 version xbox, i`m not sure which.