PS3 ManaGunZ - PS3 Backup Manager by Zar v1.41

[kozarovv]

From coding side is easy to implement noob resistant ftp. I don't know how this exactly work but i think that ftp don't have own priority to access hdd. I mean there is no risk to eg. write same place in same time etc. I think that ftp is asking like standard app "i can write here? yeah no problem is free space, but wait i need to read something first" (lol). Not just writing without any scheduler. Until is not dangerous is ok imo, maybe in default config things that you mentioned are good. But for me only with switch that remove default restriction.

 

[sandungas]

Yes, the hdd itself does the schedule of write/read operations (by using his buffer i guess) so software wise is allowed to make multiple operations to an hdd
In the practise... if you put an hdd in a USB case and connect to PC... then you read a big file from it and at the same time you write another big file to it... both operations are delayed
Phisically what the hdd does internally is to move the head to write some blocks from a position in the plate... then the head "jumps" to the other position where the readed file is and it reads some blocks from it.... then it "jumps" again to write in the other position... and so on
Is the worst scenario for a hdd... if the hdd is old and had problems it can even kill it

In the PS3 with backup managers most people are loading the backup from external.... but most games uses a hidden partition of 1 GB in internall hdd (not visible in backup managers btw) to store cache files from the game... this partition is readed almost constantlly (and writed periodically because the game replaces the files in it when you move to a new level of the game)
So even when playing from a backup in externall USB... the console is reading and writing internall hdd
This is why i think FTP should not be allowed when playing

But well is not only with games... there are other stuff that are not games that could make an intensive usage of internall hdd, probably some i cant even imagine rght now but well... one stupid example (i dont think anyone tryed this but well, is allowed) is to download something from PSN and at the same time to move a backup from PC to internall hdd of PS3

If there was some way to prevent all this for the ftp plugins in an automated way it could be nice, but is hard to imagine all scenarios, humans are very imaginative

 

[Zar]

[MENTION=872]sandungas[/MENTION] I almost done nothing, during these last month I was in the mood for playing game (on my computer) instead of coding. But I have done few stuff to support ird files (to check MD5 only), also started to re-write the menus in a better way to allow me to add new stuff much more easier and faster. Tomorrow, i'll have full access to my ps3... i'll try to do a little update for next week ^^'

About XMB priority this is pretty easy to do, so it will be on the next update for sure :p

 

[sandungas]

Thanks for the news, good to know the priority will be supported, about the question of the payload for newer firmwares, can you give some hint of how to do it ?

I know some people that only turns on the PS3 for messing with experiments or testing apps instead of playing.... so is good every few time to take a game and play a bit to not forget consoles is a hobby but we like gaming too, so time well used playing

 

[nohan2008]

[MENTION=34]Zar[/MENTION] hope MANAGUNZ will support and work for latest cfw 4.73-4.75..
thx for ur hardwork and take ur time mr zar

 

[Alexander]

I tried to compile the program but by starting it , back to the XMB . For if the source is buggy or what ?.

 

[Zar]

[MENTION=56]Alexander[/MENTION]
Did you succeed to compile the self ? the Eboot is only launching the self, the self is the homebrew (it make me remind this is useless now).
To compile the self you have to include the lib cobra and the lib ntfs inside pslight libs

 

[Alexander]

[MENTION=34]Zar[/MENTION]

Yes, I can compile the program without problems.
Using your make pkg, it automatically creates the entire PKG with all files.
I only noticed one thing, using the launcher.self of 1.21 extracted from your PKG, managunz starts, but by "Error: Can not init ManaGunZ".
If I install the PKG created by the source, so I returned to the XMB.

I included the libraries libcobra.a & libntfs_ext.a in ... \ ps3dev \ ppu \ lib \ gcc \ powerpc64-ps3-elf \ 4.5.2

cobra.h & ntfs.h and in ... \ ps3dev \ portlibs \ ppu \ include

I find it interesting your Backup Manager and was feeling a porting 4.75.

 

[Zar]

[MENTION=56]Alexander[/MENTION]
Thanks, I just came back from my holydays. Actually, I'm working on it right now.

I wasted too many time on re-writing the functiun to display the menus and still I didn't finish it because i'm working on it 30 min each time That's why every time, I forget what i've done before, and with these holydays it's rly became a mess for me ^^'

