Evilnat DEX2CEX Brick

P

Pusch3l

Member
Hello...
i got a bit of a problem with a bricked DECHA00 Frankenstein i made for someone.
background story is simple: Console worked till he decided to crossgrade from 4.91 Evilnat with DEX Kernel to 4.91 with CEX Kernel. now its a "5 Alarmbeep and off".
I tried to patch a NAND dump to 3.55 and use 355 DEX downgrader (via fsm).
i also tried to write a previous NAND dump back which was probably taken with bgtoolset or evilnat.
both tries ended up in a YLOD so i soldered the original NANDs back on.

I use a Teensy with NORwegian Socket PCB (3.3v) for dumping/writing.

Here is a SB-UART Log. maybe someone has an idea how to save the unit

Code: 
Boot Loader SE Version 4.9.1 (Build ID: 5374,50754, Build Date: 2023-12-07_13:37:12)
SDK Version: 491.000
Copyright(C) 2023 Evilnat [Akatsuki]. 02/27/2024. Happy CFW moments.
[INFO]: === eXtreme Data Rate Memory Subsystem ===
[INFO]: (Configured Memory Size per single XIO channel: 128 MBytes.)
[INFO]: XIO channel[0] is available.
[INFO]: XIO channel[1] is available.
[INFO]: ---> Total 256 MBytes are now in use.
[INFO]: SPU enable [0, 1, 2, 5, 6, 7] 11101111
[INFO]: BE:3.2, SB:DX3.1
Device: PATAC0:Cable Not Connect
Cell OS SDK4.9.1 000 (release build: r50754 2023_12_07_130000)
Copyright 2024 Evilnat [Akatsuki] 02/27/2024  .
revision: 50750
date:     Thu Dec  7 13:38:43 JST 2023
skip 2nd initialization step
storage: ACL check will be skipped for device id ffffffffffffffff
storage: ACL check will be skipped for device id 0
storage: ACL check will be skipped for device id 1
lv2(0): total memory size: 249MB+640KB
lv2(0): kern memory size:   12MB+640KB (heap:3316KB  page pool:4736KB)
lv2(0): user memory size:  237MB
lv2(2):
lv2(2): Cell OS Lv-2 32 bit version 4.9.1
lv2(2): Copyright(C) 2024 Evilnat [Akatsuki]. 02/27/2024.
lv2(2): Happy CFW moments.
lv2(2):
lv2(2): revision: 50754
lv2(2): build date: 2024/02/27 00:00:00
lv2(2): processor: Broadband Engine  Ver 0x0000  Rev 0x0202
lv2(2): PPU:0, Thread:0 is enabled.
lv2(2): PPU:0, Thread:1 is enabled.
storage: ACL check will be skipped for device id 2
lv2(2): rsx:      rsx40 a01 500/650 vpe:ff shd:3f  [NN0952-02:0:4:2:f:2:6:0:1][24:0:a:0:1:0:1][1:1:0]

lv2(2): Available physical SPUs: 6/7
lv2(2):
lv2(2): ###
lv2(2): ### System fatal error : Invalid kernel image detected
lv2(2): ###
lv2(2):
lv2(2):
lv2(2): Prepare to shutdown .....
lv2(2): Going to shutdown.
system event id=0xe1, rtc=0, size=24 [0x5354523a50415441 0x43303a4361626c65 0x204e6f7420436f6e 0x6e65637400000000]
 
Pusch3l said:
Hello...
i got a bit of a problem with a bricked DECHA00 Frankenstein i made for someone.
background story is simple: Console worked till he decided to crossgrade from 4.91 Evilnat with DEX Kernel to 4.91 with CEX Kernel. now its a "5 Alarmbeep and off".
I tried to patch a NAND dump to 3.55 and use 355 DEX downgrader (via fsm).
i also tried to write a previous NAND dump back which was probably taken with bgtoolset or evilnat.
both tries ended up in a YLOD so i soldered the original NANDs back on.

I use a Teensy with NORwegian Socket PCB (3.3v) for dumping/writing.

Here is a SB-UART Log. maybe someone has an idea how to save the unit

