Jump to content


Regular Member
  • Posts

  • Joined

  • Last visited

  • Days Won


wildcard last won the day on May 2 2017

wildcard had the most liked content!


43 Excellent


About wildcard

  • User Group: Regular Member

  • Member ID: 1330

  • Post Count: 49

  • Posts Per Day: 0.02

  • Total Rep: 43

  • MOTD's Won: 3

  • Joined: 03/08/2016

  • With Us For: 2052 Days

  • Last Activity:

  • Currently:

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. lol shorter wires. confirmed, i can dump and write on 4.07 no brick guys.
  2. 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
  3. 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.
  4. 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
  5. For anyone interested, i got ptrace going for dumping ps4 process memory, still cant get at kernel space processes, still need to get proc_rwmem working like CTurt hinted at which could make that possible. Mind the comments and build with ps4dev/ps4sdk http://pastebin.com/qunQd1Zj
  6. 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.
  7. That pretty much answered my questions, thanks for the info. 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.. 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.
  8. 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.
  9. 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.
  10. I got your back, leaked it through gbase_samu_read_register. https://mega.nz/#!eZ0gABQB!_ywso3X8_utSe6v_30ZZ_LQz2p9RtrmkeRze2hssDSo
  11. 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.
  12. 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.
  13. hopefully it is just the ftp method lol, would that be in the ftp payload or would that be done in the ftp client? 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.
  14. 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
  15. 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
  • Create New...