Jump to content

Question About the Dangers of Nulling the Hdd Key.


Recommended Posts

I would have thought the saves where linked to the serial number and not the HDD key.

 

But if the game save was locked to a  nulled HDD key you could easily copy the save to a new nulled HDD key Xbox,

But would not using the MS dash to copy the save to a memory card and then to a different Xbox not transfer it to the new SN

 

 

Cheers

SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

Link to post
Share on other sites

There are quite a few consequences and risks to changing the XboxHDKey

  • Any currently installed downloadable content and updates become invalid
  • Any gamesaves signed as "non-roamable" become invalid
  • Any Xbox LIVE accounts stored on the hard drive become invalid
  • If Xbox LIVE accounts were stored on the hard drive then the machine account becomes invalid as well
  • A zeroed (nulled) XboxHDKey on a retail console is not considered valid (however is completely valid on XDK)

There are several risks in the process of changing the XboxHDKey as well, especially on softmodded systems and cheapmod modchips with no intermediate recovery menu

  • Failing to write the EEPROM data back properly
    • The SMC failing in the middle of a write transaction could corrupt the EEPROM, resulting in a "bricked" EEPROM
    • Homebrew failing to encrypt the 'EncryptedSection' of the EEPROM data properly (where the XboxHDKey is stored), resulting in a "bricked" EEPROM
  • Homebrew failing to check for a successful EEPROM write before changing the hard drive password, which could result in the hard drive being locked with an incorrect password
  • Homebrew failing to check if ATA commands to the hard drive for disabling password/setting user password were successful after already writing EEPROM changes, which could result in the hard drive being in a permanently unlocked state or leaving the hard drive locked with the old password
  • Homebrew failing to generate the hard drive password correctly and setting an improper password, leaving the system in an unbootable/inoperable state
  • Homebrew failing to roll back changes in the event of an error if either the process of EEPROM I/O or ATA I/O fails, leaving the system in an unbootable/inoperable state
  • Homebrew (or even retail software) crashing during either the process of EEPROM I/O or ATA I/O, leaving the system in an unbootable/inoperable state

 

Zeroing the XboxHDKey makes recovery easier in the event of a failed hard drive sure but is simply keeping a backup of the original EEPROM data and leaving the XboxHDKey as-is really that much more difficult? Never really understood people always suggesting zeroing this EEPROM setting but then again, those same people never seem to explain the reasons why doing so can be detrimental and carry heavy risk

I still have my EEPROM backups from 2002 ¯\_(ツ)_/¯

  • Like 1
Link to post
Share on other sites

