vitasploit - Exploitation Framework

[MichelMichel]

I did a little Kernel info leak detector.

Some results:

Code: Select all

[+] DBG:  ModuleName: SceDriverUser Offset: 0x15b4 SyscallNumber: 0x6e1
...
[+] DBG:  @9 CALL 6e1 ( 0x82953cb0, 0x-1, 0x1dd0f85b, 0x188ba32d )
[+] DBG:  res 0x0
[+] DBG:  e0e0 ff46 b086 ff46 8010 0047 0000 7044 
[+] DBG:  c086 9246 70f9 fe46 7074 fe46 0000 7044 
[+] DBG:  901d 0047 905c 8f46 a067 ff46 0000 7044 
[+] DBG:  38b3 0047 203a 0047 c038 3747 0000 70c4 
[+] DBG:  809d 3647 f890 0047 d8d9 0047 0000 70c4 
[+] DBG:  a086 ff46 68d8 3747 4060 0047 0000 70c4 
[+] DBG:  505b fe46 2099 fe46 a0b6 9146 ffff ffff 

Code: Select all

[+] DBG:  ModuleName: SceDriverUser Offset: 0x15a4 SyscallNumber: 0x540
...
[+] DBG:  @3 CALL 540 ( 0x82953cb0, 0x2710d2f4, 0x71920eb1, 0x5c )
[+] DBG:  res 0x80022005
[+] DBG:  2000 0000 50c8 ff46 1ded ff46 ea70 0047 
[+] DBG:  ffff ffff ffff ffff ffff ffff ffff ffff 

I am not sur, but I think those leaks are unintialized structures (or elements of structure) in kernel stack.
Lot of value arround 0x46000000-0x47000000, kernel base at 0x46000000??... and allways the same even if the VITA restarted. No KASLR ?
Can someone validate or not my guesses ?

Advertising

[Hykem]

Hmm... Nice approach. I'll do some cleanup and add the fuzzer part to vitasploit after I port it over to some other firmwares (should be possible for most of them, since I was careful to have IP register manipulation on all of them).
Those values could be uninitialized structures yes, but are you sure they come from the Kernel's address space? There is KASLR after firmware 1.69, so those values should be different on each run. The most logical explanation is that they aren't addresses, but something else (IDs for example).

Advertising

[MichelMichel]

I'll do some cleanup

I'm sorry about my dirty code, I am working on it and I change it every 5 min

but are you sure they come from the Kernel's address space?

Not sur at all ! But the range is really really interesting and the values are 8-byte aligned.... I will test other thing this evening... to be sur.

There is KASLR after firmware 1.69, so those values should be different on each run.

Can you give me some paper about how people explain that >1.69 firmware come with KASLR ?
I will try to investigate better this evening

[MichelMichel]

Changelog:
* Better argument repartition
* Randomized user land buffer
* Easy to use function
* Error code
* Config

Result, more crashes and it is now easy to find interresting syscall
Example:

Code: Select all

[+] DBG:  Fuzz SceShellSvc@0xf4b4
[+] DBG:  @0 CALL f54 ( 0x11d, 0x45b24db5, 0x690a47bd, 0x15b )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_PID
[+] DBG:  @1 CALL f54 ( 0xffffffff, 0x0, 0x110, 0x18b )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_FLAGS
[+] DBG:  @2 CALL f54 ( 0x82a13d30, 0x58bbcd03, 0xffffffff, 0x3c5 )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_PID
[+] DBG:  @3 CALL f54 ( 0x82a13d30, 0x0, 0x82a13d30, 0x82a13d30 )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_FLAGS
[+] DBG:  @4 CALL f54 ( 0xf0d9c, 0x1b321da0, 0x1a4, 0x6 )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_PID
[+] DBG:  @5 CALL f54 ( 0x59d9ca31, 0xffffffff, 0x33f, 0x51125 )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_PID
[+] DBG:  @6 CALL f54 ( 0x683a4c35, 0x507afc25, 0x44, 0x82a13d30 )
[+] DBG:  res SCE_KERNEL_ERROR_INVALID_PID

[Hykem]

Nice! Great job.
I've already ported the fuzzer for other firmwares internally, soon enough I'll push the changes to the repo.
Regarding the KASLR claims, I'm afraid there's no documentation proving it. You may want to reach out to Yifan Lu, since he was the first to conclude that. I strongly believe in his claim because he has his own user land exploit (via PSM) and was able to tackle the Vita enough to reach such conclusions.

[MichelMichel]

Hello,

I updated the fuzzer with some better "Natural" technics and more than 4 arguments.
Crashes are now more complex but It is still a crappy Fuzzer...
Next, week I will work on classification of syscall and their arguments to make this syscall Fuzzer a bit "smart".

My aim to make a "trinity-like" fuzzer https://github.com/kernelslacker/trinity

@Hykem, I'm really interrested by your next commit especially if you worked on syscall/function/argument classification.

[Hykem]

Sorry for the delay. I've finally pushed the latest changes to vitasploit.
The star addition is MichelMichel's syscall fuzzer, of course. I've changed it a bit so it has it's own files and loads separately from the rest.
I've included the Python tools for finding syscalls and gadgets (I plan on improving it to find more than just LDM gadgets) and I've generated syscall maps for firmwares 2.02, 2.12 (incomplete), 3.00 and 3.18.

The fuzzer now works on all firmwares and I've tested it myself on firmware 3.00 with some nice results. The instructions to use it are all in the README file.
Thank you very much for this MichelMichel! Feel free to send pull requests to vitasploit whenever you make improvements to the fuzzer.

I've also pushed a few interesting tests and functions. There's now an audio test to output static noise on the Vita, a mount test to mount several hidden temporary folders, an address range test to bruteforce and validate all addresses available in userland and a frame buffer test to draw inside the WebKit's frame buffer.
To see the frame buffer test in action you must keep touching the screen so it's constantly refreshed. I'll eventually add a way to do this programmatically without user interaction.

The other two less important tests are simply documentations of a few things I found. One is for sending IoDevctl commands and the other gets some kernel objects' IDs.

Enjoy!

[MichelMichel]

Hello,
What a great commit !

I'll watch to all your new tests, some are very interresting (IoDevctl, mount) !

Thank you.

[Hykem]

I've added the 3.3x exploit (viewtopic.php?f=54&t=42501) to vitasploit. The index.html page will now detect which firmware version the user has and redirect the browser to the appropriate exploit.
So far, only firmware 3.36 has ROP and executes the time function from SceLibc as a proof of concept. Progress will be reported in this thread.

Enjoy!

[x86]

Do we know the what the Vita's kernel is based on? I recall somewhere that it was based on FreeBSD? Please correct me if I am wrong.