So to begin with, this was one of my well spent weekend as CTFs were lined up one after the another, and fortunately some of my team members were active. There were a variety of CTFs to choose from such as, HITCON Quals, Rooters, Cryptrix, etc I just had a taste of each of them.
Also I’m not that much of a pro so didn’t focus too much on HITCON.
Difficulty level of CTFs according to me could be arranged in the following manner :
HITCON Quals > Rooters > Hack-A-Bit > Cryptrix > Syskron
I didn’t like Syskron personally because It was full of guessing challenges.
I thought maybe post about my experience regarding all of them and maybe if possible a writeup too!!
So I’ve been practicing level2/3 crackmes on crackmes.one lately and I was excited to test my skills.
Out of them only Cryptix and Rooters had some reversing challenges which I was able to solve.
But In this blog post I’m particularly interested in solving a crackme from Cryptix known as CrackIT.
PS I was not able to solve it during the CTF, there were many reasons for that.. one of them being that Hack-A-Bit was also live at that same time and we were doing great in it. (We ended #1 in Hack-A-Bit XD)
And yeah here’s a backup for y’all so u can follow along!
The name should’ve been keygenme according to me. IDK what did the author thought while naming it LOL
Well leaving that aside, we run the binary file and also check that it is 64 bit binary which is not stripped so we are lucky till now.
Well In this writeup I’ll try to as detailed as possible, So plz ignore if I’m emphasizing more on any particular topic.
I’ve been using Ghidra decompilation feature and I have to say that it has lived upto my expections almost everytime.
So I look over the code and found that there are 2 functions which do the actual work ie. validate_key() and Do_Something().
The main function doesn’t do anything actaully, it is solely dependent on the return value of validate_key()
undefined8 validate_key(char *pcParm1)
So validate_key() checks if our input is 0x11(1710) chars long or not. and later passes our input and its length to the DoSomething() function. We see that the return value of DoSomething() will always be a 0x18(2410) char string and then their is a power operation with base as 2 on it’s each value whose result is being compared with a variable in memory, _Zproc_libc_fini. So I checked its content.
But It didn’t make any sense to me and also I was missing the most crucial part ie. what does DoSomething() do?
So I headed over to GDB and started debugging it.
We’ve set up a breakpoint just after the call to DoSomething() so that we can check the value it returns.
Now if we run it using a random 17 char string and we can see that the string returned from DoSomething() is stored in $eax and is simply base64 of our input. Oh great its just a base64 implementation function in C.
Now I set up another breakpoint on the ucomisd instruction which is a just like compare but is specifically used for doubles. You can read more about it from here. And we simply continue the execution.
Now lets see what is being compared… Ohh here we see that registers with double-precision are used. This was something new to me.
So register xmm0 now stores the value to which our b64 encrypted input char is being compared to.
Ok so the double value looks like what we want. So I tried this short script to check if I am in the right direction.
for x in range(33,127):
And to my surprise there was a result = 1.2676506002282294e+30 for character ‘d’.
Now I didn’t had more time to complete it as I told earlier.
But I afterwards when I continued with the ghidra’s source, here is what I deduced in python:
encoded = Does_Something(myinput,0x11)
So there will always be 0x18(2410) iterations on the encoded string because when a 17 char is base64 encoded it results in a string of length 24 everytime. And obviously if our encoded input is 24 char long the Zproc_libc_fini array should be of the same length.
But as I showed you I was not able to see any values as 1.2676506002282294e+30 in ghidra so I did it in gdb.
I repeated the previous process, ie. set 2 breakpoints and continued their execution and when it stopped at validate_key+167, I tried to get all the values stored in _Zproc_libc_fini. I was having a hard time doing this. Then I learnt some more things about how to examine doubles in memory. Also this question on stackoverflow helped a lot.
Now If we want to get the first value in the array we can try this :
For examining it in memory you can use:
where g = Giant words (8 bytes)
and f = floating value
But the most appropriate way here would be this.
We can get the address of _Zproc_libc_fini in memory using & operator and specify the length of values we need ie. 24 using @ symbol after the address.
So its time to write a script to reverse the process of pow() using log() to get the base64 encoded key
from base64 import b64decode
By the way, we can also brute force the base64 encoded key and get it easily using the code below :
for item in Zproc_libc_fini:
└──╼ $./keygen w34k_s3cur1ty_l0l
Also I got to know that we can change the values of Zproc_libc_fini to represent it in doubles.
Thanks to @arpox for sharing it.
You can just select all of the data in Zproc_libc_fini and right click-> data -> double.
Well I learnt many things through this challenge.
Also the challenge source was disclosed by the admin.
I’ll be posting about some of my favourite crackmes soon.
So Make sure to subscribe to the newsletter to learn together with me.
Also Comment your feedbacks and share this writeup with your friends.
And Keep Escalating the Priveleges Gang!!