|
SeventhSon
|
 |
« Reply #100 on: June 14, 2007, 11:49:07 AM » |
|
Apologies if this is a n00b question... but is it still possible to downgrade by corrupting the patches (the way it was done pre-4552) if you removed R6T3 before upgrading? Yes, but it may break after the downgrade because of file system changes. Best way is to create a complete backup image of your pre-4552 NAND, then upgrade (with R6T3 gone of course) and then flash the backup image back to NAND in order to downgrade. I've done this sucessfully a couple of times. I got the box with 1888, and removed R6T3 immediately before playing any games or connecting to Live. Since then it's been upgraded to the latest. Sadly, I neglected to be patient enough, and don't have a dump of the flash or the fuseset from any point. If I dumped the flash and corrupted the patches in the way robinsod did back on 2868, would I be able to revert to 1888 that way? (and then upgrade to an exploitable kernel and run XELL to dump the fuseset) If not, can someone actually explain why, since it's confirmed that post-4552 versions are still 1888+patches, and my fuses should've been untouched since 1888...
Ah, if you have no backup flash dump then it might be tricky. Should still be technically possible though, if you can analyse and fix the FS. |
|
|
|
|
Logged
|
|
|
|
|
torne
|
|
« Reply #101 on: June 14, 2007, 11:54:14 AM » |
|
Yes, but it may break after the downgrade because of file system changes. Best way is to create a complete backup image of your pre-4552 NAND, then upgrade (with R6T3 gone of course) and then flash the backup image back to NAND in order to downgrade. I've done this sucessfully a couple of times.
Yeah, I found this one out shortly after upgrading to 4552 in order to play Crackdown. Impatience, as I said  Ah, if you have no backup flash dump then it might be tricky. Should still be technically possible though, if you can analyse and fix the FS.
Sounds like it could be interesting. I guess I'll have to pick up an Infectus then, dump my flash, and have a fiddle. Presumably the worst that can happen is I have to put the new image back unmodified, so hey. Not played with any of this stuff yet, but I've reverse-engineered stuff in the past, and I'm an embedded ARM dev for my day job, so I might manage it |
|
|
|
|
Logged
|
- Bad ARM, no cookie for you. UQADDSUBXEQ is not a RISC instruction.
- I fail at hardware. I code pretty awesome, though.
|
|
|
robinsod
Global Moderator
Xbox Hacker
Posts: 646
Perl packed my shorts during global destruction
|
|
« Reply #102 on: June 14, 2007, 11:54:58 AM » |
|
Unfortunately 4552 has completely replaced dash.xex and its very unlikely that it will run under the unpatched kernel (lots of libraries have been updated)
|
|
|
|
|
Logged
|
|
|
|
|
SeventhSon
|
|
« Reply #103 on: June 14, 2007, 12:02:58 PM » |
|
Unfortunately 4552 has completely replaced dash.xex and its very unlikely that it will run under the unpatched kernel (lots of libraries have been updated)
If he can get hold of an old 1888 NAND image (I have one if you want it torne), then he should be able to reconstruct the FS with original xex files. Might take some time but it should work. Right? I presume the original version FS root block will still be hanging around in flash, which will help. Kev |
|
|
|
|
Logged
|
|
|
|
|
torne
|
|
« Reply #104 on: June 14, 2007, 12:14:10 PM » |
|
If he can get hold of an old 1888 NAND image (I have one if you want it torne), then he should be able to reconstruct the FS with original xex files. Might take some time but it should work. Right? I presume the original version FS root block will still be hanging around in flash, which will help.
Since the 1BL key is not per-cpu, if I had an old 1888 NAND image wouldn't it be possible to just overwrite its key vault with mine (without needing the fuseset to decrypt either the old or new one), re-encrypt the whole thing with the 1BL key, and flash that onto my NAND? (er, once you guys get the tool able to re-encrypt images). It seems like it should work... |
|
|
|
|
Logged
|
- Bad ARM, no cookie for you. UQADDSUBXEQ is not a RISC instruction.
- I fail at hardware. I code pretty awesome, though.
|
|
|
|
SeventhSon
|
|
« Reply #105 on: June 14, 2007, 12:22:31 PM » |
|
If he can get hold of an old 1888 NAND image (I have one if you want it torne), then he should be able to reconstruct the FS with original xex files. Might take some time but it should work. Right? I presume the original version FS root block will still be hanging around in flash, which will help.
Since the 1BL key is not per-cpu, if I had an old 1888 NAND image wouldn't it be possible to just overwrite its key vault with mine (without needing the fuseset to decrypt either the old or new one), re-encrypt the whole thing with the 1BL key, and flash that onto my NAND? (er, once you guys get the tool able to re-encrypt images). It seems like it should work... As far as I am aware the unique-per-cpu fuse data is verified in CB. If you had an 1888 NAND image, then you could probably just insert your CB, CD, CE and KV sections (not the CF/CG sections) from your current NAND into it and it should work. Of course, I could be spouting BS here. There are many more qualified than I who'll be able to confirm/deny this. |
|
|
|
|
Logged
|
|
|
|
|
tmbinc
|
|
« Reply #106 on: June 14, 2007, 12:23:51 PM » |
|
you could just took the smc,keyvault,CB,CD,CE from the 4552+ image, and the rest from the 1888. Effectively, this means that you just need to cut the first part of the 4552 image and stitch it together with the rest of the 1888 image. And remove the remaining CF,CG sections.
That should work. I'm currently not sure about the "SMC config" (near the end of the flash). You might have to take that one as well from the newer image.
|
|
|
|
|
Logged
|
Please don't copy/quote full text outside this board. Instead, summarize and link to this post. Thanks! This lets me keep information updated and doesn't pull things out of context.
|
|
|
|
Cpasjuste
|
|
« Reply #107 on: June 14, 2007, 12:25:37 PM » |
|
Yes, but it may break after the downgrade because of file system changes. Best way is to create a complete backup image of your pre-4552 NAND, then upgrade (with R6T3 gone of course) and then flash the backup image back to NAND in order to downgrade. I've done this sucessfully a couple of times.
I'm not sure to understand, your are saying that you are able to edit your nand dump then reencrypt it ? Or you mean hexedit the dump ? |
|
|
|
|
Logged
|
|
|
|
robinsod
Global Moderator
Xbox Hacker
Posts: 646
Perl packed my shorts during global destruction
|
|
« Reply #108 on: June 14, 2007, 12:30:08 PM » |
|
If he can get hold of an old 1888 NAND image (I have one if you want it torne), then he should be able to reconstruct the FS with original xex files. Might take some time but it should work. Right? I presume the original version FS root block will still be hanging around in flash, which will help.
Since the 1BL key is not per-cpu, if I had an old 1888 NAND image wouldn't it be possible to just overwrite its key vault with mine (without needing the fuseset to decrypt either the old or new one), re-encrypt the whole thing with the 1BL key, and flash that onto my NAND? (er, once you guys get the tool able to re-encrypt images). It seems like it should work... As far as I am aware the unique-per-cpu fuse data is verified in CB. If you had an 1888 NAND image, then you could probably just insert your CB, CD, CE and KV sections (not the CF/CG sections) from your current NAND into it and it should work. Of course, I could be spouting BS here. There are many more qualified than I who'll be able to confirm/deny this. No, I think you are 100% correct. It shouldn't be impossible to rebuild a good flash No re-encryption required (although we are very close  |
|
|
|
|
Logged
|
|
|
|
|
SeventhSon
|
|
« Reply #109 on: June 14, 2007, 12:32:26 PM » |
|
Yes, but it may break after the downgrade because of file system changes. Best way is to create a complete backup image of your pre-4552 NAND, then upgrade (with R6T3 gone of course) and then flash the backup image back to NAND in order to downgrade. I've done this sucessfully a couple of times.
I'm not sure to understand, your are saying that you are able to edit your nand dump then reencrypt it ? Or you mean hexedit the dump ? No editing involved. I just dump the nand, then upgrade (with R6T3 removed), then flash the entire dump back over the nand to downgrade. Because I replace the entire nand and no extra fuses are blown during the update, the 360 has no way of knowing it was ever upgraded (unless there's some other NV storage we don't know about somewhere). |
|
|
|
|
Logged
|
|
|
|
|
SeventhSon
|
|
« Reply #110 on: June 14, 2007, 12:35:27 PM » |
|
No, I think you are 100% correct. It shouldn't be impossible to rebuild a good flash Makes a change. Although I did forget about the SMC (thanks tmbinc). No re-encryption required (although we are very close Hurrah |
|
|
|
|
Logged
|
|
|
|
|
parasven
|
|
« Reply #111 on: June 16, 2007, 06:51:00 AM » |
|
you should have removed it before the update now your fuse is gone and cant be reverted. in other words your stuck with the newest update and its impossible for you to downgrade
|
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #112 on: June 21, 2007, 11:58:11 AM » |
|
So if i remove that resistor or whatever it is on my MoBo then i can downgrade without getting fucked? Cause i have the newest kernal but i want to downgrade
You should dump the cpu key (=fuse data). If you have that, you can downgrade to any kernel you like, even if your fuses got burned If you can't dump the fuses (because you don't have a vuln. kernel) then, indeed, best thing to do is to remove R6T3. Ofcourse, you won't be able to downgrade to kernel versions older than the one you were running when you removed it (without knowing the cpu key that is). BTW, we're investigating a possible 'workaround' for the CPU key |
|
|
|
« Last Edit: June 21, 2007, 12:43:08 PM by TheSpecialist »
|
Logged
|
|
|
|
robinsod
Global Moderator
Xbox Hacker
Posts: 646
Perl packed my shorts during global destruction
|
|
« Reply #113 on: June 21, 2007, 12:51:33 PM » |
|
Firstly, thanks to tmbinc for the idea and TheSpecialist for helping out with the RE'ing
In the decrypted CF there is a "version lockdown counter" at 0x21F. Every time an update is applied (since version 4532) an eFuse is blown and the counter is incremented by 1 before it is written into the new CF. When booting, a check is made to ensure that the lockdown counter in the selected CF >= number of blown eFuses.
The good news is that we can modify the lockdown counter byte and re-encrypt the CF section. The bad news is that a hash of the first 0x220 bytes requires the CPU Key. So as long as we know our CPU Key we can downgrade to a vulnerable kernel.
1) Brand new XBox with 1888 & 2241
The Version Lockdown Counter in my 2241 CF is 0
2) Applied 4532
The Version Lockdown Counter in my 4532 CF is 1
Also fuseset 07: f000000000000000
3) Applied 4552
The Version Lockdown Counter in my 4552 CF is 2. Confirmed that I cant downgrade to unpatched 4532 dump
4) Fixed up a dump of 4532 with CF Lockdown Counter = 2. Boots!
Now when I dump my fuse data
fuseset 07: ff00000000000000
A second fuse was blown by 4552
Expect a new build of the NAND Tool soon
|
|
|
|
|
Logged
|
|
|
|
robinsod
Global Moderator
Xbox Hacker
Posts: 646
Perl packed my shorts during global destruction
|
|
« Reply #114 on: June 22, 2007, 02:49:54 PM » |
|
I'm curious as to what the fuseset 07 : looks like after the 3 counter is set. 0f00000000000000 ?? or fff0000000000000 ??
peace,
zil
fff0000000000000, you cant 'unblow' a fuse |
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #115 on: June 23, 2007, 08:46:54 AM » |
|
BTW, we're investigating a possible 'workaround' for the CPU key Too bad, but the workaround can't work. We wanted to 'decouple' CG from CF, but that won't work: CG is hashed and the hash is stored in the signed part of CF. So it's not possible to decouple them. Looks like you really need the cpu key to downgrade. |
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #116 on: June 24, 2007, 08:00:26 PM » |
|
I've cleaned up this thread a bit. Please keep in mind that this is a special section of XBH with different rules: http://www.xboxhacker.net/index.php?topic=6673.0 If you have technical or even non technical questions/remarks about kernel hacking and you're not sure if they are helpful, please open a thread (or use an existing thread) in any other section of this site. |
|
|
|
« Last Edit: June 24, 2007, 08:17:02 PM by TheSpecialist »
|
Logged
|
|
|
|
|
TAz00
|
|
« Reply #117 on: June 25, 2007, 05:16:40 AM » |
|
So, now that we got the tools to decrypt the NAND, and rencrypt it again. It would be possible to interchange NAND's on different systems as long as you know the CPU key?
|
|
|
|
|
Logged
|
|
|
|
|
