Question for Experts and Developers

H

hawboutnow

Forum Noob
Hi everyone
I wanted to ask you ( if you may please ) to give a full explanation on what is the Lv1 & Lv2 peek/pook , the way kernel exploit is done , debugging and other stuff . i've always been interested in these things but i haven't got any experience with them since i haven't majored in software engineer or computer science but i was always in love with coding and pen testing and security assessment , that is why i began learning python a while ago , currently learning c++ and c# , and in the future aiming for java and sql and i would really appreciate it very much if you could help a friend out , on what are these concepts that i keep hearing about around here, what links or good books i should read , online courses and what languages would benefit me for this purpose , as i'm eager to join your awesome community of developers
i would very much appreciate any help you guys give me :)
 
If you are serious about this I suggest you start looking into FreeBSD architecture as the ps3 OS is basically a BSD OS.

I can only give you a brief summary with only very rough descriptions. If you wish details you will need to do your own research.

The PS3 OS is basically organised in 3 main tiers.
The first part to get loaded on boot is the hypervisor (lv1), its role is to setup hardware, devices, memory management etc... It is the lowest tier of the OS.

Once loaded, the hypervisor launches the supervisor, commonly called lv2 kernel.
The lv2 kernel contains all the code related to syscalls among other things.
Both lv1 & lv2 run in privileged mode. The memory space used by lv1/lv2 is NOT accessible for reading or writing by any user application running in userland including vsh.self.

Finally, the supervisor will execute vsh.self in userland. Vsh.self will in turn create the XMB.
Userland is the only memory space that a user application can address, it's also the only address space we can properly debug using ProDG or IDA.
When a user application requires to run some kernel code, it can only do so by calling syscalls.
Syscalls are the only way to interact with the kernel in a similar way to Linux.
Check the ps3 syscalls list. http://www.psdevwiki.com/ps3/LV2_Functions_and_Syscalls

To modify the kernel behaviour, the only way is to patch the kernel code however that code is placed in kernel memory which isn't accessible by a user application. For this reason, hackers created new syscalls like lv2 peek & poke.
Lv2 peek is a syscall that allows to read 64bit of data at a time in kernel memory space. Lv2 poke allows to write 64bit of data at a time in kernel memory.
Using these 2 syscalls, a user application can read & write to the kernel & kernel patching becomes possible from userland.
 
thank you very much bguerville , i really appreciate your work and thanks for the response , it really helped clearing some clouded informations i had about the subject, i'm really serious about learning these things and i hope i'll have the chance to work with you in the future
thx :)
 
hawboutnow said:
... what is the Lv1 & Lv2 peek/pook ,
... the way kernel exploit is done ,
... debugging and other stuff ...
Click to expand...

Lv1 = hypervisor binary
Lv2 = Game OS Kernel, comparable to your linux or windows kernel

Peek&Poke are custom syscalls added to them in order to easily read+write memory in their context from user space, a lower privileged context.
This is basically what they do:
Code: 
peek(int64 *address) {  return *address; }
poke(int64 *address, int64 value) { *address = value; }

Which kernel exploit? For the psjailbreak USB kernel exploit you can watch the clip above from ccc, fail0verflow explains it in detail, same goes for the wiki.
You also have the poc from naehrwert exploiting the mount kernel system call:

https://nwert.wordpress.com/2012/09/19/exploiting-lv2/

bguerville was faster explaining :D
 
Btw you also asked how kernel exploits are made, there is no set answer for your question. There are many ways to achieve a kernel exploit.

If you want to discover some of those ways, I recommend checking the CVE listings for BSD kernel exploits.

The most straightforward way would be to find a syscall with a vulnerability.
The idea behind this is that by passing certain values for parameters to a vulnerable syscall, you can crash the kernel. This usually happens because the parameters aren't checked properly before the kernel code uses them.
Vulnerable doesn't always mean exploitable however, but in some rare cases, specially crafted parameters will not crash the syscall but instead do something more useful like divert the code execution for instance.

Here is a simple practical example, if you find a syscall that overflows an array or buffer of some kind on the stack, you could try to make the overflowing data overwrite the value of the next return address, which is always kept on the stack. If you can manage that without messing up the rest of the stack, instead of crashing the kernel, code execution can be kept alive & be diverted exactly where you decide. If, from there, you can execute kernel code fragments (called gadgets) using return oriented programming to patch the kernel code/data, you have created a kernel exploit!
 
hawboutnow said:
awesome info, i'll look more into that
you guys never cease to amaze me :)
Click to expand...
If you wanna learn about any of this, I strongly recommend that you start getting familiar with ppc. Use the IBM ppc tutorials & primers for starters. A bit scary at first but within a couple of weeks reading ppc code, you will feel quite comfortable if you already have a programmer's mindset.
You don't need to learn all the instruction mnemonics as you will realise that ppc is a language & like most languages, most words are rarely used.

And to get a better idea of the basic overflow technique I just described in the previous post, you can open any ps3 elf in IDA (you will need the ps3 plugins for IDA).
Once the elf file has been analysed, if you look at any sub, you will notice that before a blr (return statement) you usually have a stack incrementing statement like this:
Code: 
addi r1, r1, 0xXX (adds 0xXX to the value stored in r1, usually 0xXX is > 0x60 & < 0x200)

r1 is the stack pointer in ppc & each sub uses its own stack frame where the sub's stack data is stored.
0xXX shows you the size (in bytes) of the stack frame for the current sub ie the portion of stack starting at stack pointer, which is used by the current sub to store/load its data.

Generally, above the addi statement, you will find statements loading the return address ie once the sub reaches blr (return = branch to link register), code execution will jump to the offset loaded in lr (link register) so to return to an offset, the sub's code must first load the offset into the lr register.

Code: 
ld r0, 0xYY(r1) (loads 64bit value found at r1+0xYY into r0) 
mtlr r0 (move the 64bit value found in r0 into the link register)

You will notice that 0xYY is always equal to 0xXX+0x10, ie the return offset of a current sub can always be found at current r1 value + sub stack frame size +0x10.

As you know exactly where to find the return offset of any executing sub, you can devise an overflow as suggested in previous post that will overwrite that value, if you manage that, kernel code execution is diverted & exploitation of the overflow vulnerability is successful, you have an entry point for kernel rop chains.
 
Last edited:
hawboutnow said:
i know i've asked you for a lot, but can you give me a name of good book that helped you with these things
Click to expand...
I never read a single book about ppc, only the specs, tutos & primers. Practice supposedly makes perfect though, right? ;)

For background reading on kernel exploitation, you could check "Designing BSD Rootkits" & "A guide to kernel exploitation: attacking the core".
FreeBSD publishes useful documentation on BSD architecture & kernel development on its website, you should get the various pdfs.
Regarding ROP, you might want to check the tutorial by corelan.be. It's x86 Windows based but the concept is identical & you will get fun cracking an old shareware at the same time. Lol

For more info about the ps3 environment, you need to read the documentation coming with the ps3 sdk (under license btw so no links here!).
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top