Forums GAMERGEN

Développeur Anonyme Wrote:COBRA 7.00

Hello, I'm Cobra USB main developer. First of all, this is an unofficial personal release from me, and not something from Team Cobra. Don't contact them for anything related with this release.
Second, no, no USB reqired, it can be used by anyone on any hackable ps3. That's why I called this mess of a release COBRA 7.00 and not Cobra USB 7.00.

Why this release ?

Mainly because I can't stand things not done properly. The original source code of Cobra USB 5.X was released, and yes, all PS3 functionality is there, but also a lot of unnecesary things.
Had I been contacted before the release of the source code, I would have prepared something better.
And rather than seeing someone coming with a bad or incomplete release of a CFW or payload using the source, I prefer to lead the way with a first clean release. I don't think I will do any other.

Second, I wanted to have in a CFW both the functionality of Cobra and a regular CFW, and without that slow device delaying each lv2 boot by several seconds, which caused some side effects in version 6.00 (4.30) on pads, and that I had to fix with one of those ugly hacks/incomplete workarounds that I tend to hate.

Lastly, but no less, I was bored, lot of free time lately, that kills your brains...

WHAT IS COBRA 7.00

What is not ? COBRA 7.00 is not a CFW "per se".
COBRA 7.00 is a set of 7 files : lv2_kernel.self, ps2_emu.self, ps2_gxemu.self, ps2_netemu.self, stage2.bin, ps2hwemu_stage2.bin and ps2gxemu_stage2.bin, from those 7, the first 4 are mix of 4.46 CEX OFW files and COBRA code, the others being new and not present in OFW.

Those 7 files are expected to be mixed with existing regular 4.46 CEX based (totally CEX) CFW, to make a CFW that would mainly mix the functionality of both, except for any thing that the regular CFW may do in lv2_kernel.
About "theoretical" compatibility, check the readme in BIN/CFW_BUILDS. Theoretical because only one has been tested. This is, Rogero 4.46 1.00.
A sample PUP of mix of COBRA 7.00 and Rogero 4.46 1.00 is there as well. Mainly included for convenience, for having something end-user friendly.
This CFW has been tested by me on three very different models, a CECHA, a CECHC, and a SLIM.
But because it has only been tested by a single person, caution is to be expected. You are the only responsable of what you install in your machine.

Additionally, there are other parts, like netiso.sprx or cobralib, that are not technically part of COBRA 7.00. They are things expected to be used by managers.
No real change was done to them, just removed something unnecessary in netiso.

There are also some PC tools, the only one relevant to users being ps3netsrv, which has been updated with a new feature (see CHANGELOG).
Although there is no manager that uses that feature atm of writing this.

The source code of components is in SRC folder. The main components of Cobra expect the toolchain found at BSC page, with gcc 4.1.1.
http://www.bsc.es/projects/deepcomputing/linuxoncell/cellsimulator/sdk3.0/CellSDK-Open-Fedora/ -> install all ppu* files for your architecture.

Extra things expect either Sony SDK or psl1ght.
PC tools expect gcc. Some of the tools may not compile under mingw32 or won't work in win32. Some tool could give compilation warnings in 32 bits systems, not compile or binary may not work, this wasn't tested. (watch out ps2netemu_gen446)

WHY 4.46 AND NOT 4.50

1) I had already most symbols from 4.46 from some time ago, lazyness.
2) Because there was no good reason to update to 4.50. COBRA does the sfo version patch and sdk version patch on RAM, games for 4.50 are expected to work without changes.
3) Because new versions of 4.46 CFW's are unlikely to appear, then current release would support almost all of them. Minimal modification on some files causes COBRA not to detect some modules, see the readme in BIN/CFW_BUILDS.
4) An OFW bug causes pad synchronization problems when playing PS2 games in CECHA/CECHB in 4.50. I didn't want this one to be endorsed to me.

INSTRUCTIONS

Install a 4.46 CEX cfw mixed with the 7 files of COBRA 7.00.
A sample of a mix of Rogero 4.46 1.00 and Cobra is provided in BIN/CFW_BUILDS/
Check the txt there for compatibility with other cfw.