Code: 
Boot Loader SE Version 4.9.1 (Build ID: 5374,50754, Build Date: 2023-12-07_13:37:12)
SDK Version: 491.000
Copyright(C) 2023 Evilnat [Akatsuki]. 02/27/2024. Happy CFW moments.
[INFO]: === eXtreme Data Rate Memory Subsystem ===
[INFO]: (Configured Memory Size per single XIO channel: 128 MBytes.)
[INFO]: XIO channel[0] is available.
[INFO]: XIO channel[1] is available.
[INFO]: ---> Total 256 MBytes are now in use.
[INFO]: SPU enable [0, 1, 2, 5, 6, 7] 11101111
[INFO]: BE:3.2, SB:DX3.1
Device: PATAC0:Cable Not Connect
Cell OS SDK4.9.1 000 (release build: r50754 2023_12_07_130000)
Copyright 2024 Evilnat [Akatsuki] 02/27/2024  .
revision: 50750
date:     Thu Dec  7 13:38:43 JST 2023
skip 2nd initialization step
storage: ACL check will be skipped for device id ffffffffffffffff
storage: ACL check will be skipped for device id 0
storage: ACL check will be skipped for device id 1
lv2(0): total memory size: 249MB+640KB
lv2(0): kern memory size:   12MB+640KB (heap:3316KB  page pool:4736KB)
lv2(0): user memory size:  237MB
lv2(2):
lv2(2): Cell OS Lv-2 32 bit version 4.9.1
lv2(2): Copyright(C) 2024 Evilnat [Akatsuki]. 02/27/2024.
lv2(2): Happy CFW moments.
lv2(2):
lv2(2): revision: 50754
lv2(2): build date: 2024/02/27 00:00:00
lv2(2): processor: Broadband Engine  Ver 0x0000  Rev 0x0202
lv2(2): PPU:0, Thread:0 is enabled.
lv2(2): PPU:0, Thread:1 is enabled.
storage: ACL check will be skipped for device id 2
lv2(2): rsx:      rsx40 a01 500/650 vpe:ff shd:3f  [NN0952-02:0:4:2:f:2:6:0:1][24:0:a:0:1:0:1][1:1:0]

lv2(2): Available physical SPUs: 6/7
lv2(2):
lv2(2): ###
lv2(2): ### System fatal error : Invalid kernel image detected
lv2(2): ###
lv2(2):
lv2(2):
lv2(2): Prepare to shutdown .....
lv2(2): Going to shutdown.
system event id=0xe1, rtc=0, size=24 [0x5354523a50415441 0x43303a4361626c65 0x204e6f7420436f6e 0x6e65637400000000]
Click to expand...

@Evilnat
 
I think maybe TID is CEX while your Kernel is DEX. In theory, you need to swap your coreos back to PEX… DEX TID allows both CEX and DEX kernel but CEX TID only works with CEX kernel if my memory serves right. This can be easily tested via lv2 kernel loader feature from Rebug toolbox.
 
Like @Joonie said, your PS3 has TargetID CEX while your kernel is DEX. Rarely the kernel is not changed when converting from DEX to CEX in xai_plugin (if you use the option [Convert to CEX] with DEX kernel). I have updated xai_plugin in my BETA 16 to avoid this kind of failure by adding more checks and security

I want to try to patch it avoiding the console to turn off and the ambulance beep

EDIT: If you have a HW flasher, dump the NAND, open it in HEX viewer and search "lv2Rkernel.self" (look for it twice if needed), rename it to lv2Pkernel.self and copy the dump back to the PS3

It should look like this:

Sin título.png

This will cause the PS3 to load the CEX kernel instead DEX
 
Last edited:
Thanks for chiming in :)
so in theory: if i had the coreos files for a 4.91 PEX i could put them into the extracted NAND backup and rescramble it to a new NAND set?
next question would be....where do i find them files? ;)

because the console still is in ambulance beep mode
 
Pusch3l said:
Thanks for chiming in :)
so in theory: if i had the coreos files for a 4.91 PEX i could put them into the extracted NAND backup and rescramble it to a new NAND set?
next question would be....where do i find them files? ;)

because the console still is in ambulance beep mode
Click to expand...
If the PS3 has my CFW 4.91/.2 PEX or D-PEX installed, the NAND should have both kernels stored in flash. Can you check if you can find "lv2Pkernel.self" or "lv2Rkernel.self" please?
 
@Evilnat : i have the "lv2Rkernel.self" in the ros0_491.000 folder.

i am pretty sure it was a DEX fw installed and not the PEX or D-PEX.
I have a HW-flasher (Teensy), not the fastest but gets the job done
 
thank you very much @Evilnat .
i just missed one little small tiny thing....how do i "rebuild" the files to an interleaved bin-file?
i thought flowrebuilder could do that but no. and it already was 4am so i needed some sleep
 
Pusch3l said:
thank you very much @Evilnat .
i just missed one little small tiny thing....how do i "rebuild" the files to an interleaved bin-file?
i thought flowrebuilder could do that but no. and it already was 4am so i needed some sleep
Click to expand...
If you want, you can send me in a private message your dump and I will patch it for you

You can patch your current IDPS and PSID if you want if you are calmer about your data, later you can repatch it again with the original values
 
Is there any bin as patcher for auto config of ps3 patcher? Wold be cfg and a patch bin but has to be built in a specific order I assume from x address add this length, and so on.
The hardware side we have focused last year in research of a flasher and ways to test in parallel nands (tied to nands on mobo without disassemble every time we want to flash) different flasher, teensy is dang slow(20 minutes) , nand lite flasher open source tested out write well in 4 minutes. Only one working for me is pk 1v1 rebuild but not were to be found or flash rom to be reproduced.
Last I'll build to test will be NANDO open source flasher.
From my perspective same family of Ic as E3 flasher. I assume E3 team could had that nand release but they may encounter same issue with on system read/write.
Not good to program fpga, only way to flash rom into it is to use Microsemi software to remake from scratch those pdb files unprotected.
At least not encrypted with 128 AES.
 
You must log in or register to reply here.

Similar threads

Back
Top