4.84 Custom Firmware (CEX/DEX/REX/noBD/Dualboot)

4.84 CFW / Homebrew / Plugins / Tools

Overview Extra info Reviews (1) Discussion
Joonie said:
@littlebalup I think I got it. I force enabled condition_softemu (because I have BC console) and added following in sysmbol.h

Code: 
/* rebug */
#define EXPLORE_PLUGIN_REBUG_HASH                   0xACF4AF2B000ECC91
#define EXPLORE_CATEGORY_GAME_REBUG_HASH            0x9CB3396E00056CE9
#define GAME_EXT_PLUGIN_REBUG_HASH                  0xE274AF7B0001E5D3
#define dex_ps2_nonbw_offset                        0xDDDC4
#define dex_ps2_nonbw_offset2                       0x68264
#define dex_ps2_nonbw_offset3                       0x172F0
#define dex_ps2tonet_patch                          0xCA380
#define dex_ps2tonet_size_patch                     0xCA374
Click to expand...

in fact only 'REBUG' hashes are necessary:
Code: 
/* rebug */
#define EXPLORE_PLUGIN_REBUG_HASH                   0xACF4AF2B000ECC91
#define EXPLORE_CATEGORY_GAME_REBUG_HASH            0x9CB3396E00056CE9
#define GAME_EXT_PLUGIN_REBUG_HASH                  0xE274AF7B0001E5D3
that's ok (tested)

see modulespatch.c :
Code: 
PatchTableEntry patch_table[] =
{
    { LIBFS_EXTERNAL_HASH, libfs_external_patches },
#ifdef DO_PATCH_PSP
    { PSP_EMULATOR_HASH, psp_emulator_patches },
    { EMULATOR_API_HASH, emulator_api_patches },
    { PEMUCORELIB_HASH, pemucorelib_patches },
    { LIBSYSUTIL_SAVEDATA_PSP_HASH, libsysutil_savedata_psp_patches },
#endif
#ifdef DO_PATCH_PS2
    { EXPLORE_PLUGIN_HASH, explore_plugin_patches },
    { EXPLORE_CATEGORY_GAME_HASH, explore_category_game_patches },
    { GAME_EXT_PLUGIN_HASH, game_ext_plugin_patches },
#endif
};

PatchTableEntry patch_table_rebug[] =
{
    { LIBFS_EXTERNAL_HASH, libfs_external_patches },
#ifdef DO_PATCH_PSP
    { PSP_EMULATOR_HASH, psp_emulator_patches },
    { EMULATOR_API_HASH, emulator_api_patches },
    { PEMUCORELIB_HASH, pemucorelib_patches },
    { LIBSYSUTIL_SAVEDATA_PSP_HASH, libsysutil_savedata_psp_patches },
#endif
#ifdef DO_PATCH_PS2
#ifdef EXPLORE_PLUGIN_REBUG_HASH
    { EXPLORE_PLUGIN_REBUG_HASH, rebug_explore_plugin_patches },
    { EXPLORE_CATEGORY_GAME_REBUG_HASH, rebug_explore_category_game_patches },
    { GAME_EXT_PLUGIN_REBUG_HASH, rebug_game_ext_plugin_patches },
#endif
#endif
};

and :
Code: 
    if(vsh_type != 0x666)
       memcpy(patch_table, patch_table_rebug, sizeof(patch_table));
So, if 'REBUG' hashes are not defined, they are not be copied in the patch_table... so thay are missing.
That piece of code should be improved.

