I think my google and ps3devwiki searching skills are failing, but I just can't seem to find much posted information about the changes added between previous DEX versions, that could be installed no problem on converted consoles, and DEX 4.30 (and higher) that while they install fine, result in 3 beeps and flashing red light. There is information out there, but it seems to be in bits and pieces.
I know that one of the major "issues" with the CEX to DEX conversions is that we are only changing the IDPS in EID1, and not EID5. Also, on converted units the flags for FSELF Control Flag & Debug Support Flags aren't set, though it doesn't seem there are checks on it. I also remember reading something from Naehrwert, stating there was a check on lv1ldr, that will trigger a panic, and its just not feasible to "generate" the correct data. It also confuses me a bit in how each EID section is decrypted, since EID1 for example, is decrypted with different algorithms and different keys, for each section.
I didn't want to bother @euss or naehrwert with questions. I'm basically trying to figure out all of the checks added between 4.20 (technically 4.25) and 4.30, that cause converted units to brick.
Was the only check added was to see if the target ID was changed in EID5, or what was added between the firmware revisions to prevent the update? And I assume it is just like a regular brick, but a regular progskeet/e3 flasher could successfully revert a converted unit from 4.30 dex back to 4.20, right? I don't possibly see a reason why not, but figured it's worth asking because I couldn't seem to find a post with anyone doing it.
I know that one of the major "issues" with the CEX to DEX conversions is that we are only changing the IDPS in EID1, and not EID5. Also, on converted units the flags for FSELF Control Flag & Debug Support Flags aren't set, though it doesn't seem there are checks on it. I also remember reading something from Naehrwert, stating there was a check on lv1ldr, that will trigger a panic, and its just not feasible to "generate" the correct data. It also confuses me a bit in how each EID section is decrypted, since EID1 for example, is decrypted with different algorithms and different keys, for each section.
I didn't want to bother @euss or naehrwert with questions. I'm basically trying to figure out all of the checks added between 4.20 (technically 4.25) and 4.30, that cause converted units to brick.
Was the only check added was to see if the target ID was changed in EID5, or what was added between the firmware revisions to prevent the update? And I assume it is just like a regular brick, but a regular progskeet/e3 flasher could successfully revert a converted unit from 4.30 dex back to 4.20, right? I don't possibly see a reason why not, but figured it's worth asking because I couldn't seem to find a post with anyone doing it.