Double-CryptoCrackme

Long time since I do not post a challenge and, once again, inspired by @TheDoctor I come up with something for you to have some fun.

This is not expected to be easy… but you never know, I may have overlooked something obvious…

Also it is something new (at least for me), so let me know if you experience any problem.

As usual this is a challenge for Linux 64bits.

#Double CryptoCrackme
As the title says, this is a double CryptoCrackme :scream:. It is actually 2 challenges in 1. On one hand you will find a reverse engineering challenge, but hidden in that there is a simple Crypto challenge. The Crypto challenge is easy to solve and will give you additional hints on how to solve the reverse engineering challenge, but you can just solve the reverse engineering one if you want.

#Objective
Obtain the connection information displayed by the program when the correct password is entered, and post it in the comments using the spoiler tag so people trying to solve the challenge can decide to look at your solution or not.

As a secondary goal also find the password.

Be free to add a write-up in the comments. If your write up is too long, probably it is better to create a new linked topic.

#Hints
If you do not know how to get the binary from the string below, check one of my other challenges here at 0x00sec.org

These are the hints:

Hint1:

You may want to run the program at least once

Hint2:

gdb list command shows the source code…

If by the weekend nobody has solved it (I doubt that), I will post more hints in the comments.

#The Challenging Binary

H4sIANbgB1gAA+1aeWwb15l/M6QoeiRTlOVDtBJ75Ng5XIsSZcWO40u3KMsR40NZKXbEnSGHQ1rU
kBoOaZFNN4eSpurWbY1FW6Tbxts0BVoUCdyuN5ukaCxUadosFukWbdH0AHoATWQkvZIiRZMi3O+b
eY/HWERaYP/YP/ygN997v+98x8z7Zqj7ho4O8xxHWOHJIYK9j/O9Zr+X4l03lEQAu4044bqONJmy
daSy9FbRXjepooSI5hX1XNjwUtj7j1WUiTM203PSKtKQRa63im6n0ow6KT32GyNaT/72wvyi/nqo
Dqgj4xNk4gVX69JNL56eOXDf1y9/INJ3/5dvPHAisPQsDij4wBsoH1x87a2vXn7U0UtWOkHr8pPY
2kGQ8epzKBAorsyA+Lk0B6IrDyLngRdMxtKp5RPBxXeDC294g8Xljw4UF/6w86GljwxubzI2Bs8Z
25uew2FfxstKJ1xf/0lw4QXvqeVg5MUg952H354X7t+7s/hysPi9199cPh54KfB2oBhYMpVWvgGX
h5fy6y+/w0M8nyoWi5adp+AyuVx8ObAUjLwc5L4HVm4YbHr+Ia4V4m56en092vvuYOBbC+/sNH5d
fPFyN+DZussjQK6Mg5m+k0f/eceltSKEP3EiuPBS8blLYPj5Pp6Qo4uvvfnU5WdBMvjn7wfPTcHA
zXn46eK3jy6+uvidlTPQPbX4+3v6Tl85As07A0srT4JJIIeArDz+XrEIUg3Aep278owCtKlu+eKB
S6TpP5dGF/+rqS548F4QzDX9+ZU7V3DNpxbdwYXvFpcvOq78GBgX+Sv/g4RceQkJd+VbQJ5xwyZb
zgyFhf6x0yFhekgYHxKCoenp0KQwMja9rkHcSeTNI6HI1D39vskQCG6Jb56O+qYjU8CRQqG7henJ
EwODdwjD4anQJIp/KDQ8DFYGQ04BxNdOhoQ2n+96oX/L8c2TYmJocDA0Oo0K4GtgctQ7PjbZNxia
doZODwwLif4x4A8La+JD08pp3+Tw5nmwmJgcG+0bCQmj/WPDw6HBO0KA3T02NXXP0OS4V9hJOo3Z
dKc/4o+QYbmgi3dJ6Xx8To+JWV3RhT5ZzeYkQ8xJKnRjKrYVXcvnkwIrI9lcTIQ/NauLMTmupHUx
Lc/pYlKOi5qii3lZnkc1TfVjAaacbxdEQTDdjfUP6XNiTFVABMxIpts1JePjYiYupdWcLImqLEZA
ShUzipxKlZXscRRyUq6g5cWCXkBJMaErMdAXRDEjK+LN+/PioYNd+8XUqXxHxz3i9MGe7lv2g7oo
jEtgE2PSJDXXMaen4oY1EjWrqeZwslpCxzgUvSBDS4BwZWVOVxCz5HESIopsKFrBL9ylYjzZ3Nyc
LuHQNPiLFcRMLq+LZ3Jq1vImR0wnhVxMy+eMgi6pqw8+LRciOJ/VM4Z25LgqxiXAAbl6TQoauGaG
dokpEM6ZgUmyagpkckpMLbtK6bhaaVhjfW4Xjl2aj6F/M9h8TpqH8RY0I5f2i+OKOS3xGGqcPBaC
2RDl1Nm5eCEidsyJHcOHhaoygt4qhmQKqhirOSfa1ZtIzlRNqTgsmx4NXbX0Cnosphm6uXOAoVjL
YOgK7rQzWV3SYflNlUzOiMPs4VyZ6wlmk+b+HOofCewWdQn9zYmVoeJGB4aqJMWIDDvPL8KKYsyx
ctC7RCUuWXFXbJvSIDXYU5mchDcMhJiQ5yFUXBDzTjiuxfA2ss6H9fSc4ArHCTfv5doa692fhMff
dcSqgXeKxVtRoM/jXeBHPOKMx9vncZt6B6AOA39DxbmD+EmoA4B3UL0ZKp/EJzXg+yvk0cdDUO/9
S7F4R8nPuOeT7oLHO+Bx7wLoCXzIgt4Y8vs93o/xRzytH3b0ecQFp+FpHfB4+z3uCv8/hJoD+TZq
j+FvQH0BcNffcY5eK9fKtXKtXCvXyrXy/68sw7sZlpGBgdvFmyfkrGZkxVv9u/2BjkBP1ux2+wO3
WJDY3RXY09UT2F3WxxyGN1tWBnGevoe30vfzQdq/o4b/Xab+pJPpf4W35BtqyJ90snd6N4ffHRrP
w2ViFUGec51Gwte9BMThrEtoBoDuu02wPo7EWf9vSNx1Syap/1er9w2r92mLfN0yFgHijERVwt3I
PQ7tOolwN+2Fhqs+nDYId8teOgdrZtOE87F5uJWGw33ubbgKGWC9TaGGCOE259D6+VTj81R+Awxu
LTfBBdZyJwFfyx3jAoR43DnTcoxw7S8yyZLl3TDXggwsbOxBN0noYDwpFPC4D8G16UNw+RnV7Sjp
vgcq3kVofglq888pfyPlPw7cdf+Crfug5XaTxt+x7y00zi6IEy/HMOLjXBchLW9SEZYar0fzV6Eb
/koBnMwVzrS2xoHfJszS6KKtD7AJwc6ayAzhutyUxfJg7nP9sAUFmPYunIGf0RnowhmIArBxgC+7
IpseQZW9yLRvTlgkMNQKuvuQ/VnQ9f0A8dsRd5z/w9kNckXUj/E06kfpTUQ2JCvY32TsJ0vsD1L2
HhjUr/jyDPJnoXnMIcDWbvwwlXnPmhNgEbIZV7DeQUgbrmjRQa57EsMaZAMbKw3gPAi1xqKEG8IR
fBNsbDCoUB84DTtoTM/SmMC5Q+jjTe+XOLJhgQrjPlywhPkcSvH3Yoh8BqaTfRs8ijfi9RkjQLgj
6I3hbaVoXgMLWz5NYYx/y+dpB3fjlsdpB5dvC7vzccFJQxgWeutfQUNwtNJQL2zFO0cMwz3UgK01
DvaxsP2DcMHK79uGN6N1Q7Y/AAhW/p/aPwYEK397Ow2O8Le2/xQIVn4/wUcaT36Bu5z7D1J+Dl2i
NO3PmJ9c8COg2HdC7PZ37yHc/Vwzt8PT0uDwtHkmNjVz3k1gZTtpaDgEEOwY2oTHgtPPHfY53Lc3
7G8QG7gWeH70EKs7Ch1XAziuL4uMthzwQSStOMoyepOvmVtX39v6mX4fWhDqShZ48NtQNsiDYuPi
gxxEFwDBtR99kCN86/l+gD1NEBK6bPIDr8qet4cETEvNDRwyEFvn50ZarIBbLBTuYJSDHcIcIHMj
dEgz96l+H7I2mTF7rJhHq7209lRF7YOupxz1Zo4bNQ22tZPRlk54wl9XtlVl5/rKeRlteYSrnpwt
VkAYzdYbCQ5YLDs+7ENf7X5y2HfAp3ks64Rso4DbksMd3Ey8LrDLOdxt7h3uFjxxvmbulH3I5d71
rIWr+fkcKteZzeidCS2SzEaVzmhCMQgxv9BByWqJjBH1x80P32QNz84HBxyUvJN7GC68y73O5Z46
g33V7B9xXbjhBvfUhS90tUDf4XoM0SMu9/nzjubHuj7exe9ev7Vz/+n2bJZvhDjALHuiOfZy29Pz
Uxcu/OYpvgFYPWbQm1cL2tzaxIqK7fqWw1OdPAdSqbSimVt+IBCw5QBix6yR1ZSDqqIpeiICXUmP
xA/O37anY0+P2KGKHaGM2BHTUh0ZQ4rMdKT1lKFEjJRu3UdZLZNQNSUqRuKSTjLxlG6IJQzP6rN6
wlBIWJlPGGRWSmhEV6SoNZ/JFH7Zw0uVRjQLdjOJgmLk00qFEPIsB9iSs7GYopNIMpVRSunKo5Ry
ZII1v12CThBbYUfwf5e1WJOdsE7yFjdxoZbij0qKJ39kU+TMzz9VhZ2575ZE7mSnYz1fguxa7JRc
VxKZYM2NlLpIlqTJtgusfzOlbgsPXHeBIXttGqy/j1IBhwsMHXi1AhFKgZxkze4yZNdiR+XD5UHb
RfJU+8GSlTtZ85ESdBdrnitBV6WLbBew7c/uIob/ncUBPsRVVB1wCw6uijtIKfGpwp2kt341vK78
e1kV7iLuVfHVf/lylH5ls+NrauBCDXz1bN1BGmvga2vgnqswfEo5yR+LdtxVA7cyV558le+twttq
yO+qge+tgffWwEdr4MehroN47JnaPxD8jZEvbTlWTkFtr1hH9vulBLW5Yt3ZykWhbgM7P7bZyVC/
r9rw+6jfZ2z4Z2rYuchZ+G9t+BPUvl2+QO3Y/b5Sw/5KDfxPNM4lG97IWX5fseE+fI9ZZf/voPL2
t6abKf4Lm50eittfDfZxVjxPU/ltFB/jVo//VA1cofbtb2IJitvfbZIUt+fWaTOeuqvGe5bOg9eG
30vj+RO1w77hn6sR5xMc/uLOl/JfVj5fQ/6LdH7s8p1U3j7P+LzHcdnfk79Cx2vfby3Ujn3drYTA
/DE0EpkZUI9MHPGn8AWgiyi6rqXCyVREMhIpDaTMPESV0mZThz9oqIqhaDlozCqzkVlkmVkEvkGY
+gReN8LhWCyZzcTDkMFBHhIOJxNyJGymI+EwJHaxhBINZ/KZiJRMhgN7ZEhYYoaeB88zsUQScphw
PpUNGzqKGRBRQpsJS2HMD01DKfkM5EVhSYUkJ2OEVQRBx4ijh3A0ZWZAsaxWYQ9CS+l21ywwK7MJ
h+VMBiKWdEifYoxn5nNmNnVV5FXDTGXBZckhfvaAN2980wsrUcmQgGhRK46KKa6yACzoa6k0TeFo
AFZWR/yZ/KwhyUAN3aJx1tIgTfSrWtYvZxPJaEcCcj5DmTeIX0+Zrv1KPBzTpVmF+K0+jBN2QWp2
VoHszh9V5KwalnRJU5UM6ya0WKrEkmVdybEeLIbC2hBBCU5FWJNa+j8qeP/iaczTfvn/V6z+dpu8
09b3k4r/nSHlVGWQ6j/NVcvbuqSHYt20z/KOd2hAfTaHnI0eoG0WP8tPeuttgrTYM4xhKuJgQOn/
flaXt/ePUozps+ef+2/UP0b9d9nlqH6nDbeP/25y9Zxi6aX6aRvutfUTNfQvUsFP1Jh/VrI19A/T
g+2t91n/hRr63Zss+lsbbpf9BFl9/ra2WvSXNfQZ/WwN/0Wq7+Krcbvsl2ro19GD0R6XXbaZVOy9
ipKjB/q/v49+5d6vLLdR/x+pK/vBKWX7jw7PzKxX878kWvT97t//BY7hE4OwJwAA
3 Likes