@feudalnate - First off, thanks for compiling a concise list of the cons to nulling drive keys. I'm kind of surprised this is your first post, since you registered 10 months ago and you seem know quite a bit about this pretty obscure topic. I'll admit as a proponent of nulling drive keys that I don't always make these side effects clear. I'll make an effort to be more vocal about that risk in the future. I think it would also be good if softmod packages that alter the hdd key (such as Rocky5's softmod tool) were more transparent about this side effect too.

Quote

Zeroing the XboxHDKey makes recovery easier in the event of a failed hard drive sure but is simply keeping a backup of the original EEPROM data and leaving the XboxHDKey as-is really that much more difficult? Never really understood people always suggesting zeroing this EEPROM setting [...]

It really depends on the user. If they have DLC (which can be reinstalled) or happen to have gamesaves for the minority of games that are non-roamable, then yes it could be annoying to them to realize that nulling their drive key just broke that data of theirs. But if it's someone looking to dust off their old Xbox to use it for emulators and to play new games on, then nulling the key wouldn't be a problem for them and the benefit of being able to recover easier later on may outweigh the cons. For someone like me, the benefit of never having to deal with eeprom backups or keep track of which drive is locked to which console is incredibly convenient. I keep them backed up on my computer (and a memory unit), but I generally never need to touch those backups. All my consolesare locked with the same key, so if something goes wrong with a softmod, I can drop that hard drive into a hardmodded Xbox and fix the issue rather easily.

Back in the day, unlocking a drive using a PC meant burning a CD with that Xbox's eeprom on it and making sure you used the right disc for the right hdd. I remember mixing that up a few times in my early days. These days, Xboxhdm can be run within Windows 10 even, but I've experienced issues with my PC not being able to send security ATA commands for some reason or my USB-IDE adapter not passing ATA commands to unlock my hdd. I'd prefer to skip all that and use a 2nd Xbox to deal with locking/unlocking.

Quote

Any gamesaves signed as "non-roamable" become invalid

Correct me if I'm wrong, but the number of games that sign their gamesaves is rather low. There's Phantasy Star Online, Dead or Alive X, Forza Motorsports, and Burnout 3. I bet there's more, but I believe it's a small minority of games. For some, there's trainers to get around the key signing issue. There's also a re-signing app floating around for PSO.

Quote

those same people never seem to explain the reasons why doing so can be detrimental and carry heavy risk

The risks you mentioned assume that the homebrew app being used doesn't work properly or that a random hardware fault occurs. Yes it's possible, but the casual modder would likely not experience that. And if they do, they should really go out and buy a lottery ticket. I would disagree that it's unsafe enough to be deemed "risky". I've never had issues with homebrew apps screwing up the process in the dozens (>hundred?) Xboxes I've owned over the years. The real risk is if a newbie unlocks their softmodded Xbox's hdd, then forgets to lock it and turns off their system, but Rocky5's popular HDD nuller app doesn't even give the person the opportunity to leave it unlocked.

P.s. another downside to nulling your HDD key is you won't be able to use the upcoming Xbox Live replacement, Insignia, when it comes out. The workaround is to use all 1's instead of all 0's (or 1 followed by 31 zeroes), or your original hdd key. (Rocky said he was updating his softmod package to account for this. Not sure if he did that yet.)

  • Like 1
Link to post
Share on other sites
8 hours ago, feudalnate said:

There are quite a few consequences and risks to changing the XboxHDKey

  • Any currently installed downloadable content and updates become invalid
  • Any gamesaves signed as "non-roamable" become invalid
  • Any Xbox LIVE accounts stored on the hard drive become invalid
  • If Xbox LIVE accounts were stored on the hard drive then the machine account becomes invalid as well
  • A zeroed (nulled) XboxHDKey on a retail console is not considered valid (however is completely valid on XDK)

There are several risks in the process of changing the XboxHDKey as well, especially on softmodded systems and cheapmod modchips with no intermediate recovery menu

  • Failing to write the EEPROM data back properly
    • The SMC failing in the middle of a write transaction could corrupt the EEPROM, resulting in a "bricked" EEPROM
    • Homebrew failing to encrypt the 'EncryptedSection' of the EEPROM data properly (where the XboxHDKey is stored), resulting in a "bricked" EEPROM
  • Homebrew failing to check for a successful EEPROM write before changing the hard drive password, which could result in the hard drive being locked with an incorrect password
  • Homebrew failing to check if ATA commands to the hard drive for disabling password/setting user password were successful after already writing EEPROM changes, which could result in the hard drive being in a permanently unlocked state or leaving the hard drive locked with the old password
  • Homebrew failing to generate the hard drive password correctly and setting an improper password, leaving the system in an unbootable/inoperable state
  • Homebrew failing to roll back changes in the event of an error if either the process of EEPROM I/O or ATA I/O fails, leaving the system in an unbootable/inoperable state
  • Homebrew (or even retail software) crashing during either the process of EEPROM I/O or ATA I/O, leaving the system in an unbootable/inoperable state

 

Zeroing the XboxHDKey makes recovery easier in the event of a failed hard drive sure but is simply keeping a backup of the original EEPROM data and leaving the XboxHDKey as-is really that much more difficult? Never really understood people always suggesting zeroing this EEPROM setting but then again, those same people never seem to explain the reasons why doing so can be detrimental and carry heavy risk

I still have my EEPROM backups from 2002 ¯\_(ツ)_/¯

thank u for that list. i was actually logging in to bring up the thing about downloadable content(it just suddenly dawned on me. kind of a "light bulb " moment) and was surprised to see your impressive list. there are some games like ninja gaiden that required an xbox live account to activate the dlc. it is possible to activate that dlc without xbl but it is tricky.  it would really suck for people that have downloadable content like that from way back in the day and lose it because they nulled their hdd key because they didn't know any better. we should really be more careful and thorough about recommending for people to null their hdd key.

Link to post
Share on other sites
On 10/13/2020 at 2:04 PM, GoTeamScotch said:

I'm kind of surprised this is your first post, since you registered 10 months ago and you seem know quite a bit about this pretty obscure topic

Anywhere the Xbox/Xbox 360 modding scene is you will likely find me even if I haven't posted anything, I'm usually around. The unknowns and obscure things are what still keeps my interest in the Xbox modding scenes

 

On 10/13/2020 at 2:04 PM, GoTeamScotch said:

It really depends on the user. If they have DLC (which can be reinstalled) or happen to have gamesaves for the minority of games that are non-roamable, then yes it could be annoying to them to realize that nulling their drive key just broke that data of theirs. But if it's someone looking to dust off their old Xbox to use it for emulators and to play new games on, then nulling the key wouldn't be a problem for them and the benefit of being able to recover easier later on may outweigh the cons. For someone like me, the benefit of never having to deal with eeprom backups or keep track of which drive is locked to which console is incredibly convenient. I keep them backed up on my computer (and a memory unit), but I generally never need to touch those backups. All my consolesare locked with the same key, so if something goes wrong with a softmod, I can drop that hard drive into a hardmodded Xbox and fix the issue rather easily.

I don't really disagree with any of this, DLC/updates can be signed to the new key fairly easily (shameless plug: https://github.com/feudalnate/XBX-Content-Tool) but gamesaves are more specific and some of those saves that use non-roamable signing can even incorporate scrambling/encryption which makes those saves that much more difficult to recover (although this type data security doesn't seem too common)

