vtrm danger with PyPS3checker

Smithfield

Forum Noob
I was following MrMario2011's guide on jailbreaking a PS3, and when it came time to check the flash dump (NAND, in my case) to make sure there were no dangers or warnings, I get one danger related to vtrm. MrMario2011 did say that reinstalling the OFW may fix dangers and warnings, but after I did this, I still get the same exact danger. This is the only danger, according to this log:
Code:
PyPS3checker v0.11.x. Check log.

Checked file : D:\Cell BE\PyPS3Tools\dump_orig.hex


******* Getting flash type *******
  Flash type : NAND (partial dump, 239MB)


******* Getting SKU identification datas *******
  idps = 0x01
  metldr0 = 0xEDA0
  metldr1 = 0x0ED6

  Matching SKU : OK
   CECHAxx (COK-001)
   Minimum version 1.00


******* Getting SDK versions *******
  ROS0 : 489.000
  ROS1 : 489.000


******* Checking Header_Magic *******
002.01   Header Magic 0x00 Filled Area 0 : OK
002.02   Header Magic : OK
002.03   Header Magic 0x00 Filled Area 1 : 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_prg Offset - Length : OK
003.11   trvk_prg Name : OK
003.12   trvk_pkg Offset - Length : OK
003.13   trvk_pkg Name : OK
003.14   creserved_0 Offset - Length : OK
003.15   creserved_0 Name : OK
003.16   ros Offset - Length : OK
003.17   ros Name : OK
003.18   cvtrm Offset - Length : OK
003.19   cvtrm Name : OK
003.20   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 : OK


******* 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.00   trvk_prg Region Header : OK
008.01   trvk_prg0 SCE : OK
008.02   trvk_prg0 Hash : OK
  Size = 0x2E0
  MD5 = 78629D24BD721488F3A1E846938F87DF
  Version = 3.55 (from PUP)

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

008.00   trvk_pkg Region Header : OK
008.05   trvk_pkg0 SCE : OK
008.07   trvk_pkg1 SCE : OK


******* Checking Unreferenced_Area *******
008.08   unreferenced area 0xFF filled : OK


******* Checking CoreOS_region *******
009.00   ROS Header : OK
009.01   ROS0 Header : OK
009.02   ROS0 Hash : OK
  Size = 0x6FFFE0
  MD5 = 2C6791BAC0978B921CACAEBB1E827743
  Version = 4.89 CEX/SEX OFW/HFW

009.03   ROS1 Header : OK
009.04   ROS1 Hash : OK
  Size = 0x6FFFE0
  MD5 = 2C6791BAC0978B921CACAEBB1E827743
  Version = 4.89 CEX/SEX OFW/HFW



******* Checking cvtrm_region *******
010.01   cvtrm Header : OK
010.02   cvtrm Header Static 1 : OK
010.03   vtrm Magic 1 : OK
010.05   vtrm Magic 2 : OK
010.07   cvtrm 0x00 Filled Area : OK


******* Checking cell_ext_os_area *******
011.01   cell_ext_os_area Header : OK
011.02   cell_ext_os_area 0xFF Filled Area 0 : OK
011.03   cell_ext_os_area Break Section : OK
011.04   cell_ext_os_area 0xFF Filled Area 1 : OK


******* Checking datamatches *******
per console nonce : OK
metldr size : OK
vtrm header datas : OK
vtrm : DANGER!
  Following datas should be the same :
  repetitions seq. 1 at offset 0xEB94C0 length 0x14, repeted 0x417 time
    (too long to dilplay)
  repetitions seq. 2 at offset 0xEBE6A0 length 0x14, repeted 0x78 time
    (too long to dilplay)



******* Checking repetitions *******
Header Magic Repetition : OK
asecure_loader Repetition : OK
eEID Repetition : OK
cISD Repetition : OK
cCSD Repetition : OK
trvk_prg Repetition : OK
trvk_pkg Repetition : OK
ros Repetition : OK
cvtrm Repetition : OK


******* Additional information *******
MAC address : 00:19:C5:31:8B:05
CID : 0x000200155598
eCID : 01C53D15411C17180A08000000000000
board_id (part of console S/N) : 27430155
kiban_id (board barcode) : 3HA01048031C



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

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

