vitasploit - Exploitation Framework

[Hykem]

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

[heleius]

Awesome work!

Advertising

[ss4gogeta069]

This all looks amazing! Wish I knew wtf it was! LOL

[_d3f]

Such things just make me grep my dusty vita and do a little bit of researching

[MovingxTarget]

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 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.

[Zecoxao]

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.

[HarmfulMushroom]

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 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]

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.

[Zecoxao]

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

[yifanlu]

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?