I don't have anything against those that want to change their console keys but I also don't get why holding onto your original EEPROM data presents any sort of difficulty. You mention your scenario dealing with many consoles and I can see it how having all those consoles sharing the same key can be beneficial to someone dealing with the same situation but most people aren't going to share this type of situation. The average Xbox fan/enthusiast is going to have one or two consoles and holding onto their consoles EEPROM data isn't much of a problem

My consensus on this is that people can do whatever they please with their consoles and I don't disagree with the convenience and ease of recovery that setting the XboxHDKey to something simple to remember can provide

On 10/13/2020 at 2:04 PM, GoTeamScotch said:

Back in the day, unlocking a drive using a PC meant burning a CD with that Xbox's eeprom on it and making sure you used the right disc for the right hdd. I remember mixing that up a few times in my early days. These days, Xboxhdm can be run within Windows 10 even, but I've experienced issues with my PC not being able to send security ATA commands for some reason or my USB-IDE adapter not passing ATA commands to unlock my hdd.

I have a couple of those discs laying around myself from the early days of modding. The problem with running things like this in Windows is that you're running in user-mode and Windows doesn't like when random programs send direct ATA commands to devices - programmers kind of need to fight with this to get Windows to play nice and that's why running the old style of XBHDM on boot to bypass Windows generally works better

 

On 10/13/2020 at 2:04 PM, GoTeamScotch said:

Correct me if I'm wrong, but the number of games that sign their gamesaves is rather low. There's Phantasy Star Online, Dead or Alive X, Forza Motorsports, and Burnout 3. I bet there's more, but I believe it's a small minority of games.

