Skip to main content

k3170

"So you are interpreters of interpreters?" - Socrates, Ion by Plato

Search This Blog

Pages

Posts
Post Series
Vulnerability Disclosures
About me
Books
Public Disclosure Policy

Posts

[Linux Kernel Exploitation 0x2] Controlling RIP and Escalating privileges via Stack Overflow

Posted by Keith Makan January 18, 2021

Exploit Development Linux Linux Exploit Development Linux Kernel Stackoverflows

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

[Linux Kernel Exploitation 0x1] Smashing Stack Overflows in the Kernel

Posted by Keith Makan November 27, 2020

Exploit Development Linux Linux Exploit Development Linux Kernel Stackoverflows

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

SporeCrawler : Binary Taint Analysis with Angr

Posted by Keith Makan November 12, 2020

Angr Binary Analysis Reverse Engineering Symbolic Execution Taint Analysis

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

[ELF Necromancy 0x0 ] Tricks for Resurrecting dead ELF files

Posted by Keith Makan November 11, 2020

CTF ELF Format Executable Linkable Format Linux Reverse Engineering

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

[Linux Kernel Exploitation 0x0] Debugging the Kernel with QEMU

Posted by Keith Makan November 10, 2020

Debugging Kernel Linux Exploit Development Linux Kernel

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

[Memory Corruption Bugs] Lftp Null pointer dereference (<= 4.9.1) in CmdExec::FeedCmd

Posted by Keith Makan June 20, 2020

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

[Learning LLVM I ] Introduction to the LLVM Pass Framework

Posted by Keith Makan April 06, 2020

Compiler Internals Compilers LangSec. LLVM LLVM Framework LLVM Pass Framework Reverse Engineering

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Popular Posts (Last Year)

[Linux Kernel Exploitation 0x0] Debugging the Kernel with QEMU

Hi folks, in this post I'm going to walk through how to setup the linux kernel for debugging. I will also demonstrate that the setup works by setting a break-point to a test driver I wrote myself. All the code will be available from my gitlab, all the links to my gitlab will be re-posted at the end. The setup I describe here re-uses some parts of the syzkaller setup, and for good reason later on in the post series I will break into a tutorial for the syzkaller tool as well. So lets get on with it. Screenshot of a successful debug session with full debug symbols for the kernel! We can even see the call to start_kernel and a frame before that as well! The Process Okay so we want to study kernel exploitation but given that the kernel isn't something totally accessible in userspace, its not as convenient to debug as userpace stuff, we need a bit of a run up before we can actually poke and prod the kernel to figure out how to write our exploits. So there's a number of importa

Introduction to the ELF Format (Part VI) : The Symbol Table and Relocations (Part 1)

This post is part of a series on the ELF format, if you haven't checked out the other parts of the series here they are: (Part I) : ELF Header https://blog.k3170makan.com/2018/09/introduction-to-elf-format-elf-header.html (Part II) : Program Headers https://blog.k3170makan.com/2018/09/introduction-to-elf-format-part-ii.html (Part III) : Section Header Table https://blog.k3170makan.com/2018/09/introduction-to-elf-file-format-part.html (Part IV) : Section Types and Special Sections https://blog.k3170makan.com/2018/10/introduction-to-elf-format-part-iv.html (Part V) : C Start up https://blog.k3170makan.com/2018/10/introduction-to-elf-format-part-v.html this In this and the next post I'm going to explore how Elf files manage to pull off the magic of symbol resolution as well as the format, offsets and records in the Elf that represent this information. There are many facets to this mechanism in the format, and before I get into each of them I'd like to

Introduction to the ELF Format : The ELF Header (Part I)

ELF Files are charged with using their magic to perform two holy tasks in the linux universe. The first being to tell the kernel where to place stuff in memory from the ELF file on disk as well as providing ways to invoke the dynamic loaders functions and maybe even help out with some debugging information. Essentially speaking its telling the kernel where to put it in memory and also the plethora of tools that interpret the file where all the data structures are that hold useful information for making sense of the file. Anyway that's as far as I've figured it out - the actual break down is a little less simple. I'll demonstrate why this is so here and over the next series of posts in the classic "Learn things by breaking them" style. ELF Header and Identification fields The first thing that appears in an ELF file is of course the header, which is like most things in file formats just a list of offsets in the file. Its purpose is to indicate essentially wha