Following check(s) returned a DANGER!
  datamatches : vtrm

All checks done in 3.38 seconds.
Any idea on how to fix this? Is there a chance that this NAND dump is still good? I heard that we sometimes have special cases related to NAND flash dumps on this forum where they are technically good despite warnings or dangers due to simply being unknown until a user runs into them. I looked up in the log file and cannot find out how to make the
 
@littlebalup Is the your man to ask, being the developer and resident expert on flash dumps. This post will notify him so hopefully if he's not too busy he'll get a chance to take a look at the log you posted and be able to go from there.
 
I cannot seem to figure out how to DM people or even leave a post on their profile. I will just have to hope @littlebalup will find this thread and DM me for my NAND flash dump.
 
Since you're a new user, you may not be able to do certain things on the forum straight away. Like I said, littlebalup will get a notification (well 2 now lol) and will hopefully check in to the thread and advise you. Flash dump may not be needed, just the log you've already provided - but let's just wait and see first :)
 
Unfortunately, I need to know by tomorrow, or I am either going to have to self-host the bgtoolset or use the PS3HEN fallback (which may not provide fan control (cannot find a definitive answer to fan control on PS3HEN)). The DNS I am using could potentially expire on the 24th, which is only 2 days from now.
 
Unfortunately, I need to know by tomorrow, or I am either going to have to self-host the bgtoolset or use the PS3HEN fallback (which may not provide fan control (cannot find a definitive answer to fan control on PS3HEN)). The DNS I am using could potentially expire on the 24th, which is only 2 days from now.


HEN allows fan control. There are a few others that may be able to input not a ton of NAND users as opposed to NOR flash.
 
Looks like a small vtrm corruption. Did you experienced some RSOD, BSOD or trophies issues?

Anyway there is nothing you can do at this stage without an hardware flasher. Bgtoolset or firmware update don't act to the vtrm region.

So leave it as is and go ahead with jailbreak and CFW installation. Then if you experienced some of the issues described above, you can try a RSOD fix to regenerate the vtrm. Make a new dump and see if the issue gone.
 
Looks like a small vtrm corruption. Did you experienced some RSOD, BSOD or trophies issues?

Anyway there is nothing you can do at this stage without an hardware flasher. Bgtoolset or firmware update don't act to the vtrm region.

So leave it as is and go ahead with jailbreak and CFW installation. Then if you experienced some of the issues described above, you can try a RSOD fix to regenerate the vtrm. Make a new dump and see if the issue gone.

Sorry to bother you but I have a similar issue where it says that both vtrm have datamatches in them, but is the only fix really to reflash the NOR?can I continue with installing the CFW or should i try and fix it first?
I have a CECH 2004b

thank you for reading and I await your answer

******* Checking datamatches *******
bootldr size : OK
per console nonce : OK
CELL_EXTNOR_AREA Hash1 : OK
CELL_EXTNOR_AREA Hash2 : OK
metldr size : OK
vtrm0 : DANGER!
Following datas should be the same :
repetitions seq. 1 at offset 0xEDD748 length 0x14, repeted 0xC7 time
(too long to dilplay)
repetitions seq. 2 at offset 0xEDE6E8 length 0x14, repeted 0x141 time
(too long to dilplay)
vtrm1 : DANGER!
Following datas should be the same :
repetitions seq. 1 at offset 0xEFD748 length 0x14, repeted 0xC7 time
(too long to dilplay)
repetitions seq. 2 at offset 0xEFE6E8 length 0x14, repeted 0x141 time
(too long to dilplay)
 
Last edited:
Sorry to bother you but I have a similar issue where it says that both vtrm have datamatches in them, but is the only fix really to reflash the NOR?can I continue with installing the CFW or should i try and fix it first?
I have a CECH 2004b

thank you for reading and I await your answer

