Warning on pyPS3checker

R

rasK.

Forum Noob
Hello. I was following MrMario´s latest guide to installing CFW and when I got to the NOR dump.bin in pyPS3checker I get a 004.08 asecure_loader 0x00 Filled Area
I´m sending the full log.

PyPS3checker v0.11.x. Check log.

Checked file : C:\Users\david\Desktop\ps3 tools\PyPS3checker-standalone-package_2024-07-05_121433\dump.bin


******* Getting flash type *******
Flash type : NOR
Reversed : NO


******* Getting SKU identification datas *******
idps = 0x09
metldr0 = 0xE890
metldr1 = 0x0E85
metldrkey = 0xBC78B8F02879A81184A0DA74
bootldr0 = 0x2F13
bootldr1 = 0x2F13
bootldrsize = 0x2F170

Matching SKU : OK
CECH-20xxx (DYN-001)
Minimum version 2.70


******* Getting SDK versions *******
ROS0 : 491.000
ROS1 : 491.000


******* Checking first_region_header *******
001.01 First Region Header 0x00 Filled Area 0 : OK
001.02 First Region Header Magic : OK
001.03 First Region Header 0x00 Filled Area 1 : OK


******* Checking flash_format *******
002.01 Flash Format String : OK
002.02 Flash Format Version : OK
002.03 Flash Format 0xFF Filled Area : OK


******* Checking flash_region_table *******
003.01 Flash Region Table Header : OK
003.02 asecure_loader Offset - Length : OK
003.03 asecure_loader Name : OK
003.04 eEID Offset - Length : OK
003.05 eEID Name : OK
003.06 cISD Offset - Length : OK
003.07 cISD Name : OK
003.08 cCSD Offset - Length : OK
003.09 cCSD Name : OK
003.10 trvk_prg0 Offset - Length : OK
003.11 trvk_prg0 Name : OK
003.12 trvk_prg1 Offset - Length : OK
003.13 trvk_prg1 Name : OK
003.14 trvk_pkg0 Offset - Length : OK
003.15 trvk_pkg0 Name : OK
003.16 trvk_pkg1 Offset - Length : OK
003.17 trvk_pkg1 Name : OK
003.18 ros0 Offset - Length : OK
003.19 ros0 Name : OK
003.20 ros1 Offset - Length : OK
003.21 ros1 Name : OK
003.22 cvtrm Offset - Length : OK
003.23 cvtrm Name : OK
003.24 Flash Region Table 0x00 Filled Area : OK


******* Checking asure_loader_region *******
004.01 asecure_loader Header : OK
004.02 metldr Offset : OK
004.03 metldr Length : OK
004.04 metldr Name : OK
004.05 metldr RevKey : OK
004.06 metldr Binary Size : OK
004.07 metldr Statistics : OK
004.08 asecure_loader 0x00 Filled Area : WARNING!
All bytes from offset 0xF0D0 to offset 0x2F000 should be 0x00.
Byte at offset 0x196C1 has value : 0x08
Subsequent bytes in the range may be wrong as well.



******* Checking eEID_region *******
005.01 eEID Header : OK
005.02 EID0 Offset - Length : OK
005.03 EID1 Offset - Length : OK
005.04 EID2 Offset - Length : OK
005.05 EID3 Offset - Length : OK
005.06 EID4 Offset - Length : OK
005.07 EID5 Offset - Length : OK
005.08 EID0 IDPS0 : OK
005.09 EID0 IDPS1 : OK
005.10 EID0 Static : OK
005.11 EID2 BlockSize/Padding : OK
005.12 EID3 Static0 : OK
005.13 EID3 Static1 : OK
005.14 EID3 Static2 : OK
005.15 EID5 IDPS0 : OK
005.16 EID5 IDPS1 : OK
005.17 EID5 Static : OK
005.18 eEID Region 0xFF Filled Area : OK
005.19 eEID Statistics0 : OK
005.20 eEID Statistics1 : OK