meme

4 Likes

Thanks for another challenge, @0x00pf.

To retrieve the information, the identification of the XOR encryption was required. In this case, the decryption key was 0x2a which is found in the mp (this function prints to the command line using write) function as well as the ck (password-checking) function. After locating this vital piece of data, you could run off and mass decrypt the rest of the encrypted strings found in the binary or you could find the password
To find the password, proceed to decrypt the string movsxed into the r8d register in the ck function. Why? The cmp edx, 0x2a instruction tells us that the input password from the user (in edx) and the password (in r8d) are being XORed together to get the XOR key as a result (due to the properties of XOR). It’s obvious that the string movsxed into r8d is the password as it is retrieving the password from its database within its own binary. Using some kind of dumping tool, dump the binary at that location and then XOR the data with the key and you get the password H0meIswh3reYou4B0tN3tIs.

The information you get from entering in the password OR mass XORing the encrypted strings inside the binary is as follows:

Well done. You’re 1337 h4x0r
Connecting to irc:darknet.evil Channel #BotOv3rl0R

P.S. Someone needs to fix the spoiler tag and the backticks.

2 Likes

@dtm
I should have foreseen that you could make it with a bit of static analysis… I may try to made a few changes to make it a bit more interesting… it’s time to move to another obfuscation thecnique :wink:

@_py
Good catch, you solved the crypto part. Did you try to go further with those hints?.. hope you will try some dynamic analysis :disappointed_relieved:

@0x00pf: yep, solved it. I will post my solution soon(currently in class).

1 Like

Alright so, my initial thought was straight to GDB, but after seeing the “antidebug” tag and combined with the recent ptrace post, I thought that there’d be definitely a call to ptrace to stop the executable from being traced. Which was indeed the case since the output of strace was:

Thus, trying to run the program through GDB wasn’t a pleasure:

This output made it obvious that ptrace was being called before main, probably in some sort of “constructor attribute”, but I’m not completely sure. The disassembly gives in some intel on this matter:

It looks like a modified version _start(), where dump is a helper debugging function(?), then cdg() is being called, which is probably the ptrace prevention(?) and finally main() is being called.

There is a way to bypass the ptrace anti-debugging technique (through patching the ptrace with NOPs or by patching the return value of ptrace which tells the program if it’s being traced or not), but I failed implementing it (maybe @0x00pf can shed some light into it?).

I decided to leave the RE part aside and focus on the crypto part which ended up being fairly easy. By using the strings command, a part of the output is this:

Thanks to some wargames I was playing recently, it immediately hit me that ROT13 was being used. The decrypted part of it is this:

Some Includes here
Nothing interesting really
This is the source code you are looking at..... cool!
Some XORed strings in here	
A function to print frobbed strings
This is minimal memfrob version
  for (;l >=0; b[l--] ^=42);
