sceVideocodecStop() kxploit
Posted: Fri Feb 27, 2015 6:34 pm
So I escaped from my studies for a while and decided to get back to reversing and trying to show people a little of sony's flaws. Ugly C reverse included!
The kermit function that breaks the kernel is sceMeWrapper_driver_4D78330C but we have to access it using sceVideocodecStop()
sceVideocodecStop() requires the values passed as argument0 to be valid. So it calls sub_00000C38() to make sure they dont stomp on any kernel address.
You might wonder how do we get past that values check of sub_00000C38()?. Well this is possible because of race conditions.
Basically we feed that sub with valid values, and when it succeeds (returns 0) we change the values using another thread that is being executed parallely.
After that, sceMeWrapper_driver_4D78330C is called and it nops 8 contiguous bytes on any address.
There are some conditions on the values you have to use that you might want to check by reading the C code I wrote.
C reverse fully commented
You can also see the reversed code assembly sceVideocodecStop.s, sceMeWrapper_driver_4D78330C.s
This is a try and fail case, thats is why we have to swap between valid and the exploited values a lot of times until it succeeds and our kernel code is executed.
Also, if you missed it you can check out the sceSdGetLastIndex() kxploit reverse and explanation
Enjoy
The kermit function that breaks the kernel is sceMeWrapper_driver_4D78330C but we have to access it using sceVideocodecStop()
sceVideocodecStop() requires the values passed as argument0 to be valid. So it calls sub_00000C38() to make sure they dont stomp on any kernel address.
You might wonder how do we get past that values check of sub_00000C38()?. Well this is possible because of race conditions.
Basically we feed that sub with valid values, and when it succeeds (returns 0) we change the values using another thread that is being executed parallely.
After that, sceMeWrapper_driver_4D78330C is called and it nops 8 contiguous bytes on any address.
There are some conditions on the values you have to use that you might want to check by reading the C code I wrote.
C reverse fully commented
You can also see the reversed code assembly sceVideocodecStop.s, sceMeWrapper_driver_4D78330C.s
This is a try and fail case, thats is why we have to swap between valid and the exploited values a lot of times until it succeeds and our kernel code is executed.
Also, if you missed it you can check out the sceSdGetLastIndex() kxploit reverse and explanation
Enjoy