Install mmCM_04.18.pkg, which has been included here for convenience (it has only been repackaged to avoid version error with multiman).
This won't delete your current version of multiman (if any), it will instead add mmCM to it.
After installation of this package, multiman can run in two modes, "multiman" and "mmCM", by default it will run in "mmCM" mode under Cobra.
Check CHANGELOW below about how to force COBRA 7.00 to run multiman in "multiman mode", this only makes sense if you installed both, mutiman and mmCM.

CHANGELOG

Changes from Cobra USB 6.0 -> COBRA 7.0 :

Cobra USB device related functions removed. Syscall sys_cobra_usb_command is still there for compatibility reasons, but it will do nothing.

Code cleared from encrypted functions, data and other security measures like the randomization of data or code not longer needed.
Stage 1.5 removed from both, lv2 and ps2emu. There is still a stage 1.5 lan -compiles as stage2.bin-, but that is for developers only.
Stage 1 security garbage removed, now the code can be easily understood
Support for cobra encrypted sprx/self is still kept for compatibility reasons, but security that would protect them from easy methods of dumping has been removed.
drm.c file is still kept for compatibility with already existing compiled versions of netiso.sprx used by mmcm.

(Dirty patch improved)
Text section of vsh.self was made writable by a patch.
This indeed made the memory writable by direct access, but functions like copy_to_user or copy_to_process would still think the section was read only.
The patch has been replaced with a better one that fixes this issue.

PSP mode selection will not longer take effect. Although it was not told to user at that moment, mode 2 made Cobra to use the psp emulator taken from 4.00 OFW (decrypted long ago before keys were released, with a lv2 kernel exploit I discovered) and hidden in the last version of psp launcher.
This made sense for 3.55, since the compatibility of both emu was different (including some regressions in 4.00), but it doesn't makes sense to use 4.00 emulator now.
Maybe it would be a better idea to package the 3.55 one, but not done.
Technical details: cobra syscall sys_psp_set_emu_path will return success, but it will do nothing.

Support for PS2 isos in non BC consoles was removed in 4.30, due to ps2_softemu missing. It has been reenabled now by hacking of ps2_netemu.
You can use it in the same way as before, just load an iso and launch from disc icon, Cobra core takes care of rest.
No need for encrypted isos, isos patched with limg sectors, etc. Just your normal PS2 isos dumped from discs or taken from somewhere.
However, there is no support for optical discs in ps2_netemu. Don't forget to set the memory cards in XMB, in the old memmory card utility for PS/PS2, as ps2_netemu won't let you assign them in game.
BC consoles will still use their respetive emulators (ps2_emu, ps2_gxemu), which have much better compatibilty and also support optical discs, original or backup.

Support for setting fake version was removed in 4.30, since it was permenanetly faked as 4.31. It has been readded, but it will need update on mmcm to use that again.

Cobra USB read its configuration from spi flash. COBRA 7.00 reads it from "/dev_hdd0/vm/cobra_cfg.bin".
When no setting has ever been written, the file will not exist and configuration will have default values. Due to the different timing in which Cobra USB and COBRA 7.00 read the configuration, some others changes in code were needed.

Added partial emulation of READ TRACK INFORMATION command and updated the READ TOC/PMA/ATIP and READ CD commands partial emulation (LV2 only).
This fixes a bug when playing CDDA tracks of psx/ps2 bin/cue images in the XMB player. This didn't happen in 3.55, but Sony changed the code of the audio player at some point after that.

The patches to force XMB load psp launcher, which is a total invalid psp mini package, had some side effects on DRM content, such as ps2 classics.
Now the patches are only done after loading a psp iso, and they will be undone once the manager unloads the psp iso.
Note to users: Don't run any DRM content while there is a psp iso loaded (psp launcher icon not black), it may not work and it may cause the XMB to delete the rif data!

