|
joeyddr
|
 |
« Reply #40 on: November 21, 2009, 08:14:10 AM » |
|
so what did you use to find the exact sector?
|
|
|
|
|
Logged
|
|
|
|
|
boby2pc
|
|
« Reply #41 on: November 21, 2009, 08:58:17 AM » |
|
so what did you use to find the exact sector?
For now there is no any tool. For comfortable searching you could separate DATA and SPARE (ECC) data by InfectusTool. I used winhex for searching but any hex editor is good. |
|
|
|
|
Logged
|
|
|
|
|
l_oliveira
|
|
« Reply #42 on: November 21, 2009, 09:20:30 AM » |
|
so what did you use to find the exact sector?
Exactly what boby2pc suggested. Manual inspection of the file with a hexadecimal file viewer/editor. What exactly you're looking for is one kilobyte chunk of "random" data followed by a footer of 15 kilobytes of zeros (a whole sector). Because secdata.bin is quite small, it's stored on a single sector along a bunch of zeroes. Think of it being like cluster waste on hard disk file systems where you set a cluster size of 16KB and even a single byte file will use 16KB of disk space because of the cluster size. By my observation it's high the chance that more than one copy of the secdata.bin may exist. And it contains information that could make a very old file unusable (information related to the current kernel/dash version) so you may have to search the whole filesystem area. To be honest I didn't expect Microsoft would forget to "fix" something simple as this. It's surprising how you can fix any console with this trick even without having a CPU key for it or knowing what's inside the secdata file. My jaw dropped when I figured this out. And I don't expect this to be possible for long as even I (as I'm not a programmer) can think of things they can do to prevent this from being possible in the future. |
|
|
|
|
Logged
|
 It's a Rough World |
|
|
|
joeyddr
|
|
« Reply #43 on: November 21, 2009, 09:50:16 AM » |
|
so winhex and flashtool to find the block?
|
|
|
|
|
Logged
|
|
|
|
|
l_oliveira
|
|
« Reply #44 on: November 21, 2009, 09:53:14 AM » |
|
so winhex and flashtool to find the block?
Flashtool will give you the position for the current version of the file (the target block for restoring the older version of the file) For the older version of the file you have to scavenge the "trash" of the file system to find it...  |
|
|
|
|
Logged
|
It's a Rough World |
|
|
|
joeyddr
|
|
« Reply #45 on: November 21, 2009, 09:59:32 AM » |
|
if i do a text search for secdata.bin it finds it.... so i suppose the trash data is gonna be somewhere above that?
|
|
|
|
|
Logged
|
|
|
|
|
d05register
|
|
« Reply #46 on: November 21, 2009, 10:33:15 AM » |
|
  My unbanned secdata.bin (top pic) is 2 blocks (0x345) above crl.bin (0x347) The new banned secdata.bin (bottom) has been moved to (0x011E) but the original remains at (0x345) as also crl.bin remains at (0x347) Is this true for all? I saw it's true for boby2pc |
