Editing Validating flash dumps

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 7: Line 7:
}}
}}
So what can we use to prevent that, and make sure our dumps are as proper as we can check?
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 />
{{Dumpstatistics}}
If you do not have HxD many other hex editors have a statistics option. If you want a standalone application that specifically informs you on the validity of the given statistical range (NOR only) use the [http://betterwayelectronics.com/files/BwE%20NOR%20Statistics%20v1.4.exe BwE NOR Statistics application].
== Bytereversed ==
  00 00 00 00 AC 0F FF E0 00 00 00 00 AD DE EF BE  (HEX)  and  saceru_eoldare  (Text)  RAW/PS3 readable - this is E3 default byteorder
  instead of
  00 00 00 00 0F AC E0 FF 00 00 00 00 DE AD BE EF  (HEX)  and  asecure_loader  (Text)  REV/Human readable - this is Progskeet default byteorder
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]] or [http://www.neillcorlett.com/cmdpack/ cmdline tools] (using record to swap: 2).
== 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 />
Other semistatics: http://pastebin.com/7QMpLSBw (not all unique, but can be used to check offsetting by bad addresslines)
=== 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 ==
{{warning|content=If they are even missing or bad, its a sure road to permabrick
}}
Note: There is a program that will list some of the important information below and more - automatically! [http://www.betterwayelectronics.com/files/BwE_NOR_NAND_Dump_Info.rar BwE NOR/NAND Dump Info]
<br>
<br />
{{metbootldr}}


= Flowrebuilder =
= Flowrebuilder =
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Validating_flash_dumps"