And some anti-debug code that you have to remove 
in order to debug the program.
It is hidden in an asm file with some opcode misaligment
A function to compare XORed strings without unXORing
This is the main function, but it is not the first function being called, thanks to some linker magic. Ar you using GDB or objdump -d -S?
The function to dump this file as the source code of the program. So you get this messages in your debugger... whenever you figure out that they are ROT13 encoded 
The real entry point. It dumps this file, runs the anti-debug function and finally invokes main.... Easy

And voila, the program is using memfrob() for the encryption, aka 42 XORing.

Moving on to the disassembly, I had a bit of a hard time identifying the function symbols in order to understand which function was doing the password checking etc…But:

cmp edx, 0x2a kinda spoiled it since 0x2a == 42 == memfrob()'s encryption. After re-reading a couple of times the disassembly of ck, it seemed like edx was being compared with r8d. edx seemed to be the register holding the user’s input and r8d was holding the already XOR’d password (keep in mind the hint from the ROT13 decrypted string “A function to compare XORed strings without unXORing”). So movsx is moving a string stored in the binary into r8d. That string is probably the needed password.

There has to be an easier way than mine but this is what I thought of:

readelf -l

The above pic gives in a lot of useful info but for this challenge I was curious about the load segments. So as you can probably see the text segment (containing the .text, .rodata, .hash, .dynsym, .dynstr, .plt, .rel.got sections) is loaded at the address 0x400000 and the data segment (containing the .data, .dynamic, .got, .bss sections) is loaded at address 0x601000.

