Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Everything posted by SonyUSA

  1. It's been done, I saw someone in dev channel that can read/write to internal HDD and that's how they run Linux.
  2. OK look, grab Oracle VM, make a new VM (Linux, Ubuntu-64bit), attach the .iso to the "dvd drive", plug in your USB stick or External HDD, start the VM with NO virtual disk. Click Devices>USB>Then click on your portable device. Install it to the stick like that, then you're all set
  3. OK look, grab Oracle VM, make a new VM (Linux, Ubuntu-64bit), attach the .iso to the "dvd drive", plug in your USB stick or External HDD, start the VM with NO virtual disk. Click Devices>USB>Then click on your portable device. Install it to the stick like that, then you're all set
  4. Not extract, install it TO the USB stick. I'm gonna make a small FAT32 partition at the front of the disk then try installing ubuntu to the rest...
  5. I'm gonna go out on a limb and assume you either do not have a 1.76 firmware PS4 or you didn't put the kernel and initramfs on a USB stick plugged into the PS4.
  6. ... you aren't installing anything, it just runs in memory. You pull the power plug out, that's how you get back to PS4 Orbis.
  7. Low wifi strength/slow network could be causing problems in the payload, try hard-wire and use the online playground instead of self-host maybe?
  8. Your TV supports 1080 I'm assuming. After it goes black for a bit, try turning your TV off and then back on again, some TVs are wishy-washy when flipping inputs/video modes.
  9. Perhaps you aren't waiting long enough or you just think it's shutting off. The PS4 -does- have to reboot before Linux boots, so my TV loses incoming signal and takes a sec to pick it back up after the PS4 starts video output again. Try switching the TV input after waiting a sec when you run it.
  10. Erm... you ARE running the completed DLCLOSE exploit first as .bin ... right? I haven't tested running it right after jailbreak/root escalation, but I close the browser then re-open, as the documentation suggests before running a new function and it works great
  11. Works fine for me, if the USB stick isn't FAT32 it will do that.
  12. I don't understand your English half the time, but I hope it means fun tools for everyone soon! xP
  13. @bigboss Weren't you going to leave us a little "birthday present"?
  14. That may be, but you run into the same thing the WiiU faced... people wanted a back-ported version of some of the kernel based tools, but there was no reason to stay on a lower firmware so they never got ported. I think you are just causing yourself extra trouble in the long run... think of it this way: once you get the exploit stable and loading what you want it to load, you won't even need debug output so you will probably remove it from the code anyway to slim it/tidy it up, so you may as well hardcode it for 1.76 now and just remove it altogether later. Edit: The dynamic resolver will also help for -forward- firmwares when webkit bugs are released, and that's why he mentioned to use them. I don't believe he's worried about older FW...
  15. @Zer0xFF My PS4 was on 1.71, HOWEVER, as stated in the PS Playground readme, it uses 1.76 hardcoded stuff and never worked for me (out of memory, etc.) so I updated to 1.76 via USB. I don't think you need to worry about lower firmwares -just- yet because 1: No reason to stay lower firmware and 2: Probably he won't back port to older firmwares because they are rare and can't test reliably.
  16. I feel like there is some kernel memory corruption that still needs to be addressed. Mainly, you can't cleanly shut down the system. Edit: Nevermind, I saw they realized that on the other forum ;D
  17. You have a typo in uchar unknonw[0xE4] // Carefull!
  18. This should narrow it down maybe: http://pastebin.com/84kaQUrL Lol look at this: LOAD:FFFFFFFF823F5510 mov rdx, offset aWBuildJ0073_10 ; "W:\\Build\\J00739801\\sys\\freebsd\\sys"... They use W: drive xD
  19. Have a thing: http://pastebin.com/Uhfwri9K
  20. Newer code set never gets to Kernel Patch success or fail: http://pastebin.com/YfBQ6SD2 // At this point we should have root and jailbreak if(getuid() != 0) { printf("\t[-] Kernel patch failed!\n"); rc = -2; goto err; } printf("\t[+] Kernel patch success!\n"); // Lets stop the system to get all the messages over TCP printf("\t Lets halt the system to make sure we get all the messages!\n") while (1);
  21. Yeah, I see now, it truncates lots of data into "Packet" output text string, however the log shows the real output... Just know if you see "Packet" to check the log for all the real data
  22. Boop! Live TCP data is screwy... here we go: [+] Starting... [+] UID = 1 fd = 3840 queue created = 6400000f01 queue created = 6500000f02 queue created = 6600000f03 queue created = 6700000f04 queue created = 6800000f05 queue created = 6900000f06 queue created = 6a00000f07 queue created = 6b00000f08 queue created = 6c00000f09 queue created = 6d00000f0a queue created = 6e00000f0b queue created = 6f00000f0c queue created = 7000000f0d queue created = 7100000f0e queue created = 7200000f0f queue created = 7300000f10 queue created = 7400000f11 queue created = 7500000f12 queue created = 7600000f13 queue created = 7700000f14 queue created = 7800000f15 queue created = 7900000f16 queue created = 7a00000f17 queue created = 7b00000f18 queue created = 7c00000f19 queue created = 7d00000f1a queue created = 7e00000f1b queue created = 7f00000f1c queue created = 8000000f1d queue created = 8100000f1e queue created = 8200000f1f queue created = 8300000f20 queue created = 8400000f21 queue created = 8500000f22 queue created = 8600000f23 queue created = 8700000f24 queue created = 8800000f25 queue created = 8900000f26 queue created = 8a00000f27 queue created = 8b00000f28 queue created = 8c00000f29 queue created = 8d00000f2a queue created = 8e00000f2b queue created = 8f00000f2c queue created = 9000000f2d queue created = 9100000f2e queue created = 9200000f2f queue created = 9300000f30 queue created = 9400000f31 queue created = 9500000f32 queue created = 9600000f33 queue created = 9700000f34 queue created = 9800000f35 queue created = 9900000f36 queue created = 9a00000f37 queue created = 9b00000f38 queue created = 9c00000f39 queue created = 9d00000f3a queue created = 9e00000f3b queue created = 9f00000f3c queue created = a000000f3d queue created = a100000f3e queue created = a200000f3f queue created = a300000f40 queue created = a400000f41 queue created = a500000f42 queue created = a600000f43 queue created = a700000f44 queue created = a800000f45 queue created = a900000f46 queue created = aa00000f47 queue created = ab00000f48 queue created = ac00000f49 queue created = ad00000f4a queue created = ae00000f4b queue created = af00000f4c queue created = b000000f4d queue created = b100000f4e queue created = b200000f4f queue created = b300000f50 queue created = b400000f51 queue created = b500000f52 queue created = b600000f53 queue created = b700000f54 queue created = b800000f55 queue created = b900000f56 queue created = ba00000f57 queue created = bb00000f58 queue created = bc00000f59 queue created = bd00000f5a queue created = be00000f5b queue created = bf00000f5c queue created = c000000f5d queue created = c100000f5e queue created = c200000f5f queue created = c300000f60 queue created = c400000f61 queue created = c500000f62 queue created = c600000f63 queue created = c700000f64 m kernelAllocation: queue created = c800000f65 m2 kernelAllocation: queue created = c900000f66 Trigger sceKernelDeleteEqueue mapping = 201284000 perform overflow? Calling sys_dynlib_prepare_dlclose moment of truth Trigger sceKernelDeleteEqueue [+] Entered critical payload
  23. @Zer0xFF Basically, what I was saying is that code paste was the only thing coming over TCP before the PS4 shut off, so I'm having different results than the log file you posted previously :/ P.S. I have a kernel dump with links/names and everything, do you need it? @bigboss Do you have this working? Any chance you are gonna share...?
  • Create New...