Mamba Loader (+AutoLoader)

Merci :)

I have fixed this error and updated my git again now MAMBA has support for NetIso on all CFW (it will patch user_thread_prio_patch when it was loaded like COBRA does) and also if want you can now build MAMBA "DEBUG" (buildtype set to debug instead of release in makefile) for all cfw too.

I will updated Loader and Autoloader with the New MAMBA right now, i thinks this time MAMBA is really COBRA LITE (no ps2, no psp support but support all ps3 features like cobra) nothing more need to be add i think.

There is still something that I would like to add, but it is on the server side of netiso (but I don't have the tools to compile the project)...
Recently I added support to Cobra/Mamba for more CD sector sizes (2048/2336/2352/2448).. they work for hdd0/usb and ntfs, but not for netiso due the server need to be updated.
webMAN can detect the sector size and pass it to the server, but the server don't use it and always assume that the CD sector size is 2352.

Here is the project with my modification.
https://www.sendspace.com/file/i2ujhl

My change was very simple: in the function process_read_cd_2048_critical_cmd it uses the custom CD sector size received from webMAN through the unused variable "cmd->pad":
Code:
	uint32_t CD_SECTOR_SIZE_2352 = 2352;

	if(cmd->pad>0xFF) CD_SECTOR_SIZE_2352 = BE32(cmd->pad);

What I need is to compile it this project to make some tests with webMAN... It would be appreciated if some dev could help me with this.
 
There is still something that I would like to add, but it is on the server side of netiso (but I don't have the tools to compile the project)...
Recently I added support to Cobra/Mamba for more CD sector sizes (2048/2336/2352/2448).. they work for hdd0/usb and ntfs, but not for netiso due the server need to be updated.
webMAN can detect the sector size and pass it to the server, but the server don't use it and always assume that the CD sector size is 2352.

Here is the project with my modification.
https://www.sendspace.com/file/i2ujhl

My change was very simple: in the function process_read_cd_2048_critical_cmd it uses the custom CD sector size received from webMAN through the unused variable "cmd->pad":
Code:
	uint32_t CD_SECTOR_SIZE_2352 = 2352;

	if(cmd->pad>0xFF) CD_SECTOR_SIZE_2352 = BE32(cmd->pad);

What I need is to compile it this project to make some tests with webMAN... It would be appreciated if some dev could help me with this.

I have tried but i always get an error at end (same with original files and your mod)

ps3netsrv.jpg
 
[MENTION=89]aldostools[/MENTION] Compile fine with deank modification, some errors on yours.

OS = windows
BUILD_TYPE = release_static

868437Capture.png
 
Last edited:
[MENTION=89]aldostools[/MENTION] Compile fine with deank modification, some errors on your.


Thanks! Joonie managed to compile it, but for some reason the changes that I did didn't work... so I removed all the code about custom CD sector size for ps3netsvr.

Anyway it is working fine for NTFS, internal HDD and USB.
 
arf :banghead:
ok fine so without network :/

Edit: Anyway [MENTION=89]aldostools[/MENTION] i just saw % is missing in record function
https://github.com/aldostools/webMAN-MOD/blob/master/main.c#L2792

also https://github.com/aldostools/webMAN-MOD/blob/master/main.c#L6277
why IDPS[6]? leaves as before 1 instead 6 displayed idps is wrong now in cpursx.ps3 :/

The lack of custom CD sector size for network should not be big deal... The standard sector size is 2352 for CD, so the change was only for non standard images. They can be played fine locally.

Thanks for the 2 reports. They are typos in the code... I'll post the fix to github in a while.

EDIT:
Updated github and uploaded a test build
 
MAMBA will now support mmCM like COBRA does :) (MAMBA updated on github, i will updated loader and autoloader later).
This time its really done with it i think ^^
 
MAMBA will now support mmCM like COBRA does :) (MAMBA updated on github, i will updated loader and autoloader later).
This time its really done with it i think ^^
If you accept more suggestions before the release, personally i think the name is very confusing, i been reading several of your threads related with it days ago and i dont even know how many different names it had in the previous mutations (is confusing, at least for me)

Now that it seems the project is close to the final concept of how it will work you could use a more simple name that identifyes it better, like dunno... other snake specie... or "mamba core"... etc... but something simple

Edit:
Here are some ideas :)
List of snakes by common name - Wikipedia, the free encyclopedia
 
Last edited:
Black Mamba
wallpaper-di-uma-thurman-che-interpreta-black-mamba-di-kill-bill-volume-1-116565.jpg
 

Attachments

  • wallpaper-di-uma-thurman-che-interpreta-black-mamba-di-kill-bill-volume-1-116565.jpg
    wallpaper-di-uma-thurman-che-interpreta-black-mamba-di-kill-bill-volume-1-116565.jpg
    167.5 KB · Views: 331
[MENTION=600]_NzV_[/MENTION]

Awesome work !
Congratulations!
Your work in the past weeks has been fantastic.

If you allow-me the suggestion:
Another great evolution for mamba, will be the possibility of the mamba installer, being able to search and patch the offsets in mamba at install time, so to make mamba behaving as "firmware independent"...
;)

(This is more or less the way kW made psnpatch to patch prxloader at install time. If someone's interested I can share that piece of code).


Sent from a mobile device using Tapatalk
 
If you allow-me the suggestion:
Another great evolution for mamba, will be the possibility of the mamba installer, being able to search and patch the offsets in mamba at install time, so to make mamba behaving as "firmware independent"...
;)

