Though I would guess you probably wont be able to dump any of those on odd dashes with any of the available on console software dumping methods. The one on 14699 I would think should dump that way, but who knows,it may be to far from the "retail(final)" version to dump either. though it may be the same as other software options , here's another to try LINK If I were to guess, the ones on the odd dashes will have to be hardware dumped. I do also agree with grabbing a kdnet/windbg log so we can see whats actually happening when you push that hud patch. Really some cool stuff here!! EDIT:: was the console error you got in swizzy's flasher "failed to dump NAND " ? that error code is only called one time in the program and it's after a generic "valid" nand size is found but fails to be read by the rawflash_readImage() method,,either way I stick to my above statement of doubting these will software dump with any of the available tools in stock trim. Spoiler that error defined in translation files : #define MSG_FAILED_TO_DUMP_NAND "failed to dump NAND \n" called in xenon_sfcx.c : if(rawflash_readImage(size, fd) == 1) dprintf(MSG_IMAGE_DUMPED); else dprintf(MSG_FAILED_TO_DUMP_NAND); this would have to return 0 in the highlighted areas below for you to get the above described error. int rawflash_readImage(int len, FILE * fd) { int i=0; int secondPgOffset = sfc.page_sz_phys; int addr, status; int readsz = sfc.pages_in_block*sfc.page_sz_phys; int numblocks = (len/sfc.block_sz_phys); blockbuf = (unsigned char*)malloc(readsz); if(blockbuf == NULL) { dprintf(MSG_ERROR MSG_UNABLE_TO_ALLOCATE_BUFFER, readsz); return 0; } if(sfc.meta_type == META_TYPE_2) secondPgOffset = 0x1080; // 0x210*8 while(i < numblocks) { dprintf(MSG_PROCESSING_BLOCK, i+1, numblocks, ((float)(i + 1) / (float)numblocks) * 100); addr = i*sfc.block_sz; // check first two pages of each block to find out if it's a good block status = sfcx_read_block(blockbuf, addr, 1); if((sfcx_is_pagevalid(blockbuf) == 0) || (sfcx_is_pagevalid(&blockbuf[secondPgOffset]) == 0)) status = status | STATUS_BB_ER; if (fwrite( blockbuf, readsz, 1, fd) < 0) { dprintf(MSG_ERROR_FAILED_TO_WRITE_BYTES_TO_FILE,readsz); return 0; } if((status & (STATUS_BB_ER|STATUS_ECC_ER)) != 0) dprintf(MSG_BLOCK_SEEMS_BAD, i, status); i++; } dprintf("\r\n\n"); return 1; } also seeing the rawdump4g stuff in the code makes me curious as I personally have never used that function in this program.
Credit to XeDK for suggesting I look at the boards closer; for those wondering of the 9 corona, 7 are v2 4gb nand while one is a v1 but is the kit with 13147/20533 flashed to it and the 9th board is a v4 NAND. Hope that helps someone, but what it means is no easy dumping apparently. I'm not as "hep" to the RGH and Jtag shiat as some are.
So I think what I will do vs soldering random shit on an xdk board is run internaldrivelinker.xex and pull the flash files through Xbox Neighborhood and upload them for people to peer through. Any objections or better suggestions? And to answer the question I think XeDK asked, both simple NAND flasher and 360nandflash crash and do not display the type of NAND or the size.
That is an odd combo of revisions, with little other reason in my mind to make hardware changes at that stage of the console, I would have to think M$ was doing anything within reason to make changes that would at least slow the RGH down or limit the number of people capable of doing it. V3+ removed the POST_OUT traces, resistor bridging req on some, etc no real proof of relation to security fixing attempts here so far, but an odd time of changes for sure. I'm still sticking with my theory that these somehow aided in adding/testing all the new stuff that came in around 14699. Yea i'd say at this point that's the best alternative to check some things out.
Ladies and gentlemen; the FLASH https://mega.nz/#!d1QxET4L!WyY_mNSmt6hGdAyBcYcjxTM2rEgdv1XuoUcBQxIS3YA So I didn't have to run internaldrivelinker.xex....... it looks to have been done on all the kits already? They all show up in neighborhood as XNA appearing XDK and all have flash access inherently which I have never seen without some fuckery happening to the kits previously. So this seems slightly odd seeing as how they all had to be named the first go around when I booted them all up..... Also to prove the internal drive linker was used, they all say "Development" vs "Test" when there is no sidecar attached..... Please review and let me know what, if anything, anyone finds. Please share your findings here for all to see.
uh.. Code: [xbdm] drivemap internal=1 netsim reload file=\SystemRoot\netsim.ini Teh fak is that second line? A network simulator? EDIT: Code: [xbdm] netsim insertq in cfg=1001000000001010010701081A220006000014F135220006000014F2353B netsim insertq in cfg=1002000000320005DC00000001F400640069 netsim insertq out cfg=10010000000010100107010819220006000014F135220006000014F2353B netsim insertq out cfg=10020000003200028488000001F400640069 netsim insertipv4redir cfg=100000000000000AB8E33B000000041014441202150E2E68746E732E78626F782E636F6D0E2E68746E6D2E78626F782E636F6D122E68746E732E78626F786C6976652E636F6D122E68746E6D2E78626F786C6976652E636F6D010828010836220022011231034300032201121E034300033B2201120F034300033B22011200034300033B3A
Considering the recovery on those things is anything but normal it isn't a stretch as to think it has flash access enabled by default.
Possibly. I just have no idea what to make of any of it. The boards appear to have more LEDs on the actual board than my corona final with sidecar.
OK so here is my guess, They are probably slightly special made internal kits used for testing dashboard updates and the reason they are getting tossed is that MS is done with the 360 so no more updates thus the kits are not needed. All the oddities are just from the kits having internal debug recoveries and are probably not that special, very nifty to have tho. With that said who knows it might provide useful info for someone and that net sim looks nifty so IDK maybe its outputting something via network or it is set to write logs to a PC somewhere.