Print

[Ghengis]

I'm running into troubles upgrading my hard drive.  I bought an 80 gig seagate.  Partitioned, formatted, files all copied.  Thought I was fine, but after locking with the new (as of 1.7) linux lock tools, I got an error 6 when I tried to use the new drive.  After some troubleshooting, it came down to this:

1.) Installed Evox with the SC trick (thru hotswap)
2.) Settings->Backup, FTP'd in and got the whole backup dir.  Also ftp'd out the C and E dirs, and put those in the respective dirs when making xboxhdm CD.  So, I should have a "full" xboxhdm CD -- system files + eeprom.  Don't need anything else, right?
3.) If I put the new, more-or-less set-up drive, in my PC and "lockhd", it locks successfully.
4.) Putting this locked drive in gives a system error 6.
5.) "unlockhd" on the drive locked in 3 works fine, since it generates the same (wrong) key -- see below.
6.) If I put the original (still working) XB HD in my PC and try to use the linux unlock script, nothing happens.  Status still says it's locked.  The generated key does NOT match the HDDLockDisablePassword in hddinfo.txt.  Additionally, if I do a driveinfo manually (pointing it to /cdrom/eeprom/eeprom.bin, etc.), it gives the same (wrong) password, and also lists the HDKey incorrectly.
7.) If I put the original XB HD in and use the DOS unlock tool, and hand-type my password (from hddinfo.txt), it's fine.  Re-locked (with shaking hands, the way you guys describe bricking HDs) and it's fine.



What can we deduce from this?  Somehow, either Evox is saving an incorrect eeprom.bin and a correct hddinfo.txt, or the linux tools are reading the eeprom.bin incorrectly.  Either one is a pretty scary thought.  Any ideas?

[RiceCake]

Might be some bad code in there and it generated the wrong HD key from your eeprom.bin backup?

Else you messed up?

Its not the dashboard...jeeze man! Don't give answers when you don't know!

[xman954]

if you have XP then try liveinfo

[Ghengis]

Never, *ever* would I accuse the Man of such a thing.  No, he's using available tools (like xinfo) that he didn't write, and I'm wondering if they're the weak link.  I mean, basically hdinfo.txt and eeprom.bin are flatly contradicting one another, or else the tool is reading it wrong.  Ldots (who wrote the script to use the tool) did an awesome, AWESOME job.  I could really use some shell-scripting skizzles like that.

[RiceCake]

Uhh, he did the scripting - not the code. Whatever utilities he has scripted to run have bad code...or like I said you did something wrong.

And jesus, whats this, kiss Ldots ass-day?

[RiceCake]

I'm not saying he's a jackass or anything, was just wondering why all of a sudden everyone gets all offended by me saying whatever code is handling the HD key generation sucks.

[SargeZT]

Look, I'm personally a HUGE fan of LDots, his code rocks.  I probably use XboxHDM at least three times a week, often more.  However, that's not to say he's perfect by any means.  Saying he couldn't have messed up on the script is ludicrous.  Everyone screws up some times.  However, I agree with Ghengis on this one.  It's probably the actual programs.

[ldots]

QUOTE (RiceCake @ Jul 22 2004, 07:41 AM)

Uhh, he did the scripting - not the code. Whatever utilities he has scripted to run have bad code...or like I said you did something wrong. And jesus, whats this, kiss Ldots ass-day?

Just a lot of happy users I guess
Seems that either people praise my packages or they refer to them simply as scripts . Something in between would be nice
Everything in this distro is not scripting though. Some of the tools are coded by me, others modified/enhanced. The linux locking tool for example did not lock with a Master Password and set the security level to maximum. ConfigMagic sets it to High, so I took the same route. This is also needed to use a Master Password.

But yes, all credit for the password generation goes to the xbox-linux team (Speedbump I believe). Could be there is a bug, I'll have a look, but I doubt it. The "HD key generation" definitely doesn't suck. I think the answer must be something else.

Ghengis, when in 6.) you say you did a "driveinfo manually", do you mean Liveinfo? What would be really usefull would be if you tried using this eeprom.bin of yours and ran these tools on both the new and the old HD :
1) Liveinfo (from windows)
2) hdkey (from xboxhdm)
3) lockhd (from xboxhdm, but aborted after the "Ready to attempt locking").

