Took care of E81 / SECDATA REHASH / CRL

[rf1911]

Ok, first thanks to cory1432 for giving me the hint on secdata offset where the hmac-sha1 starts.

This will allow you to resolve E81 due to LDV downgrading and reupgrading, clean secdata from any flag.

First you need your CPU key. I used ibuild.

1) I assume you have a dump and extracted all the files (using ibuild or 360 flash tool + ibuild compatible files)
2) Secdata: Make a backup. Edit it with an hex editor, cut the first 0x10 bytes. Edit LDV at 0x19 and the other bytes (see http://xedevwiki.com/wiki/SECDATA for the bits)
3) Open HASHCALC (google it). Open file secdata.bin input CPU KEY in hex in HMAC and press calculate
4) Now copy the 0x10 bytes into original secdata.bin EDITING the same info you changed in the backup
5) Open CRL.bin with hex editor, fix LDV on 0x14F to match the same on secdata (for restoring from E81 when upgrading to 13599/13604)
6) rebuild a 9199 nand with ibuild fixing after if needed the LDV of CF/CG with 360 flash tools
7) Flash.
Done

Thanks.

Old Skool,

Edit: Now u can use ggbuild/xebuild to reconstruct a clean nand with modified secdata.

[djblade17]

thanks man got 2 consoles to test this on when i get home
trinity and falcon

[rf1911]

You can use 360 flash tool, to import the edited secdata and crl. First change ldv in 6bl/7bl. Save new nand. Then open new nand and import the 2 files. Havent tested it yet but it should work too.

[djblade17]

yeah didnt get a chance last night trying to brush up on my hex editing and getting confused by the 0x10 $#!t

[rf1911]

Open a copy of undecrypted secdata in hex editor, like hexworkshop. Select the first 0xf bytes (so till 0x10). Remove them. Change the secutiry bytes u need. Save. Open hashcalc fill the cpukey in hmac then press calculate. Copy the first 0xf bytes from sha1. Now open the original undecrypted secdata. Change the first 0xf byte to the 0xf values of sha1 and DO make the same changes to the secutiry bit u did in copy of secdata. Now u have a new secdata with correct hmac. Follow the instruction for 360 flash tool. After flashing DO no connect to live or update unless xval says SECDATA is CLEAN!!!

[l_oliveira]

I foresee the algorithm for security files protection changing in ..3  ..2 ..1

...



 

[rf1911]

If MS changes who cares... pp simply wont be able to do it... ppl was not able before, ppl could not be able after, that does not change much.. If cant do something then i try something to do that something, if then i no longer can do that something im the same state i was at the beginning...

anyway..... humm i see new CB soon....

I heard around this was not that much appreciated. But guys, all infos where there, since quite a while too... RGH made this possible, the wikis and articles here have plenty of infos, not surely using 10 minutes of brain..

I pissed someone off, then sorry. You can go ahead and cancel the thread. I also bet that not that many ppl do understand what to do anyway.

[rf1911]

Also... why did MS include a LDV check ONLY in 13599 in first place? Before that dash it was possible to update without E81, secdata was invalid, but u could still upgrade and use you xbox. No.. from 13599 E81 came out. How would they possibly know that ppl would have been able to downgrade? Why did MS start splitting CB on refurbished fats too?

[snowdaysrule1]

Wait... So M$ has implemented new security methods with dash 13559 and up? How are the secdata and crl involved? It sounds like they store a copy of the lDV as an additional method to prevent upgrading and downgrading? But since we can only downgrade on consoles with known cpu key, and since the cpu key can be used to modify the secdata and crl files to allow upgrading and downgrading, what the heck's the point of the extra security? It doesn't really do anything to prevent us from upgrading / downgrading does it? Is it a way to prevent people who have gotten policy violations (hacked dvd firmware) from going on xbox live because they can't update to the latest required dash to connect because they get E81?

Thanks in advance for handling the sheer amount of questions. I just want some answers haha. And if this is all in a thread somewhere a link (yes I know spoon feeding haha) I'll go do some reading.

Edit:

@rf1911

I remember someone on here talking about why they changed the CB format from one part to two parts. His theory was that M$ did this for compatibility reasons. Something to do with consoles coming in for repair with bad blocks in the beginning of the nand and due to part of the CB being corrupted the consoles could no longer boot. I believe that CBA is smaller than the old CB and it has the ability to boot CBB from a different non bad block section of the nand, hence allowing the consoles to run a good CB set and boot.

I don't know if this makes any sense though because I thought the SMC handled bad block remapping so this alone might disprove the big "theory" about two part CB.

[cory1492]

It seems to pop up E81 when it's unable to save security data, which is something that gets updated when you run an updater. If secdata is invalid (for example LDV mismatch) it is essentially a sign of tampering (the only other way I can think of for this data to go bad is an inopportune power outage), and thus when it goes to save to it you will get a E81. I'd consider the fact that it's doing it now, simply that someone noticed a missing check in code that has been around for quite a while - it's even possible this behavior was not intentional during updates.

I personally think CB_A/CB_B was just an attempt to re-secure the boot chain (CB_B has the CPU key factored into the crypto key) and create a chicken/egg situation again where you can't get the data decrypted if you don't have the CPU key. Keep in mind, this also complicates things if a service center is dealing with a corrupt NAND...

[l_oliveira]