So, I decided to roll back to the 1.21. And to do it in other way later.


I don't know what exactly is ur issue but i've already ported it to 4.75 CEX.
FYI, here what you need to do to port it to a new fw :
-include the payloads : mamba and iris (sky & unmount)
-update the offset in common.h
-update the function init_fw()
-increase the number version in makefile

If you'll do it, just release it here or pm me


I'm not releasing yet because i want to fix some small issue that ppl reported me and also I saw that [MENTION=29]Joonie[/MENTION] is working on 4.75 dex => https://github.com/Joonie86/COBRA7.1/commit/73fe223f0c6cc253a48c0b3141fe0a64f2d90fd0 , so, i want to port it to 4.75DEX when i'll have my hand on it ^^'

 

[Alexander]

[MENTION=34]Zar[/MENTION]
I am attaching my source by MPs. I will absolutely not release an unofficial without your permission.
You can control it and take off on some offset / patterns and if you want I can give you help.

I like to help the scene ps3

 

[Zar]

[MENTION=872]sandungas[/MENTION] I got some trouble with ITEM_PROPRIETY.

on the ps3devwiki :

Used to order the contents vertically in XMB columns, contents with any value of ITEM_PRIORITY are displayed at top of XMB column, and after them all the other contents without ITEM_PRIORITY

Contents with bigger values in ITEM_PRIORITY are placed at top of the list, the scale is from 0x00000000 (at bottom) up to 0xFFFFFFFF (at top)

But it look like that "0" is disabling the key "ITEM_PRIORITY".


My trouble is that we have to "refresh" the XMB (rebuilding the database ?) because if i just change the value in the SFO it's not working but iif install the pkg (with exactly the same SFO after modification) the XMB is "refreshed" and the icon go to the top.

Any idea how to "refresh" the XMB ?

 

[kozarovv]

[MENTION=34]Zar[/MENTION]

Rebuild Database without Recovery Menu
Rebuild process itself isnt done in recovery mode. There is no need for this to have set the console into recovery mode. This means no steps required to turn it off and hold for the beeps.
Because it can be done via mms modules by vsh anytime, you also do not need to set any eprom flags or anything. To instantly begin database rebuild process create the following file:

/dev_hdd0/mms/db.err
This file must contain following 4 bytes:

00 00 03 E9
Reboot the Level2-LPAR/console and you should've come to a message telling you to rebuild the database.

Source: Recovery Menu - PS3 Developer wiki

Edit: Other way without rebuilding database is editing database, but is hard to implement i think.

MMS_MEDIA_TYPE_HDD is what need to be edited (i think), read more here: XMB database - PS3 Developer wiki

 

[haxxxen]

[MENTION=872]sandungas[/MENTION] I got some trouble with ITEM_PROPRIETY.

on the ps3devwiki :


But it look like that "0" is disabling the key "ITEM_PRIORITY".


My trouble is that we have to "refresh" the XMB (rebuilding the database ?) because if i just change the value in the SFO it's not working but iif install the pkg (with exactly the same SFO after modification) the XMB is "refreshed" and the icon go to the top.

Any idea how to "refresh" the XMB ?

i don't know if it is the correct answer to your problem, but if you just change a sfo of an already installed pkg, you have to first run the pkg again, to make changings on sfo visible and working. other than that you can also rebuild database, but that is not neccessary in this case.

though, it would be fine if we could manually reload xmb

 

[sandungas]

What kozarovv and haxxxen said is correct, the reason why an "unnofficially edited" PARAM.SFO doesnt appears inmediatlly with the new changes in XMB is because we have the "annoying" XMB database that is making a copy of all the PARAM.SFO's used to display contents in XMB (well, is annoying for us, but is working as a cache of contents to speed up the xmb loading time)

When a .pkg is installed (or when a game creates a gamesave, or when a game install gamedata, etc...), after the PARAM.SFO is created or copyed to hdd... the responsible of creating it (either game, or the firmware itself) should send an order to xmb database to "index" the new PARAM.SFO
Because we are overwriting a correctlly indexed PARAM.SFO... his content is not readed (because xmb doesnt reads it when the ps3 boots.... it reads the database instead to speed up load times) only is readed when the game or app boots
When the app boots, the modifyed PARAM.SFO is fully readed and indexed correctlly... overwriting the copy of the "old" one that was indexed originally when the .pkg was installed

