Advertising (This ad goes away for registered users. You can Login or Register)

vitasploit - Exploitation Framework

Open discussions on programming specifically for the PS Vita.
Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
Post Reply
Hykem
Guru
Posts: 75
Joined: Sat Jan 15, 2011 8:11 pm

vitasploit - Exploitation Framework

Post by Hykem » Thu Nov 13, 2014 7:26 pm

Hi. I've been working on the PSP/PSVita reverse-engineering scene for quite some time now and I've seen a bunch of repositories and source code aimed at the recently revealed WebKit exploit.
I too was working on this particular bug before and I've been keeping track of all the latest updates. Recently, I finally got a new unit and began working on native exploitation using the incredible work done by Amat Cama, johntheropper and freebot, who came up with a clean and effective solution to play around with this bug.

Anyway, I've opened up a repository with my version of an exploitation framework here: https://github.com/Hykem/vitasploit
It's obviously based on the "webkitties" project and features CodeLion/BrianBTB/BBalling1's module dumping code and nas's sceSysmoduleLoadModule finding (which was published a couple days ago).

The main difference here is that I've gathered all code in one single solution, so vitasploit combines webkooz, akai, memtools_vita and JSoS-Module-Dump-Release in a single project. The scripts can be used for both memory reading/writing and ROP code execution by changing a single variable.
I've also cleaned up a lot and implemented BBalling1's module dumper in a more user-friendly fashion.

In addition to the standard ROP tests (from "akai"), I've also implemented a memory alloc/free test using SceLibKernel syscalls. The memory allocated using these functions may be useful for writing more extensive payloads in the future.
Also, all the ROP chain code has been ported to firmware 3.00 and I currently intend on porting it over to as many firmwares as possible. Some firmwares (e.g.: 3.01) may still use the same offsets (just like 3.18 uses the same code as 3.15), but it's most likely that they all need recalculations for this to run on them.
The main goal is to dump all modules across firmwares for differential analysis and study the poisoned NIDs (after firmware 2.06).

On a side note, as you noticed, nas published a method to load more modules into user memory in order to dump them afterwards. This requires finding SceWebKitProcess' base offset in advance (which you can do by running the module dumper once and take note of it, then change it in include/exploit.js).
I've implemented this in vitasploit and BBalling1 did so as well in JSoS-Module-Dump-Release, so here's the list of all user modules that could be loaded in a 3.00 unit:

Code: Select all

