View source for Validating flash dumps

[[Category:Hardware]][[Category:Software]]
= Why so important? =
Whenever you want to mess with flash (NAND or NOR), you have to '''make sure you are getting 100% correct, valid, verified dumps.'''

When you don't, and for some reason(s) the dump is invalid/bad, and you are rewriting to flash, you have <span style="background-color:white; color:red;">no way of restoring</span> the console hence making a perma-brick (unrecoverable brick).

So what can we use to prevent that, and make sure our dumps are as proper as we can check?

= Visual inspection =
<div style="float:right">[[File:HxD.png|thumb|left|HxD - hexeditor]]</div>

Open up the flashdump (make it unified first if it is still 2 seperate NAND dumps) with a hexeditor (e.g. [http://mh-nexus.de/en/hxd/ HxD])<br />and compare what you see with the [[Flash]] page.

== Statistical analysis ==
One neat option in HxD is the analysis option. Open dump file and select Statistics in the Analysis menu. Mouse over the blue graph bars of [[:File:HxD-Analysis-Statistics-mouseover-00.jpg|00]] and [[:File:HxD-Analysis-Statistics-mouseover-FF.jpg|FF]] <br />

Valid dumps will have 
{| class="wikitable"
|-
! Value !! NAND !! NOR
|-
| 00's || 1.72% - 2.68% || 18.71% - 29.01%
|-
| FF's || 18.25% - 24.54% || 10.42% - 10.48%
|-
| rest || below 0.5% || below 0.5%
|-
|}
<!--// <Jwh1o1> CECHA: 00s: 1.43% / FFs: 19.29%   //-->
<!--// <olum> 	CECHGxx (SEM-001): 00s: 1.66% / FFs: 20.10% //-->
<!--// <Caesar007>  CECHA: 00s: 1.77% / FFs: 24.92% //-->

== Bytereversed ==
   00 00 00 00 AC 0F FF E0 00 00 00 00 AD DE EF BE  (HEX)   and   saceru_eoldare  (Text)
   instead of
   00 00 00 00 0F AC E0 FF 00 00 00 00 DE AD BE EF  (HEX)   and   asecure_loader  (Text)
You can use either the bytereverse option in the the flasher application and redump, or bytereverse the current dump with [[Validating_flash_dumps#Flowrebuilder|Flowrebuilder]].

== Only zeroes ==
 00 00 00 00 00 00 00 00 00 where data should've been
* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check

== patterned non zeroes / patterned non ff's ==
   30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
   00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80   where zeroes should've been

   EF FF EF FF EF FF EF FF EF FF EF FF EF FF EF FF   where FF's should've been

* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check
* Can also be caused by bad grounding, too low Vcc, interference or too long wires -> check

== patterned FF's ==
   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   repetive banding of FF's where data or zeroes should have been
* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check

== malformed headers / filenames / regionnames ==
   IJI              instead of   IFI
   asecure_loaher                asecure_loader
   eIIH                          eEID
   cESH                          cISD
   cCSH                          cCSD
   trvg_prk0                     trvk_prg0
   trvg_prk1                     trvk_prg1
   trvg_pkk0                     trvk_pkg0
   trvg_pkk1                     trvk_pkg1
   cztrm                         cvtrm
   mitldr                        metldr
* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check

== absent files / regions ==
   00FC0000  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ    missing bootldr in NOR

   00000000  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ    missing bootldr in NAND
* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check

== malformed files / regions ==
   00FC0000  28 B4 4F D2 F9 3F BC 43 28 B4 4F D2 F9 3F BC 43  (´OÒù?¼C(´OÒù?¼C    corrupted bootldr in NOR (it should always start with 00 00 there)
* Seems reading is a problem, mostly caused by bad wiring/clip seating -> check

== Repetitions ==
take 16 bytes of an offset that should be unique, e.g. the 0x10 offset which normaly has the DEADBEEF magic header :
   NOR: 0x0000010 00 00 00 00 0F AC E0 FF 00 00 00 00 DE AD BE EF  //  NAND: 0x040010 00 00 00 00 0F AC E0 FF 00 00 00 00 DE AD BE EF
And find all instances in hexeditor <br />
When it says found in 0x10 and 0x10010 you substract them (0x10010 - 0x10 = 0x10000) <br />
So that means there is an error with setting 0x10000 (only one bit set!) low <br />
because the programmer applies 0x10010 but the actual data on the address lines (received by the nor flash) is 0x10 <br />

=== Checking again with other unique 16 byte sequence ===
   617365637572655F6C6F616465720000 (asecure_loader in hex)
Same check, found at 0x420 and 0x10420 (0x10420-0x420 = 0x10000)

=== OK, you've found the pattern, now how do we deduct from that the faulty line? ===
address is 2 bytes. 0x10 in dump with hexeditor is in reality 0x8 on the address bus because we read 2 bytes at once <br />
so the address is no longer 0x10000 but 0x8000 <br />
0x8000 (hexadecimal = base 16) = 1000 0000 0000 0000 (binary = base 2) <br />
which means the 16th bit = 1, we start counting at A0, so the 16th is A15 <br />

conclusion : A15 is bad


<!--// Well here is a program that will verify the size of the dump, check the header 0xDEADBEEF and its repetation and shows you which address line is bad and it will also check if the console is downgradable or not by looking at the bootloader data. So with this tool you have all in one checker but even we will say you to verify the dump manually or using flowrebuilder also, Link to the program: http://www.sendspace.com/file/byubqj

This program will check for bad file size as well as if the magic header are repeated or not and also calculate the difference of repeated header and tell you which address line is bad. If the dump is good it will tell you weather the console is downgradable or not? //-->

==== Quick lookup table ====
{| class="wikitable"
|-
! repetition !! addressline 'stuck'
|-
| 0x2 || A0
|-
| 0x4 || A1
|-
| 0x8 || A2
|-
| 0x10 || A3
|-
| 0x20 || A4
|-
| 0x40 || A5
|-
| 0x80 || A6
|-
| 0x100 || A7
|-
| 0x200 || A8
|-
| 0x400 || A9
|-
| 0x800 || A10
|-
| 0x1000 || A11
|-
| 0x2000 || A12
|-
| 0x4000 || A13
|-
| 0x8000 || A14
|-
| 0x10000 || A15
|-
| 0x20000 || A16
|-
| 0x40000 || A17
|-
| 0x80000 || A18
|-
| 0x100000 || A19
|-
| 0x200000 || A20
|-
| 0x400000 || A21
|-
| 0x800000 || A22
|-
| 0x1000000 || A23
|-
| 0x2000000 || A24
|-
| 0x4000000 || A25
|-
| 0x8000000 || A26
|-
| 0x10000000 || A27
|-
| 0x20000000 || A28
|-
| 0x40000000 || A29
|-
| 0x80000000 || A30
|-
|}

== Check metldr+bootldr sizes ==
If they are even missing, its a sure road to permabrick
{{metbootldr}}

= Flowrebuilder =
<div style="float:right">[[File:FlowRebuilder.png|thumb|left|Flow Rebuilder]]</div>

== Links to versions ==
http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder%20v.4.2.2.0.exe FlowRebuilder v.4.2.2.0.exe (389 KB)] // [http://www.mirrorcreator.com/files/7G5JLEK9/FlowRebuilder_v.4.2.2.0.exe_links mirror]
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder%20v.4.2.1.2.exe FlowRebuilder v.4.2.1.2.exe (313.50 KB)] // [http://www.mirrorcreator.com/files/08SGK09K/FlowRebuilder_v.4.2.1.2.exe_links mirror]
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder%20v.4.2.1.1.exe FlowRebuilder v.4.2.1.1.exe (473.57 KB)] // [http://www.mirrorcreator.com/files/GUUUKNWE/FlowRebuilder_v.4.2.1.1.exe_links mirror]
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder%20v.4.2.0.1.exe FlowRebuilder v.4.2.0.1.exe (474.01 KB)] // [http://www.mirrorcreator.com/files/C4U1C3OO/FlowRebuilder_v.4.2.0.1.exe_links mirror]
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder+v.4.1.3.2.exe FlowRebuilder v.4.1.3.2.exe (459.95 KB)] // [http://www.mirrorcreator.com/files/1UEPOIHX/FlowRebuilder_v.4.1.3.2.exe_links mirror]
* [http://www.ps3devwiki.com/files/flash/Tools/Flowrebuilder/FlowRebuilder%20v.4.1.0.0.exe FlowRebuilder v.4.1.0.0.exe (454.85 KB)] // [http://www.mirrorcreator.com/files/EC2ZFONW/FlowRebuilder_v.4.1.0.0.exe_links mirror] (don't use, for historic reasons listed)

==Flowrebuilder options==
* (NAND only) UNSCRAMBLE then interleave two NAND flashes into one unified dump - (4.1.0.0 and higher) : Makes a unified dump.bin from 2 seperate NAND flash dumps.
** In the second step it also extract the content of the unified dump. Make sure it extracts correctly (it will give no warning if it fails!) and all the needed files are there.
* (NAND only) RE-SCRAMBLE a modified dump then de-interleave it into two new flashes - (4.1.0.0 and higher) : Splits the unified dump.bin into 2 new seperate NAND flash dumps.
* Byte reverse and EXTRACT a NOR  dump file - (4.1.0.0 and higher) : First byte reverse the single dump.bin then extract NOR content.
* EXTRACT a Byte reversed NOR dump or an interleaved and unscrambled NAND dump - (4.1.0.0 and higher) : Extract the single dump.bin.
* Byte reverse and PATCH a NOR dump - (4.2.1.1 and higher).
* PATCH a Byte reversed NOR dump or an interleaved and unscrambled NAND dump - (4.2.1.1 and higher).
* Byte reverse a dump - (4.2.1.1 and higher).

Note: <span style="text-decoration: line-through;">when getting [http://pastie.org/3656024 errors with autopatcher], use Winskeet to patch the <abbr title="validated interleaved and unscrambled NAND dump">unified dump</abbr> and then Flowrebuilder to Rescramble it.</span> -> Fixed in FlowRebuilder v.4.2.1.2

== Extracted flash content files ==
<div style="float:right">[[File:Nand-extract-noerror.png|200px|thumb|left|Flowrebuilder extraction no error]]<br />[[File:Nand-extract-error2.png|200px|thumb|left|Flowrebuilder extraction error]]</div>

<span style="background-color:white; color:red;">(make sure they are all there, flowrebuilder will not give warning when it fails!)</span>:
* bootloader_0
* bootloader_1 (NAND only)
* cCSD
* cISD
* creserved_0 (NAND only)
* cvtrm
* eEID
* trvk_pkg
* trvk_prg
* \asecure_loader\metldr
* \ros\<nowiki>[two seperate folders named to FW version]</nowiki>\[[CoreOS|CoreOS files]] (19 up to 25 files, depending the FW version)

'''Notes:'''
*  if it only extracted bootloader_0 + bootloader_1, check that both NANDs are dumped correct (known error with flashers that has bug with second NAND channel to read), and that high/low where selected correct.

* Do not use spaces in the folderpath, or Flowrebuilder will not extract the files.<!--// http://www.mediafire.com/?229seszf07votsv domelec //-->

* <span style="text-decoration: line-through;">Bug workaround: delete previous extraction attempts to prevent Flowrebuilder to always error. -> [http://pastie.org/3744043 bugreport]</span> -> Fixed in FlowRebuilder v.4.2.2.0

== From unified to seperate low/high NAND files ==
If for some reason you loose the original seperate low/high NAND files and only have the <abbr title="unscrambled then interleaved 2 NAND to unified dump">unified</abbr>, you need donor files to regenerate them. 
* [http://www.ps3devwiki.com/files/flash/dumps/NAND0-1.rar NAND0-1.rar]
extract and in Flowrebuilder select the option "RE-SCRAMBLE a modified dump then de-interleave it into two new flashes"
* Select the NAND backup "Flash 0" (TOP) file : here drop the 1bkp.bin
* Select the NAND backup "Flash 1" (BOTTOM) file : here drop the 2bkp.bin
* Select the Input NAND interleaved Modified file : here drop your unified flash .bin file
and click Execute Operation

This will result in making 2 new deinterleaved files you could use for reflashing (it is recommended to alway use '''''your own''''' deinterleaved sourcedumps, this method is only mentioned as last resort for people that lost their backups).

= Online help =
Upload your dump to a fileshare host (e.g. http://www.mirrorcreator.com/) and join IRC ef.net in channel #ps3downgrade 

Please use this method only after you first tried the above options first (so you have learned from it as well) :)