******* Checking cISD_region *******
006.01 cISD Header : OK
006.02 cISD0 Offset - Length : OK
006.03 cISD1 Offset - Length : OK
006.04 cISD2 Offset - Length : OK
006.05 cISD0 0xFF Filled Area : OK
006.06 cISD1 IDLog Header : OK
006.07 cISD1 Semistatic 1 : OK
006.08 cISD1 Semistatic 2 : OK
006.09 cISD1 0xFF Filled Area 0 : OK
006.10 cISD1 Static : OK
006.11 cISD1 Semistatic 3 : OK
006.12 cISD1 0xFF Filled Area 1 : OK
006.13 cISD1 Statistics : OK
006.14 cISD2 : OK
006.15 cISD 0xFF Filled Area : OK


******* Checking cCSD_region *******
007.01 cCSD Header : OK
007.02 cCSD Entry Table : OK
007.03 cCSD 0xFF Filled Area : OK


******* Checking Revokation_region *******
008.01 trvk_prg0 SCE : OK
008.02 trvk_prg0 Hash : OK
Size = 0x2E0
MD5 = 43D940901E9655AD502C12D990977811
Version = 3.41 (from PUP)

008.02 trvk_prg0 0xFF filled area : OK
008.03 trvk_prg1 SCE : OK
008.04 trvk_prg1 Hash : OK
Size = 0x2E0
MD5 = 78629D24BD721488F3A1E846938F87DF
Version = 3.55 (from PUP)

008.04 trvk_prg1 0xFF filled area : OK
008.05 trvk_pkg0 SCE : OK
008.06 trvk_pkg0 0xFF filled area : OK
008.07 trvk_pkg1 SCE : OK
008.08 trvk_pkg1 0xFF filled area : OK


******* Checking CoreOS_region *******
009.01 ROS0 Header : OK
009.02 ROS0 Hash : OK
Size = 0x6FFFE0
MD5 = AFA10D61A1156CF56A994CA85E3B4777
Version = 4.91 CEX/SEX OFW/HFW

009.03 ROS0 unused 0xFF Filled Area : OK
009.04 ROS1 Header : OK
009.05 ROS1 Hash : OK
Size = 0x6FFFE0
MD5 = AFA10D61A1156CF56A994CA85E3B4777
Version = 4.91 CEX/SEX OFW/HFW

009.06 ROS1 unused 0xFF Filled Area : OK


******* Checking cvtrm_region *******
010.01 Pre cvtrm 0xFF Filled Area : OK
010.02 cvtrm0 Header : OK
010.03 cvtrm0 0xFF Filled Area : OK
010.04 vtrm0 Magic : OK
010.05 vtrm0 Reserved Entries : OK
010.07 cvtrm1 Header : OK
010.08 cvtrm1 0xFF Filled Area : OK
010.09 vtrm1 Magic : OK
010.10 vtrm1 Reserved Entries : OK


******* Checking Second_Region_Header *******
011.01 Second Region Header 0x00 Filled Area 0 : OK
011.02 Second Region Header Magic : OK
011.03 Second Region Header Count : OK
011.04 Second Region Header 0x00 Filled Area 1 : OK
011.05 Second Region Unknown Block 0 : OK
011.06 Second Region Header 0x00 Filled Area 2 : OK
011.07 Second Region Unknown Block 1 : OK
011.08 Second Region Header 0x00 Filled Area 3 : OK


******* Checking Unreferenced_Area *******
012.01 unreferenced area 0xFF Filled : OK


******* Checking CELL_EXTNOR_AREA_Region *******
013.01 CELL_EXTNOR_AREA Header : OK
013.02 CELL_EXTNOR_AREA 0x00 Filled Area 0 : OK
013.03 CELL_EXTNOR_AREA 0x00 Filled Area 1 : OK
013.04 CELL_EXTNOR_AREA 0x00 Filled Area 2 : OK
013.05 CELL_EXTNOR_AREA 0x00 Filled Area 3 : OK
013.06 CELL_EXTNOR_AREA 0xFF Filled Area 0 : OK
013.07 CELL_EXTNOR_AREA 0x00 Filled Area 5 : OK
013.08 CELL_EXTNOR_AREA 0x00 Filled Area 6 : OK
013.09 CELL_EXTNOR_AREA 0xFF Filled Area 1 : OK


******* Checking bootldr_region *******
014.01 bootldr0 : OK
014.02 bootldr1 : OK
014.03 bootldr Rev key : OK
014.04 bootldr Statistics : OK
014.05 bootldr 0xFF Filled Area : OK