Edit:
That should do the job without to add anything else to symbols.h :
Code: 
PatchTableEntry patch_table_rebug[] =
{
    { LIBFS_EXTERNAL_HASH, libfs_external_patches },
#ifdef DO_PATCH_PSP
    { PSP_EMULATOR_HASH, psp_emulator_patches },
    { EMULATOR_API_HASH, emulator_api_patches },
    { PEMUCORELIB_HASH, pemucorelib_patches },
    { LIBSYSUTIL_SAVEDATA_PSP_HASH, libsysutil_savedata_psp_patches },
#endif
#ifdef DO_PATCH_PS2
#ifdef EXPLORE_PLUGIN_REBUG_HASH
    { EXPLORE_PLUGIN_REBUG_HASH, rebug_explore_plugin_patches },
    { EXPLORE_CATEGORY_GAME_REBUG_HASH, rebug_explore_category_game_patches },
    { GAME_EXT_PLUGIN_REBUG_HASH, rebug_game_ext_plugin_patches },
#else
    { EXPLORE_PLUGIN_HASH, explore_plugin_patches },
    { EXPLORE_CATEGORY_GAME_HASH, explore_category_game_patches },
    { GAME_EXT_PLUGIN_HASH, game_ext_plugin_patches },
#endif
#endif
};
 
Last edited:
@Zar do you think you can fix the bug for vmode? it doesn't get correct vsh offset unlike psp and ps2.

Code: 
static INLINE void do_video_mode_patch(void)
{
uint64_t vm_patch_off = vmode_patch_offset;
if(vsh_type == 0xCE)
{
//REBUG REX lv2 DEX and vsh CEX
#ifdef cex_vmode_patch_offset
vm_patch_off = cex_vmode_patch_offset;
#endif
}
else if(vsh_type == 0xDE)
{
//REBUG REX lv2 CEX and vsh DEX
#ifdef dex_vmode_patch_offset
vm_patch_off = dex_vmode_patch_offset;
#endif
}
if(vm_patch_off == 0) return;
process_t p = get_current_process_critical();
if (!vsh_process) vsh_process = get_vsh_process(); //NzV
    if(!vsh_process) return;
if (p == vsh_process)
{
uint32_t patch = 0;
if (effective_disctype == DEVICE_TYPE_PSX_CD)
{
if (video_mode != 2)
{
int ret = get_psx_video_mode();
if (ret >= 0)
video_mode = ret;
}
}
else
{
if (video_mode >= 0)
video_mode = -1;
}
if (video_mode >= 0)
{
if (video_mode < 2)
{
patch = LI(R0, video_mode);
video_mode = 2;
}
}
else if (video_mode == -1)
{
patch = LWZ(R0, 0x74, SP);
video_mode = -2;
}
if (patch != 0)
{
if(vm_patch_off) // prevent undefined vmode_patch_offset
{
DPRINTF("Patching Video mode in  VSH..\n");
copy_to_user(&patch, (void *)(&vm_patch_off+0x10000), 4);
DPRINTF("Offset: 0x%08X | Data: 0x%08X\n", (uint32_t)vm_patch_off, (uint32_t)patch);
}
}
}
}
 
hmm I don't see any mistake, in the function.
Do you think the offset found by offsetfinder is wrong?
 
Last edited:
Zar said:
hmm I don't see any mistake, in the function.
Do you think the offset found by offsetfinder is wrong?
Click to expand...

No, offset is correct for elf, but the vsh offset in memory changes like PS2 and PSP ones.

And it doesn't calculate the memory offset for vmode code.
 
I wrote it to search the offset only once.
Do you think it can move ? if yes, i'll have to modify the function to bruteforce it everytime the function is called.

anywayt here it is :

