|
le_uberfry
|
 |
« Reply #60 on: November 21, 2009, 03:22:12 PM » |
|
|
|
|
|
|
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!
|
|
|
|
|
Mudrac
Newbie
Posts: 4
|
|
« Reply #62 on: November 21, 2009, 04:11:13 PM » |
|
Delete messege please.
|
|
|
|
« Last Edit: November 21, 2009, 05:28:39 PM by Mudrac »
|
Logged
|
|
|
|
|
Arakon
|
|
« Reply #63 on: November 21, 2009, 04:31:29 PM » |
|
The application has failed to start because its side-by-side configuration is incorrect. Please see the application log for more details.
win7 64bit.
|
|
|
|
|
Logged
|
I do NOT give support by email, PM, ICQ or whatever. Anyone annoying me that way will have his balls removed. With a rusty butterknife. Slowly. And I'll enjoy doing it.
|
|
|
|
l_oliveira
|
|
« Reply #64 on: November 21, 2009, 04:38:36 PM » |
|
If you open your nand on Winhex and search for SECDATA.BIN you will find the filesystem entries.
Will look like this:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00DDC3B0 73 79 73 75 70 64 61 74 65 2E 78 65 78 70 32 00 sysupdate.xexp2.
00DDC3C0 00 00 00 00 00 00 03 33 00 03 A4 B0 33 76 60 08 .......3..¤°3v`.
00DDC3D0 73 65 63 64 61 74 61 2E 62 69 6E 00 00 00 00 00 secdata.bin..... <- this is the filename
00DDC3E0 00 00 00 00 00 00 03 57 00 00 04 00 33 76 60 01 .......W....3v`. <- this is the block it's being stored at.
00DDC3F0 6F 64 64 2E 62 69 6E 00 00 00 00 00 00 00 00 00 odd.bin.........
00DDC400 00 00 00 00 00 00 03 69 00 00 00 40 33 76 60 04 .......i...@3v`.
Remembering that the XBOX360 is a big endian system, that's exactly block "357" on this example. Just look for all occurrences of these filesystem lists (each one represents a "generation" of the filesystem under the wear leveling system) and scavenge for valid blocks.
Edit:
P.S.: More spoonfeeding than this, only if someone makes an automated tool for this stuff.
|
|
|
|
« Last Edit: November 21, 2009, 04:41:19 PM by l_oliveira »
|
Logged
|
 It's a Rough World |
|
|
|
|
|
d05register
|
|
« Reply #66 on: November 21, 2009, 05:32:01 PM » |
|
Yes l_oliveira is right. I have found "secdata.bin" at various places and 4 different address blocks from the lines below the string line
0x0345 unbanned
0x011E banned
0x0356 invalid (more than 2 blocks)
0x012B it seems there is another valid copy here, probably older
How does 360 Flash Tool decides which is the active secdata.bin and reports its address correctly? Is there another flag somewhere?
EDIT: Also could someone explain what happens with jasper 256-512 nands? I have dumped the starting 1024 blocks (0x400) and the size is 16MB. So the block size is again 0x4200 bytes? I thought it was larger... And not any tool (360 flash, degrader, infectus tool) can open neither the whole 512MB dump nor the partial. How can I validate that it's OK?
|
|
|
|
« Last Edit: November 21, 2009, 07:45:53 PM by d05register »
|
Logged
|
|
|
|
|
Keihanzo
|
|
« Reply #67 on: November 21, 2009, 07:10:27 PM » |
|
The application has failed to start because its side-by-side configuration is incorrect. Please see the application log for more details.
win7 64bit.
Same here. |
|
|
|
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #68 on: November 21, 2009, 09:29:51 PM » |
|
The application has failed to start because its side-by-side configuration is incorrect. Please see the application log for more details.
win7 64bit.
Same here. I'm a real n00b in VS, so unless someone can tell me how to compile it for x64, you'll have to be content with WinXP x86 compatibility mode  |
|
|
|
|
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!
|
|
|
|
le_uberfry
|
|
« Reply #69 on: November 21, 2009, 09:30:57 PM » |
|
hey le_uberfly I sent you my nand one hour ago and you already have a tool???  Also could you explain what your tool does? We don't need more c4evas  Sure: it finds the most recent fsroot, deletes it, rewrites it to the same banned.bin  BTW: http://www.megaupload.com/?d=UFOZJQCLThis is a recompiled version with static mfc library... maybe this'll work? If it does, no biggie to make a diff version for jasper. The c4eva comment was uncalled for IMHO. I think after all he's done, FOR FREE, he deserves a little more respect. |
|
|
|
« Last Edit: November 21, 2009, 10:07:59 PM by le_uberfry »
|
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!
|
|
|
|
jz_5_3
|
|
« Reply #70 on: November 21, 2009, 09:33:04 PM » |
|
jasper fs seems quiet different. I could not understand the block # for each file entry.
|
|
|
|
|
Logged
|
|
|
|
|
d05register
|
|
« Reply #71 on: November 21, 2009, 09:57:27 PM » |
|
Me too!! This applies to the 16MB jasper also? I have a 512MB so I haven't seen a 16MB jasper dump
Then I wonder, how did they patched the jasper nand with Xell, if FS, block #, ECC bytes etc. are different?
|
|
|
|
« Last Edit: November 21, 2009, 09:59:36 PM by d05register »
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #72 on: November 21, 2009, 10:05:55 PM » |
|
Xell doesn't use FS... maybe you need to calculate using 0x10800 instead of 0x4200 for jasper?  |
|
|
|
|
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!
|
|
|
|
|
|
le_uberfry
|
|
« Reply #74 on: November 21, 2009, 10:34:17 PM » |
|
can you tell me what you got at 0x3C6.4A00? or even 0x3E0.D600?
|
|
|
|
« Last Edit: November 21, 2009, 10:38:00 PM by le_uberfry »
|
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!
|
|
|
|
jz_5_3
|
|
« Reply #75 on: November 21, 2009, 10:43:38 PM » |
|
that is FFD4010000000006 20040000aa9c60b3, 0x3E0.D600 is all ff.
I think the problem is to derive 03B4 from 01d4. 01d4 appears to be the block #.
|
|
|
|
« Last Edit: November 21, 2009, 10:47:34 PM by jz_5_3 »
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #76 on: November 21, 2009, 10:57:24 PM » |
|
hmpf, this is too high for me... anyway, what's at 0x2DF1250? maybe "65 64 01" ? or something similar?
|
|
|
|
|
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!
|
|
|
|
jz_5_3
|
|
« Reply #77 on: November 21, 2009, 11:03:36 PM » |
|
FF is mark, d401 (01d4) is the block #. this is where large size nand differs from small one.
((3c71210/210)*200)/20000=1d4
|
|
|
|
|
Logged
|
|
|
|
|
le_uberfry
|
|
« Reply #78 on: November 21, 2009, 11:11:55 PM » |
|
(0x3C71210-0x200)/0x210 = 0x1D4E1 remapping bad blocks maybe? look what's at 0x3C74FF0 anyway, I think we're drifting off the subject... I thought this was about restoring old secdata.bin and not big block calculation  |
|
|
|
« Last Edit: November 21, 2009, 11:15:59 PM by le_uberfry »
|
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!
|
|
|
|
jz_5_3
|
|
« Reply #79 on: November 21, 2009, 11:19:35 PM » |
|
that is FFD4010000... too,
yeah, you are right, but related. I think a large # of banned consoles are jasper too
|
|
|
|
|
Logged
|
|
|
|
|