******* Checking datamatches *******
bootldr size : OK
per console nonce : OK
CELL_EXTNOR_AREA Hash1 : OK
CELL_EXTNOR_AREA Hash2 : OK
metldr size : OK
vtrm0 : OK
vtrm1 : OK


******* Checking repetitions *******
Header Magic0 Repetitions : OK
asecure_loader Repetitions : OK
eEID Repetitions : OK
cISD Repetitions : OK
cCSD Repetitions : OK
trvk_prg0 Repetitions : OK
trvk_prg1 Repetitions : OK
trvk_pkg0 Repetitions : OK
trvk_pkg1 Repetitions : OK
ros0 Repetitions : OK
ros1 Repetitions : OK
cvtrm Repetitions : OK


******* Additional information *******
HDD : Hitachi HTS545012B9SA00 090514PB0A00QMG5E2SA
MAC address : 00:24:8D:18:5D:C1
CID : 0x000201605D86
eCID : 01CA0401C0148718050ECF4000000000
board_id (part of console S/N) : 27453023
kiban_id (board barcode) : 3HG10103225B



******* Checks completed *******

Total number of checks = 155
Number of dangers = 0
Number of warnings = 1

Following check(s) returned a WARNING!
004.08 asecure_loader 0x00 Filled Area

All checks done in 7.39 seconds.

I´ve also updated the console from 4.41 firmware to 4.91. It´s a Slim CECH-2004A
 
Last edited by a moderator:
Thanks! I´m a bit skeptical since I haven´t seen much people get that same error, so I don´t know. Still any help is appreciated!
 
If you're still hesitant about going ahead, you could wait for littlebalup to give his input if/when he has the time, since he is the developer of PyPS3checker and an expert on PS3 flash dumps. esc0rtd3w has already tagged him so he'll get a notification about this thread. Hang tight :)
 
No problem. As esc0rt already advised, you will be fine installing CFW with a single warning, however for that 100% piece of mind I would suggest holding off for now.

What you could do in the meantime however, is re-dump (as esc0rt suggested) your flash and re-check it using PyPS3checker to see if the same warning is produced. You can do this multiple times if you wish. You could also compare the hashes of two or more of the flash.bin dumps to see if they match. WinMD5Free is a portable freeware tool which compares the MD5 hash of two files. If they match, then the file data is identical.
 
You're welcome :) I'll keep an eye on the thread to see what progress there is. I'm quite confident littlebalup will give his expert insight when he next gets a chance to log in; he has done many many times in the past when someone has been unsure about a PyPS3checker log.
 
Hello! I have checked and compared the hashes of 2 dumps I did and they do match. The dumps that I did all give the same warning. Still hesitant about continuing!
 
I'd like to get littlebalup's response, but if I try to patch the flash memory to install CFW, I wouldn't risk bricking it? Sorry for all these questions, I'm new to this things and I got my PS3 a few days ago.
 
Last edited:
rasK. said:
I'd like to get littlebalup's response, but if I try to patch the flash memory to install CFW, I wouldn't risk bricking it? Sorry for all these questions, I'm new to this things and I got my PS3 a few days ago.
Click to expand...
If I were a betting man, I would bet you could patch and install CFW no problem, based on my own experience and testing over the years, dealing with warnings on dumps.

But as said earlier, waiting is up to you for confirmation that the exact warning is fine.
 
Hi, sorry for this late answer... I am not as diligent as I used to be.

rasK. said:
Following check(s) returned a WARNING!
004.08 asecure_loader 0x00 Filled Area
Click to expand...

rasK. said:
******* Checking asure_loader_region *******
004.01 asecure_loader Header : OK
004.02 metldr Offset : OK
004.03 metldr Length : OK
004.04 metldr Name : OK
004.05 metldr RevKey : OK
004.06 metldr Binary Size : OK
004.07 metldr Statistics : OK
004.08 asecure_loader 0x00 Filled Area : WARNING!
All bytes from offset 0xF0D0 to offset 0x2F000 should be 0x00.
Byte at offset 0x196C1 has value : 0x08
Subsequent bytes in the range may be wrong as well.
Click to expand...

https://www.psdevwiki.com/ps3/Flash
https://www.psdevwiki.com/ps3/Flash:asecure_loader

