kR105-zz / PS4-dlclose

Fully implemented dlclose exploit for PS4 fw 1.76 with included linux loader
MIT License
95 stars 37 forks source link

Filesystem issues after exploit #2

Open ghost opened 8 years ago

ghost commented 8 years ago

Hi,

I have noticed these strange behaviours while accessing filesystem after the exploit:

1) Most of root folders are empty (adm, app_tmp, data, eap_user,eap_vsh, hdd, host, hostapp)

2) If I execute the stat call on all folders which are external to those inside the orginal sandbox directory (user, etc. ) the call always returns an error.

3) If I execute the statvfs call (I added it to the SDK) it gives me always the same (little) values, even on /mnt/disc which instead accesses the blu ray inside the ps4 when browser.

StatVFS: / bsize 4096 fblock 340 (1 MB) fragsize 4096 size 1276 (4 MB) fsid 0 mount flags 1 max length 255 StatVFS: /mnt/disc bsize 4096 fblock 340 (1 MB) fragsize 4096 size 1276 (4 MB) fsid 0 mount flags 1 max length 255

4) There is no /etc folder so it's impossible to enumerate all mounted filesystem

So my question is: are we really out of the jail ?

ghost commented 8 years ago

I tried also to mount the disk devices present according to http://www.psdevwiki.com/ps4/Files_on_the_PS4, yet both mount and nmount calls always crash (after having added them to PS4-SDK). Has anybody been able to access the root folders (system, system_ex, etc) in some way with this exploit ?

// NMount example
// crazy way of passing parameters, len +1 is taken from build_iovec implementation (https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c612757f0/sbin/mount/getmntopts.c) , do not ask why.
int NMount (char *fstype, char *fspath, char *device) {
    int ret;

    struct iovec v[6];

    v[0].iov_base="fstype";
    v[0].iov_len=strlen(v[0].iov_base)+1;

    v[1].iov_base=fstype;
    v[1].iov_len=strlen(v[1].iov_base)+1;

    v[2].iov_base="from";
    v[2].iov_len=strlen(v[2].iov_base)+1;

    v[3].iov_base=device;
    v[3].iov_len=strlen(v[3].iov_base)+1;

    v[4].iov_base="fspath";
    v[4].iov_len=strlen(v[4].iov_base)+1;

    v[5].iov_base=fspath;
    v[5].iov_len=strlen(v[5].iov_base)+1;

    DEBUG("before nmount %s\n",fspath);
    ret=nmount(&v[0],6,MNT_RDONLY);
    if (ret!=0) {
        DEBUG("Error %d while mounting dev %s on %s fs %s\n",errno,device,fspath,fstype);
    }
    DEBUG("after nmount %s ret %d\n",fspath,ret);

    return ret;
}

    ret=NMount("ufs","/system_data","/dev/da0x9.crypt");
//      mount code
    struct ufs_args dev;
    dev.fspec="/dev/da0x9.crypt";
    DEBUG("before mount\n");
    ret=mount("ufs","/system_data",MNT_RDONLY,&dev);
    DEBUG("after mount ret %d\n",ret);
fx0day commented 8 years ago

module type source destination SceSysCore mini nmount /dev/da0x4.crypt /system SceSysCore mini nmount /dev/da0x5.crypt /system_ex SceSysCore mini nmount_ufs /dev/da0x9.crypt /system_data SceSysCore mini nmount_ufs /dev/da0x13.crypt /user SceSysCore mini nmount_ufs /dev/da0x14.crypt /eap_user SceSysCore mini mount /dev/da0x12.crypt /update SceSysCore mini nmount /dev/da0x0.crypt /preinst SceSysCore mini nmount /dev/da0x1.crypt /preinst2 SceSysCore nmount /data /user/data

All is mounted for me /eap_user is empty but i got dirs and files in all the others ...

ghost commented 8 years ago

How did u check the mount points above (i.e. what call did you use) ? Did you run something else after the exploit ? For me they are all empty, like unmounted or at least shadowed with empty dirs.

fx0day commented 8 years ago

I didn't check mount points but but i can see files/dirs in : /system /system_ex /user /update /preinst /preinst2

And i can see/dump them with your ftp server ;)

ghost commented 8 years ago

The ftp server does not log anything like that you have posted, maybe you got that log from here http://www.psdevwiki.com/ps4/Bootprocess ? Do not try to cheat anymore

fx0day commented 8 years ago

I'am not sure to understand what you mean ;)

You asked : Has anybody been able to access the root folders (system, system_ex, etc) in some way with this exploit ?

So my answer is yes even with your Ftp server ;) So i suppose there's not mount problem ...

From Irc (you missed answers) :

[10:59] n00b438 data hdd host host-app are all empty :( any idea why ? [11:01] n00b438 there is no way to access all the mounted filesystems (no /etc/fstab or mtab) [11:02] n00b438 and if you dump all the contents they take abot 6 GB of data.....I think that something is missing [11:03] n00b438 are you there ? am I correct ? [11:06] n00b438 ok nevermind sorry for asking [11:08] * n00b438 (webchat@188.72.101.11) a quitté #ps4dev [11:08] flatz there is nothing new on twitter pic, this is just sys_getdents (syscall from user mode) using ROP... [11:10] flatz n00b438 data hdd host host-app are all empty :( any idea why ? [11:11] flatz they are empty because they are empty : Hope it helps ...

capture d ecran 2016-04-19 a 17 18 32

eth-man commented 8 years ago

were able to mount system_ex with write access?