Added support for plugins at boot time. The number of vsh plugins has been increased from 1 to 7. Slot 0 is reserved for use for iso plugins (netiso.sprx and rawseciso.sprx).
Slots 1-6 are for boot plugins.
Plugins are loaded in the following way: text file /dev_hdd0/boot_plugins.txt shall contain a plugin path per line.
Some currently developed plugins like the test one from prxloader don't work (they actually load, but don't work), because they expect that network is already prepared, which is not the case at boot time.
Note for plugin developers: when making a boot plugin for Cobra, if your plugin requires something that is not up yet (like network), just do some waiting at main thread (NEVER in module start, or you'll delay the whole system!), 3 seconds should be enough.
Or just check that network is ready, which is the proper way.

Because of the posibility of a boot plugin crashing the system and causing a pseudo-brick exists, a safety system has been designed:
Enter ps3 recovery mode and select the option "Rebuild database". The recovery process, emer_init.self, will mount dev_hdd0 for a short moment, Cobra core will detect that and it will delete boot_plugins.txt.
Cobra core won't load vsh plugins when there is not VSH: like for example, in recovery and update modes.

Note to developers : please design plugins in such a way that they can be unloaded and they free all resources when that happens.
A sample boot plugin called "testplugin.sprx" is included here. It is a simple plugin that will poweroff the ps3 when L3+R2+X is pressed, or reboot it if L3+R2+O.
Plugin uses an internal vsh function, which does a clean powerroff/reboot, unlike directly calling sys_sm_shutdown.
If you are in a game, enter PS menu to make the combination work.

Added peek, poke, lv1_peek (partial, continue reading), lv1_poke and lv1 call syscalls.
Cobra core wasn't originally developed to coexist with other payloads. As soon as I enabled all these syscalls, a lot of incompatibility problems and payloads and applications destroying some patches that Cobra needs, happened.
So I decided to add a compatibility layer. This is, a custom implementation of all of these syscalls, where Cobra core detects the most common problems.
For example, Iris Manager would temporally load its syscall8, removing the Cobra one. Cobra core is now aware of this, and instead of letting Iris Manager change the syscall address, it concatenates both syscalls: cobra syscall 8 will call Iris syscall 8 when the opcode is not for Cobra.
That was just one of the incompatibilities. Some other incompatibilities have been resolved for the following 3 programs: Iris Manager, Multiman (in multiman mode, see below), and vsh prx loader.
The relevant parts of the compatibility layer are in stage2/main.c
I didn't test all features of those programs, therefore, it is possible that something in them causes problem to Cobra core or that Cobra core causes problems to them.
If you see something odd happening, just reboot the ps3.

After installation of mmCM over Multiman, Multiman will have two modes: "Multiman" and "mmCM".
The first one for regular cfw, the second one for cobra cfw. Multiman detects which cfw is in, and loads the proper self.
Now the problem: when I enabled those syscalls, multiman thought it was in a regular cfw and wouldn't launch mmcm.
So I made a workaround: if multiman is launched from its original location, /dev_hdd0/game/BLES80608/USRDIR/EBOOT.BIN, cobra will block lv2_peek access for the process, to force multiman detect Cobra.
Now, because I also wanted to have a way of launching multiman in its normal mode, there are two ways :
1) Install multiman in a different location (untested). Then, BLES80608 would be mmCM, and the other would be multiman.
2) If L2+cross is kept pressed while launching multiman from BLES80608, Cobra won't block access to lv2_peek, and multiman will load in "multiman mode".
The relevant parts of the code for this are in stage2/modulespatch.c

lv1_peek syscall VS Cobra syscall 8.
Because lv1_peek syscall in lv2 is also syscall 8, the support of Cobra for lv1_peek is partial.
If the address queried is >= 0xA000, Cobra core will do a normal lv1_peek. If its below 0xA000, it will run the specific cobra sub syscall.
Now, this would still cause problems, as some programs -lv1 dumpers- would soon or later crash the system while dumping 0-0xA000, by accidentally calling a Cobra subsyscall.
Cobra core is now aware of this and will temporally block a process from using syscall 8 if it detects it is a possible lv1 dumper, only until some condition is met (like reading from >= 0xA000).

