Posts

Showing posts with the label Reverse Engineering

Reversing a bare bones Raspberry Pi Kernel : Branching To the Kernel

Image
I lost the first version of this post because of problem in blogger's auto-save function.

Anyway so if you want to get your own raspberry pi os kernel going, I share some cool posts on that in here and expand on them by unpacking some of the assembler code essentially reverse engineering it or "unrolling" the os. 
Setting up your Development Environment I think the explanation of the 'Roll your own Rapsberry Pi Os' at https://jsandler18.github.io/ pretty much sorts this out I can at least do the favor of confirming that this persons advice definitely does the job so check it out.  The post also discusses the background of why we need certain files in the project for instance like the linker scripts and kernel.c files. As a short summary here's the basic work flow:

1 - Write a linker script This is to make sure the compiler can recombined the boot.S and kernel.c parts 2 - Write a boot.S This file is to initialize the run time for your kernel and branch into i…

[Reverse Engineering Primer] Unpacking cramfs firmware file systems

Image
Reverse engineering firmware from the point of view of an attacker involves levering as much as possible what is accessible from the physical board. Of course the classic question this strives to answer is, if someone gets hold of my board what could go wrong? Reverse engineering some devices in the wild often exposes security keys, default passwords and other forms of security failures that can expose an unfair escalation of privilege or perhaps also allow a complete take over of the device right down to boot loader level - all of this sometimes also possibly learned by analyzing the firmware.

I'm going to talk about some of the more basic skill in getting toward exposing the code and other sensitive artifacts used by the device. Before you can find remote code execs and admin auth by pass vulns you need to get to grips with firmware image formats and embedded file systems.

Setting up the environment 
Before getting super in depth and writing our own file format parsers, machine …

Windows Exploit Development (primer II) : Corrupting Structured Exception Handling and Controlling Memory Pointers

Image
I folks this post is part of a series in which I introduce some good fundamentals in windows exploit development - basically documenting as I learn it myself!

In this post we are going to essentially going to find out how our input breaks certain structures in memory, find different ways to crash the program and discuss the fun things these crashes let us do with out input! Lets get going :)
What you need to get going Exactly the same as last time!
Windows Virtual Machine Debugger Tools for windowsEasy MPEG to DVD Burner (copy available on exploit-db)(optional) python script payloadgen.py mentioned later on in the post Corrupting Memory
I assume you've got everything sorted out in terms of debugging the application. If its broken in you can get it running after a breaking by using the "g" command like this:



It should start running unless for some reason it hits another breakpoint. Hit "g" as many times are you need to get the application running smoothly and re…

Windows Exploit Development (primer) : Debugging Threads and Analyzing Memory

Image
Hi folks I thought its about time to start blogging about the little experience I have in low level exploitation and analysis - so here goes. To start off on your windows exploitation journey you need to be able to get to grips with a tool and some tricks to get you look at your target the right way. In this post I cover somethings that may help a ton! 
Debugging ThreadsTo get started you are probably going to need a couple things sorted out first, namely a simple windows VM setup with debug tools (tons of tutorials out there on the internet) and a target to exploit: A Windows VM (Microsoft made them free which is awesome!)Windows Debug ToolsYou should grab a copy of  Easy MPEG to DVD Burner on exploit db.
Before we can start crashing programs and controlling EIPs we need to make sure we have the right view of the target we are exploiting. Windows debugger is actually pretty useful in this regard so open it up, open the target program and attach the debugger to it like so:




Once you've…