Code: 
int64_t vm_patch_off = -1;
static INLINE void get_vmode_patch()
{
    if(vm_patch_off != -1) return
    
    #ifdef DEBUG
    DPRINTF("[VIDEO MODE] Trying to find patche offset...\n");
    #endif
    
    vm_patch_off = vmode_patch_offset;
    uint64_t i;
    uint64_t mv_offset;
    uint64_t adrr;
    
    if(vsh_type == 0xCE)
    {
        //REBUG REX lv2 DEX and vsh CEX
        #ifdef cex_vmode_patch_offset
        vm_patch_off = cex_vmode_patch_offset;
        #endif
    }
    else if(vsh_type == 0xDE)
    {
        //REBUG REX lv2 CEX and vsh DEX
        #ifdef dex_vmode_patch_offset
        vm_patch_off = dex_vmode_patch_offset;
        #endif
    }
    
    //First try with static offset..
    addr = (vsh_offset + vm_patch_off);
    for(mv_offset = 0; mv_offset < 0x2000000; mv_offset += 0x100000)
    {
    
        if(lv1_peekd(addr + mv_offset) == 0x800100742F800000ULL || // LWZ(R0, 0x74, SP)
           lv1_peekd(addr + mv_offset) == 0x380000002F800000ULL || // LI(R0, 0)
           lv1_peekd(addr + mv_offset) == 0x380000002F800000ULL  ) // LI(R0, 1)
        {
            if(lv1_peekd(addr + mv_offset + 0x20) == 0x386100704800651DULL)
            {
                #ifdef DEBUG
                DPRINTF("[VIDEO MODE] vmode_patch_offset found with static offset at address: 0x%lx\n", addr + mv_offset);#endif
                #endif
                return vm_patch_off;
            }
        }
    }
    
    //brute-force
    mv_offset = (vsh_offset + 0x700);
    for(i = 0; i < 0x2000000; i += 4)
    {
        if(lv1_peekd(mv_offset + i) == 0x800100742F800000ULL || // LWZ(R0, 0x74, SP)
           lv1_peekd(mv_offset + i) == 0x380000002F800000ULL || // LI(R0, 0)
           lv1_peekd(mv_offset + i) == 0x380000002F800000ULL  ) // LI(R0, 1)
        {
            if(lv1_peekd(mv_offset + i + 0x20) == 0x386100704800651DULL)
            {
                #ifdef DEBUG
                DPRINTF("[VIDEO MODE] vmode_patch_offset found with brute-force at address 0x%lx\n", i);
                #endif
                return i;
            }
        }
    }
    
    #ifdef DEBUG
    DPRINTF("[VIDEO MODE] Failed to find patche offset.\n");
    #endif
}

static INLINE void do_video_mode_patch(void)
{
    get_vmode_patch();
        
    if(vm_patch_off == 0) return;
    
    process_t p = get_current_process_critical();

    if (!vsh_process) vsh_process = get_vsh_process(); //NzV
    if(!vsh_process) return;

    if (p == vsh_process)
    {
        uint32_t patch = 0;

        if (effective_disctype == DEVICE_TYPE_PSX_CD)
        {
            if (video_mode != 2)
            {
                int ret = get_psx_video_mode();
                if (ret >= 0)
                    video_mode = ret;
            }
        }
        else
        {
            if (video_mode >= 0)
                video_mode = -1;
        }

        if (video_mode >= 0)
        {
            if (video_mode < 2)
            {
                patch = LI(R0, video_mode);
                video_mode = 2;
            }
        }
        else if (video_mode == -1)
        {
            patch = LWZ(R0, 0x74, SP);
            video_mode = -2;
        }

        if (patch != 0)
        {
            if(vm_patch_off) // prevent undefined vmode_patch_offset
            {
                copy_to_user(&patch, (void *)(&vm_patch_off+0x10000), 4);
            }
        }
    }
}
 
Zar said:
I wrote it to search the offset only once.
Do you think it can move ? if yes, i'll have to modify the function to bruteforce it everytime the function is called.
Click to expand...

There are only two noticeable VSH offsets (0x510000 and 0x910000) apart from those, I can't think of anywhere else. I'll try your changes :)
 
Joonie said:
@Zar @littlebalup I did some testing with Ben a bit.. and managed to patch vmode offset in ram. however it just doesn't change the refresh rate..

Here's the tested code.

https://pastebin.com/Mv9DLbpm
Click to expand...

Thanks. However I'll not be able to test or code this weekend.

Zar said:
nice catch.

so, the good fix is probably :
Code: 
if(vsh_type == 0xCE)
       memcpy(patch_table, patch_table_rebug, sizeof(patch_table));
Click to expand...

Note this doen't work in D-REX with CEX VSH.
 