For developers, a proper way to guess if you are in a Cobra cfw is this (if my memory doesn't fail me, this piece of code would work even in Cobra USB 1.0!)

Code: Select All Code

static inline int sys_get_version(uint32_t *version)
{
    system_call_2(8, SYSCALL8_OPCODE_GET_VERSION, (uint64_t)(uint32_t)version);
    return (int)p1;
}

int am_i_in_cobra(void)
{
    uint32_t version = 0x99999999;

    if (sys_get_version(&version) < 0)
        return 0;

    if (version != 0x99999999) // If value changed, it is cobra
        return 1;

    return 0;
}

(Other code changes)
SELF/SPRX patch offsets are now in modulespatch.h instead of modulespatch.c. Also, the self/sprx offsets in storage_ext.c (video mode patch) and psp.c has been moved as well to that file.
There shouldn't be any self/sprx offset/address left that is not in modulespatch.h.
config.ps2softemu set value ignored now. Cobra will always do those patches in non BC consoles.
Added cobra syscall sys_sm_ext_send_poweroff_event, which allows Cobra to send a poweroff/reboot event to VSH (cleaner poweroff than sys_sm_shutdown).
Usage is simple: syscall8(SYSCALL8_OPCODE_SEND_POWEROFF_EVENT, reboot_boolean);
Now pad can be read from kernel mode (lv2/pad.h)
"laboratory.c/h": File unused in compiled version of stage2. It is there just in case someone wants to do tests...

EXTRA things

ps3netserver, the pc server for netiso.sprx, has been updated with support of games in jailbreak directory format, so it is not longer restricted to isos.
Bad thing is that there is currently no program using this feature, just wait for someone to do it.

For developers, usage of this new feature is amazingly easy, as it is all done at server side. No new opcode added, no change of netiso.sprx was needed at all.
If in the remote server you have a game in jailbreak directory format whose path is "/GAMES/BLES00635", just pass this path to netiso.sprx instead: /***PS3***/GAMES/BLES00635"
And thats it. Upon receiving the open command from netiso, the server will understand the path, and it will create a "virtual iso", this is, it will scan the directory /GAMES/BLES00635, and it will build in RAM the structure of the iso9660 and joliet filesystems.
For the client side, the folder would be just like another PS3 iso file.

For no-ps3 content, you can use "/***DVD***/". For example, for remote PC directory "/my_dvd_video", just pass "/***DVD***/my_dvd_video".
Note that no UDF FS is created, therefore this woudn't be apropiated for blu ray video content iirc.

Limitations :
1) if the folder has way too many files, the server will need sometime to scan the full content and build the virtual iso.
The time is only proportional to the number of directories and files, not the actual size of the game.
You should be aware of this, and that netiso may take its time in mounting the game in those cases.
2) Only the open command is aware of /***PS3***/ and /***DVD***/. All other commands that pass a path are not. That includes the stat command, which would be the only other one that makes sense to have this for.


ntfs_ext_iso.self and rawseciso.sprx

Recently developer Estwald ported libntfs to the ps3 (good job!). Inmediatelly, it came to my mind, that mixing that and Cobra sys_storage_ext_mount_discfile_proxy would lead to inmediate support of ps3, psx, dvd and bd isos in ntfs volumes.
libntfs_ext was modified to add a new function "ps3ntfs_file_to_sectors". This function will locate all the sectors sections ("parts") of a file in the disk.
The modified source code of libtntfs_ext is at /SRC/EXTRA/libntfs_ext. Changes are explained in "Changes (COBRA).txt"

ntfs_ext_iso is a program that is expected to be launched by another program, it is not a standalone program, it doesn't show any gui (it only prints to stdout), you will have to wait for someone to make such app.
ntfs_ext_iso expects three params (third is optional): 1) path of iso within the ntfs volume. 2) One of "EMU_PS3", "EMU_PSX", "EMU_BD", "EMU_DVD". 3) An optional cue path for psx games. If no cue is passed for psx game or if cue can't be parsed, a single data track is assumed.

Example usages :

Code: Select All Code

char *argv[3];

argv[0] = malloc(N);
strcpy(argv[0], "/******/tequen6.iso");
argv[1] = malloc(8);
strcpy(argv[1], "EMU_PS3");
argv[2] = NULL;

sysProcessExitSpawn2(ntfs_ext_iso_self_path, (const char**) argv, NULL, NULL, 0, 1001, SYS_PROCESS_SPAWN_STACK_SIZE_1M);

char *argv[4];

argv[0] = malloc(N);
strcpy(argv[0], "/PSXISO/Last Fantasy VII.bin");
argv[1] = malloc(8);
strcpy(argv[1], "EMU_PSX");
argv[2] = malloc(N);
strcpy(argv[2], "/PSXISO/Last Fantasy VII.cue");
argv[3] = NULL;