(This is more or less the way kW made psnpatch to patch prxloader at install time. If someone's interested I can share that piece of code).

That is what GetSymbols does too... although the success rate is near 100%, but it is not perfect.... which means that many functions would work but others would be buggy (specially DEX has different patterns).

I love your idea... but I have some concerns about if it could be implemented error-free for more than 100 symbols.
 
That is what GetSymbols does too... although the success rate is near 100%, but it is not perfect.... which means that many functions would work but others would be buggy (specially DEX has different patterns).

I love your idea... but I have some concerns about if it could be implemented error-free for more than 100 symbols.

Yes. That's an issue enough to crash everything ;)
What was done in PSNPatch was to deal with some exceptions:
Shortening the search pattern (while unique) for some symbols.
Or accepting a certain number or different bytes in other symbols, enough to guarantee that a correct Mach is done.
I will prepare that module source code and publish it here to be easier to explain.
It is not so standard as wanted but it is a nice evolution. Of course that doing this in prxloader is much easier than in mamba, that have much more symbols :)

Ah yes, and it is only for CEX (to many differences for DEX).

(Edit) from what ive seen this approach covers every 4xx CEX until now - of course that after this discussion something will fail in 4.80 or 4.90 :D
 
Last edited:
Trying to sumarize, the way that PSNPatch, "patches" prx-loader when installing-it in flash to be loadable at boot time by special sys_init_osd from any firmware versions 4.XX (CEX guaranteed, DEX not tested):

= Prx-loader sysmbols.h:
Added section for a firmware 0_00.
This section includes fixed offsets to be used as known "place-holders".
payload_0_00.bin is the prx-loader version of the payload included with PSNPatch.pkg and compiled for this "virtual" firmware version.

=Plugin-noncobra module:
This is the module that PSNPatch uses to install and uninstall the "plugin handler" (sys_init_osd + payload).
When installing the payload, this module searches for the lv2 symbols and patches the payload by searching the place-holder in the file.
When searching for the symbols, there is a comp64() function that can be used to accept some small differences (trying to be more flexible searching for symbols, without getting false positives) – this still needs some adjustments. For now, it works. IF it fails in the future, we will think in a more flexible uniform approach.

This gives some firmware awareness and also some flexibility in doing small future changes to the payload without needing to remade or recompile psnpatch.

Of course this is an initial approach.
It is not yet standardized as it should be.
And of course, doing this for mamba will take a lot of work, as there are many more symbols to prepare ;)

https://www.sendspace.com/file/2qwv3g


Attached:
Symbols.h
Plugin-noncobra.h
Plugin-noncobra.c
 
Trying to sumarize, the way that PSNPatch, "patches" prx-loader when installing-it in flash to be loadable at boot time by special sys_init_osd from any firmware versions 4.XX (CEX guaranteed, DEX not tested):

= Prx-loader sysmbols.h:
Added section for a firmware 0_00.
This section includes fixed offsets to be used as known "place-holders".
payload_0_00.bin is the prx-loader version of the payload included with PSNPatch.pkg and compiled for this "virtual" firmware version.

=Plugin-noncobra module:
This is the module that PSNPatch uses to install and uninstall the "plugin handler" (sys_init_osd + payload).
When installing the payload, this module searches for the lv2 symbols and patches the payload by searching the place-holder in the file.
When searching for the symbols, there is a comp64() function that can be used to accept some small differences (trying to be more flexible searching for symbols, without getting false positives) – this still needs some adjustments. For now, it works. IF it fails in the future, we will think in a more flexible uniform approach.

This gives some firmware awareness and also some flexibility in doing small future changes to the payload without needing to remade or recompile psnpatch.

Of course this is an initial approach.
It is not yet standardized as it should be.
And of course, doing this for mamba will take a lot of work, as there are many more symbols to prepare ;)

https://www.sendspace.com/file/2qwv3g


Attached:
Symbols.h
Plugin-noncobra.h
Plugin-noncobra.c

A small optimization for this code:
for (i=0x8000000000000000ULL; i<0x80000000002B0000ULL ; i+=2)

could be changed to this:

for (i=0x8000000000003000ULL; i<0x8000000000300000ULL ; i+=4)

The reason is that all the symbols are after TOC, and aligned to 4. Also some symbols can be found after 2B0000. So I increased the search limit to 300000.
Just this change (i+=4) would make the search 2X faster.
 
A small optimization for this code:
for (i=0x8000000000000000ULL; i<0x80000000002B0000ULL ; i+=2)

could be changed to this:

for (i=0x8000000000003000ULL; i<0x8000000000300000ULL ; i+=4)

The reason is that all the symbols are after TOC, and aligned to 4. Also some symbols can be found after 2B0000. So I increased the search limit to 300000.
Just this change (i+=4) would make the search 2X faster.

Good point on widening the searching intervals - it will be done.
About the 4 bytes vs 2 bytes alignment, I remember an issue with some symbol in a firmware version - I think it was something related to the way rtoc is caluclated - I need to recheck the lv2 dumps.
Thanks you for the suggestions :)
 
Our user has problems using the application Mamba / PRXLoader (autoloader) on Custom Firmware noBD Ferrox, from black screen, likely not work without Blu-ray player?

Cobra was never fully compatible with noBD system, becuz noBD patch itself is not full patch I assume, I think that's where problem is coming from for mamba


Sent from my iPhone using Tapatalk
 
Last edited:
Back
Top