Awesome

About

This is where I will post analysis of Public Exploits, or some of my 1day exploits.

Personally I think the best way to learn a public exploit is by understanding it line-by-line until I can understand the exploit to the fullest. I will post some of these (overly-commented ;) ) exploits so hopefully others can learn from it, and as an attempt to give something back to the community. Also for documenting purposes, cause these things kind of fade away from my head as time passes.

This is a commented version of freener's android LPE exploit
arm32
Heap overflow
This exploit overwrites an object pointer in another object. It uses ret2dir attack to make the corrupted pointer point to a predictable fixed address in kernel which holds the exploit payload. This exploit technique bypasses PXN & PAN.

This is a commented version of Jianqiang Zhao's android LPE exploit
arm64
Zero-out 16 bytes at an arbitrary address
This exploit wipes out 16 bytes of a useful global object, which is located at a fixed address in kernel.
A corrupted object pointer within the global object references exploit payload from userland. This kind of attack will not work on devices/kernels with PAN(or PAN emulation).

My attempt to understand the extra_recipe jailbreak
I was especially interested in the kpp bypass part. Although there were a couple slides on the subject where I could glean a vague image of the bypass, I really wanted to dig into the fine details and see what is actually going on inside the code
I also wanted to understand the final ingredients for a jailbreak(Installing Cydia, etc.)

I commented the part relevant to the actual bug, and how it was exploited.
The reason why I looked into yalu102 instead of the original exploit is because the port-feng-shui technique looked more cleaner and straightforward to understand.
The analysis stops right before the kpp bypass

I jump here because it had a little more information on the various numeric offsets.
Also, the patchfinder.c is intact, as opposed to yalu102 which there is only an object file.
The cydia part is kind of incomplete so I jump to the cydia branch after kpp

Trying to understand the ingredients for a jailbreak after tfp0 and post-exploitation

A detailed breakdown of Ian Beer's empty_list kernel exploit.
It uses amazing techniques to start from really weak primitives, to build a stronger AAR, and finally build a full-fledged task port. The port magic behind the exploit code is unbelievable. All of this with an 8 NULL byte heap overflow. Absolutely mindblowing.
I've scribbled some naive ideas to improve the reliability. Hopefully someone will release a more reliable version of the exploit in the future. :)
Thanks Ian Beer for the amazing exploit!

This is a commented version of @niklas_b's iOS Webkit exploit.
A huge thanks to kudima(@begger_dd) to the very clear and concise, thoroughly annotated writeup! :)
The writeup explains the JIT type confusion bug, some limitations on conversions of boxing/unboxing(which could introduce unreliability), and a detailed walkthrough of how the early/late AAR/AAW primitives are constructed. He also provides insight on the changes in exploitation techniques after the recent round of mitigations(index masking, ArrayBuffer backing store poisoning, Some changes on the mechanism of W^X JIT, changes in the JSObject structure, etc)

This is a commented version of kudima's WebKit infoleak exploit(fixed in 2018.8.27).
It stems from an incomplete fix from one of the bugs reported by lokihardt. The patch from lokihardt's report fixed the Double -> Object type confusion primitive, but didn't fix it the other way around; Object -> Double.
It sprays the webkit heap with butterflies containing a single object and a marker, and later on triggers the concat bug and fills a large portion of several double arrays with uninitialized heap data. It iterates through the uninitialized, buggy concat produced, double arrays until it finds the previously sprayed object's address, and leaks it.
Thanks again kudima(@begger_dd) for the nice exploit and writeup! :)

This is another contribution from kudima. It is a commented version of kudima's WebKit remote code execution exploit(fixed in this commit). It is fixed in iOS 12.1, and works up to iOS 12.0.1.
The issue is that while executing code in baseline-jitted forin loops, you can introduce code that frees the StructureID object backing the JSOBject and trigger the garbage collector, but the garbage collector doesn't mark the "JSPropertyNameEnumerator->m_cachedStructureID" member, and the StructureID object that "JSPropertyNameEnumerator->m_cachedStructureID" points to gets freed during sweep phase resulting in a dangling pointer.
After the StructureID object is freed with GC, you can introduce code that creates a new StructureID object, which takes the previously freed "StructureID object" slot.
By freeing the StructureID of object A, and then making object B create a new StructureID which takes it's place, it is possible to make a type confusion situation because "JSPropertyNameEnumerator->m_cachedInlineCapacity" is set to object A's inline property size, while "JSPropertyNameEnumerator->m_cachedStructureID" points to the new Structure ID object which represents object B. This makes a check in 'op_get_direct_pname' pass and lets object B access inline properties out of it's boundaries.
This can be abused to build stronger primitives such as AAR/AAW, and further use that to execute arbitrary code.
Thanks kudima(@begger_dd) for the cool exploit and very detailed writeup! :)

One day I looked at singi's exploit after it was presented at Zer0con 2018, and decided to improve it.
This is a standalone version of the exploit, before I integrated it into pwnjs.
The improvements include
- Increased reliability(works flawlessly after extensive browsing sessions with contaminated memory)
- Removed all hardcoded offsets to make it compatible with various browser versions
- Used a different exploitation technique(the standard misalign technique)
- Eventually integrated it into the pwnjs framework by creating a webkit prototype
- Made the code a lot more readible, and added lots of comments
Special Thanks
- qwertyoruiop & Samuel Grob for the amazing phrack article and public exploits
- Brian Pak & Andrew Wesie for the awesome pwnjs framework!