Introduction to the ELF Format Part II : Understanding Program Headers

Welcome back folks! In the previous post I covered pretty much the most trivial parts of the ELF file format. In this post we are actually going to work with one of the most interesting mechanisms in the file - the program headers! I skipped some parts of the ELF header in the previous post and decided to cover them here specifically because they inform on the Program Headers anyway. Lets get started! Introduction : What are Program Headers? I mentioned in part 1 that the ELF format performs two tasks. A recipe for how to sublimate dead files into living processes and adds the bells and whistles needed to make the file look pretty to gdb, the dynamic loader and a bunch of other tools. Program Headers ( among other functions ) are more often for telling the memory loader where to put stuff. It also has some house keeping functions. We'll get into how these memory loading powers and formats work a little later for now its just important to keep in mind a good idea of what

[Linux Kernel Exploitation 0x1] Smashing Stack Overflows in the Kernel

Previous Post in Series : [Linux Kernel Exploitation 0x0] Debugging the Kernel with QEMU https://blog.k3170makan.com/2020/11/linux-kernel-exploitation-0x0-debugging.html Hi folks this blog post is part of a series in which I'm running through some of the basics when it comes to kernel exploit development for Linux. I've started off the series with a walk through of how to setup your kernel for debugging and included a simple debug driver to target. The post here carries on from this point and explores some stack security paradigms in the kernel. We're gonna add some stuff to that driver to make it do a dangerous memcpy and then look at whether we can manipulate memory structures with our input. I initially intended to cover full exploit to a root shell with this post but that proved a bit more challenging than I anticipated so I'm splitting this up into two posts. This one will cover almost everything right up to actually controlling the instruction pointer in the ker

[InfoSec Rant] "Unspecifying" vulnerabilities is a vulnerability for vulnerability specification.

There is a practice in the information security world in which vendors issuing statements about the vulnerabilities reported to them can withhold as much information as they like; reducing what is meant to be helpful identification and declaring of software errata as another place for companies to save face. It is literally like someone writing a book and lying about things they got wrong so the book keeps selling- given the strong language parallels I can make here this analogy is quite applicable! Essentially capitalizing not only on software but also on the errata of their software. Which is to say they make money from making mistakes in the way the have essentially declared they will make money i.e. "We said we would sell you this wonderful software, but it turns out is completely broken and possibly doesn't do anything we initially promised it does; so in order to preserve our rights to say it does the initial stuff we promised we are not really gonna tell you why the

[Linux Kernel Exploitation 0x2] Controlling RIP and Escalating privileges via Stack Overflow

Previous Post in Series : [Linux Kernel Exploitation 0x0] Debugging the Kernel with QEMU https://blog.k3170makan.com/2020/11/linux-kernel-exploitation-0x0-debugging.html [Linux Kernel Exploitation 0x1] Smashing Stack Overflows in the Kernel https://blog.k3170makan.com/2020/11/linux-kernel-exploitation-0x1-smashing.htm l this post Hi folks! I'm back and this time I've got a banger of a post; we're going to finish off the last part of the exploit chain for stack overflows. In the previous post we discussed some details of memory protections in the kernel and looked at what a few probes around some of the memory structures looked like. If you don't know how to debug a Linux Kernel, build one or build a Qemu image please check out the previous stuff in the series. In this post we're going to start really wielding our power over the stack and craft ROP chains and calls to some interesting functions. Controlling EIP (No Canary) Target Driver: https://gitlab.com/k3170ma

Archive

2021 1
- January 1
  - [Linux Kernel Exploitation 0x2] Controlling RIP an...

2020 6
2019 6
- December 2
- June 1
- March 2
- January 1
2018 23
- December 1
- November 2
- October 5
- September 3
- July 1
- June 2
- May 3
- February 4
- January 2
2017 19
- December 3
- November 2
- October 3
- September 6
- August 2
- July 1
- April 2
2016 3
- September 2
- February 1
2015 2
- July 2
2014 7
2013 10
- October 3
- August 4
- May 1
- March 1
- January 1
2012 23
- December 6
- October 1
- July 2
- June 1
- April 2
- March 1
- January 10

Show more Show less

Labels

About.me
addJavascriptInterface
Adult Swim
AI.
Alan Turing
Altcoin
Androguard
Android
Android Application Hacking
Android Application Security

Show more Show less

Report Abuse

Powered by Blogger

Keith Makan