From what I've seen it's mostly games that were released after modding was known to be rampant (2003-2004?). Can't provide a specific list of games, really all I can say on this but there's a good amount
 

On 10/13/2020 at 2:04 PM, GoTeamScotch said:

The risks you mentioned assume that the homebrew app being used doesn't work properly or that a random hardware fault occurs. Yes it's possible, but the casual modder would likely not experience that. And if they do, they should really go out and buy a lottery ticket. I would disagree that it's unsafe enough to be deemed "risky".

Hard drive

The most commonly used functions in homebrew programs that deal with ATA security commands come from an open source library that Yoshihiro/Team-Assembly put out in ~2003. The functions for sending ATA commands for disabling and setting the password are very hacky and they do work.. technically. The issue with these widely used functions is that they do not follow the ATA specification at all and that is what is dangerous

There is no check for the device ready flag to know if the command sent will be accepted. The "cleaning" of model/serial characters manually pulled from an identify packet command instead of pulling and using already prepared data sitting in the kernel, the exact data the kernel requires and will expect when generating the hard drive password. Commands being directly sent to the I/O port instead of through the DeviceIoControl function in the kernel that can provide additional context setup, mutexing, and checking. No checking for error flags in the error register after a command is sent even though direct port access is being used. The sending of ATA commands, looping for X amount of tries until successful but always returning true even if the command was in fact, not successful

EEPROM

Programming any type of flash while in-circuit carries an inherit risk. It's much the same risk as writing a TSOP or a cheapmod modchip with no recovery software in place. I'm sure there's a more technical term for this type of IC writing but I've always referred to it as a kamikaze write - where if anything were to be written incorrectly for any reason then that IC will be left in a bricked state

I'll say this, there is a reason Microsoft immediately pulls all EEPROM data into memory upon powering on the console, leaves it there in memory for the entire duration the console is powered on, and always references that copy in memory instead of directly accessing the IC. There is a reason most kernel functions specifically avoid writing to the EEPROM and only do so when there is a setting that must persist through a power cycle. There is a reason why a bunch of non-vital settings in the EEPROM go unused in retail kernels and a reason why those settings were moved into the "config" area on the hard drive instead

 

A lot of the homebrew programs that deal with these two security areas on the Xbox do usually work and I won't say they don't but there is always a chance of failure in the programming of these homebrew programs and to say that there isn't would be ignorant of reality. I'm sure many Xbox's have "died" to an error during EEPROM writes, not only from homebrew software but from the Xbox/Xbox LIVE dashboards as well. Just because no one specifically reports an EEPROM write error doesn't imply it's not a real thing and most people aren't going to know this was what caused their issue to begin with so how would they report it. However, an incorrectly set security state for the hard drive will always come from homebrew of some kind

Even when done correctly, dealing with these security areas is risky and the risk is there because both the EEPROM and the hard drive are critical system components

On 10/13/2020 at 2:04 PM, GoTeamScotch said:

another downside to nulling your HDD key is you won't be able to use the upcoming Xbox Live replacement, Insignia, when it comes out. The workaround is to use all 1's instead of all 0's (or 1 followed by 31 zeroes), or your original hdd key

As I said in my initial post, a zeroed XboxHDKey is not considered valid by the kernel. The kernel doesn't throw an error for this but if you were to somehow attach a debugger to a retail console while it boots, it would assert an error on kernel initialization. A zeroed XboxHDKey is only valid on debug kernels

Realistically if this new homebrew LIVE service comes to light then the real issue looking forward is how is the LIVE dashboard going to function when softmods based on the UXE exploit use an exploitable version of the LIVE dashboard? How are softmods going to boot when they require the LIVE dashboards files but so does this homebrew service? Will need to see how things turn out with this homebrew LIVE service first to see if a solution is needed - the XboxHDKey is only one problem of potentially many

 

Some references

