Hacking Warning for ENSO users (in future everyone)

[Deleted User]

snip

 

[SKGleba]

I thought the bricks from game dumps were in the past. "Safe" game dumps can't have malicious code in them, right?

Or does safe homebrew only help when the code is in the eboot? Can it do nothing against suprx files?

I'm not sure we need to go as far as getting SHA-256 from the dumps. Just getting everything from a well known dumper should be fine because if a trusted dumper can calculate the SHA-256, that means they already have a good dump to upload.

I will repeat: You can make an app-starter eboot which will load ur code and next game code.
I will test some scenarios

 

[Deleted User]

snip

 

[CMDreamer]

[...] And all game dumps should be marked as safe, so nobody would install it.

This is something I didn't know... What homebrews can mark them as SAFE to install before even copying them to my very limited space 4GB memory card?

 

[Deleted User]

snip

 

[CMDreamer]

[...]
VitaOrganizer.
Usually game dumps are already safe though.

Thank you! Will check it later.

 

[SKGleba]

I just tried making a safe homebrew that launches an unsafe eboot.
When I put the unsafe eboot in the VPK with the filename "unsafeeboot.bin", the VPK was detected as an unsafe one. I removed "unsafeeboot.bin" from the VPK and installed it. The VPK didn't give the warning about being unsafe when I did that. Then I transferred the file directly to ux0:app/titleid. It was able to launch, of course. This means that game dumps that are marked as "safe" can't load an unsafe eboot from app0: without the VPK being marked as unsafe. What they can do is launch an unsafe eboot from ux0:data while the VPK is still safe. Game dumps don't have a data folder, so this isn't a problem. However, you could make the safe eboot make another eboot in ux0:data/titleid and launch that.

eboot.bin (safe) code:
https://pastebin.com/s326Bb16

unsafeeboot.bin (unsafe) code:
https://pastebin.com/vMQBPnpu

edit: I can't seem to load an eboot from ux0:data/titleid, only app0:. Good job, Henkaku developers!


VitaOrganizer.
Usually game dumps are already safe though.

Try just to rename eboot.bin to lol.png and put it in /manual.
And your safe eboot will rename&run the unsafe one
And no, its not a job of hen devs, (or im bad informed)

 

[Deleted User]

snip

 

[SKGleba]

Safe homebrew can't rename files that are in the manual.

tried what you said and the VPK was still detected as an unsafe one.

Interesting.... gonna find a way around :-)

 

[SonsofOcelot]

Interesting.... gonna find a way around :-)

I have to know why you are so inclined to find a way around FloW's vpk safety checks? If you are trying to warn people about this potential security risk I don't think posting about how to (potentially) get around the existing security checks that attempt to prevent this from happening is a good idea. You would literally be putting more users at risk by finding a way around this and posting about it here, than you would be protecting at this point.

Also as I remember it both Vitashell and maidump check for the os0 and vs0 lines when installing. If either is detected it flags the game/homebrew as unsafe and forces you to turn unsafe brew on and then it prompts you to confirm that you want to install it.

Again though, why would you want to find a way around these checks unless you plan on releasing a Bricker yourself? Seems counterproductive to your warnings...

 

[Deleted User]

snip

 

[SonsofOcelot]

If you find a way to bypass the unsafe VPK checks, you can report it to TheFloW and have it fixed. Finding it before somebody with malicious intent finds it is a lot better.

Checking for os0 or vs0 probably won't do anything, right? I made some test code.
In this code, you can find "os0:" as a string in the eboot:

FILE * fp;
fp = fopen ("os0:_stuffz/a.txt", "w+");
fprintf(fp, "%s", "This is test string");
fclose(fp);

In this code that has the same end result, you can't find "os0:" as a string in the eboot:

char buffer[256];
strcpy(buffer,"o");
strcat(buffer,"s");
strcat(buffer,"0");
strcat(buffer,":_stuffz/a.txt");
FILE * fp;
fp = fopen (buffer, "w+");
fprintf(fp, "%s", "This is test string");
fclose(fp);

Point taken on finding the vulnerability but I still would refrain from posting about it in an open forum.

 

[GerbilSoft]

Point taken on finding the vulnerability but I still would refrain from posting about it in an open forum.

Security through obscurity isn't security.

Obfuscation is quite literally one of the most basic things you can do to bypass a security scanner. Polymorphic viruses have been around since at least 1990.

That article also has an example for obfuscating a string using XOR operations.

EDIT: I don't know the low-level details of the PSVita OS, but would it be possible for the program loader to somehow hook into the open() syscall to filter out calls to "protected" devices? The string has to be deobfuscated before calling open() [or fopen()], so that would be the most logical place to put an actual security check.

 

[CMDreamer]

If you find a way to bypass the unsafe VPK checks, you can report it to TheFloW and have it fixed. Finding it before somebody with malicious intent finds it is a lot better.

Checking for os0 or vs0 probably won't do anything, right? I made some test code.
In this code, you can find "os0:" as a string in the eboot:

FILE * fp;
fp = fopen ("os0:_stuffz/a.txt", "w+");
fprintf(fp, "%s", "This is test string");
fclose(fp);

In this code that has the same end result, you can't find "os0:" as a string in the eboot:

char buffer[256];
strcpy(buffer,"o");
strcat(buffer,"s");
strcat(buffer,"0");
strcat(buffer,":_stuffz/a.txt");
FILE * fp;
fp = fopen (buffer, "w+");
fprintf(fp, "%s", "This is test string");
fclose(fp);

I've a question. You gave us a pretty convincing example of a plausible attack pattern, to call it somehow. Can the os0: partition be mounted as read-only while running a game? Or is mandatory to be in +RW mode?

Now this, do each and every partition on the vita/memory card have something like an "UUID"? And can they be protected by Ensö while using them?

Where can I get more specifics of how the Vita work in terms of both software and hardware as we know so far, does something like a "wiki" exists?

Oh, one more thing, can the read/write access to os0: and related partitions be controlled by Ensö?

 

[SKGleba]

I've a question. You gave us a pretty convincing example of a plausible attack pattern, to call it somehow. Can the os0: partition be mounted as read-only while running a game? Or is mandatory to be in +RW mode?

Now this, do each and every partition on the vita/memory card have something like an "UUID"? And can they be protected by Ensö while using them?

Where can I get more specifics of how the Vita work in terms of both software and hardware as we know so far, does something like a "wiki" exists?

Oh, one more thing, can the read/write access to os0: and related partitions be controlled by Ensö?

os0 is mounted r only, even in games etc. homebrews like vitarw allows user to rw.
just include a vitarw code in ur app.
And a clarif: enso is only an preloader exploit, only henkaku from start, dont expect magically things.

 

[Deleted User]

snip

 

[Deleted User]

and now, the vita will have the stuff the dslite had, a bricker thats injectable :/