asecure_loader region is where the metldr file (and only the metldr as far as we know) is stored in the flash memory. This region starts at 0x800 and ends at 0x2F000 (for NOR) so is 0x2E800 lenght (186KiB).

metldr is a very critical file, encrypted with perconsole key. The console is toast if is corupted.
That said, per your log, the metldr file itself looks ok, at least its structure (we can't be 100% sure):
rasK. said:
004.02 metldr Offset : OK
004.03 metldr Length : OK
004.04 metldr Name : OK
004.05 metldr RevKey : OK
004.06 metldr Binary Size : OK
004.07 metldr Statistics : OK
Click to expand...

metldr file is usually way smaller than the asecure_loader region where it is stored (your looks to be 0xE890 lenght ~58KiB) leaving a bunch of empty space (0x00 values) at the end of the region.

That's what the warning is about:
rasK. said:
004.08 asecure_loader 0x00 Filled Area : WARNING!
All bytes from offset 0xF0D0 to offset 0x2F000 should be 0x00.
Byte at offset 0x196C1 has value : 0x08
Subsequent bytes in the range may be wrong as well.
Click to expand...

The checker found the value 0x08 at address 0x196C1 where it is supposed to be 0x00. There may be other subsequent bytes with other values (the checker stops at the first mismatch).

So, first of all, it would be interesting to open your dump in an hex editor and to check what it looks like at that address.
If it's only one byte (in fact even one bit as 0x08 is the fourth flipped bit of 0x00), well, it's not a big issue. We already seen that kind of weird bytes in empty unused space. If it's a bunch of bytes, well that's weird, or at least strange.

Anyway, as long as it's located in unused space those kind of "corruptions" should not affect anything. Specially if your console is actually working and if you use bgtoolset to flash your console. I would be more careful if you use an hardware flasher.
 
Hello, thank you so much for helping me. Don´t worry about the late answer. I´m sending you the dump file through PM.
littlebalup said:
Hi, sorry for this late answer... I am not as diligent as I used to be.





https://www.psdevwiki.com/ps3/Flash
https://www.psdevwiki.com/ps3/Flash:asecure_loader

asecure_loader region is where the metldr file (and only the metldr as far as we know) is stored in the flash memory. This region starts at 0x800 and ends at 0x2F000 (for NOR) so is 0x2E800 lenght (186KiB).

metldr is a very critical file, encrypted with perconsole key. The console is toast if is corupted.
That said, per your log, the metldr file itself looks ok, at least its structure (we can't be 100% sure):


metldr file is usually way smaller than the asecure_loader region where it is stored (your looks to be 0xE890 lenght ~58KiB) leaving a bunch of empty space (0x00 values) at the end of the region.

That's what the warning is about:


The checker found the value 0x08 at address 0x196C1 where it is supposed to be 0x00. There may be other subsequent bytes with other values (the checker stops at the first mismatch).

So, first of all, it would be interesting to open your dump in an hex editor and to check what it looks like at that address.
If it's only one byte (in fact even one bit as 0x08 is the fourth flipped bit of 0x00), well, it's not a big issue. We already seen that kind of weird bytes in empty unused space. If it's a bunch of bytes, well that's weird, or at least strange.

Anyway, as long as it's located in unused space those kind of "corruptions" should not affect anything. Specially if your console is actually working and if you use bgtoolset to flash your console. I would be more careful if you use an hardware flasher.
Click to expand...

littlebalup said:
Specially if your console is actually working and if you use bgtoolset to flash your console.
Click to expand...
Yeah, my PS3 works really well and I´m going to use bgtoolset to flash my PS3 if there´s no major issue with it since I don´t have an E3 or a Teensy.
 
Last edited:
rasK. said:
Hello, thank you so much for helping me. Don´t worry about the late answer. I´m sending you the dump file through PM.

Yeah, my PS3 works really well and I´m going to use bgtoolset to flash my PS3 if there´s no major issue with it since I don´t have an E3 or a Teensy.
Click to expand...

upload_2024-10-6_13-59-8.png


So it confirms it's an isolated flipped bit. All the other bytes in the range are 0x00. We don't know exactly what can cause that sometime. It may be a bad flash from the factory not detected during QA controls (they may not check blank spaces) or a small corruption appeared after (aging component?).
Anyway it's an unused space, so no problem.
 
You must log in or register to reply here.

Similar threads

Back
Top