Jump to content


Photo

Double dashboard exploit


  • Please log in to reply
267 replies to this topic

#61 ldots

ldots

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,496 posts

Posted 06 May 2004 - 09:07 PM

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 biggrin.gif
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?

#62 afon

afon

    X-S X-perience

  • Members
  • PipPip
  • 401 posts

Posted 06 May 2004 - 09:44 PM

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. rolleyes.gif I get it now..Clever.

#63 []V[]nm6687

[]V[]nm6687

    X-S Senior Member

  • Members
  • PipPip
  • 181 posts

Posted 07 May 2004 - 01:43 AM

QUOTE (mkjones @ May 6 2004, 03:50 AM)
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... sad.gif

Also, it would make DVD2XBOX unusable. So anyone upgrading a HD using softmods (as I have) wouldnt be able to back up their games sad.gif

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.

#64 debeautar

debeautar

    X-S Member

  • Members
  • Pip
  • 109 posts

Posted 07 May 2004 - 05:01 AM

Would it be possible to run a hacked dash as e:/default.xbe, that would a) unlock the reset-on-eject problem and cool.gif 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

#65 zorxd

zorxd

    X-S Senior Member

  • Members
  • PipPip
  • 154 posts

Posted 07 May 2004 - 01:20 PM

QUOTE (debeautar @ May 7 2004, 07:01 AM)
Would it be possible to run a hacked dash as e:/default.xbe, that would a) unlock the reset-on-eject problem and cool.gif 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

you mean a third dash? tongue.gif
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 tongue.gif

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

Edited by zorxd, 07 May 2004 - 03:38 PM.


#66 afon

afon

    X-S X-perience

  • Members
  • PipPip
  • 401 posts

Posted 07 May 2004 - 11:25 PM

QUOTE (zorxd @ May 7 2004, 03:20 PM)
you mean a third dash? tongue.gif
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 tongue.gif

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. sad.gif Third dashing wouldnt work.

#67 debeautar

debeautar

    X-S Member

  • Members
  • Pip
  • 109 posts

Posted 08 May 2004 - 12:42 AM

Thanks for trying. Shows ya how much I know. sad.gif

Sorry for wasting your time.

#68 YoshiKool

YoshiKool

    X-S Expert

  • Members
  • PipPipPip
  • 641 posts
  • Location:Yoshi's Island
  • Xbox Version:v1.0

Posted 08 May 2004 - 11:21 AM

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 smile.gif
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 biggrin.gif Never works with audio cd in, but thats not important anyway smile.gif
If i ever need no-resetoneject i have the audio exploit smile.gif
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 smile.gif

#69 BluhDeBluh

BluhDeBluh

    X-S Senior Member

  • Members
  • PipPip
  • 209 posts

Posted 09 May 2004 - 09:19 AM

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

#70 rmenhal

rmenhal

    X-S Senior Member

  • Members
  • PipPip
  • 254 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 10 May 2004 - 04:27 PM

QUOTE (ldots @ May 5 2004, 06:22 PM)
OK - see your point. Don't know how far in execution of xonlinedash we are when we reach the blinking led at 1). Are you sure the reset-on-eject has been enabled and then disabled?

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.


#71 rmenhal

rmenhal

    X-S Senior Member

  • Members
  • PipPip
  • 254 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 10 May 2004 - 05:10 PM

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


#72 ldots

ldots

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,496 posts

Posted 10 May 2004 - 05:40 PM

Thanks a lot for the clarifications rmanhal - much appriciated.
QUOTE
...either find some new serious hole in the XBE loader or find a way to disable ROJ after it's been enabled...

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

#73 rmenhal

rmenhal

    X-S Senior Member

  • Members
  • PipPip
  • 254 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 10 May 2004 - 05:47 PM

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.

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.


#74 mbriody

mbriody

    X-S Young Member

  • Members
  • Pip
  • 37 posts

Posted 11 May 2004 - 07:37 AM

QUOTE (xb0xb0y @ May 5 2004, 11:32 PM)
You guys can keep talking amongst yourselves and ignore my previous question, which has been up to this point anyway  blink.gif .  I've figured out how the font exploit works and got the double dash working.

Good work rmenhal, great job!

BTW, I didn't do any of the tuning of BERT at all.  Am I suppose to?  And how many people actually needed to?  Can someone explain what the tuning is for?  Thanks.

Cheers!  beerchug.gif

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?


Edited by mbriody, 11 May 2004 - 07:37 AM.


#75 xb0xb0y

xb0xb0y

    X-S X-perience

  • Members
  • PipPip
  • 300 posts
  • Xbox Version:unk

Posted 11 May 2004 - 02:23 PM

QUOTE (mbriody @ May 11 2004, 04:37 AM)
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.

Edited by xb0xb0y, 11 May 2004 - 02:24 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users