This post is about a coverage-guided, emulation based greybox fuzzer that makes use of a custom Just-In-Time compiler to achieve near-native performance. It works by lifting RISC-V elf binaries to an intermediate representation before JIT compiling them to x86 during execution. During JIT compilation the code is instrumented to enable fuzzing-improvements such as coverage tracking, asan, cmpcov, or snapshot-based fuzzing.
Since it currently only supports RISC-V it is still mostly a proof-of-concept, but working on this had a lot of educational value for me, and I believe that it still highlights many advantages of an emulation based fuzzing approach.
Anyone that has played souls-like games before knows that they can get quite challenging, so why not make our lives a little easier by writing some cheats for Dark Souls 3.
In this post, I am going to start by covering basic cheat engine usage to extract information from the game. Since just running the cheats through cheat engine is boring, I will continue by translating the cheat table into a dll and write a dll-injector that we can use to inject the hack into the game.
The code for both the dll injector and the actual dll is written in Rust.
This is the fifth part of a series on the Chrome browser and its javascript engine V8. After having learnt about all the major parts of the V8 engine in the previous parts, we can now finally start talking about actual exploitation. We will start by talking about various mitigations used by Chrome to make exploits more difficult. Next we will discuss what type of vulnerabilities we can expect in the browser and the basic building blocks that you can expect to see in most exploits.
This is the fourth part of a series on the Chrome browser and its javascript engine V8. This part's main focus will be on Turbofan, Chrome's just-in-time compiler. Turbofan is in charge of producing highly optimized machine code for the target architecture that the browser is being run on. To fully understand how all of this works, we will start by talking about the Sea of Nodes graph-representation that V8 uses for its optimizations and then proceed to walk through various optimizations passes performed by V8 while visualizing them using turbolizer to display the Sea of Nodes graph.
This is the third part of a series on the Chrome browser and its javascript engine V8. This part's main focus will be on how V8 manages its memory. We will start with some basic such as some commonly used objects and how the memory space is divided. Next we'll move on to pointer tagging, a concept I already mentioned the previous parts. We will cover how exactly objects are stored in memory including object maps and how V8 handles type transitions due to javascript's weak typing. Next we'll look at some specific objects in a debugger and analyze how exactly they are stored in memory. Finally we will close off this part by looking at V8's garbage collector.
This is the second part of a series on the Chrome browser and its javascript engine V8. This part's main focus will be on Ignition, Chrome's bytecode generator & interpreter. I will also briefly cover some surrounding aspects such as parsing and the abstract syntax tree (AST), both of which are part of the pipeline that eventually leads to Ignition.
This is the first part of a series on the chrome browser and its javascript engine v8. In this part I will start by covering general information about chrome's browser architecture, how v8 fits in and its general compilation pipeline to execute javascript code. Finally we will setup a suitable debugging environment and look at a small js program in the debugger.
My goal with this series is to make browser exploitation a little more accessible and to provide a strong baseline for anyone interested in getting started with this topic.
In this post I will cover the basics of return oriented programming in kernel land. Many of the overarching concepts are similar to usermode return oriented programming, however there are also some major differences. I will be demonstrating these concepts against an intentionally vulnerable kernel module on kernel version 5.8. The following mitigations will be enabled for this exploit: kcanary, smep, smap, kpti and kaslr.
This will be the first post in a series focused on writing a linux character device driver. This post covers the basics of initializing a driver and implementing simple open/release/read/write functions. Kernel modules are used to extend the kernel's functionality to support different devices and non-standard operations. This series will assume no prerequisite knowledge and cover the creation of a linux kernel module starting from the very beginning.
I recently decided that I wanted to start learning a bit about game hacking to become a better reverse engineer, and figured, what better target than the classic minesweeper game? This is the first game I ever reversed, so my process was definitely not the most efficient, but after about 5 hours I accomplished the 2 goals I set for myself when starting this:
1. Guaranteed Win
2. Print out all bombs at game start