This tutorial will help you build a custom Linux distribution for your IoT/Embedded project using Buildroot (i.e: a Raspberry Pi). There are some other options out there but I find Buildroot to be consistent and easy enough so we’ll stick to it for the propose of this article.
Buildroot is a community-driven and open-source set of tools that will help you generate an entire root file system that you can then flash into a device.
It can build toolchains, rootfs, bootloaders, kernels and libraries all by its own.
You can read more about it on its official page:
To start with Buildroot you can download the proper version from the official page and access the official documentation uing the following links. …
The Game Boy uses a 8-bit computer chip similar to an Intel 8080. As it has only 256 instructions it’s an interesting candidate for experiments such as writing an assembler from scratch — and that’s what this article is about.
Here I’ll describe the process I went through when I wrote this Game Boy assembler in Node.js.
In case you want to try it just issue the following:
# option 1: using npm
npm install -g game-boy-assembler# option 2: using docker
docker run -ti alanvivona/gameboy
Now let’s jump into the process of writing such a thing!
The first thing we need is to analyze the instruction set and write a list of them. I extracted the instructions from this awesome manual and generated a file as the one you can see in the screenshot below. …
Today we are going to generate a simple keygen to crack this beautiful crackme named “Get The Password”. Here’s the beast:
Cool graph, isn’t it?
In the top part we can see there’s a pattern, right here:
So, what’s going on here? Well, basically…
cl is being used as an index, compared against a hardcoded value which increments each time (0,1,2..9) …
Today we are dealing with yet another .net crackme. Let’s see how it goes…
The crackme is a sort of X-times usage trial. After we’ve opened the executable 10 times we have the opportunity to test if we cracked the trial or not.
Using dotPeek we can decompile the binary, search for the class that is in charge of keeping track of the trial.
Using dnSpy we can not only inspect the binary but patch the code with ease. If we change the validation being made on this line in a way it can never be true we’d effectively cracked the binary.
And so I did, changing the hardcoded 9 to a 0 makes the validation useless as it could never be true.
Now we can start the binary as many times as we want without any issues!
Follow Infosec Write-ups for more such awesome write-ups.
Let’s see how to solve this .net crackme. Let’s try the crackme with some random credentials to see how it goes.
We can see reading through the code that the registration key depends on the result of a random value. My first idea was that maybe the random number generation is guessable when providing no seed for the constructor. Here’s the validation code.
But after checking how the Random constructor work when it’s given no seed I concluded that’s not an option. Here are the official docs for you to check.
As the key depends on this random value given by the
Random.Next()method the most efficient way to crack the binary is to patch it.
I removed the validation for the serial using dnSpy and as you can see here the cracked binary works for any username and password you provide.
And that was it! Hope you enjoyed this writeup
This time we are tackling this .net crackme. Let’s try it out first.
It’s a simple form requesting a username and a serial key.
On the main form code, we can see the validation method being called inside the confirmation button click method.
On the form creation method values are being set for each Label component, which are the labels showing the product ID. The only textbox element is the username.
So, given any username, this is the correct serial.
Let’s test this out
Great! we cracked the binary!
This time I’m tackling this crackme called Mexican. In order to solve this, we will use radare2’s to analyze the binary and find the flag. Then we’ll have to patch the binary in order for it to output the flag. Let’s jump right in!
If we open the binary using radare2 and go to the main function we see a call to the flag function… but something is odd 🤔
After executing __main it compares the value 0xC1 with itself (lines 0x0040163a and 0x00401642) and it will call the flag function only if 0xc1 is bigger than 0xc1. …
We’ll be facing an alien binary this time. Level 2 alien technology, to be precise. Found on ruins of an ancient alien civilization.
You can download the binary using this link and follow along:
Let’s jump right into it!
Taking a quick look at the code-flow in the main function we can see there is a direct comparison between two strings (using the strcmp function) and there’s no much more logic into it.
Running the binary using
ltrace shows the exact value of the strings being compared.
In the following screenshot, you can see my input was just a bunch of “a” and the other string that is being used is the password that will give us access to all ancient alien secrets!
From there we can copy the string and crack the binary.
This time I’m tackling this beautiful crackme, the third of the series. To solve this we will use radare2’s macros and unicorn emulation. Let’s jump right in!
The crackme asks for a 4 digit password that the user needs to input one digit at the time. Similar to a PIN.
Looking at main we can see the “check_code_int” function is called near the end of its largest block.
A quick look at the “check_code_int” function reveals a chain of “if” blocks ending on checks between eax and ebx, one for every digit.
The blocks are almost identical, they all do some calculation, then compare the value of ebx against the expected value stored in eax. If the condition is met there's a jump to the next block, if not they return an error code. …
This is a walkthrough for the second crackme of this series.
Here’s the main function. Here we can see there’s a function call to the “xxx” function right after the input is received.
Here’s the meat of the crackme. Inside the “xxx” function the password is generated:
If we step through this function in gdb we can see the generated string is “isAAthisFunBBCCD”
Another good way to solve this is by tracking the library calls using ltrace
You can see here that the string “isAAthisFun” appears as the return value for the last strcat() being called right before the password check.
And that’s the password! That’s it!