Jump to content
OGXbox.com

Question About the Dangers of Nulling the Hdd Key.


bulkchart32
 Share

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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

  • 1 year later...
9 minutes ago, EriolGaurhoth said:

Possibly dumb question: is there any way to upgrade to a new, larger HDD for the Xbox WITHOUT nulling the key?  I would like to use my larger HDD to store more ripped games, but I also don't want to corrupt my DLCs and gamesaves on the current HDD.

Are you soft or hard modded?

Soft mod: backup your eeprom to your PC. Build a new HDD using XBHDM and your matching eeprom. 

Hard mod: Get a copy of Hexen 2021 inserted in your disc tray. Turn off Xbox and hook up the new drive, then boot the console directly into Hexen and you can build your new HDD from the disc. 

  • Like 1
Link to comment
Share on other sites

4 hours ago, EriolGaurhoth said:

Possibly dumb question: is there any way to upgrade to a new, larger HDD for the Xbox WITHOUT nulling the key?  I would like to use my larger HDD to store more ripped games, but I also don't want to corrupt my DLCs and gamesaves on the current HDD.

yes! u can clone your current drive to a new hdd and lock the new one to your motherboard. use a program called chimp to clone and lock the new drive. i have done this several times and it works great! there are some risks involved if u don't know what you're doing though. it only requires a softmod and it sounds like u already have that. and not a dumb question. i'm not certain about madmatigna's method.

Edited by bulkchart32
  • Like 1
Link to comment
Share on other sites

35 minutes ago, bulkchart32 said:

yes! u can clone your current drive to a new hdd and lock the new one to your motherboard. use a program called chimp to clone and lock the new drive. i have done this several times and it works great! there are some risks involved if u don't know what you're doing though. it only requires a softmod and it sounds like u already have that. and not a dumb question. i'm not certain about madmatigna's method.

I've seen a few tutorial videos of chimp in action, where you connect both HDDs to the console while it's running.  Every video I've seen though has involved an already nulled original HDD, so I wasn't sure if following those steps would work the same with a non-nulled HDD, or if there was something extra I needed to do.

Link to comment
Share on other sites

33 minutes ago, EriolGaurhoth said:

I've seen a few tutorial videos of chimp in action, where you connect both HDDs to the console while it's running.  Every video I've seen though has involved an already nulled original HDD, so I wasn't sure if following those steps would work the same with a non-nulled HDD, or if there was something extra I needed to do.

All three methods will work. Some people find chimp a bit more difficult and you’ll need to purchase a molex splitter or have a second Xbox available to power both HDDs. If you’re going to swap drives on a soft mod then you’re going to need your eeprom which will allow your new HDD to be locked to the console. If you have a chip or tsop you can basically just swap unlocked drives like underwear.

 

Edit: so it does not matter if you are nulled or not as long as you have Your key written down or backed up somewhere. Nulling just makes things easier IMO. 

Edited by MadMartigan
  • Like 1
Link to comment
Share on other sites

  • 1 year later...
On 11/18/2021 at 9:24 PM, EriolGaurhoth said:

I've seen a few tutorial videos of chimp in action, where you connect both HDDs to the console while it's running.  Every video I've seen though has involved an already nulled original HDD, so I wasn't sure if following those steps would work the same with a non-nulled HDD, or if there was something extra I needed to do.

chimp makes an exact clone of the hdd. that means it also tranfers the security code. so u will not need to null the key or even know what it is to use chimp. sorry i didn't answer u earlier, i just now saw your question for the first time.

Link to comment
Share on other sites

On 10/13/2020 at 7:49 PM, bulkchart32 said:

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.

If someone has a dlc that is not in the list on xbmc4gamers downloader I encourage them to get ahold of rocky5 and get it to him.  Once they are in the downloader it's not really something to worry about anymore unless you've no access to internet. 

Link to comment
Share on other sites

2 hours ago, Puritan001 said:

If someone has a dlc that is not in the list on xbmc4gamers downloader I encourage them to get ahold of rocky5 and get it to him.  Once they are in the downloader it's not really something to worry about anymore unless you've no access to internet. 

it is an issue with some. ninja gaiden hurricane packs required og xbox live to activate and bind to the hdd key. nulling the key would deactivate them and they would be lost to the person. they're probably other games where this is the case too.

Link to comment
Share on other sites

