Challenge RE #12
Tags: reverseengineer, assembly, c, challenges
Published: 2023-09-21 16:41:45

Hi there, let's solve the 12th challenge on RE, from [challenges.re](https://challenges.re/12). This time it's quite exiting we have a binary file, and always the code. Having the binary will allow us to use [Ida](https://hex-rays.com/ida-free/) in order to see the code, and also it will mark us loops involved in the program. Yes, I'm aware that you can do quite more things with [Ida](https://hex-rays.com/ida-free/). Let's start analyzing this binary. In case you want to know how to install Ida or other tool that will allow you to disassembly the binary, Google it's your friend.

## Analysis

We have to be careful all the time when we are analyzing a binary file, in case the binary it's a malicious program. In this case looking at the binary file, I don't see anything suspicious. The program make use of simple functions from Linux like **puts**, **xtats**, **time** and **utime**. I mean there's no use of write to file or anything that could affect the files on your computer. Let's assume my guess it's correct, and let's try to run this program first without argument to see it's output. If the source of the binary file it's a trustful one, it's always super helpful to interact with the program. This will help us to describe more precisely what the program does.

In this case a call without argument produces the following output:

```bash
[COMMAND]

$ ./e12

[OUTPUT]

Usage: <filename>
error #1!

```

Immediately that we call the program we get a clue of what the program it's expecting, in this case, we will need to supply a filename. Let's try to supply a non existing filename to see what we get. 


```bash
[COMMAND]

$ ./e12 lalala

[OUTPUT]

error #1!
```

We just get the **error #1!** output. Then ok, let's try now to supply a filename that exists.

```bash
[COMMAND]

$ ./e12 example

[OUTPUT]
```

Interesting, we don't get any output. Ok, it's time to dig on the program, we already explored how it's supposed to be used, let's see in detail what it's doing.

### Logic

The first thing we see at the start of the program are these instructions

```asm
main:
    push    rbx
    mov     rbx, rsi
    sub     rsp, 160
    cmp     edi, 2
    je      .L2
    mov     edi, OFFSET FLAT:.LC0
    call    puts
```

Looking at this code we can say that we have only the `main` method, and we perform a check on the number of parameters supplied to the program in the lines `cmp edi, 2` and `je .L2`. In case we don't supply a file, automatically we output the usage, otherwise we print the error message. Nothing new, that we haven't investigate already by running the program. Let's keep digging.

When  we supply the correct arguments, the program make a call to `_xstat` which it's equivalent to [stat](https://www.man7.org/linux/man-pages/man2/stat.2.html). Looking at the doc of this method, you can infer that the program it's storing in `rdx` the information about the stats of the file. In case of error taking file stats we output the single line `error #1!`. On the other hand, what happens if the stats are collected successfully? We don't see any output to console, so something must be happening. I mean the program should use these stats for something. The code that handle this parts it's the following:

```asm
mov     rax, QWORD PTR [rsp+88]
xor     edi, edi
mov     QWORD PTR [rsp], rax
call    time

mov     rdi, QWORD PTR [rbx+8]
mov     rsi, rsp
mov     QWORD PTR [rsp+8], rax
call    utime

test    eax, eax
js      .L11
```

Here we have one call to [time](https://man7.org/linux/man-pages/man2/time.2.html) and another one to [utime](https://man7.org/linux/man-pages/man2/utime.2.html). The first one retrieves the current time in seconds, storing it in `rsp` as a `time_t` structure. While the second one, use this structure to overwrite the **last time and modification times** of the file. With this we can infer that yes, the program it's not outputting anything to the console, but it's modifying the last time that this file was accessed.

Let's try our hypothesis. To see this information normally in the console, let's run `ls -lsh` to see the last time the `example` file, the one we created previously, was accessed. In my case I have

```bash
ls -lsh

[OUTPUT]
4.0K -rw-rw-r-- 1 gulolio gulolio    6 Sep 21 18:27 example
```

We have that the last time, was 21 of September on 18:27. Now let's run the program and right after `ls -lsh` again, to see if this data changed.

```bash
./e12 example && ls -lsh

[OUTPUT]
4.0K -rw-rw-r-- 1 gulolio gulolio    6 Sep 21 18:30 example
```

Indeed the time changed, so now we can summarize what the program does in a single line.

**Formal description**

> The program modified the last access and modification times of the file specified in the argument.

## Conclusion

Quite simple program, also analyzing the program with [Ida](https://hex-rays.com/ida-free/) helped a lot. For example it marks you the flow of the whole program, so you don't have to lose time drawing arrows on a notebook. It's marks you in the program where strings are been used, so you don't have to go back where the string was defined to see it. It even added useful name to variables, like in the following case

```asm
mov     rax, [rsp+0A8h+stat_buf.st_atim.tv_sec]
```

I would highly recommend you to use it, there's a free version for almost every OS(except some exotic option I imagine). Take the time to learn how to use it, could save you a lot of time.