So to summarize....
We need to either rebuild the database or wait for the user to boot managunz at least one time
Because the other option is to force a database rebuild by using the trick zokarovv suggested, but i think this is not appropiate because it happens at the next reboot of the PS3, and is a bit annoying (only takes couple of minutes thought, but is something a bit unexpected and the users will not like it)

The perfect solution to the problem is to find how to send the order to xmb database to "index" our modifyed PARAM.SFO but i have no idea how this is made

 

[pinky]

I'd strongly urge against a manual edit of the indexer. doing so suggests that u want to retain ur database. however, if u corrupt it, u'll be forced to rebuild ur database. that er flag will be placed on ur hdd if the system can't load the database. iirc, the database itself relies on 8 sprx files, so it's extremely sensitive.

 

[Zar]

Thanks you everyone, i think i understood how it works now ^^'

Indeed, it will be better to change the value in the database (XMB database - PS3 Developer wiki) but I won't try something "new", I'm afraid to brick it :s (Perhaps it's better to rebuilding the database before launching all the sprx and that's why we need to restart or to be in recovery menu (?))

Anyway, i'll just change the value in the param.sfo then wait that the user relaunch the homebrew. If i use the trick to rebuild the database, it need to reboot so the user will have to relaunch the homebrew anyway...

 

[kozarovv]

Anyway, i'll just change the value in the param.sfo then wait that the user relaunch the homebrew. If i use the trick to rebuild the database, it need to reboot so the user will have to relaunch the homebrew anyway...

Is best way for thing you want to do. Just one sugestion, add some warning screen like "changes that you already made will be active AFTER next boot of homebrew".

The perfect solution to the problem is to find how to send the order to xmb database to "index" our modifyed PARAM.SFO but i have no idea how this is made

Is one of that interesing thing (for me) that probably never will be revealed. Some R.E. is needed to find out how it work, i think full r.e. package installer will answer that, i think after correct install pkg some "signal" is send to read database right now. So r.e. package installer should give answer. But for cfw devs is not important so they don't touch this.

 

[sandungas]

Is best way for thing you want to do. Just one sugestion, add some warning screen like "changes that you already made will be active AFTER next boot of homebrew".

Agreed, displaying a warning is the easy way and is good enought
The other options are not a safe development road because at some point the workaround could be obsolete (and i say workaround because the only good way is to update the database but this is unknown by now... all the others methods are workarounds)

But thinking about workarounds... is posible to force the install of a .pkg from inside managunz ?... i mean an automated sequence of actions triggered from managunz that "quits" managunz, then install the .pkg automatically without user intervention
The idea is to take advantage of the fact that a .pkg of a version can be installed over the .pkg of the same version.... so you can install managunz over itself using the same version (and the update .pkg contains the new PARAM.SFO + only the eboot)
This should update the database correctlly because is an standard install

Is one of that interesing thing (for me) that probably never will be revealed. Some R.E. is needed to find out how it work, i think full r.e. package installer will answer that, i think after correct install pkg some "signal" is send to read database right now. So r.e. package installer should give answer. But for cfw devs is not important so they don't touch this.

I think there are a lot of different ways to update the database... probably the .sprx functions are very nested like an spiderweb and a lot of them can communicate with the other .sprx's pinky mentioned that seems to be in chargue of the database management

 

[littlebalup]

[MENTION=34]Zar[/MENTION]

Yes, I can compile the program without problems.
Using your make pkg, it automatically creates the entire PKG with all files.
I only noticed one thing, using the launcher.self of 1.21 extracted from your PKG, managunz starts, but by "Error: Can not init ManaGunZ".
If I install the PKG created by the source, so I returned to the XMB.

I included the libraries libcobra.a & libntfs_ext.a in ... \ ps3dev \ ppu \ lib \ gcc \ powerpc64-ps3-elf \ 4.5.2

cobra.h & ntfs.h and in ... \ ps3dev \ portlibs \ ppu \ include

I find it interesting your Backup Manager and was feeling a porting 4.75.

I also tryed to compile 1.21 public sources. Build donne without any error, but once installed, black screen + back to xmb...

Spoiler