sysProcessExitSpawn2(ntfs_ext_iso_self_path, (const char**) argv, NULL, NULL, 0, 1001, SYS_PROCESS_SPAWN_STACK_SIZE_1M);

rawseciso.sprx file must be put in same directory that ntfs_ext_iso.self

Explanation of how it works: using the modified libntfs_ext, the program will scan all usb devices. When a ntfs volume is found, it will check if the iso file exists, and get all disk sector regions of it. It will pass these regions to the iso vsh plugin rawseciso.sprx.
rawseciso.sprx will use Cobra sys_storage_ext_mount_discfile_proxy functions to request that all disc reads are passed to it.
rawseciso.sprx will feed the kernel with the iso data by rawly accesing the external storage device.
rawseciso.sprx itself is totally fs-agnostic, it just reads raw sectors. It is ntfs_ext_iso.self which tells him where the iso file is.

Limitations : although libntfs_ext supports ext2/3/4 partitions, I only added the file_to_sectors functions to the ntfs code, so this won't work on said partitions.
If the file has more than 8188 fragments (that's a heavy fragmentation), this thing won't work. Defragment the file or the whole partition in those cases.
Drives with more than 2TB: if the parts of the files goes over 2TB offset, this won't work.
rawseciso is not optimized, maybe it would have been a better idea to implement it in core, but I didn't plan this feature at the beginning, it was just a test.

KNOWN PROBLEMS

The PSX video problem. When the psx emulator is launched "naturally" by vsh.self, it sets the video mode parameters. This would cause NTSC games work badly on PAL, and viceversa.
But COBRA does a patch to avoid that, by forcing the video mode to be the same of the current psx game. Now the problem: in 3.55 this worked OK for everyone. But in 4.30, a tester and some users reported problems.
The patch still works for me though. The tester and me had same ps3 models, I used his xRegistry.sys file for testing, and yet I couldn't reproduce the issue. Only thing different was the TV...
Homebrew that launch directly PSX games don't suffer this problem, because this problem is caused by vsh. But mmCM returns to XMB after mounting a PSX iso game.

Sometimes, PSX CD-R and PS2 CD-R/DVD+-R are not detected by Cobra. This happens mainly on bad media and bad drives. Try to reboot with the disc inside, it may be detected.

To mix COBRA 7.00 with a 4.46 CEX CFW, replace/add the 7 following files :

CORE_OS_PACKAGE: lv2_kernel.self (replace)
/dev_flash/ps2emu/ps2_emu.self (replace)
/dev_flash/ps2emu/ps2_gxemu.self (replace)
/dev_flash/ps2emu/ps2_netemu.self (replace)
/dev_flash/sys/stage2.bin (add)
/dev_flash/ps2emu/ps2hwemu_stage2.bin (add)
/dev_flash/ps2emu/ps2gxemu_stage2.bin (add)


COMPATIBILITY TESTED

Rogero 1.00, sample pup provided.

Rogero 1.01. Known problems :
1) psp games won't work. This is a bug that happens in unmodified Rogero 1.01 too.
For reasons I didn't check, all modules in /dev_flash/pspemu/release return a 8001006 when being loaded by psp_emulator.self.
2) The added program at "/dev_flash/pkg/" won't appear at app_home with Cobra, because that redirection is provided by Rogero 1.01 lv2_kernel.self
To mimic that with Cobra, change the following line in source code:
map_path("/app_home", "/dev_usb000", 0); -> map_path("/app_home", "/dev_flash/pkg", 0);
The redirection would be destroyed by cobralib used by mmCM, anyways.

UNTESTED, *Theoretical compatibility*

HABIB 4.46 v1.13
LDZ FERROX 4.46
ARCH 4.46 CFW Build AO1

WILL NOT WORK / REQUIRES PORTING

CFW that have DEX modules like Rogero. They need a specific port.
If lv2_kernel is CEX one, lv2/symbols.h doesn't need update, and would only require changes in stage2/modulespatch.h.

ABOUT THEORETICAL COMPATIBILITY

