29 July 2017
~15 min
By saif
Exploiting MS17-017 EoP Using Color Palettes This post is an accompaniment to the Defcon 25 talk given by Saif. One of the core topics of the talk was the release of a new technique GDI object abuse technique, name Palette Objects. Saif presented a previously unreleased Windows 7 SP1 x86 exploit involving the abuse of a newly discovered GDI object abuse technique.
A complete white-paper on the topic was released and can be found here: Whitepaper
Intro After analysing the implementation of ptmalloc2 which, is a must read if you don’t know anything about the linux userland heap, I decided that for the second part of it, I would approach it as in a series of blog posts. Why? You might ask. Well it is easy for someone to tackle a problem in bite sized “chunks”. Understanding the heaps can be difficult and each of the techniques to be described in this series takes a decent amount of time to learn, understand and practice. Also, it is easier to find 15 minutes in a day rather than a few hours in a day. Also – hack the system.
Intro Hi there (again)! This series are going to an end as the next and feasible step is the widely known buffer overflow and its analysis in the heap and, I am not too convinced about it since the unsafe unlink method is long gone. But don’t be sad, today we are going for a bonus one! During the last post (double free attacks) one I stumbled across some weird behaviour that caught my attention by functions of the vfprintf.c family (for example printf or puts functions).
(If you’re new to this project, read the intro first)
For the past few months, I’ve been working on porting the USaBUSe stack from the custom hardware (AVR+ESP8266) to the Linux USB gadget stack. I wanted to make the techniques more accessible to people unfamiliar with embedded development, and I also wanted to take advantage of the variety of possibilities inherent in having a fully featured Linux environment to work in. I presented this work at HackCon in Norway.
03 January 2017
~28 min
By saif
Starting from the beginning with no experience whatsoever in kernel land let alone exploiting it, I was always intrigued and fascinated by reverse engineering and exploit development.
The idea was simple: find a 1-day patch with an exploitable bug but with no proof of concept exploit currently available, in order to start my reverse engineering and exploit dev journey with.Now the bug discussed here was not my initial choice: I failed at that one. It is actually my second choice and it took almost 4 months to fully understand the exploit and everything related to it.