Added v6 with 2.1.3b to the pevious post.
To be honest it makes no difference if you load the exploit seperatly or with HEN.
They both use the exact same process and files.
The success rate you get with 6.72 is down to luck or coincidence.
To be honest it makes no difference if you load the exploit seperatly or with HEN.
They both use the exact same process and files.
The success rate you get with 6.72 is down to luck or coincidence.
Let us know how you get on.
Keep in mid that although 2.1.3b fixes the blank trophy date for most people it also introduces some bugs which are not in 2.1.3.
https://github.com/Leeful/ps4-hen-vtx/releases
I'm currently testing a v9 menu which uses Sleirsgoevy's latest changes. It's not perfect but the success rate seems to be a lot better. (might just be a fluke, we will see.)
I'll upload it here soon for you and anyone else to test out. Keep a look out.
the best success rate running hen on 6.72 I could get is 88%, 2 kernel panic out of 18 total tries from leeful v7, looking for improvement on upcoming v9, btw @Leeful, can you still let the option to load only jailbreak available, I want to run backup payload weekly then shutdown, no hen needed.
Last edited by ItsmeAJ,
there's now a db restore payload? I was just injecting it manually. three of the databases are in the same folder from what I remember. app.db, addcont.db, and notification.db, I think.
I didn't even know it existed even on 5.05. I know there's an orbis manager for the notification.db. afaik, it just dumps it. I deleted mine after installing everything, so it looks like nothing has been installed on my system. I named all of my stuff after content id to keep things organized, but that's not what psn stuff is named. iirc, orbis (fake pkg generator) will allow you to assign a name to display instead of content id, which I think is default. without knowing the name of the content as seen on psn, I'd imagine a fake name might be a major red flag or one with duplex in the name. lol I learned that you could safely delete the file from @Leeful . no issues as a new one is created in its place kinda like incognito and the activity log on the 3ds, which I've never tried.
the dumper payload dumps everything else including savedata.db. I think the savedata.db is kinda useless since you can just create a new save over x number of slots, then inject a save, load the save (with incorrect info) and immediately save again to update the database. I once got it to rebuild just the savedata.db while on the home screen, but I don't know how unless the database got corrupted somehow. it might be the easiest way to get saves back if something were to happen. though, a savedata.db would save you from having to start a new game just to index saves.
it's weird that there's an app.db and an addcont.db. afaik, the vita only has the app.db with addcont being a part of it, but you can create a license database in vitashell. they may be separate then. I've noticed that some people have major problems with that python script in case you have to rebuild the database, so backing up at the very least the app.db will save you the trouble later on. I backed up mine after I installed all 80-100 games I had on hand. I had a weird error with final fantasy vii remastered where it would error after boot yet still work. I rebuilt the database then, but not before I backed up my app.db. I'm not sure what was causing the error, but the error disappeared after rebuilding the database. even though the app.db was rebuilt too, I injected the one I had made before. no issues after that. I know that beyond actually rebuilding the database, the system will fix pfs errors as well, which it might've been. once, when I forgot to unmount a save in save mounter, it got stuck in limbo in the pfsmnt folder, so I couldn't unmount it or delete it. it required a rebuilding of the database to fix. I made note of that in my save mounter tutorial. that is obviously very important. I hadn't made an app.db backup yet, so I just went ahead and installed the games over again. it was only 13 games, my only legit titles, so it didn't take too long. I knew what not to do after that.
the dumper payload dumps everything else including savedata.db. I think the savedata.db is kinda useless since you can just create a new save over x number of slots, then inject a save, load the save (with incorrect info) and immediately save again to update the database. I once got it to rebuild just the savedata.db while on the home screen, but I don't know how unless the database got corrupted somehow. it might be the easiest way to get saves back if something were to happen. though, a savedata.db would save you from having to start a new game just to index saves.
it's weird that there's an app.db and an addcont.db. afaik, the vita only has the app.db with addcont being a part of it, but you can create a license database in vitashell. they may be separate then. I've noticed that some people have major problems with that python script in case you have to rebuild the database, so backing up at the very least the app.db will save you the trouble later on. I backed up mine after I installed all 80-100 games I had on hand. I had a weird error with final fantasy vii remastered where it would error after boot yet still work. I rebuilt the database then, but not before I backed up my app.db. I'm not sure what was causing the error, but the error disappeared after rebuilding the database. even though the app.db was rebuilt too, I injected the one I had made before. no issues after that. I know that beyond actually rebuilding the database, the system will fix pfs errors as well, which it might've been. once, when I forgot to unmount a save in save mounter, it got stuck in limbo in the pfsmnt folder, so I couldn't unmount it or delete it. it required a rebuilding of the database to fix. I made note of that in my save mounter tutorial. that is obviously very important. I hadn't made an app.db backup yet, so I just went ahead and installed the games over again. it was only 13 games, my only legit titles, so it didn't take too long. I knew what not to do after that.
RE: Database Backup. Years ago I had an idea to make HEN automatically backup up your databases to the PS4 HDD every time you run it. That way everyone who used it would always have a recent backup of their databases.
The problem with that is if you had a forced database rebuilid and then you ran HEN it would overwrite the good backup with the new empty one the PS4 made after the db rebuild, making the backup useless.
A workaround would be for HEN to check the date of the backup files and ONLY make a new backup if todays date was a day or more later than the backup date.
The problem with this is that I have no idea how to code the payload to do this.
Anyone have any ideas for another method of making it work?
The problem with that is if you had a forced database rebuilid and then you ran HEN it would overwrite the good backup with the new empty one the PS4 made after the db rebuild, making the backup useless.
A workaround would be for HEN to check the date of the backup files and ONLY make a new backup if todays date was a day or more later than the backup date.
The problem with this is that I have no idea how to code the payload to do this.
Anyone have any ideas for another method of making it work?
RE: Database Backup. Years ago I had an idea to make HEN automatically backup up your databases to the PS4 HDD every time you run it. That way everyone who used it would always have a recent backup of their databases.
The problem with that is if you had a forced database rebuilid and then you ran HEN it would overwrite the good backup with the new empty one the PS4 made after the db rebuild, making the backup useless.
A workaround would be for HEN to check the date of the backup files and ONLY make a new backup if todays date was a day or more later than the backup date.
The problem with this is that I have no idea how to code the payload to do this.
Anyone have any ideas for another method of making it work?
that's why I backup windows with a disk image every month or so. I don't let it do an incremental update to the disk image, because if something is wrong with the system, it might back up that problem with it. some things it's best to do manually, and imo, it's probably better for people to do this themselves, because most sceners are already complacent enough due to the ease apps make most scenes, so a lot of them don't even back up their NAND. they're convinced nothing will ever go wrong until it finally does. that's my opinion on the matter. speaking of which, I think my bluetooth has gone out on my pc. I even reflashed a disk image and no change, so I'm going to have to contact dell to have the bluetooth replaced. it's still under warranty.
at the moment i have no kernel panics, but with v6 menu on ps4 pro 7200, the two steps methods to entering hen. With v8 yes or yes i have a kernel panic all times the first trying when coming from power on. Anyways waiting for that new improved v9 exploit....
You mean the ctime/mtime/atime timestamps?
Anyone have any ideas for another method of making it work?
I suppose from HEN wouldn't be reasonable to link libsqlite to do an SQL query to the app.db itself, unless defeating the ASLR and calculating where Orbirs has loaded libsqlite... ^o^
Otherwise I would check the file size, I haven't looked at the app.db after a DB rebuild, but I would say that a fresh DB file should be smaller than a populated DB file...
Last edited by MostlyUnharmful,
, Reason: clarification
Any day now. Watch this space.
I'm still not 100% happy with it because of the 6.72 exploit but I'll put out a working version of what I have soon.
https://streamable.com/kpp9wn
Also something new to try...
https://streamable.com/5omhk5
And there are 2 new versions of the basic 6.72 menu. v9a and v9b.
'a' uses the previous exploit but 'b' uses the latestet one from sleirsgoevy which takes slighly longer to load but I've had better loading success rate with it.
I'll upload them all for people to test soon.
wowowoow that looks very good
anyways i dont know anything about that new optimized exploit you go to use on that v9, but what i want to specially bold is that the one step menu game me always kernel panic, where the 2 steps v6 way gamve me 0. Tested in the last 2 weeks..
Maybe that new optimized exploit do a better job ?
anyways i dont know anything about that new optimized exploit you go to use on that v9, but what i want to specially bold is that the one step menu game me always kernel panic, where the 2 steps v6 way gamve me 0. Tested in the last 2 weeks..
Maybe that new optimized exploit do a better job ?
Similar threads