I just made sure that the modified files of those firmwares would be detected by Cobra (stage/modulespatch.h, see 4_46 hashes).
I didn't do any test and I didn't check the required lv1 patches.

LV1 patches needed by COBRA 7.00:
1) lv2_kernel protection removed. Severity: MANDATORY.
2) Lv1 peek/poke. Needed for the patch for PS2 optical discs and for lv1_peek/poke in lv2. Severity: OPTIONAL, without this, only those features will be affected.

If one of the CFW in the UNTESTED list happened not to do the lv2_kernel patch, they would lead to a very likely brick when mixing with COBRA 7.00.


HOW TO PORT TO OTHER CFW 4.46 CEX BASED:

Almost all CFW patch the following files statically:

/dev_flash/vsh/module/vsh.self
/dev_flash/vsh/module/basic_plugins.sprx
/dev_flash/vsh/module/nas_plugin.sprx
/dev_flash/vsh/module/explore_plugin.sprx
/dev_flash/vsh/module/explore_category_game.sprx



COBRA dinamically patches those and also:


/dev_flash/vsh/module/bdp_discheck_plugin.sprx
/dev_flash/vsh/module/game_ext_plugin.sprx
/dev_flash/ps1emu/ps1_emu.self
/dev_flash/ps1_netemu.self
/dev_flash/pspemu/psp_emulator.self
/dev_flash/pspemu/release/emulator_api.sprx
/dev_flash/pspemu/release/emulator_drm.sprx
/dev_flash/pspemu/release/PEmuCoreLib.sprx
/dev_flash/sys/external/libsysutil_savedata_psp.sprx
/dev_flash/sys/external/libfs.sprx



When porting to a new CFW based on same OFW, you need to check the 64 bits hashes of these files.
To calculate those hashes, use the tool at /SRC/PC/hashcalc
These 64 bits hashes are a reminiscence from psjailbreak times. They are not secure hashes, and some different files may have same hash.
But I actually like the fact that almost identical files will have identical or almost identical hashes.
After checking the hashes, check if they are in the 4.46 section of modulespatch.h
If they all are, the CFW should be working, providing that the lv1 requirements are met.
If one or more are missing, create a name for your hash, and add an entry in the patch table in modulespatch.c. Also, add to hash_to_name function.
Check if there are more references to the base hash inside modulespatch.c, which is the case for basic_plugins and emulator_drm and add your hash to the "if" if required.
(Note: now that I'm checking the file, I saw that I forgot to add BASIC_PLUGINS_ROG_HASH to an if sentence in line 793, but since psp_emulator redirection was disabled in psp.c, it doesn't have any impact in functionality)


4.50 / DEX / ANY FUTURE VERSION :

The very basic thing to do before anything else is to add ALL the 4.50 kernel symbols to lv2/symbols.
Check the ones of 4.46 as base. The file still has symbols from old versions, but only 4.46 section has all symbols required for COBRA 7.00 (plus some unused)

stage0 and stage1 Makefiles need changes in offsets/adddress.
lv2gen446: change the call to "scetool.exe" to include the correct parameters for your firmware version.
stage2/modulepatch.c/h: add the offsets and hashes of user modules patches.
ps2: changes to ps2/symbols.h, ps2emu_stage1_file start.S and Makefiles, ps2emu_gen446/main.c, ps2emu_stage2/hwwemu (main.c, restore.h and maybe ldscript.ld, check read!!!.txt file), ps2emu_stage2/gxemu (same as previous), ps2emu_stage2/netemu (main.c, ldsscript), ps2emu_stage2/ps2netemu_gen446/main.c

And that's more or less for a proper full port, I may have forgotten some file. Change the defined firmware version in all Makefiles too.

The cheap way of porting: as lv2_kernel and ps2emus don't usualy have significant changes, you may feel tempted to only port modulespatch and use the 4.46 based lv2_kernel/ps2emus of this release, with maybe, only a resign.
Well, I don't know if this would work, I have never done a mix of firmwares like that. Maybe it woud require some additional patch, maybe not.
It could break some homebrew too, that depends of how some howmebrews detect the firmware.
In the case of ps2emu, doing something cheap like this can be justified if the person doing the port doesn't have the specific model for one or more of the emulators.