Editing Validating flash dumps

= 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 =
Open up the flashdump (make it unified first if it is still 2 seperate NAND dumps) with a hexeditor (e.g. HxD) and compare what you see with the [[Flash]] page.

== 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 ==
 30 30 30 30 30 30 30 30 30 where zeroes 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

== 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

==== 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
|-
|}

= Flowrebuilder =
== Links to versions ==
* [http://www.multiupload.com/KNSNWVAAI1 FlowRebuilder v.4.2.1.1.exe (473.57 KB)]
* [http://www.multiupload.com/INR8272DRC FlowRebuilder v.4.2.0.1.exe (474.01 KB)]
* [http://www.multiupload.com/L9QPX7DIY5 FlowRebuilder v.4.1.3.2.exe (459.95 KB)]
* [http://www.multiupload.com/CZP2S9CIPF FlowRebuilder v.4.1.0.0.exe (454.85 KB)]

==Flowrebuilder options==
*(NAND only) Unscramble then interleave flashes into one unified dump : Makes a single 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 modified dump then de-interleave it into two new flashes : Splits the single dump.bin into 2 seperate NAND flash dumps.
*Byte reverse and extract a NOR  dump file : First byte reverse the single dump.bin then extract NOR content.
*Extract a Byte reversed NOR dump or an interleaved and unscrambled NAND dump : Extract the single dump.bin

== Extracted flash content files ==
<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
* cCSD
* cISD
* creserved_0
* cvtrm
* eEID
* trvk_pkg
* trvk_prg
* \asecure_loader\metldr
* \ros\<nowiki>[two seperate folders named to FW version]</nowiki>\[[Boot_Order#CoreOS_PKG_Filelisting|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),

= Online help =
Upload your dump to a fileshare host (e.g. http://www.multiupload.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) :)