Jump to content

wildcard

Regular Member
  • Content Count

    49
  • Joined

  • Last visited

  • Days Won

    3

wildcard last won the day on May 2 2017

wildcard had the most liked content!

Community Reputation

43 Excellent

Usergroups

About wildcard


  • User Group: Regular Member

  • Member ID: 1330

  • Post Count: 49

  • Posts Per Day: 0.03

  • Total Rep: 43

  • MOTD's Won: 3

  • Joined: 03/08/2016

  • With Us For: 1727 Days

  • Last Activity:

  • Currently:

Profile Information

  • Gender
    Other

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 ca
  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 s
  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
  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, i
  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
  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 belei
  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
×
×
  • Create New...