$ make pkg
mamba_421C.lz.bin
mamba_421D.lz.bin
mamba_430C.lz.bin
mamba_430D.lz.bin
mamba_431C.lz.bin
mamba_440C.lz.bin
mamba_441C.lz.bin
mamba_441D.lz.bin
mamba_446C.lz.bin
mamba_446D.lz.bin
mamba_450C.lz.bin
mamba_450D.lz.bin
mamba_453C.lz.bin
mamba_453D.lz.bin
mamba_455C.lz.bin
mamba_455D.lz.bin
mamba_460C.lz.bin
mamba_465C.lz.bin
mamba_465D.lz.bin
mamba_470C.lz.bin
mamba_470D.lz.bin
payload_sky_421C.bin
payload_sky_421D.bin
payload_sky_430C.bin
payload_sky_430D.bin
payload_sky_431C.bin
payload_sky_440C.bin
payload_sky_441C.bin
payload_sky_441D.bin
payload_sky_446C.bin
payload_sky_446D.bin
payload_sky_450C.bin
payload_sky_450D.bin
payload_sky_453C.bin
payload_sky_453D.bin
payload_sky_455C.bin
payload_sky_455D.bin
payload_sky_460C.bin
payload_sky_465C.bin
payload_sky_465D.bin
payload_sky_470C.bin
payload_sky_470D.bin
umount_421C.bin
umount_421D.bin
umount_430C.bin
umount_430D.bin
umount_431C.bin
umount_440C.bin
umount_441C.bin
umount_441D.bin
umount_446C.bin
umount_446D.bin
umount_450C.bin
umount_450D.bin
umount_453C.bin
umount_453D.bin
umount_455C.bin
umount_455D.bin
umount_460C.bin
umount_465C.bin
umount_465D.bin
umount_470C.bin
umount_470D.bin
gim.cpp
gim2png.cpp
aes.c
aes_omac.c
bn.c
ec.c
ecdsa.c
frontend.c
getopt.c
iso.c
keys.c
libfont.c
list.c
main.c
mt19937.c
np.c
osk_input.c
pad.c
pkg.c
rvk.c
sce.c
self.c
sha1.c
spp.c
syscall8.c
tables.c
ttf_render.c
util.c
zlib.c
linking ... MGZ.elf
CEX self ... MGZ.self
scetool 0.2.9 <public build> (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz

[*] SELF built.
[*] Data compressed.
[*] Data encrypted.
[*] c:/PSDK3v2/ManaGunZ_v1.21/MGZ/MGZ.self written.
main.c
linking ... ManaGunZ_v1.21_v1.21.elf
CEX self ... ManaGunZ_v1.21_v1.21.self
scetool 0.2.9 <public build> (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz

[*] SELF built.
[*] Data compressed.
[*] Data encrypted.
[*] c:/PSDK3v2/ManaGunZ_v1.21/ManaGunZ_v1.21_v1.21.self written.
building pkg ... ManaGunZ_v1.21_v1.21.pkg
scetool 0.2.9 <public build> (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz

[*] SELF built.
[*] Data compressed.
[*] Data encrypted.
[*] c:/PSDK3v2/ManaGunZ_v1.21/build/pkg/USRDIR/EBOOT.BIN written.

I didn't modified the source at all. Just a try to compile correctly. I'm on 4.70.1 REX.

[MENTION=34]Zar[/MENTION], could you say us which version of cobra and ntfs libs you are using? I used those one : https://github.com/Joonie86/Cobra-7.00/tree/master/446/EXTRA/ntfs_ext_iso

Thx

 

[pinky]

maybe I missed it, but [MENTION=34]Zar[/MENTION], u wanted to change the name of an sfo without having to open the homebrew or rebuilding the database? [MENTION=31]eXtreme[/MENTION] once asked me if I could figure out a way to have his homebrew install automatically. u can force it to install to a specific location, but the database won't be updated. thus, it wouldn't appear at all. aside from the err file to force a rebuild of the database, which I know many wouldn't want considering album names would be gone afterwards, I couldn't figure out any other way of doing it. though, taking from my knowledge of the 360, the hacked dash on that system uses a metadata indexer as well to speed up loading while the system itself doesn't. how it works is that u can either manually force it to scan the content on the hdd or u can have it scan the hdd automatically upon bootup. something similar might work for the ps3 in the form of a prx plugin.