SceAacenc.seg0.bin
SceAacenc.seg1.bin
SceAppUtil.seg0.bin
SceAppUtil.seg1.bin
SceAtrac.seg0.bin
SceAtrac.seg1.bin
SceAvcodecUser.seg0.bin
SceAvPlayer.seg0.bin
SceAvPlayer.seg1.bin
SceBeisobmf.seg0.bin
SceBeisobmf.seg1.bin
SceBemp2sys.seg0.bin
SceBemp2sys.seg1.bin
SceClipboard.seg0.bin
SceClipboard.seg1.bin
SceCommonDialog.seg0.bin
SceCommonDialog.seg1.bin
SceDriverUser.seg0.bin
SceDriverUser.seg1.bin
SceFiber.seg0.bin
SceFiber.seg1.bin
SceGpuEs4User.seg0.bin
SceGpuEs4User.seg1.bin
SceGxm.seg0.bin
SceGxm.seg1.bin
SceHafnium.seg0.bin
SceHafnium.seg1.bin
SceHandwriting.seg0.bin
SceHandwriting.seg1.bin
SceIme.seg0.bin
SceIme.seg1.bin
SceLibc.seg0.bin
SceLibc.seg1.bin
SceLibDbg.seg0.bin
SceLibDbg.seg1.bin
SceLibFios2.seg0.bin
SceLibFios2.seg1.bin
SceLibft2.seg0.bin
SceLibft2.seg1.bin
SceLibGameUpdate.seg0.bin
SceLibGameUpdate.seg1.bin
SceLibHttp.seg0.bin
SceLibHttp.seg1.bin
SceLibKernel.seg0.bin
SceLibKernel.seg1.bin
SceLibLocation.seg0.bin
SceLibLocation.seg1.bin
SceLibLocationExtension.seg0.bin
SceLibLocationExtension.seg1.bin
SceLibMp4Recorder.seg0.bin
SceLibMp4Recorder.seg1.bin
SceLibNetCtl.seg0.bin
SceLibNetCtl.seg1.bin
SceLibPgf.seg0.bin
SceLibPgf.seg1.bin
SceLibPspnetAdhoc.seg0.bin
SceLibPspnetAdhoc.seg1.bin
SceLibPvf.seg0.bin
SceLibPvf.seg1.bin
SceLibRudp.seg0.bin
SceLibRudp.seg1.bin
SceLibSsl.seg0.bin
SceLibSsl.seg1.bin
SceLibVitaJSExtObj.seg0.bin
SceLibVitaJSExtObj.seg1.bin
SceLibXml.seg0.bin
SceLibXml.seg1.bin
SceLiveAreaUtil.seg0.bin
SceLiveAreaUtil.seg1.bin
SceMp4.seg0.bin
SceMp4.seg1.bin
SceMusicExport.seg0.bin
SceMusicExport.seg1.bin
SceNearDialogUtil.seg0.bin
SceNearDialogUtil.seg1.bin
SceNearUtil.seg0.bin
SceNearUtil.seg1.bin
SceNet.seg0.bin
SceNet.seg1.bin
SceNetAdhocMatching.seg0.bin
SceNetAdhocMatching.seg1.bin
SceNgsUser.seg0.bin
SceNgsUser.seg1.bin
SceNotificationUtil.seg0.bin
SceNotificationUtil.seg1.bin
SceNpActivity.seg0.bin
SceNpActivity.seg1.bin
SceNpBasic.seg0.bin
SceNpBasic.seg1.bin
SceNpCommerce2.seg0.bin
SceNpCommerce2.seg1.bin
SceNpCommon.seg0.bin
SceNpCommon.seg1.bin
SceNpManager.seg0.bin
SceNpManager.seg1.bin
SceNpMatching2.seg0.bin
SceNpMatching2.seg1.bin
SceNpMessage.seg0.bin
SceNpMessage.seg1.bin
SceNpPartyGameUtil.seg0.bin
SceNpPartyGameUtil.seg1.bin
SceNpScore.seg0.bin
SceNpScore.seg1.bin
SceNpSignaling.seg0.bin
SceNpSignaling.seg1.bin
SceNpSnsFacebook.seg0.bin
SceNpSnsFacebook.seg1.bin
SceNpTrophy.seg0.bin
SceNpTrophy.seg1.bin
SceNpTus.seg0.bin
SceNpTus.seg1.bin
SceNpUtility.seg0.bin
SceNpUtility.seg1.bin
ScePhotoExport.seg0.bin
ScePhotoExport.seg1.bin
ScePsp2Compat.seg0.bin
ScePsp2Compat.seg1.bin
SceSasUser.seg0.bin
SceSasUser.seg1.bin
SceScreenShot.seg0.bin
SceShellSvc.seg0.bin
SceShellSvc.seg1.bin
SceShutterSound.seg0.bin
SceSqlite.seg0.bin
SceSqlite.seg1.bin
SceSystemGesture.seg0.bin
SceSystemGesture.seg1.bin
SceTeleportClient.seg0.bin
SceTeleportClient.seg1.bin
SceTeleportServer.seg0.bin
SceVideoExport.seg0.bin
SceVideoExport.seg1.bin
SceVoice.seg0.bin
SceVoice.seg1.bin
SceVoiceQoS.seg0.bin
SceVoiceQoS.seg1.bin
SceWebFiltering.seg0.bin
SceWebFiltering.seg1.bin
SceWebKit.seg0.bin
SceWebKit.seg1.bin
SceWebKitProcess.seg0.bin
SceWebKitProcess.seg1.bin
Finally, I would like to invite all developers to contribute to this project. I think it would be a good idea to have a common repository to work on this.
Advertising

User avatar
heleius
Posts: 372
Joined: Tue Oct 08, 2013 12:48 am
Location: chaos
Contact:

Re: vitasploit - Exploitation Framework

Post by heleius » Thu Nov 13, 2014 7:40 pm

Awesome work!
Advertising
my console list is in your mom's bedroom...

ss4gogeta069
Posts: 633
Joined: Sun Jul 06, 2014 12:50 am
Location: Roundabout Alabammer
Contact:

Re: vitasploit - Exploitation Framework

Post by ss4gogeta069 » Thu Nov 13, 2014 7:45 pm

This all looks amazing! Wish I knew wtf it was! LOL
GAME GENIE ROCKS! CHECK IT OUT!
Game Genie Website

User avatar
_d3f
Posts: 7
Joined: Sun Sep 02, 2012 6:55 pm

Re: vitasploit - Exploitation Framework

Post by _d3f » Thu Nov 13, 2014 8:09 pm

Such things just make me grep my dusty vita and do a little bit of researching ;-)
  • PsVita - PCH-1004 - OFW 2.02
  • PsVita - PCH-2016 - OFW 3.51
  • PSP - PSP1001 - CWF 6.60 PRO-C

User avatar
MovingxTarget
Posts: 153
Joined: Sat Aug 03, 2013 6:57 pm
Location: Under a rock

Re: vitasploit - Exploitation Framework

Post by MovingxTarget » Thu Nov 13, 2014 8:47 pm

Someones gonna make the front page ;)

Hopefully the future for a full blown vita hack is slow. Dont get me wrong I want a native hack, but the way the vita is looking in terms of games is well... dry to say the least.