******* Checking datamatches *******
bootldr size : OK
per console nonce : OK
CELL_EXTNOR_AREA Hash1 : OK
CELL_EXTNOR_AREA Hash2 : OK
metldr size : OK
vtrm0 : DANGER!
Following datas should be the same :
repetitions seq. 1 at offset 0xEDD748 length 0x14, repeted 0xC7 time
(too long to dilplay)
repetitions seq. 2 at offset 0xEDE6E8 length 0x14, repeted 0x141 time
(too long to dilplay)
vtrm1 : DANGER!
Following datas should be the same :
repetitions seq. 1 at offset 0xEFD748 length 0x14, repeted 0xC7 time
(too long to dilplay)
repetitions seq. 2 at offset 0xEFE6E8 length 0x14, repeted 0x141 time
(too long to dilplay)


Hi, unfortunately I'll not have a different answer for you than my previous post on this thread. So, go ahead with CFW installation. Then if you have any issue like RSOD or trophies, you may need an RSOD fix. Otherwise, keep it as is.
 
Hi, unfortunately I'll not have a different answer for you than my previous post on this thread. So, go ahead with CFW installation. Then if you have any issue like RSOD or trophies, you may need an RSOD fix. Otherwise, keep it as is.
Oh well, shame that it's not an easy fix.
thank you for for your time
 
Remainder nands have bad blocks most often from write allocations.
Error correcting codes (ECC) are used with NAND flash memory to detect and correct bit errors that may occur with the memory. NAND flash memory bit error rates increase with the number of program/erase cycles and the scaling of technology.
Now with nands is matter of situation where bad blocks took his place.
Been able to remap few units over time (most all fixed when I read and flash with hardware flasher).
I won't be able to help others as I don't know how they use hardware flasher to fix. Most of the time I just read content with flasher (if possible on rebug toolbox full dump even better)
Rebuild with software top and bottom without any errors or bad blocks. Flash another set of nands models from cok001 /001 are most likely not happening to have any errors. Erase, flash, boot straight.
Most useful tool is flowrebuilder to remap, if ecc took place in empty blocks easy fix. If there is ecc an full of data block only developers with years of studying will know how to shift those. That situation will be headache and most likely be a paid service if worth time.
Nor models idk but for me seems more like a hardware issue, when it comes to vtrm area, will probably produce rsod like red screen with time or something like ylod. For most cases I like to swap Samsung nor ic out, Idk why they were most bad nor ic. They were known for bad blocks or even that effect when you can't read more than half of memory no matter how skilled you are.
It's matter of user to understand what he is doing with programming side.
 
Last edited:
Remainder nands have bad blocks most often from write allocations.
Error correcting codes (ECC) are used with NAND flash memory to detect and correct bit errors that may occur with the memory. NAND flash memory bit error rates increase with the number of program/erase cycles and the scaling of technology.
Now with nands is matter of situation where bad blocks took his place.
Been able to remap few units over time (most all fixed when I read and flash with hardware flasher).
I won't be able to help others as I don't know how they use hardware flasher to fix. Most of the time I just read content with flasher (if possible on rebug toolbox full dump even better)
Rebuild with software top and bottom without any errors or bad blocks. Flash another set of nands models from cok001 /001 are most likely not happening to have any errors. Erase, flash, boot straight.
Most useful tool is flowrebuilder to remap, if ecc took place in empty blocks easy fix. If there is ecc an full of data block only developers with years of studying will know how to shift those. That situation will be headache and most likely be a paid service if worth time.
Nor models idk but for me seems more like a hardware issue, when it comes to vtrm area, will probably produce rsod like red screen with time or something like ylod. For most cases I like to swap Samsung nor ic out, Idk why they were most bad nor ic. They were known for bad blocks or even that effect when you can't read more than half of memory no matter how skilled you are.
It's matter of user to understand what he is doing with programming side.
Should I make use of it while it still works or replace the NOR chip as soon as I can?
P.S. I modded it with CFW(the latest EVILNAT) yesterday and kept the dump, the CFW works without any issues so I don't know if it's going to get worse to repair by keeping it like this instead of repairing it
 
Last edited:
Should I make use of it while it still works or replace the NOR chip as soon as I can?
P.S. I modded it with CFW(the latest EVILNAT) yesterday and kept the dump, the CFW works without any issues so I don't know if it's going to get worse to repair by keeping it like this instead of repairing it
What type of nor is that you have? Keep it as it work. You have a valid dump can always be repaired. Don't fix it if ain't broken. But if you still have your thoughts bother you pay me for your time you spend to swap it.
 
Back
Top