Jump to content

wildcard

Regular Member
  • Posts

    49
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by wildcard

  1. ok what is that guy on 4.XX ?? that video has confused the fuck outta me lol. Thanks for the link @judges, that seems to debunk what i was saying.. i think it may just be due to slightly long cables since they are twice as long when connecting flash to ps4 vs to breadboard and teensy. Also i dont have a decoupling cap so that could be it, or i dread to think that aeolia was effeted when removing flash.. well at least that cleared things up. Also this proves why psxhax is so credible huh XD

  2. 23 hours ago, judges said:

     

    Hi.. I had some doubts about this, since flashing the PS4 isn't something many people do and I never received any feedback. But some time ago I saw these vids on utube and now I'm pretty sure that it's working fine and that there's no protection or what so ever involved:

     

    https://www.youtube.com/watch?v=O612Mtz43OI

    https://www.youtube.com/watch?v=P1OT3isiqvM

    https://www.youtube.com/watch?v=j9BNn-uH7oY

     

    -- judges

    LOL, thanks for replying @judges, well i can say yeah, there doesnt seem to be any protection XD. After i commented here i spent the night and morning setting up avr studio and adding some functions to print out registers relating to security. all 00s for security features and password protection had a default of 1 meaning it was not enabled. Well from reading other very credible resources like psxhax for example, ive heard that there was some kind of protection implemented outside of flash that checks if you have written to it. This occurred after 2.50 rumor has it and reports are that you cant even flash back a dump without the ps4 being briked or in a flashing blue light state. I think sony implemented some kind of security to prevent the Brazilian cloners lol. Also i have seen 2 regions in flash change every boot, they look like a header and table and mirror eac hother but are slightly differnt. I dont think they have something to do with the flash check but i would need to compare these findings on a ps4 below 2.50 that i dump flash every time it boots and see if these values change as well. i think they should... ok while writing this i just checked my 1.76 dumps that i had from fs that occurred on diff boots, and.. the sections are diff as well just like occurs on 4.07. so lol it has nothing to do with flash checks. Its either in syscon or aeolia kernel which i dont think it is.

  3. On 8/15/2016 at 8:24 PM, judges said:

    I don't have a PS4, so I couldn't test it, but keep in mind that SPIway might not be able to "clone" the flash. I.e. you can dump the flash, you can reflash to a different flash chip, but this might not result in a 1:1 copy.

     

    The data ofc is copied 1:1, but the MX25L25635F comes with a couple of security features:

     - 4Kb secured OTP mode -> provides 512 bytes independent from main data for storing a serial number or whatever, can be read and also written to a new flash device, but currently isn't supported by SPIway

     - Password protection mode -> the device can be protected with a 64bit password (OTP). Data can still be read when protected, but not programmed or erased. So this doesn't prevent reading data, but (and this is just a guess) could be used to validate if it's a genuine device and also for tamper protection ofc.

     

    -- judges

     

     

    Hey Judges, did you plan on implementing these features into spiway? I have a strong suspicion that flash has tamper protection, i have a dedicated 4.07 board i am using for flash testing. After dumping and flashing back data it wont accept it even though the dump is identical to what i have written. There are 2 sections in flash however that have a header of some sorts and table, these are updated every boot but after enough testing i think that they aren't involved in flash verification. I think your right about tamper protection and my dumps wont show anything cause like you said its in a separate area via OTP mode. If you wanna help me itd be appreciated, ill be looking into creating the support for OTP mode but hopefully with the help of your expertise.

     

    wild

  4. Ive got both a copy of my sflash taken with a teensy and from the /dev directory, they look pretty much the same in sense that the same dump that you get with a flasher is the same dump youll get in /dev.  Until we reverse engineer the flash and OS we wont know if any possible checks the ps4 performs on it. I think the only way to know now would to be to dump flash then write it straight back and see if it boots. Maybe there are some hash checks on the sflash0 partition when its mounted at boot. sflash0 also has a .crypt file so it is treated like an encrypted partition so the system isnt just mounting the flash directly, it needs to decrypt the image with a key. I think sceSblServiceCrypt has something to do with it, maybe sonys version of a geli or gdbe, just need the right passphrase and sflash could be mounted as a decrypted partition, just like sbram and other da0 partitions could be.

    • Upvote 1
  5. That pretty much answered my questions, thanks for the info.

     

    1 hour ago, cfwprophet said:

    I give you a hint....i never heard of 'ps4KernelMemoryCopy'. You do that with basic shit c.

     

    It was a reference to hitodamas sdk https://github.com/ps4dev/ps4sdk/blob/master/common/kernel/source/kernel/memory.c

    basic shit c is where im at..

     

    Quote

    it's just that peoples that do trust them each other to a specific point do share some stuff they archived. That is all. And since what happend in past, dude it is no wonder. We get some nice stuff, the next day later the half of it is leaked. So don't put that shit on us. Go put it on the persons that are held for this.

     

    Yeah screw that/them, id be so pissed if someone took something i worked on without my permission. Dont take that outta the circle comment as im against a circle lol just meant that it was new information to me and just didn't know.

  6. 1 hour ago, cfwprophet said:

    uhm..first i may allowed to ask how 'big' your kernel dump is ?

    And then the stuff you talk here is already knowen. Please calm down and wait thoes 2 months till NEO and VR is released.

     

    my dump is 15,025kb using ps4KernelCall(ps4KernelMemoryCopy, (void *)0xffffffff80700000, dump,  0xeac180)

    any later and it fails and before it i can dump up to 0xFFFFFFFF80000000 which has BIOS_FLASH data in a mix of compressed and encrypted.

     

    I was only asking cause i haven't seen anyone mention disabling ASLR only a hint at the function by cTurt with looking into UART enabling.

    lol I may just be outta the circle and that i didn't pick up on that consensus cfwprophet.

  7. So lately ive been able to dump ps4 kernel memory using hitos sdk and taking inspiration from cTurts work. I wanna be able to dump userland memory more easily without my ps4 crashing cause ive got the wrong addresses. I just so happened to find a function called sceSblRcMgrIsAllowDisablingAslr in my kernel dump and after tracing it it links to a unk_FFFFFFFF83324318 at in kernel memory 0xFFFFFFFF83324318. Now there are a bunch of other functions that refer to this address in a similar fashion to how the debug menu function worked. I also seen this function sceSblRcMgrIsSoftwagnerQafForAcmgr, im guessing this could be function to enable a qa menu? Unless all options are enabled in the debug menu and that is effectively what a qa menu would be, it just got me curious. Any way these functions link to this unk_FFFFFFFF83324318 in a similar fasion to how debug menu was. So im thinking that ASLR can be disabled like debug/store mode was enabled by kR105.

     

    // sysctl_machdep_rcmgr_debug_menu and sysctl_machdep_rcmgr_store_moe
    	*(uint16_t *)0xFFFFFFFF82607C46 = 0x9090;
    	*(uint16_t *)0xFFFFFFFF82607826 = 0x9090;
    	
    	*(char *)0xFFFFFFFF8332431A = 1;
    	*(char *)0xFFFFFFFF83324338 = 1;

     

    I understand those char pointers point to an unk that sets the values to 1 which would be the same for the unk linked to aslr disable. Yet i have no idea how he worked out where to change and what to change it to for the unsigned ints. They are in the hex dump but i see no reference to those locations in kernel code. Any help would be appreciated!

     

    Been looking into how we could possibly mount and decrypt ps4 filesystem partitions such as sbram and sflash, as well as the other partitions. Ive found a sceSblServiceCrypt function that i believe is the equivalent to geli or gbde for freebsd but sonys take on those interfaces. Makes sense since geli creates files like sflash0.geli and crypt would logically create a sflash0.crypt.

    • Upvote 1
  8. What about files in /dev like sflash0s0x0.crypt, im assuming that that is a partition that can be mounted as well? Could finally get a glimpse of the flash decrypted then mabye... there is also sbram0.crypt in /dev which appears to be the ddr3 ram that mediacon is connected to (south bridge ram?) which is also a mountable partition then? correct me if im wrong.

  9. I got excited there hoping it was that simple lol, that makes more sense now thanks. So basically to add files in or change them we need to edit whats inside those encrypted partitions. Not a sandboxing issue or a matter of running the ftp in kernel mode then. So just mounting with rw on them will suffice then.

  10. 1 hour ago, fx0day said:

    Don't know where you try to write but remember that there are some mount points who are in Read Only , so you have to mount them with R/W permissions if you want to write with Ftp on these ...

     

     

    hopefully it is just the ftp method lol, would that be in the ftp payload or would that be done in the ftp client?

    1 hour ago, eXtreme said:

    you have tested it with the new FileNinja tool ? or maybe it's possible to add those mount function to the tool. I have no connection to my ps4 with the tool, so I can't test it.

    Ive been using filezilla for my ftp, use fx0day's playground or add his bit to your own, you just connect to your ps4 ip with 1337 as the port and it works from there. It has the exploit bundled with the ftp enabling code.

     

    Ive just tested FileNinja and i think i know what your issue maybe.. do you get a error that it cant connect to 9050 or something like that? It just happened to me and had to wait like a minute or two until code execution was finished. then i connected. Sadly its only got read access so ill stick with filezilla for now.

    • Upvote 1
  11. Yes we need to either run ftp in kernel which can be done by crafting a ftp program and run it like a kernel payload, or find out where the filesystem rules are in say a kernel dump and the patch them like the other sand boxing restrictions were patched in the dlclose exploit. Im hoping its that simple though, and i could be wrong if there is some other process that checks file checksums or something and fixes the sand boxed files then even editing files in the filesystem via from kernel mode wouldnt solve this. Its weird there is the sandbox that bdj is loaded to and then in system_ex i beleive is where it is loaded from. Yet if i rename the file bdjstack.jar to something like testbdjstack.jar if i go up a folder then back in its changed back to bdjstack.jar, so some process or something has maybe a list of the directory. But idk if it has a checksum of every file since files change? unless after the ps4 edits a file it creates a new checksum to be logged? idk its all just speculation atm but i find it weird i can rename a file for one but then it is changed back.

     

    Yeah for that image i only tested putting a file in one directory lower so i haven't tested deeper sub folders if they will except files but i assume say if /mnt accepts files then every directory lower will too ie. mnt/xxx/ mnt/xxx/xxx and so on.

     

    EDIT: ah i was wrong with assumption, say if a restricted folder like system_ex is loaded under the mnt directory it cant be added to since the restrictions carry over. I just tested /mnt/sandbox/NPXS20001_0000/system_ex/app/NPXS20113/bdjstack

  12. I got the same thing when i tried to do what was mentioned in the other thread. There might be some other sand boxing for the filesystem or possibly a process that is running that preserves the file structure. The dlclose puts the process in root but the ftp is in userland as root, maybe if the ftp was running in kernel mode? If we had a loader that runs in kernel itd be interesting to see if testing with bdjstack.jar renaming works. Hitodama teased at it in his sdk..

    https://github.com/ps4dev/elf-loader/blob/master/ps4/binary/kernel/source/main.c

    Might not be hard to write one in C

     

    I made a little image a while back as well that showed what folders i could add files to without the error you talked about, sadly only file sub directories seemed to be unprotected.

    This was after running kR105s playground with the exploit + ftp initializer.

     

    http://imgur.com/51aGHI4

    • Upvote 1
  13. For anyone interested ive added hitodamas elf-loader into ps4-playground, it links to a lower directory with the html and js files. You can now load elfs on your ps4 with wifi-loader or what ever you want to use. You also need to netcat to listen to your ps4 on port 5052 and send the elf on port 5053. Ive only tested it on my windows pc with a different ip but it should work fine. Here it is. https://mega.nz/#!PM0G2ABJ!BVm6vZckrElKE8L9vzq8wczWcy0Rjp3-1Gu5bsp7H80

    • Upvote 1
  14. Hey has anyone gotten process memory dumping down? Ive been trying to do what CTurt described in his third article on PS4 hacking. Using ptrace to dump process memory, im missing bits like how to initialize things like mappingAddress etc that he must have intentionally left out. Anyone got any clues, so far SDKs from hitodama and CTurt have yet to provide examples on how to dump ps4 memory, at least in a meaningful way. lol unless im missing something. Im hoping that if i sflash is dumped from its PID then it will be decrypted?

  15. 3 hours ago, Red-EyeX32 said:

     

    Don't take my word for it, but I believe it is to mount it to SAMU so it can decrypt/encrypt it.

     

    That would make more sense in the file structure of O.=. header files. Yet why would binwalk detect compression on encrypted data? Perhaps SAMU also has compression capabilities as well. Ive only seen a few functions for SAMU in the 1.76 kernel which dont point to much but i could be mistaken. I wonder if it would be possible to dump decrypted sflash from ram or would by the time of the kernel execution in webkit this type of information would no longer be contained there.

    • Upvote 1
  16. *update*

    Just to get more of a jumping off point for anyone interested ive described a few things in the file headers that ive been noticing.

     

    I have seen to have found a pattern, when looking at elf files like the ones on the root of the drive, and comparing them to the shell ui elf as well as an eboot for an app several similarities were found. The first 4 bytes are always the magic O.=.  and then there is a string of 8 bytes after it like this 00 01 01 12 01 08 00 00 and these can be found in every file. It is unclear if these bytes are flags for compression or are just version numbers. It would support them possibly having some kind of version identity since all examples taken from a 1.76 machine have this string however looking at a pup file the later 4 bytes are different, could this be version related? What was also interesting was the next 4 bytes the made up the rest of the 16 byte line in hex seem to be constant in different types of elf files. A 00 02 70 02  was found in i guess operating system related elfs like mini-syscore, a 40 02 70 02  was found in the safemode.elf and this could be because it is completely differ in the sense it is booted like a separate kernel? And a 60 03 10 03  set of bytes were found on an application eboot as well as the shell ui elf does this mean that they are different because they run in the shell, idk ill need to look at more files to find a more correct trend if any. What was interesting was that the second row of 8 bytes mentioned in the first row are all the same on the elfs but a 1.76 pup file shares its 8 bytes with one of a different version on the dev wiki however further comparison needs to be done to find more of a relationship. Interestingly enough the newer pup files from ps4 firmware don't seem to have the magic at least from what ive seen, but i need to confirm this edit* they do contain the magic but they now feature 32 bytes before it as well as a chunk of data located in the researved area. Finally to wrap this up from my samples ive seen that the following rows of bytes on all the elf files contain 2 sets of 3 bytes that show different offsets perhaps start and length. Interestingly enough to further support them being offsets the second lot of 3 bytes on the start of this offset table (here being 04 00 22) is constant for files with the same size header and differs on files with larger compression headers such as the shell elf and eboot.bin.

     

    here is a visual representation..

    AlXMJ52.gif?1

    • Upvote 2
  17. Hey has anyone got any insight into ps4 elf files and the sflash0 files. When looking at ps4 elf files such as the ones located on the root of the filesystem ( mini-syscore.elf, safemode.elf, SceBootSplash.elf, SceSysAvControl.elf) they all appear to be scrambled either encrypted or compressed. They don't show the obvious signs of being encrypted since they aren't labeled as .self files and also running binwalk heuristic analysis on them reports that they are most likely compressed. Ive read somewhere that some ps4 files are compressed but then have a further level of encryption beneath. At the moment i haven't seen any information in the scene or else where regarding decompressing theses files. There is a suggestion made on the dev wiki however. http://www.psdevwiki.com/ps4/Talk:SLB2_structure Johndrinkwater mentions the structure of the inner pup magic and some other values that could point to files being lzma compressed. Ive tried all sorts of tricks to decompress them but nothing has worked. Something that is common though is that all files such as ps4 update files, eboots, elf files, and sprx files all have the O.=. or x4F x15 x3D x1D magic in them. Something that is also puzzling me is the relationship of the sflash0 files. Cturt mentioned that he could dump decrypted flash partitions from the /dev/ directory, after looking at them the flash files just appear to be the same as they are if you dumped them with a flasher. They have a main dump file and then many smaller versions that seem like cut portions of the same flash file just so the ps4 can direct to different chunks of its data easier. There is also the matter of the .crypt files which are needed for decrypting? Binwalk reports that the flash is encrypted with its heuristic analysis further supporting that the elf files are compressed since i was worried about a false positive on them. So was Cturt wrong about the flash files, or did he decrypt them with samu and was able to dump those? Hopefully we find ways as well to decrypt ps4 system files with SAMU so that we can analyse the system further, however a fuck up like Sony has made in the past doesnt look likely if they just gave AMD the job of making sure their system is secured with SAMU. There are a lot of unanswered questions and i haven't really seen anyone asking them or document this so i wanted to get a discussion on the matter.

    • Upvote 1
  18. Currently i get the linux equivalent on 3.7 clang however i did remove all clang versions but the toolchain and then built lips4 and the ps4link libs with it. Then finally for ps4link itself did the 3.7 install and compiled from that since the toolchain version cant find includes. Im probably suppose to compile everything with the toolchain version yes? including ps4link under elfldr...

  19. Its looking like ps4link still needs tweaking to get running, i currently have been experiencing out of memory errors without modification and im sure ive compiled it just like he has with toolchain clang doing the link lib and standard clang 3.7 building the ldr.js file. Ive tried using xerpi's FTPS4 code but its a year old and throws and out of memory error when loading it after dlclose. The farthest i got was having feedback from FTPS4 without an exploit, but even there i couldnt transfer any files; what are we supposed to use filezilla? There doesnt seem to be any documentation. I assume anyone with ftp transfer capability has been using there own modded code of others or themselves to facilitate transfers and that no complete public code exists yet. Honestly id rather just deal with a simple ftp binary like FTPS4 if its been known to be working, compared to the hoops jumped through to get ps4link working.

  20. Has anyone actually gotten big boss's ps4link up and running with out changing any of the code? Currently i can compile it on Ubuntu but i needed to pass export COMPILER=clang-3.7 for it to work since his instructions are for osx. Whenever i create a ldr.js file i always get an out of memory error when reaching stage 5 with no feedback from socat. If anyone does have it working it'd be less of a hassle on Ubuntu to just change my ip to that of the compiled ldr.js file. I believe its an issue with working with all the versions of clang and getting all the tools to be built with the tool chain, and even then its hard to say if parts even compiled properly or if its some unrelated issue. Some of the instructions are worded a bit backwards or unspecific so it tripped me up a couple of times until i figured out what i needed to do but it seems like kinda a lot to connect together to just get some ftp going. There is also Xerpi's FTPS4 code that an example of ps4link is based on as well but i haven't been able to get that working and after priv escalation it'll give me a out of memory too. From what i understand from big boss's instructions we need to compile libps4 and ps4 link librarys with the toolchain version of clang and then finish with copiling ps4link with the standard version of clang-3.7.

  21. Never mind i found the way to fix it.. What you need to do if you enable IDU mode with debug settings is that you need to hold the staff mode button combo here http://www.psdevwiki.com/ps4/Button_Combo_Menus

     

    It was confusing since i tried pressing it like the QA toggle method on the ps3 but it wouldn't work. The trick is that you need to hold these buttons down long enough till it says staff mode entered or something like that. At this point i had the XMB and had to go to user guide to re enable debug settings but this was because of initializing the system so it should be still on there if you haven't reinstalled the firmware. Just had to set IDU mode to off under system and then reboot to make the changes. Phew I was panicking then thinking that i had lost my 1.76 PS4 lol.

    • Upvote 2
  22. 14 hours ago, fx0day said:

    10mn ago i didn't know what was the "IDU" now i know :bash_head:

     

     

    I'm in the same boat, as soon as i got debug settings i was like what is this? Instinctively was reminded of DFU mode for iPhones, damn being impulsive. So far Ive wiped the drive and reformatted then reinstalled recovery 1.76 but IDU is still there :(

     

    12 hours ago, lezek20 said:

    Yes there is, but don't enable it, its useless.

    What solution do you know of lezek20? From what Ive seen maybe i need the disc version of the 1.76 update that is like 1.07 gb and then install that? Cant seem to find that version anywhere.

×
×
  • Create New...