36 minutes ago, bulkchart32 said:

it is an issue with some. ninja gaiden hurricane packs required og xbox live to activate and bind to the hdd key. nulling the key would deactivate them and they would be lost to the person. they're probably other games where this is the case too.

There is a script in xbmc4gamers downloader to rehash the dlc to the new hdd key.  It's only an issue if you don't either re download the dlc or rehash it with the script...  being there are multiple ways to fix it,  I don't see it as an issue,  but I guess that's just me. 

 

I still encourage anyone with dlc not on the list to attempt to get a copy of it to rocky5 so he can add it. 

Link to comment
Share on other sites

2 hours ago, Puritan001 said:

There is a script in xbmc4gamers downloader to rehash the dlc to the new hdd key.  It's only an issue if you don't either re download the dlc or rehash it with the script...  being there are multiple ways to fix it,  I don't see it as an issue,  but I guess that's just me. 

 

I still encourage anyone with dlc not on the list to attempt to get a copy of it to rocky5 so he can add it. 

show me a screenshot of this script selection. i'd like to use it, myself.

Link to comment
Share on other sites

2 hours ago, bulkchart32 said:

show me a screenshot of this script selection. i'd like to use it, myself.

I'm currently at work.  Open the xbmc4gamers  downloader, go to other,  there are 3 scripts, one is for rehash hdd key for dlc, one a cache formatter,  and i forget what the other is off hand maybe alternative art for screen saver. 

Edited by Puritan001
Link to comment
Share on other sites

15 hours ago, Puritan001 said:

I'm currently at work.  Open the xbmc4gamers  downloader, go to other,  there are 3 scripts, one is for rehash hdd key for dlc, one a cache formatter,  and i forget what the other is off hand maybe alternative art for screen saver. 

that doesn't work for the ninja gaiden hurricane packs. i just tested it. i don't know what other games this could cause issues with but i'd guess it's more than one. nulling that key is still not a great idea for a beginner. and there is still the issue of some game saves that are tied to the original hdd key. if the person needs a back up then clone the master drive to a new one and put the backup(old hdd) drive in a safe place. a beginner isn't going to know how to transfer that nulled key to a new drive, in the event of hdd failure, anyway. so there's not really a good reason for it imho. and beginners need to be aware of the dangers of nulling their key. most softmodding guides recommend nulling that key as soon as the softmod is installed. that is really bad advice because a beginner doesn't know what he is getting into.

Link to comment
Share on other sites

1 hour ago, bulkchart32 said:

that doesn't work for the ninja gaiden hurricane packs. i just tested it. i don't know what other games this could cause issues with but i'd guess it's more than one. nulling that key is still not a great idea for a beginner. and there is still the issue of some game saves that are tied to the original hdd key. if the person needs a back up then clone the master drive to a new one and put the backup(old hdd) drive in a safe place. a beginner isn't going to know how to transfer that nulled key to a new drive, in the event of hdd failure, anyway. so there's not really a good reason for it imho. and beginners need to be aware of the dangers of nulling their key. most softmodding guides recommend nulling that key as soon as the softmod is installed. that is really bad advice because a beginner doesn't know what he is getting into.

Do you know if this guide works for them? 

https://stinger-magazine.com/side-stories/how-to-play-ninja-gaidens-hurricane-packs/

Link to comment
Share on other sites

4 hours ago, Puritan001 said:

i don't know. it looks mostly legit from the youtube guide of the guy doing it but it also looks complex. i'm not new to this scene and it would even take me a little bit to figure everything out and hope that it works when i finish. i say that as someone who has repaired and hardmodded 2 xbox, softmodded one, repaired several others, and cloned the hdd for 8(some of those were more than once). so i'm not an expert but i'm not a noob either. if it would be a struggle for me, then a guy installing his first softmod shouldn't even attempt this yet. even if the guide does work, that wouldn't bring back the lost saves that were attached to the hdd key. imagine how heart breaking it would be for someone that beat that game on master ninja difficulty 15-20 years ago and then lose that save because of this. and i doubt this is the only game that relies on it. we really need to stop telling noobs to null their key. there's a much better chance a noob could use his old backup hard drive to clone another one if his new drive fails than to be able to put a new key on a hdd and lock it with his pc.

 

Edited by bulkchart32
Link to comment
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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

 Share

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.