What should hopefully be the conclusion is that on the new drive all three tools give the same (maybe wrong) password. On the old drive see if any of the generated passwords match the one in Evox's hdinfo.txt.

It has happened in the past that Evox has produced bad eeprom dumps. I even had an xbox where Evox produced a wrong password in the hdinfo.txt.
You could try to use ConfigMagic to dump the eeprom and try generate the password with the three tools above.

[Ghengis]

Thanks for the quick reply, ldots.  For the record, I both praised the pacakge and called it a script.  Did not realize you had modified the "stock" tools -- even cooler, IMHO.

Anyway, the "info" I'm talking about is the one that's in the /ldots/2.6 dir when you boot with option 3.  I forget the name, and can't check right now since I'm posting from work.  Might have been "xinfo" or similar.... you use it in your script, and it gives all bios info and generates an HDD unlock password for hda.  I have not yet hooked any xbox-y drives up to anything running windows.  I will try the three suggestions below as soon as I get home.

I'll also try to read up on ConfigMagic -- haven't used it yet.  Like I say, I only just got Evox running yesterday.

The one other thing I was thinking about was running the xinfo program (that's the one with '-f <filename> -p' to show a HD password, right?) to read the EEPROM directly.  That should work, right?  I figured once Evox is running, I should be able to SSH in and run it, or so I would imagine.  If I can't get ConfigMagic up and running, and xinfo doesn't do the trick, I'll be back to this thread to ask for further help.  Thanks to all who replied.

[RiceCake]

Hmm...why would setting a master password be referred to as maximum security, whereas just the key be called medium?

Since when is having two passwords for the same thing more secure?

Anyhow, Ldots, great shit, (Even though alot of people are probably hoping they'll never have to use it) didn't know you had actually modified the code in some of those applications, but either way was just saying somethings going funky.

And as for EvoX giving bad dumps (hehe, dumps) at least Xbhdm isn't like some tools and just dumbly locks it without making sure of anything.

I'd say use ConfigMagic to dump your EEPROM - might not be convienient but uhh, wanna fry a hard drive by accident now...?

[ldots]

QUOTE (RiceCake @ Jul 22 2004, 08:22 PM)

Hmm...why would setting a master password be referred to as maximum security, whereas just the key be called medium? Since when is having two passwords for the same thing more secure?

The ATA security features defines two levels of passwords. Master and User. The xbox uses the User password - the one generated from the eeprom. As the name implies the Master password allows you to unlock a drive knowing this Master password, even without knowing the User password. That's why I wanted that to be set to something simple (XBOXSCENE) just like ConfigMagic sets it to (TEAMASSEMBLY). I would say having this second, easy to remember, password is more secure/safe.

The ATA specs also state that you have two levels of security, Maximum and High. In High mode the drive can be unlocked with both the Master and User password. In maximum mode you can only unlock with the User password.

[total_ass]

Hey guys, a few questions about security levels and shit.

1.) What security level does XboxHDM lock the hard drive with? Is it medium, high or maximum?

2.) If the hard drive is locked and then attempted to be unlocked but a wrong password is entered, is it simply left locked or is the drive dead?

3.) So if linux locks it with the wrong password, i just unlock it with 'XBOXSCENE' and it is back to normal?

[RiceCake]

QUOTE

I would say having this second, easy to remember, password is more secure/safe.

Yeah, so you can't as easily mess up the system.

What I originally thought was it used the user password only on medium, and the user/master on maximum security, which from a security standpoint is stupid (This would make medium more secure). But nevermind, I got it now.

[total_ass]

ok thanks, so i could technically put as many wrong passwords in as i want it would not damage the hard drive?

[ldots]

1) The 520 page ATA specification I got a hold off stated that there is only a High and a Maximum level. High accepts both User and Master.
2) Nothing would happen. Except a counter is increased by 1 for each failed unlock attempt. After a certain number of failed attempts (firmware dependent I think) the drive will freeze. A reboot resets the counter and allows further unlock attempts.
3) At least thats the way it should work and why I hope its safer now. On a spare drive I bravely attempted to lock with a wrong password and sure enough I could unlock the drive in atapwd with the Master password.