littlebalup said:
Note this doen't work in D-REX with CEX VSH.
Click to expand...
Yeah, I messed up lv2 and vsh... sry. Rebug is always using DEX modules. So, the question is : "are we in REBUG CEX ? if yes use DEX hashes. So, I think your fix is best one.

Are we in REBUG ?
if(vsh_type != 0x666) memcpy(patch_table, patch_table_rebug, sizeof(patch_table));
Click to expand...

Is it CEX or DEX ?
Code: 
PatchTableEntry patch_table_rebug[] =
{
    { LIBFS_EXTERNAL_HASH, libfs_external_patches },
#ifdef DO_PATCH_PSP
    { PSP_EMULATOR_HASH, psp_emulator_patches },
    { EMULATOR_API_HASH, emulator_api_patches },
    { PEMUCORELIB_HASH, pemucorelib_patches },
    { LIBSYSUTIL_SAVEDATA_PSP_HASH, libsysutil_savedata_psp_patches },
#endif
#ifdef DO_PATCH_PS2
#ifdef EXPLORE_PLUGIN_REBUG_HASH
    { EXPLORE_PLUGIN_REBUG_HASH, rebug_explore_plugin_patches },
#else
    { EXPLORE_PLUGIN_HASH, explore_plugin_patches },
#endif
#ifdef EXPLORE_CATEGORY_GAME_REBUG_HASH
    { EXPLORE_CATEGORY_GAME_REBUG_HASH, rebug_explore_category_game_patches },
#else
    { EXPLORE_CATEGORY_GAME_HASH, explore_category_game_patches },
#endif
#ifdef GAME_EXT_PLUGIN_REBUG_HASH
    { GAME_EXT_PLUGIN_REBUG_HASH, rebug_game_ext_plugin_patches },
#else
    { GAME_EXT_PLUGIN_HASH, game_ext_plugin_patches },
#endif
#endif
};


Joonie said:
@Zar @littlebalup I did some testing with Ben a bit.. and managed to patch vmode offset in ram. however it just doesn't change the refresh rate..

Here's the tested code.

https://pastebin.com/Mv9DLbpm
Click to expand...

I'm not sure if I understand, it found the offset, but the rest of the code isn't working ?
 
Zar said:
I'm not sure if I understand, it found the offset, but the rest of the code isn't working ?
Click to expand...
It gets vsh offset and find the correct vmode offset for patching, and it patches when mounting PSX ISO. however when it runs PSX game it doesn't swap refresh rate to 50hz when playing PAL game on my unit.

This works fine on COBRA without changing any code. But MAMBA patches the static offset that was defined for vsh.elf not in ram. So that's why we did this method to get the vsh offset in ram to apply the patch in the correct spot which doesn't seem to be working.
 
Friends, please help. I have a console CECHK Fat 80 GB and used PS3Xploit and install CFW Rebug 4.82. Now i want to go back to OFW, and read about Dualboot 4.84. Tell me please, what version of the firmware should I install? 4.84 Littlebalup Dualboot Edition or 4.84 Overflow Dualboot Edition?
And please tell me, if in the future I need to return to CFW, then i just need to put CFW 4.84 on it, and then, if I want to go back to OFW, i should install OFW 4.84 Dualboot again?
And yet, please tell me about the advantages of Dualboot firmware, how to use it properly, and what functions to use so as not to get a ban for playing a purchased game on disk, or in the PS Store?

Thank you!
 
dualboot function is to eaisly go back to cfw at any time without a hardware flasher just a CFW PUP just activate qa flag in rebug toolbox that is installed in your ps3 install any Dualboot both are the same Dualboot is like a OFW with the ability to go back to CFW created for users who wants to play online safly but no 100% safty for ban remember that then when you want to go back to cfw just put any 4.84 cfw rebug,ferrox,overflow and let it install
 