|
|
|
|
Logged
|
|
|
|
|
joeyddr
|
|
« Reply #47 on: November 21, 2009, 10:42:58 AM » |
|
i just checked 4 other dumps from other boxes and its always 2 blocks above crl.bin except the banned nand dump i have thats at 113
|
|
|
|
|
Logged
|
|
|
|
|
joeyddr
|
|
« Reply #48 on: November 21, 2009, 10:47:05 AM » |
|
|
|
|
|
|
Logged
|
|
|
|
|
d05register
|
|
« Reply #49 on: November 21, 2009, 10:58:26 AM » |
|
That's good... Except l_oliveira's case who said he found old copy 2 blocks above the new copy and not above crl.bin... weird  |
|
|
|
|
Logged
|
|
|
|
|
boby2pc
|
|
« Reply #50 on: November 21, 2009, 11:31:06 AM » |
|
That's good... Except l_oliveira's case who said he found old copy 2 blocks above the new copy and not above crl.bin... weird Then we have two possibilities so far and there will be more. Safe method to search for proper sector is to look at ECC change number of as I presented previously. In my example I started from 3F change and look backward to 3E etc. The 36 was first which doesn't refered to area with XEX2, CRL or filetable. secdata.bin must be constructed as l_oliveira described. |
|
|
|
|
Logged
|
|
|
|
|
d05register
|
|
« Reply #51 on: November 21, 2009, 12:11:11 PM » |
|
I didn't understand your method. My new secdata.bin at 0x011E has ECC lines
1st block: 1E 01 00 00 00 FF 00 00 00 00 00 00 80 77 B1 5A
2nd block: 1E 01 00 00 00 FF 00 00 00 00 00 00 C0 8C CA F7
which byte is the ECC change number? What do I have to search for, next?
|
|
|
|
|
Logged
|
|
|
|
|
boby2pc
|
|
« Reply #52 on: November 21, 2009, 12:38:41 PM » |
|
I didn't understand your method. My new secdata.bin at 0x011E has ECC lines
1st block: 1E 01 00 00 00 FF 00 00 00 00 00 00 80 77 B1 5A
2nd block: 1E 01 00 00 00 FF 00 00 00 00 00 00 C0 8C CA F7
which byte is the ECC change number? What do I have to search for, next?
ECC numbers begins from 0 then look at 1D 01. |
|
|
|
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #53 on: November 21, 2009, 01:02:17 PM » |
|
Anyone who can give me their nand? Think I could help (needs to be banned and untouched afterwards) |
|
|
|
|
Logged
|
I had a blast at the party yesterday!
Oh wait, what you mean you weren't invited? It was in your mouth and everyone came!
|
|
|
|
d05register
|
|
« Reply #54 on: November 21, 2009, 01:08:50 PM » |
|
Hmmm I understand now, but it's impossible to go from 0x010E (banned) to 0x0345 (unbanned) counting backward  That's because my new secdata was written before the old. This is the case for joeyddr too. I think a combination of methods and some guesswork is what is needed... |
|
|
|
« Last Edit: November 21, 2009, 01:33:52 PM by d05register »
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #55 on: November 21, 2009, 01:23:22 PM » |
|
Seriously guys, consider sending me your nands, I've been looking into FS and I think I could be of some help.
|
|
|
|
|
Logged
|
I had a blast at the party yesterday!
Oh wait, what you mean you weren't invited? It was in your mouth and everyone came!
|
|
|
|
l_oliveira
|
|
« Reply #56 on: November 21, 2009, 01:50:53 PM » |
|
le_uberfry, you can "create" an banned nand yourself. Just take a console with protected keyvault and 7371+ dash and try to change it's keyvault. The "Christmas light" effect will happen and then next time you boot the box (with the proper keyvault) it will behave as an banned XBOX (even if it is not). Then you will have some research material.
|
|
|
|
|
Logged
|
It's a Rough World |
|
|
|
le_uberfry
|
|
« Reply #57 on: November 21, 2009, 02:48:11 PM » |
|
l_oliveira: don't have one of those. anyway, here's something you might want to try: http://rapidshare.com/files/310269628/fstool.rar.htmlInstructions: Put the app anywhere without too many spaces Put banned.bin in C:\ (example: C:\banned.bin) Run the app: fstool.exe Done Report back please |
|
|
|
|
Logged
|
I had a blast at the party yesterday!
Oh wait, what you mean you weren't invited? It was in your mouth and everyone came!
|
|
|
|
boby2pc
|
|
« Reply #58 on: November 21, 2009, 03:01:16 PM » |
|
The only possibility when it's not possible to restore old secdata.bin is when it's overwritten.
That will be if whole file system area will be written.
|
|
|
|
|
Logged
|
|
|
|
|
joeyddr
|
|
« Reply #59 on: November 21, 2009, 03:18:42 PM » |
|
can you post it on something other than rapid share? its hosed up right now.
|
|
|
|
|
Logged
|
|
|
|
|