My reasoning is: Image Image not loading? http://imgur.com/ineBOWx

Piracy is just the end term result for all. And i doubt devs wanna work on a console that has its doors bused down to its kernel. Maybe a userland exploit would be dope since piracy cannot be achieved from there but please don't take it down to the kernel level where piracy will begin.Then again so *&^% is gonna eventually do it so *sigh*

Amazing work done by everyone so far, and i hope to see more. ;)
[spoiler]Image[/spoiler]

User avatar
Zecoxao
Posts: 281
Joined: Mon Sep 27, 2010 7:27 pm

Re: vitasploit - Exploitation Framework

Post by Zecoxao » Thu Nov 13, 2014 9:27 pm

this is the best thing the exploit has:

Code: Select all

//libkernel_mem_test("mem", SCE_KERNEL_MEMBLOCK_TYPE_USER_RW, 0x1000);
it'll allow in the end for the attacker to go to the kernel memory range, 0x81000000.
My sig is original :D

User avatar
HarmfulMushroom
Posts: 752
Joined: Wed Dec 25, 2013 10:02 pm

Re: vitasploit - Exploitation Framework

Post by HarmfulMushroom » Thu Nov 13, 2014 9:28 pm

MovingxTarget wrote:Someones gonna make the front page ;)

Hopefully the future for a full blown vita hack is slow. Dont get me wrong I want a native hack, but the way the vita is looking in terms of games is well... dry to say the least.

My reasoning is: Image Image not loading? http://imgur.com/ineBOWx

Piracy is just the end term result for all. And i doubt devs wanna work on a console that has its doors bused down to its kernel. Maybe a userland exploit would be dope since piracy cannot be achieved from there but please don't take it down to the kernel level where piracy will begin.Then again so *&^% is gonna eventually do it so *sigh*

Amazing work done by everyone so far, and i hope to see more. ;)
It's going to happen eventually, always does. All Sony can do is hope to delay the inevitable as long as possible. I can't wait for the day we finally reach that level myself, I always enjoy customizing my devices as much as possible. Piracy is a necessary evil to get to that point unfortunately.

Thanks for the release OP!

yifanlu
Guru
Posts: 760
Joined: Sun Mar 11, 2012 6:42 am
Contact:

Re: vitasploit - Exploitation Framework

Post by yifanlu » Thu Nov 13, 2014 9:52 pm

Zecoxao wrote:this is the best thing the exploit has:

Code: Select all

//libkernel_mem_test("mem", SCE_KERNEL_MEMBLOCK_TYPE_USER_RW, 0x1000);
it'll allow in the end for the attacker to go to the kernel memory range, 0x81000000.
I don't know what you mean by this but 1) kernel is < 0x40000000 (technically it can be anywhere 0 to 0xffffffff but this is a reasonable assumption for now), 2) 0x81000000 is the default base before aslr, and 3) memalloc returns only user memory.

User avatar
Zecoxao
Posts: 281
Joined: Mon Sep 27, 2010 7:27 pm

Re: vitasploit - Exploitation Framework

Post by Zecoxao » Thu Nov 13, 2014 10:52 pm

yifanlu wrote:
Zecoxao wrote:this is the best thing the exploit has:

Code: Select all

//libkernel_mem_test("mem", SCE_KERNEL_MEMBLOCK_TYPE_USER_RW, 0x1000);
it'll allow in the end for the attacker to go to the kernel memory range, 0x81000000.
I don't know what you mean by this but 1) kernel is < 0x40000000 (technically it can be anywhere 0 to 0xffffffff but this is a reasonable assumption for now), 2) 0x81000000 is the default base before aslr, and 3) memalloc returns only user memory.
regarding 2), can you explain me this? https://github.com/DHrpcs3/rpcs3/blob/m ... y.cpp#L135
My sig is original :D

yifanlu
Guru
Posts: 760
Joined: Sun Mar 11, 2012 6:42 am
Contact:

Re: vitasploit - Exploitation Framework

Post by yifanlu » Thu Nov 13, 2014 11:21 pm

Zecoxao wrote:
yifanlu wrote:
Zecoxao wrote:this is the best thing the exploit has:

Code: Select all

//libkernel_mem_test("mem", SCE_KERNEL_MEMBLOCK_TYPE_USER_RW, 0x1000);
it'll allow in the end for the attacker to go to the kernel memory range, 0x81000000.
I don't know what you mean by this but 1) kernel is < 0x40000000 (technically it can be anywhere 0 to 0xffffffff but this is a reasonable assumption for now), 2) 0x81000000 is the default base before aslr, and 3) memalloc returns only user memory.
regarding 2), can you explain me this? https://github.com/DHrpcs3/rpcs3/blob/m ... y.cpp#L135
Someone making an educated guess?

Post Reply

Return to “Programming and Security”