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?

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.

nope, 1.3

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.

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

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

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

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

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

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.

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

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.

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

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?

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

I have been doing some hardware testing on this, but havent found anything that would matter at this point.

i'm starting to think this has something to do with the "trusted computing platform" proposed by MS and the other big companies (TCPA). i remember reading that the xbox contains certain components of this platform...could this flag held in hardware be one of them?

Only one program knows how to disable this HARDWARE flag. It is the XBOX Music Maker DVD, but NO gamesave HACK has been found for this certain disc.

I wish we could find the hardware signal on the mainboard for this ROE problem,
maybe it could be solve by "cutting" the trace or installing a switch. I know, a
little worse than software solution, but a possible solution.

well the music maker is able to do it through software....so one would assume it would be possible to do mimic that. i'm sure it wouldn't be easy however. i think it would be an interesting topic to look into and if people figured it out it would be incredibly useful....but i wouldn't be suprised at all if no advancements were made. as for atomix, yeah, it's frustrating...but as of yet, ROE is untouchable with gamesave exploits.

i don't think music mixer removes the ROE flag that is the problem with gamesaves...i think it just doesn't set the flag in the first place. (i'm guessing its ROE flag is probably 8 and not 0 so it doesn't get enabled at all)

You are entirely correct; the 8 in the 0x80000002 below tells the kernel "don't enable reset on eject" eh:


Edit: and if it was already enabled it would remain enabled, alas eh!

(There are a few others, but hardly any that's for sure [and none of them disable ROE/J] eh.)

Can't someone disassembly the MS kernal section where it checks these
flags, and study the assembly code used to SET the "ROE" feature, and
then from the actual code doing the "flag setting", figure out the "port"
the kernal is writting to, and then write test code in trying to "rewrite"
this port.

I'm sure M$ likes to keep XBE's that turn ROE off to a minimum

yes garyopa...somebody could disassemble the kernel and check for where it's getting flagged....somebody could also crack MS's private key so that modding wouldn't even be necessary....is it going to actually happen? not in our lifetimes....but it could happen. (it's way too complicated to make it feasible)

i'm doing something similar right now. not with dissasembly though. i'm trying to locate the address and/or bus that is used to set the flag. still have a long way to go and i'm not positive i'll find anything either...

since ppl have already tried to find it, it might be a lost effort but i'll try anyway.

EDIT: getting closer, i know pretty much for a fact the the SMBUS is used to write the value

Any progress on this issue at all?

From the reading I've post of this post it seems like it's came to a dead end, but it would be interesting to know if something has been found.

I apologise in advance if there's newer posts etc but I DID use the Search to find this one.

TIA