Reset On Eject...bug?, kinda weird, read desc. Options

[atomiX]

i've had a gamesave installer made for a while. i updated it today with optmisations which require a reboot and removal of the exploitable game from the drive.

i included a command in my scripts to open the tray when the 1st part of the install process is finished and when it does, the tray ejects fine but the xbox reboots when the tray is half-out, then goes back in because of the reboot.

this also happens when manually opening the tray when in the dash.

before jumping to conclusions...it is NOT a bios/kernel patcher issue because ROJ is deffinately disabled. i'm pretty sure it's an issue with UX. and yes, it's the newest UX version.

i've seen a few similar problems but have yet to see an explanation.

anybody know of a fix for this?

[pepsik]

I ran into this on 1.6 version xboxs, if that is the version you have in question. It should narrow it down this way.

[atomiX]

nope, 1.3

[atomiX]

i tested a few things...seems this only happens with nkpatcher. i turned on my chip with ind-bios 5003 to test the installer and the eject worked well. when using nkpatcher, it still does the reboot after the tray is half-out.

i tried compiling nkpatcher with different variations of IRG and ROE to no avail.

[Jezz_X]

Wasn't this one of the fatal flaws of Gamesave hacks that you couldn't eject them without ROE and why most people used them to install other hacks I think it had somthing to do with the MSDash setting somthing in the bios.
I suggest you go search in the GameSave forum because it was discussed manytimes when I used a softmod, things might of changed since then though it was before UXE and NKPatcher

[atomiX]

i'm already aware of this.
but this is not the case. regular gamesaves that you get from xbins will have ROE because they only modify the kernel's public key in memory, meaning that the kernel is still in a retail state except for the public key. this is why there is ROE on those gamesaves.

however, my save boots a habibi-signed nkpatcher which in turn will boot the dash. so when UX is loaded, all hacks implemented in nkpatcher are already loaded which means that ROE is also disabled.

the weird thing is that is doesn't reset the moment you press the button like when you have ROE enabled...it only restarts when the tray is about half-out

EDIT: I've done a bit more pokin around and now I don't think it's an UX issue. I think it has to do with nkpatcher since when i load apps with my save's UX filemanager, the same thing happend when i reset...weird that this happens with the save and not when nkpatcher is booted with the UXE exploit...

This post has been edited by atomiX: Jan 27 2005, 12:51 AM

[Jezz_X]

Heres a quote from the Pinned topic in the gamesaves forum I made the bits RED

Here's the low down. This forum is for gamesave exploits. This means an exploit thats loaded through a gamesave. With these exploits, you can only really run homebrew programs because you can't eject the DVD tray Now if you want to eject the DVD tray, I suggest you install an XBE exploit. Gamesave exploits are however, the most recommended way to get into your Xbox to install an XBE exploit.

Where can you find these XBE exploits? Well on the Xbox-Scene forum its directly below this forum.
Or here even for you lazy people!

If by any chance you come across tutorials on things like font hacks, FreeX tutorials, Bert And Ernie guides, etc, these are just highly outdated XBE exploits. DO NOT USE THESE. The current top exploit is UXE, and works on any model or region Xbox.

[atomiX]

you obviously don't understand what i did
i use the gamesave to load nkpatcher (embeded in the save). the gamesave exploit itself does have ROE because it doesn't patch the kernel to disable it.

i use the gamesave exploit to load nkpatcher (embeded in the save) INSTEAD of a dash (like evox in most downloadable hacked gamesaves). plus, that nkpatcher is customised to boot the dash inside the save (in my case, UX) that i use as the installer portion.

my whole gamesave goes beyond a simple hacked save that you can get on xbins...

in short:
1. regular hacked save is loaded
2. boots habibi-signed nkpatcher INSTEAD of habibi-signed dash
3. nkpatcher runs and patches kernel in memory to enable various bios hacks (like lba48, live block and others including ROE fix)
4. when patching is done, nkpatcher loads the installer interface (UX) from the gamesave folder.

the quote you posted doesn't apply to my save. if you want proof, ask the softmod mods like devz3r0 and rmenhal. i know quite a lot about exploits myself...

and like i said above, the ROE prob is related to nkpatcher and not UX like i thought at first. i already PM'ed rmenhal about it

[Jezz_X]

Well From my limited readings it seems that the game that is loaded to use the hacked gamesave sets a flag on the actual hardware that can't be changed by memory. This is the same reason that people who use Bios loaders to load a completely different bios into memory will still experience the ROE issue when loaded from a gamesave even after things like soft reboots and stuff.

The reason it dosn't effect things loaded from font/xbe exploits is that it the bios gets changed either by nkpatcher or a bios loader before the ROE flag is set. And loading nkpatcher after the flag is set on the hardware would not make any difference because the xbox thinks that as soon as the drive opens reboot

I would like to point out that I'm not trying to argue with you just help I could be 100% wrong and I would love to hear what rmenhal has to say about it

This post has been edited by Jezz_X: Jan 27 2005, 06:11 AM

[atomiX]

sure, i'm not trying to argue either, i just want to find what's going on and appreciate that you're trying to help

i've never heard about this impossibility to reverse the ROE flag with a gamesave but it might be true...just hope this isn't the case.

the reason i think it might be something else is because when the ROE flag is set, the xbox reboots immediately after pressing the eject button but with my setup, it only reboots a few seconds after (when the tray is half-open).

if any moderator reads this, you can move the thread to the gamesave or xbe exploits forums (whichever that seems more appropriate) since it really doesn't belong here anymore.

[atomiX]

i've done a little reading outside X-S and it indeed seems like it's a hardware issue.
if anyone has TECHNICAL details on how the ROE flag works, please post here. thx

[eh.]

When booting from a DVD the kernel honors the media type's non-secure mode flag, which for almost all DVD .xbe's is 0, which causes ROE/J to be enabled. (When booting from HDD the kernel doesn't do this at boot, but does for .xbe's thereafter unless their flag is 8...). Once set there's no known way to unset it (and folks have tried) eh.

This post has been edited by eh.: Jan 27 2005, 05:06 PM

[DaddyJ]

As eh stated,
Once ROE has been set, it cant be unset, until a power cycle has occured.

[atomiX]

ok, getting a bit closer to understanding this but eh, where exactly is the flag data stored if it can't be changed in memory?

[eh.]

It's believed that secure mode activates a hardware toggle (that cannot be reversed via software) eh.