Keep in mind, this also complicates things if a service center is dealing with a corrupt NAND...

Not if they have an different CB program that has lower number of security checks or no checks at all, signed with 1BL key for use in the service center.

They just need to make sure it's not "dangerous" (requires some sort of HW dongle) in the wrong hands in case of a leak or make sure it doesn't leak at all.

[cory1492]

Isn't that pretty much the definition of "complicates"? 

[rf1911]

Wait... So M$ has implemented new security methods with dash 13559 and up? How are the secdata and crl involved? It sounds like they store a copy of the lDV as an additional method to prevent upgrading and downgrading? But since we can only downgrade on consoles with known cpu key, and since the cpu key can be used to modify the secdata and crl files to allow upgrading and downgrading, what the heck's the point of the extra security? It doesn't really do anything to prevent us from upgrading / downgrading does it? Is it a way to prevent people who have gotten policy violations (hacked dvd firmware) from going on xbox live because they can't update to the latest required dash to connect because they get E81?

Thanks in advance for handling the sheer amount of questions. I just want some answers haha. And if this is all in a thread somewhere a link (yes I know spoon feeding haha) I'll go do some reading.

Edit:

@rf1911

I remember someone on here talking about why they changed the CB format from one part to two parts. His theory was that M$ did this for compatibility reasons. Something to do with consoles coming in for repair with bad blocks in the beginning of the nand and due to part of the CB being corrupted the consoles could no longer boot. I believe that CBA is smaller than the old CB and it has the ability to boot CBB from a different non bad block section of the nand, hence allowing the consoles to run a good CB set and boot.

I don't know if this makes any sense though because I thought the SMC handled bad block remapping so this alone might disprove the big "theory" about two part CB.

The invalid sec data check has been there since at least 8955, the lower i obviously could test , but u were able to update... ldv is stored in secdata which is hashed and crl, which is not. Starting from 13599 the update gives E81 if ldv does not match secdata.

For the CB story, wow took them 6 years...

@Oliveira, i thought that u coudlnt modify CB (so even resign it with 1BL Key) as 1BL wont allow that to run. Doesnt 1BL use RotSumSha1 to verity RSA signature? Also the security involved in such process, HW key or whatever, is useless, as once the nand is written with a special CB the leaker could just dump it.. so yes it's complicated

[raidenxtribe]

CB downgrading, the dream of every xbox owner... jtag hack everywhere... just a dream....

[Pacote-san]

Thanks for the thread

Cory changed the LDV for me on secadata file but is nice to see how its manually done

[l_oliveira]

@Oliveira, i thought that u coudlnt modify CB (so even resign it with 1BL Key) as 1BL wont allow that to run. Doesnt 1BL use RotSumSha1 to verity RSA signature? Also the security involved in such process, HW key or whatever, is useless, as once the nand is written with a special CB the leaker could just dump it.. so yes it's complicated

CB is hashed with the private MFG key. We know the public one which is on the rebooter and on flashtool.

Because we don't have the private key, we can't change anything (if we do it will fail the hash check and it means instant 0022) we can't change it to for example remove the revocation of the older bootloaders. It's just because we can't change a single bit on CB it's protected and we need to glitch the CPU to enter at another point of the boot...

If we could, even the JTAG would be moot and we would be booting things straight.

On the PS3 the hackers got the private keys for almost everything so it became *party* ... lol

[rf1911]

CB is hashed with the private MFG key. We know the public one which is on the rebooter and on flashtool.

Because we don't have the private key, we can't change anything (if we do it will fail the hash check and it means instant 0022) we can't change it to for example remove the revocation of the older bootloaders. It's just because we can't change a single bit on CB it's protected and we need to glitch the CPU to enter at another point of the boot...

If we could, even the JTAG would be moot and we would be booting things straight.

On the PS3 the hackers got the private keys for almost everything so it became *party* ... lol

.. its seems to me your are making me wanna ask: "we should try to glitch the memcmp that checks for the revocation". Something like a two stage hack. 1st glitch to get cpukey, 2nd to glitch cb to allow us to load any previously blacklisted kernel (maybe by just changing one byte in the hardcoded hash).

[djblade17]

having lots of issues can someone fix mine please

i get everything up till building the image with ibuild..
I used flash360 to extract files
I have ibuild just not familiar with using it and any google search brings back easy freeboot

If i extract with ibuild i always get the system update error 13146nand
so i extracted my 9199 dump
For building what should i be using
I have tried
ibuild c original -c falcon -d data2\ -b DD88AD0C9ED669E7B56794FB68563EFA  -p 112411111111111111111111111 imagine.bin fuses.bin
which builds a image but ldv is wrong and i extracted files and changes werent made

[modguru]

hello i have a jasper console red  and i have make the update 13146 but something has go wrong . before complete the update bar to 100% the shows me a black screen with the error E81 .
i have try all the other update that exist 13599 13604 but every time hapend this before complete the update bar E81 screen
so i have deside to take the cpu key and to extract as many data i can from the nand dump .. in the kernel extraction this message shows up

as i can understand something has gone wrong with the update and the 13146 kernel it is corrupted .
now i am wonder if they exist some way to fix that console ...
any ideas is welcome ...

[djblade17]

this seems to happen with anything that is after 9199(could be wrong) just uncheck kernal you dont need it anyways all other steps should fix your issue