ATA/ATAPI-4 Specification

ATA Security Clarification

XKUtils Library by Yoshihiro/Team-Assembly

 

Most of what I've stated in this thread stems from research I've done with the kernel, EEPROM, SMC, and hard drive (along with looking into open source homebrew, reversing homebrew, and softmod stuff)

Edited by feudalnate
Link to post
Share on other sites
On 10/14/2020 at 10:40 PM, feudalnate said:

Anywhere the Xbox/Xbox 360 modding scene is you will likely find me even if I haven't posted anything, I'm usually around. The unknowns and obscure things are what still keeps my interest in the Xbox modding scenes

 

I don't really disagree with any of this, DLC/updates can be signed to the new key fairly easily (shameless plug: https://github.com/feudalnate/XBX-Content-Tool) but gamesaves are more specific and some of those saves that use non-roamable signing can even incorporate scrambling/encryption which makes those saves that much more difficult to recover (although this type data security doesn't seem too common)

I don't have anything against those that want to change their console keys but I also don't get why holding onto your original EEPROM data presents any sort of difficulty. You mention your scenario dealing with many consoles and I can see it how having all those consoles sharing the same key can be beneficial to someone dealing with the same situation but most people aren't going to share this type of situation. The average Xbox fan/enthusiast is going to have one or two consoles and holding onto their consoles EEPROM data isn't much of a problem

My consensus on this is that people can do whatever they please with their consoles and I don't disagree with the convenience and ease of recovery that setting the XboxHDKey to something simple to remember can provide

I have a couple of those discs laying around myself from the early days of modding. The problem with running things like this in Windows is that you're running in user-mode and Windows doesn't like when random programs send direct ATA commands to devices - programmers kind of need to fight with this to get Windows to play nice and that's why running the old style of XBHDM on boot to bypass Windows generally works better

 

From what I've seen it's mostly games that were released after modding was known to be rampant (2003-2004?). Can't provide a specific list of games, really all I can say on this but there's a good amount
 

Hard drive

The most commonly used functions in homebrew programs that deal with ATA security commands come from an open source library that Yoshihiro/Team-Assembly put out in ~2003. The functions for sending ATA commands for disabling and setting the password are very hacky and they do work.. technically. The issue with these widely used functions is that they do not follow the ATA specification at all and that is what is dangerous

There is no check for the device ready flag to know if the command sent will be accepted. The "cleaning" of model/serial characters manually pulled from an identify packet command instead of pulling and using already prepared data sitting in the kernel, the exact data the kernel requires and will expect when generating the hard drive password. Commands being directly sent to the I/O port instead of through the DeviceIoControl function in the kernel that can provide additional context setup, mutexing, and checking. No checking for error flags in the error register after a command is sent even though direct port access is being used. The sending of ATA commands, looping for X amount of tries until successful but always returning true even if the command was in fact, not successful

EEPROM

Programming any type of flash while in-circuit carries an inherit risk. It's much the same risk as writing a TSOP or a cheapmod modchip with no recovery software in place. I'm sure there's a more technical term for this type of IC writing but I've always referred to it as a kamikaze write - where if anything were to be written incorrectly for any reason then that IC will be left in a bricked state

I'll say this, there is a reason Microsoft immediately pulls all EEPROM data into memory upon powering on the console, leaves it there in memory for the entire duration the console is powered on, and always references that copy in memory instead of directly accessing the IC. There is a reason most kernel functions specifically avoid writing to the EEPROM and only do so when there is a setting that must persist through a power cycle. There is a reason why a bunch of non-vital settings in the EEPROM go unused in retail kernels and a reason why those settings were moved into the "config" area on the hard drive instead

 

