plutoo and I found this bug back in september of last year. Effectively this will grant ROP in an IOS usermode process which may then be further used to target the kernel. The vulnerability itself is a TOCTTOU race condition.
Initially the ioctlv handling of the IOS kernel contained a major design flaw, namely that the buffer address verification of the vectors happens in-place provided that we supply more than 8 vectors. This enables the PPC side to change the buffer address after its verification. Due to the nature of the bug exploitation requires the number of vectors passed in to be relatively large.
The bug was fixed with version 5.2.0 by adding a new field to the device context that limits the number of vectors, which is set to 8 by default and may be changed using syscall 0x2E if required.
The goal was to gain ROP under an IOS usermode process. For this we had to look for a device that did not check the number of vectors itself. It turns out that “/dev/im” provides us with some very handy ioctlv handlers, namely:
Thus this allows us to write 8 bytes worth of data to an address we eventually control. With this arbitrary write we can now carefully setup a ROP stack inside the AUXIL process, overwrite the return address of one of the devices’ handler threads and get the handler thread to return by overwriting the corresponding message queue handle.
Note that this is by no means the only way to exploit this flaw – interested readers are encouraged to let us know about any alternative strategies they might come up with.
If you ever wanted to know what’s stored in a DVD’s BCA, you’ve probably read it out using your favourite device. Here I present you a different approach: reading it out by scanning the area and running “pattern recognition” on the image.
Here is a part of a Wii game that I’ve scanned:
After filtering and thresholding it looks like this:
The black and white image is then fed into a tool I wrote that will estimate the midpoint and the major and minor axes of the inner ellipse, detect all the BCA cuts around it, mark them and spit out the timing between the cuts. This timing can then be decoded into the actual data that is stored in the area. Note that the thick cuts are actually two normal ones that my scanner’s resolution didn’t pick up anymore, the tool will detect that too. Here is a part of a generated image (the blue lines are the detected cuts):
And here is a complete output too:
To be able to understand what is going to follow, I first have to do a little mathematics:
Let’s define a polynomial over a finite field of degree as () where is a prime number and is a finite field with elements. If we have ( for ) and with we can use Lagrange interpolation to directly calculate : .
But what are we going to use this for? Consider you want to divide a secret into different parts and you want that parts are required to reconstruct the secret. This is what is called a threshold scheme. We can use our little mathematics from above to implement such a scheme. Choose the secret and create a random polynomial of degree with . To create the parts (shares) evaluate the polynomial at random and distribute the pairs to the different participants (the can be public, the are private to each one). To reconstruct the secret, of the participants can share their and then use the explicit formula from above ([AS]).
Here is an example run along with some source of my implementation:
bn_t *N = bn_from_str(bn_alloc(32),
bn_t *s = bn_from_str(bn_alloc(32),
//Create random polynomial.
poly_t *p = ssecrets_create_poly(s, 3, N);
bn_t **lx = (bn_t **)malloc(sizeof(bn_t *) * 4);
bn_t **ls = (bn_t **)malloc(sizeof(bn_t *) * 4);
for(i = 0; i < 3; i++)
//Evaluate at random x.
lx[i] = bn_reduce(bn_rand(bn_alloc(N->n)), N);
ls[i] = ssecrets_create_share(p, lx[i]);
bn_print(stdout, "P(", lx[i], ") = ");
bn_print(stdout, "", ls[i], "\n");
bn_t *cs = ssecrets_calc_secret(lx, ls, 3, N);
bn_print(stdout, "secret = ", cs, "\n");
* P(9EF35877FC0E2DB6B76BFF03B8CFA2EADD90190719DA598482D1569C6F9CA1EF) =
* P(810A3DB3AB3E4EA758A535A0616A6C9E1FE08B610D5F0496911A1AFFD3BC8136) =
* P(37D9B47A812B434077C025ADA5300EA41778036222ECD4853E4D64CB92CDF135) =
* secret =
First one needs to understand, that an ideal decompiler, that will recover the original source code, is impossible to create. The process of compilation is removing a lot of high level information, such as used data types or loop types. Then optimization could re-arrange code/data flow, eliminate common subexpressions, perform function inlining, etc. Therefore any output of our decompiler will most likely not match the original source code, but if we do it right, we can get a (very) close approximation.
So what is it, that I’m doing at the moment?
Currently the decompiler will need to be fed with an ELF binary, that has its section headers present and from them it will extract information about executable and data regions. For every executable region it will then extract subroutines and split every of them into basic blocks. A basic block is a piece of code, that only contains simple operations and ends with a branch. This basics blocks might get split again, if a branch to any of its operation occurs from inside the subroutine. This way we will collect a list of all the basic blocks, can link them according to their exit branches and end up with the control flow graphs of all the subroutines. For identification of high level statements like ifs and loops (see [REC] for loop detection) we compute DFS and dominator trees and for later use the frontiers of each block (see [DOM] for used algorithms). Next we perform register liveness analysis to identify subroutine arguments and return values (see [LIV] for used algorithm). Now we can translate all the assembler instructions into simplified operations, e.g. translate “ori rt, ra, 0” into “rt <- ra” and identify local stack variables in that process too, following IBM’s SPU ABI specifications (see [ABI]).
More additional steps are then required to produce high level code, as you can see in the following list (entries marked with (DONE) are finished and working already):
- Extract text/data regions (DONE)
- Extract subroutines (DONE)
- Extract basic blocks (DONE)
- Create control flow graphs (DONE)
- Compute (reverse) DFS/dominator/frontier information (DONE)
- Extract high level statements using (reverse) DFS/dominator trees (DONE)
- Local and global liveness analysis to find subroutine arguments (DONE)
- Extract and simplify operations from every basic block (DONE)
- Transform operations into SSA form using frontier information (PARTIAL)
- Perform constant/expression propagation and dead code elimination (PARTIAL)
- Transform operations from SSA form
- Build expression tree from optimized operations
- Output high level (pseudo-)code from restored expressions
I’m currently looking into methods that don’t need SSA form to perform propagation, but if they don’t work (too well) I’ll have to stick with SSA. Here is the output of a little argument test program and here is the original source (R ~ register, S ~ stackvar, I ~ immediate).
After SPU decompilation is working, I plan to refactor the source code to make it more generic, so it’s easier to port it to other CPU architectures (e.g. PPC).
As the exploit that was used to dump lv0ldr/bootldr/howeveryouliketocallit is public now, let’s have a closer look at it to understand what’s going on. Here is what I have reversed from lv0 (it shares the syscon portion of the code with its SPU counterpart):
//In .data section.
static u8 tmp_pkt[0x800];
//Get size from sc packet.
#define GET_SIZE(pkt) ((pkt << 8) | pkt)
int read_cmpl_msg(/*...*/, u8 *payload_buf /*r5*/, int min_size /*r6*/, /*...*/)
//Get packet header.
memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, 0x10);
//Check packet size.
pkt_size = GET_SIZE(tmp_pkt);
if(pkt_size - 4 < min_size || pkt_size + 8 > 0x800)
//Run first sc_checksum.
//Read packet again (plus header!).
pkt_size = GET_SIZE(tmp_pkt);
memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, size + 0x1B);
//Get size again (not checked now).
//I suspect that this is actually a compiler 'quirk' and not a
//programmer mistake. The original source probably accesses the
//packet size through a structure and the compiler noticed the
//non const access of the packet and generated this read of the
//size member because it could have changed.
pkt_size = GET_SIZE(tmp_pkt);
//Let's have some fun (payload_buf on caller stack).
memcpy(payload_buf, tmp_pkt + 8, size - 4);
//Run second sc_checksum.
The syscon library implements some high level functions, e.g. to shutdown the console on panic or to read certain configuration values. Every of this functions internally uses another function to exchange packets with syscon and the exchange function uses the read_cmpl_msg one to get the answer packet. The top-level function will pass a fixed size buffer to the exchange function. So if we are able to control syscon packets, e.g. by emulating MMIO (and thanks to IBM we are), we can change the packet size between the two packet readings and overwrite the caller stack. And if we first copy a little stub to shared LS and let the return address point to it, we can easily dump the whole 256 kB.
Nothing more left to say now, let’s wait and see if this is going to be fixed in future firmware versions (we just have to check lv0 fortunately).
A long while ago KaKaRoTo pointed me to a stack overflow he found while reversing lv2_kernel. But there are two problems:
- The vulnerability is in a protected syscall (the SELF calling it got to have the 0x40… control flags set). So you’d first need to find a suitable usermode exploit (don’t ask us), that gives you code execution with the right privileges.
- The payload data is copied to lv2 heap first and the function will do a free call on it before the payload has any chance to get executed. This might not sound like a problem but it looks like lv2’s heap implementation will overwrite the free’ed space with 0xABADCAFE and thus destroy the payload.
Here is my sample implementation for 3.41 lv2_kernel (although the vulnerability should be present in all versions of lv2 up to the latest firmware), maybe someone of you will find a way to overcome problem (2.) and can get something nice out of it because right now it’s only good to crash lv2.
When metldr is encrypted at factory, a special keyset is set in the binary before encryption. Later when an isolated loader is loaded by metldr, it will copy the keyset to LS offset
0x00000. It consists of eid_root_key and eid_root_iv. To not having to use the same key for all eEID parts, several subkeys are generated from special data called individual information seed. These seeds are stored in the metadata header of isolated modules loaded by isoldr. When isoldr will load a module, it will call a subroutine that encrypts each seed chunk (
0x40 bytes) using eid_root_key and eid_root_iv. Then the so-called individual infos are passed in registers
0x100 bytes in total) to the loaded module where they are used further. Usually isolated modules have a seed section of
0x100 bytes but all of them (except sb_iso_spu_module) have all zeroes but the first
0x40 bytes chunk. You can, for example, find the recently published EID0 seed in the metadata section of aim_spu_module. Appliance info manager is used to get e.g. the target ID or the PSID from EID0. This explains why the seed can also be found in isoldr directly, since that one is checking EID0 too.
As you can probably think, a fair amount of reversing time and knowledge has gone into finding this, so stop calling us *swearwords* for not releasing information that could potentially lead to more piracy, because we think that this would do more harm to the “scene” than just keeping some information in private (for now). Also I can only encourage everyone that thinks about us this way or is greedy demanding for developers/reverse engineers to release their stuff, to fire up isoldr in IDA or disassemble it with objdump and try to reverse all this from start to end. We’ll see, who is able to pull this through on his own…