BPS said:
Friends, please help. I have a console CECHK Fat 80 GB and used PS3Xploit and install CFW Rebug 4.82. Now i want to go back to OFW, and read about Dualboot 4.84. Tell me please, what version of the firmware should I install? 4.84 Littlebalup Dualboot Edition or 4.84 Overflow Dualboot Edition?
And please tell me, if in the future I need to return to CFW, then i just need to put CFW 4.84 on it, and then, if I want to go back to OFW, i should install OFW 4.84 Dualboot again?
And yet, please tell me about the advantages of Dualboot firmware, how to use it properly, and what functions to use so as not to get a ban for playing a purchased game on disk, or in the PS Store?

Thank you!
Click to expand...

Dualboot is a Firmware (for CFW users only) that has very small changes it will act and behave as an Official Firmware would. The only ability it has that you can install/return a CFW at anytime. Which gives us a few uses as CFW user's .

So the purpose is so user's can play their disc games without a risk of a ban when connected to PSN. As the functions of the FW are the same as OFW and the change is very small to simply allow a CFW PUP to be installed over the top. So you can regain CFW abilities.

You do not have to Q/A flag your console (but not a bad thing to do) if you do not want to its not required for this, what you need to do is just install the same version (or higher if ones exist) of CFW (4.84, 4.83 ect..) as the dualboot version you have installed
So if you use 4.84 Littlebalup Dualboot, over the top you would have to install any 4.84 CFW PUP over the top WHEN you want to return to CFW and then when you want to be safer on PSN and reduce ban risk dramatically. reverse the process and install the highest version of Dualboot (currently 4.84) when you connect to PSN or play your disc games on PSN

Also you can choose to stay on CFW and boot to PSN and use apps that disable CFW syscalls (a temporary disabling of CFW until the console next boot). also has been thought to reduce bans also, but the dualboot way is for sure a good way and maybe the best way to stay away from a ban, personally i take the risk and just disable cfw syscalls because i respect the network and use it as i would an unmodded console and i have not had a ban myself but i have heard of many being banned and with bans there is so many unknowns so that is what makes dualboot firmware a great option
 
Last edited:
STLcardsWS said:
The purpose of a dualboot firmware?
Its a Firmware (for CFW users only) that has very small changes it will act and behave as an Official Firmware would. The only ability it has that you can install/return a CFW at anytime. Which gives us a few uses as CFW user's if we want a safer PSN experience by reduce a ban risk dramatically.

So the purpose is so user can play their disc games without a risk of a ban when on PSN. As the functions of the FW are the same and the change to allow a CFW PUP to be installed over the top

You do not have to Q/A flag your console if you do not want to its not required for this, what you need to do is install the same version (or higher if ones exist) of CFW (4.84, 4.83 ect..) as the dualboot version you have installed
So if you use 4.84 Littlebalup Dualboot, over the top you would have to install any 4.84 CFW PUP over the top WHEN you want to return to CFW and then when you want to be safer on PSN and reduce ban risk dramatically. reverse the process and install the highest version of Dualboot (currently 4.84) when you connect to PSN or play your disc games on PSN
Click to expand...

Thank you for your answer, I don't understand some things which you say's to me (English not my main language, and i'm not a technician). But i would like to know, why i shouldn't install 4.84 Overflow Dualboot Edition, and install 4.84 Littlebalup Dualboot instead? And tell me please, how install this dualboot OFW? Like other firmwares? Create PS3/UPDATE folder on usb stick and e.t.c?
 
BPS said:
Thank you for your answer, I don't understand some things which you say's to me (English not my main language, and i'm not a technician). But i would like to know, why i shouldn't install 4.84 Overflow Dualboot Edition, and install 4.84 Littlebalup Dualboot instead? And tell me please, how install this dualboot OFW? Like other firmwares? Create PS3/UPDATE folder on usb stick and e.t.c?
Click to expand...

Either one should work fine, but personally i know liitlebalup work a little better.
Overflow last DB was flawed i think it was simple oversight but still something to consider when there is a choice. .

Install it the same way as any PUP file from USB Storage
 
You must log in or register to reply here.

Similar threads

Back
Top