A lot of the homebrew programs that deal with these two security areas on the Xbox do usually work and I won't say they don't but there is always a chance of failure in the programming of these homebrew programs and to say that there isn't would be ignorant of reality. I'm sure many Xbox's have "died" to an error during EEPROM writes, not only from homebrew software but from the Xbox/Xbox LIVE dashboards as well. Just because no one specifically reports an EEPROM write error doesn't imply it's not a real thing and most people aren't going to know this was what caused their issue to begin with so how would they report it. However, an incorrectly set security state for the hard drive will always come from homebrew of some kind

Even when done correctly, dealing with these security areas is risky and the risk is there because both the EEPROM and the hard drive are critical system components

As I said in my initial post, a zeroed XboxHDKey is not considered valid by the kernel. The kernel doesn't throw an error for this but if you were to somehow attach a debugger to a retail console while it boots, it would assert an error on kernel initialization. A zeroed XboxHDKey is only valid on debug kernels

Realistically if this new homebrew LIVE service comes to light then the real issue looking forward is how is the LIVE dashboard going to function when softmods based on the UXE exploit use an exploitable version of the LIVE dashboard? How are softmods going to boot when they require the LIVE dashboards files but so does this homebrew service? Will need to see how things turn out with this homebrew LIVE service first to see if a solution is needed - the XboxHDKey is only one problem of potentially many

 

Some references

ATA/ATAPI-4 Specification

ATA Security Clarification

XKUtils Library by Yoshihiro/Team-Assembly

 

Most of what I've stated in this thread stems from research I've done with the kernel, EEPROM, SMC, and hard drive (along with looking into open source homebrew, reversing homebrew, and softmod stuff)

can u help me get the hurricane packs for ninja gaiden working on my xbox? it's hard modded.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By BlackIvan
      I've got a question about shortcuts on xbmcorigins with UI update installed. Is it normal to only be able to select games as shortcuts? I know emulators require custom addon.xml to do it, but I am actually trying to have apps available as shortcuts. Like DVD2Xbox and other stuff.
      I don't know how to write an addon.xml, so even if it would make the apps show up as selectable I won't be able to do it. Is there some kind of template I can follow to learn how to write one?
       
      Another quick question, since I only use coinops for emulation, could I place the folder in F\Games so it shows up with the other games?
    • By YungStar
      Hello everyone, just got myself another Xbox a couple weeks ago, 1.6 with a dead DVD Drive, $15 for console, cords, 2 S-Controllers (no breakaways 😢) and 2 games (FIFA 07 and Halo 3, lol)

      I stumbled upon my copy of Mechassault I had stashed  hopped online for a USB to XBOX adapter, and a Duke controller $20. Softmodded with Rocky5s installer!
      My DVD drive problem was solved by a friend who let me swap drives temporarily in exchange for modding his system.

      Rummaged through my old HDDs (no ide sadly, but!) I found a 2TB 3.5 drive lying about. Ordered a SATA to IDE adapter and an 80wire cable, now I have more games and emulators then I know what to do with anymore! lol

      Anyways, Thats the story of why I am here, to check out all the cool homebrew and troubleshoot anymore problems I stumble across in my journeys.

      Happy gaming guys, and long live the lil(Big?) black box!


      P.S. For anyone who might be familiar with my name, I was once a quite active member of the now dead isoZone. Hello especially to all of you that are still around the homebrew scene!
    • By Riff-Raff
      Hello all. It's been a long time since I visited the old Xbox. I've modded quite a few back in the day and recently acquired a couple a few days ago in a box along with about 5 PS2s. I kinda got a little excited being as I haven't touched either one of them for several years. I had read about soft modding and wanted to try it since it didn't require any hardware or tools as I had gotten rid of everything I had. Well once I fired up the boxes I found both of them had hdd and dvd issues. I opened them up and, ..ugh. Both of them were 1.6b. Anyway, I jumped online and ordered a couple of Aladdin XT chips. It's slowed me down but has given me the time to look the forums over. I'm getting the itch back! I don't think the wife is going to like this all over again. Anyway I just wanted to say hi to everyone.

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.