Going back to the disassembly of , we can see that a string from the location 0x400318 + something is being stored into r8d. This address lives within the text segment, which kinda makes sense since the .rodata (read-only) section belongs to the text segment and the string itself is part of the binary’s “data”. So we have an idea of where the string is actually located.

I wrote a quick lil elfparser in order to go through each section and find the one I was interested in. I stored the data of the section in a buffer of size sh_size and starting at address sh_addr. Here is a preview of the output but I won’t show it as a whole since the source code belongs to a (hopefully soon) finished project for 0x00sec that I’ve been working on.

Wherever you see actual addresses next to the sections it means that they will be loaded during runtime, whereas 0x0 means the opposite.

So I stored the content of the text segment itself and XOR’d it with the key in order to get the password and I once I entered it, I joined some really creepy darknet/evil IRC channel.

@0x00pf: Thanks for taking the time to create this challenge. Much appreciated.

3 Likes

Well done @_py!.. You went through most of the hidden features in this crackme!

I see you used objdump most of the time. Did you try the flags suggested in the hints after running the program at least once?

I’ll post the sources and some explanations probably next week

Thanks @_py and @dtm for trying… and solving it!

1 Like

@0x00pf: Yes, I used the -S flag if that’s what you are referring to but all I got was the disassembly with some ROT13 encrypted text in between some sections which led me to the same decryption result as the strings command. I didn’t decrypt it all because it looked familiar as I said but I might have skipped some hints. I assume you were expecting a different solution than the ones you saw.

I’ll probably try to find other solution alternatives in the meantime.

1 Like

Here’s how you bypass the anti-debugging:

The cdg function contains the pt function, prints that failure message and then exits the program IIRC. To get rid of this, simply NOP fill the function call to the cdg function in the st1 function, i.e., replace the five bytes of the call with 0x90.

Good luck.

2 Likes

Not really. Your solution is perfectly fine. I tried to make something extra happen for you guys but, looking to the solutions, it obvious requires some more work on my side… Maybe in the next one

Regarding the antidebug… @dtm solution works fine. Other option is:

Change the _pt function to immediatly return:

Original:

00000000004002a9 <_pt>:
  4002a9:	eb 01                	jmp    4002ac <_pt0+0x1>

00000000004002ab <_pt0>:
  4002ab:	e9 b8 65 00 00       	jmpq   406868 <__errno_location+0x6574>

patched

00000000004002a9 <_pt>:
  4002a9:	c3                   	retq
  4002aa:	01 e9                	add    %ebp,%ecx

00000000004002ab <_pt0>:
  4002ab:	e9 b8 65 00 00       	jmpq   406868 <__errno_location+0x6574>
2 Likes

@0x00pf: The spoiler tags in your post don’t seem to work in my browser, while these in the comments do work. Could you check it?

Screenshot:

1 Like

Yes. I know. When I edit the post it looks OK in the edit window, but when I submit the update, the tag is not processed. Do not know why

1 Like