Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Hykem last won the day on December 17 2015

Hykem had the most liked content!


58 Excellent


About Hykem

  • User Group: Developer

  • Member ID: 469

  • Post Count: 17

  • Posts Per Day: 0.01

  • Total Rep: 58

  • MOTD's Won: 1

  • Joined: 02/19/2015

  • With Us For: 2438 Days

  • Last Activity:

  • Currently:

Profile Information

  • Gender
    Not Telling
  • Consoles I Own
    PS Vita
    PS4 Slim
    PS4 Pro
    PS5 Digital

Contact Methods

  • Twitter

Recent Profile Visitors

2,485 profile views
  1. I would like to add that I wouldn't be posting any information about this if I wasn't completely sure about it. Also, the Christmas release is merely an intention, don't kill me if it's not done by then.
  2. Oh look, the IRC log caught my "Jailbread" idea. Anyway, I guess everyone should understand now why we warned CTurt so much. It's not about keeping stuff private, it never was.
  3. Quite a lot: - Running unsigned code: just patch the kernel calls that enforce header checks; - Decrypting system files: the kernel can do that for you; - CFW: patch the kernel carefully and you can have a nice custom firmware as well. One thing that won't be possible though is to get system keys.
  4. Sorry, I wasn't done writing, but my post was published by accident. I've updated my previous post.
  5. Not quite. The PS4 system is significantly different from the Wii U. Here's a quick comparison: - Userland (entry point was the same for both systems): - Wii U: exploited through the browser using CVE-2013-2842 and CVE-2014-1300; - PS4: exploited through the browser using CVE-2012-3748 (same one used on the Vita); - Kernel: - Wii U: PPC processor's kernel was exploited first using a bug in proprietary functions (OSDriver); - PS4: AMD x86-64 processor's kernel was exploited using CVE-2014-9322 (BadIRET) which was an exploit originally found in Linux based systems, but was quickly proven to be valid for FreeBSD (which is the base operating system of the PS4); - Going further: - Wii U: another processor (ARM) is responsible for crypto operations and uses a proprietary operating system (dubbed IOSU); - PS4: there's also another processor (also ARM) that is responsible for crypto operations (dubbed MediaCon); - Going even further: - Wii U: boot0 and boot1 represent the earliest stage of the boot chain and they haven't been compromised yet; - PS4: don't count on exploiting it's earlier boot stages; Both secondary processors run their own operating systems with their own kernels. Considering that the Wii U's IOSU was already defeated, the PS4 is still way behind that. You may compare this PS4 kernel exploit with the Wii U's PPC kernel exploit, but the PS4's x86-64 processor has more fun stuff in it. Also, the PS4 has yet another protection layer provided by AMD's technology in their APU: SAMU (http://www.google.com/patents/US20120102333). Don't count on having that defeated either.
  6. There's only one PSM exploit and it's the one used in UVLoader. Yifan Lu has it for years and it was never patched. The reason for releasing it now is because the PSM project ended. Nonetheless, it's a powerful exploit and Yifan used it for dumping Vita's RAM a long time ago.
  7. Here are all the ones we've discovered and are implemented in JPCSP and PPSSPP: 0x01020001 - Get UMD Primary Volume Descriptor 0x01020002 - Get UMD Path Table 0x01020003 - Get UMD sector size 0x01020004 - Get UMD file pointer 0x01010005 - Set UMD file seek 0x01020006 - Get UMD file start sector 0x01020007 - Get UMD file length in bytes 0x01030008 - Read UMD file 0x01D20001 - Get UMD device file current sector seek position 0x01F30003 - Read raw sectors from UMD device file 0x01F100A6 - Set UMD device file seek by sector 0x04100001 - Define decryption key (DRM by amctrl.prx) 0x04100002 - Set PGD offset 0x04100010 - Get PGD data size You can find their implementation and parameters here: https://github.com/gid15/jpcsp/blob/master/src/jpcsp/HLE/modules150/IoFileMgrForUser.java https://github.com/hrydgard/ppsspp/blob/master/Core/HLE/sceIo.cpp The commands 0x01D20001, 0x01F30003 and 0x01F100A6 are used for sector based operations, so they may be useful in this case. Also, The issue you're describing may be related to asynchronous operations. The asynchronous IO thread may act differently inside the pspemu, resulting in weird behavior (as opposed to a real PSP).
  8. We had to implement this by hand in JPCSP: https://github.com/gid15/jpcsp/blob/master/src/jpcsp/filesystems/umdiso/UmdIsoReader.java https://github.com/gid15/jpcsp/blob/master/src/jpcsp/HLE/modules150/ModuleMgrForUser.java PPSSPP has an identical implementation as well: https://github.com/hrydgard/ppsspp/blob/master/Core/FileSystems/ISOFileSystem.cpp https://github.com/hrydgard/ppsspp/blob/master/Core/FileSystems/ISOFileSystem.h https://github.com/hrydgard/ppsspp/blob/master/Core/FileSystems/VirtualDiscFileSystem.cpp For example, we found this for "Monster Hunter Freedom Unite": // For example: // MONSTER HUNTER FREEDOM UNITE ULES01213 // hleKernelLoadModule(path='disc0:/sce_lbn0x11981_size0x59c0') // and the sector 0x11981 is found inside a huge "DATA.BIN" file (a CD image): // PSP_GAME/USRDIR/DATA.BIN: Starting at sector 0xD960, with size 737 MB Depending on the game, you could try to manually read the file to which the sector belongs to, seek to the corresponding offset, read the contents and write them to a new file. You would then have to redirect somehow the IO calls to use that file instead, but I'm not sure if that's possible.
  9. Yep, I know. The point on thezander keeping his Wii U on 3.1.0 will be to check if the exploit can be adapted for firmwares higher than 3.0.1 (which was not entirely confirmed).
  10. Sure. If you manage to get the 3.1 binaries (since they can now be decrypted) I'll be more than happy to help you out and write the ROP chain for 3.1, since the current WebKit exploit just needs to be adapted. So, apparently the thread can be closed now, but for a different reason: http://gbatemp.net/threads/wii-u-hacking-discussion.367489/page-196#post-5362293 The person in question will remain anonymous, but I can confirm I have received the money.
  11. Thanks GregoryRasputin! Unfortunately, spending around 300 euros/340 dollars on a gaming console is just impossible for me, so without the donations there's no way I can help any further. The research is there and other members have access to Wii Us, but it has become clear that doing this remotely is just impractical. I guess for now this is as far as I can go. Thanks for the support though!
  12. Please check this post: https://gbatemp.net/threads/wii-u-hacking-discussion.367489/page-194#post-5362070 This thread can be closed. Thanks!
  13. Hmmm, that might be a problem. The current WebKit exploit needs to be adapted to run on firmware 3.1 (we only have it working from 4.1.0 to 5.1.0). However, don't update your unit regardless. It may come in handy for IOSU exploiting later on. Thanks for the help nonetheless!
  14. Thanks! Yes, you would get it back of course, but I don't know for how long I would need it. If, on the other hand, you wish to donate any amount, you could donate to: http://jpcsp.org/ Please check my post on GBAtemp here: https://gbatemp.net/threads/wii-u-hacking-discussion.367489/page-188#post-5355497 The issue is that whenever the exploit fails (e.g.: doesn't give the expected result), the console may need to be reset and the RPC server needs to be started again by the remote user. So, for remote testing, the user would need to stay active for as long as the testing would take.
  • Create New...