Wednesday, May 25, 2016

CONFidence CTF 2016 task solution slides

The CONFidence CTF 2016 is over and therefore it is time for a short summary.

Let's start with congratulating once again the top three teams who took home the prizes:
  1. Tasteless (2700 pts)
  2. p4 (2250 pts)
  3. 9447 (1900 pts)
Well done, well played!

The full scoreboard is available on and includes 22 teams (limited to teams which solved at least one task).

As far as tasks go, the CTF offered 19 tasks altogether, split as following:
  • 5 x Exploitation
  • 4 x Reverse Engineering
  • 3 x Web
  • 2 x Cryptography
  • 2 x Steganography
  • 1 x Miscellaneous
  • 1 x Networking
So yes, it was a binary heavy CTF with some diversity in other categories. A brief solution to each of the task can be found on the following slide deck (originally used during a post-CTF task presentation just after the CTF):

And that's it for this year's edition. Once again, a big round of thanks to all the players, as well as to the CONFidence conference organizers and Dragon Sector team members and our friends for making this happen!

See you next year!

Photos by: masakra, gynvael

Wednesday, April 20, 2016

Write-ups for 0CTF 2016 Quals and Pwn2Win CTF 2016


It's been quite a while since we published any write-ups, so it's a high time to do so. Here goes a bunch of them from two recent CTFs:

Tuesday, May 26, 2015

CONFidence CTF 2015 - Slides explaining the tasks

Our CTF in Kraków ended today - big "Thanks!" goes to each and every team and player that participated, we hope you had fun :). After 27 hours of playing and quite a lot of shuffling going up all around the scoreboard, the winners were decided:

2. H4x0rPsch0rr
3. SpamAndHex


We'll probably write another post about the CTF/tasks/etc later on (after everyone gets enough sleep - currently some of our team members had forgotten what "sleep" is), however due to popular demand  we wanted to publish the slides of our post-CTF presentation during which we explained the key points of all tasks we published during the CONFidence 2015 CTF:

Link: Tasks Explained
(It's a Google Slides presentation. To download in PDF please click File → Download → PDF.)

Please also find a quick photo of the final first page of the scoreboard below. And with that we'll end this post for now - good night!

Thursday, April 23, 2015

The CONFidence Teaser CTF takes place this weekend!

This is just a short reminder that the CONFidence Teaser CTF organized by Dragon Sector will take place this weekend, and more specifically starting 25 April 2015, 10:00 CEST until 26 April 2015, 10:00 CEST.

The registration has just started at the event's website,, and will stay open all throughout the game.

A quick rundown on the basic information is as follows:

  • Start: 25 April 2015, 10:00 CEST
  • End: 26 April 2015, 10:00 CEST
  • Duration: 24h
  • Format: online, jeopardy, team-based, no team size limit, teaser
  • Categories: web, re, pwn, crypto, stegano
  • Contact (IRC): #dragonsector @
  • Contact (e-mail):


Top 1:
  • Travel allowance if coming to the offline event (up to 4*500 USD for European teams and 4*1500 USD for non-European teams)
  • 4 conference passes for CONFidence
  • 4 places in a rent-out hostel for conference attendees
Top2 - Top9:
  • 4 conference passes for CONFidence
  • 4 places in a rent-out hostel for conference attendees

See you on the battlefield!

Monday, March 2, 2015

Boston Key Party 2014 / Riverside

Get the file :

# wget
# file challenge.pcapng.28c58da9dd07532d45aa68f9b825941e 
challenge.pcapng.28c58da9dd07532d45aa68f9b825941e: pcap-ng capture file - version 1.0

Lot of USB data inside:
# tshark -r challenge.pcapng.28c58da9dd07532d45aa68f9b825941e | head
  1 0.000000000         host -> 1.0          64 USBHUB GET_STATUS Request
  2 0.000011000          1.0 -> host         68 USBHUB GET_STATUS Response
  3 0.074167000         host -> 12.0         64 USB GET DESCRIPTOR Request DEVICE
  4 0.075077000         12.0 -> host         82 USB GET DESCRIPTOR Response DEVICE
  5 0.150556000         host -> 1.0          64 USBHUB GET_STATUS Request
  6 0.000015000         host -> 1.0          64 USBHUB GET_STATUS Request

Device [12.0] description:
    bLength: 18
    bDescriptorType: DEVICE (1)
    bcdUSB: 0x0200
    bDeviceClass: Use class info in Interface Descriptor (0x00)
    bDeviceSubClass: 0
    bDeviceProtocol: 0
    bMaxPacketSize0: 8
    idVendor: 0x046d      <---- Logitech Inc.
    idProduct: 0xc00e     <---- Logitech Optical Mouse,
    bcdDevice: 0x1100     
    iManufacturer: 1
    iProduct: 2
    iSerialNumber: 0
    bNumConfigurations: 1
( Ref:

Take sample data:
# tshark -r challenge.pcapng.28c58da9dd07532d45aa68f9b825941e  'usb.device_address == 12' -x
105 5.078857000         12.1 -> host         68 USB URB_INTERRUPT in
0000  c0 44 a9 c7 00 88 ff ff 43 01 81 0c 02 00 2d 00   .D......C.....-.
0010  7f 99 ea 54 00 00 00 00 93 3c 09 00 00 00 00 00   ...T.....<......
0020  04 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00   ................
0030  08 00 00 00 00 00 00 00 04 02 00 00 00 00 00 00   ................
0040  00 01 00 00    

Find tech spec:
struct mouse_report_t
    uint8_t buttons;
    int8_t x;
    int8_t y;
    int8_t wheel;

Write parser -> och it is on-screen keyboard:)
Enhance parser :

Monday, January 19, 2015

31C3 CTF - Mynx (Pwn 30)


After selecting this challenge we were welcomed by a rather laconic description:


Once connected to the service, we were greeted by the following menu:


It appeared to be some kind of a storage service for ASCII art. We could upload ASCII arts, add comments and apply filters. After fuzzing the input for a while we didn’t discover anything useful, so it was time to look inside the executable.

Reversing the binary
The file command revealed that it was an x86 ELF executable. After opening it in IDA we could see a main loop which was responsible for displaying the minimalistic menu shown in the previous picture. Its C representation looks something like that:

Main function

Because vulnerabilities are often caused by badly handled user input it is a good idea to look for some potential overflows. There are 3 places where input from user is requested:
  1. the read_3_digits function
  2. the add_art function
  3. the add_comment function
Unfortunately we were not able to find any  obvious problems in the code. In every single place the length of input was limited and buffers were large enough to store the input data.

When adding a new structure, the program looked for the first free slot and placed the structure there. We reconstructed the “art” and “comment” structures, which were both 256 bytes long:



These structures were filled when a new ASCII art or a comment was added. The interesting fact was that, when a comment was added, 252 bytes of input were read into a buffer of size 251, so there was an overflow after all! 

It was just a single byte, but that was all we needed. Using this one byte we could overwrite the first byte of the next structure which was a type field. So we could convert a comment object into an art object and vice versa. The first one was particularly useful because when a comment was interpreted as an ascii_art then the first 4 bytes of the comment string were interpreted as a function pointer named “filter_method”. By applying a filter we would be executing arbitrary address with our string as first argument. In other words, we could simply call system() and get a remote shell. :)

All we needed was to overwrite a comment and change it to art. After that there would be two ascii_art structures with the same id (ascii art and its comment converted to ascii_art). We needed our transformed comment to be earlier in memory so that it was selected first. We achieved this by making use of the  remove_comments function. This step could have been done in many different ways but we discovered the following first: 
  1. Add two ascii_arts A1 and A2.
  2. Add two comments C1 and C2 (Cx is a comment for Ax).
  3. Add ascii_art A3.
  4. Remove comment C2 and add comment C3 (it will be put in C2’s place).
  5. Remove comment C1 and add comment C2 (it will be put in C1’s place).
With the last one we overwrited C3’s type field and turned it into an ascii art. It was placed before the original A3 and thus when ascii art with id=3 was requested our spoofed art was selected. Applying a filter resulted in arbitrary address call with the argument being an address of a controlled string.


Because ASLR as well as NX were enabled (no PIE/RELOC though), we needed a memory leak in order to call the system function (or we could have created a ROP but come on - we had function call with our string as argument).

Fortunately for us, there was a printf function imported by the executable, so we could force a format string vulnerability by simply calling it with a controlled string.  Sadly, our format string was not stored on the stack, so leaking .got entries became much, much harder than it typically is.

Cheer up, not everything was lost. The “main” function is not called directly at program startup but through the __libc_start_main function which is a part of libc, so the return address from the main function also resides in libc. And this one is definitely on the stack. 

After finding the correct offset and leaking the address, all we needed to do in order to get the flag was to find out what version of libc the system was using (so we could calculate the distance between the leaked return address and the system function). 

In the end, we failed to  identify the specific libc build and consequently had to brute force the offset remotely. It took approximately 8 hours, but we eventually got the system address right and obtained the flag.


To exploit this challenge we used function pointer overwrite, combined with custom memory management, and then forced format string vulnerability by calling printf function. Knowing libc base address we called system() and spawned remote shell. 

It was a great CTF challenge and I personally enjoyed how the solution leveraged one vulnerability to cause another. I thank the organizers for interesting contest and I hope it will be even better next year.

Tuesday, December 30, 2014

31C3 CTF - Nokia 1337 (Pwn 30)

Here you are, playing a CTF with you mates in Hamburg. You notice there's a new task, “Nokia 1337”.
Enter the trilogy: pwn this phone. Please use only the qemu provided.
Remote instance requires proof of work: nc 1024
Connect locally via telnet to localhost:10023 after qemu booted completely.
You download the image, fire it up in Qemu and...

See the phone boot up on
...Oh. Oh my.

Club Mate and Rum (it's called a Tschunk!) in hand, you give it a shot...

The challenge

The challenge is the first part of a trilogy of awesomeness prepared by the organizers of the 31C3 CTF. You were given a qemu machine that booted up into a Nokia-like ncurses interface. The machine was an emulated Xilinx Zynq ARM SoC. There was a low-privileged mobile user and a root user. The mobile user had the ncurses UI (a binary with DWARF debug symbols, phew) set as a shell. There was also a baseband communication coprocessor that was essential to solving the second and third parts of the challenge.

Locally, we could log in as root and see that there was a /home/mobile/flag file, containing placeholder text. Remotely, we could only access the ncurses UI via telnet. Obviously, we had to get remote code execution through the UI and read the flag.

The “phone” didn't have that much functionality. You can send and receive SMS messages, save, remove and retrieve contacts, and save, remove and use SMS templates. All storage was handled by an SQLite3 database.

The bug

As previously mentioned, the UI is a DWARF-enabled ARM binary. It's nonrelocatable, and has a writeable and executable data section. This makes our life easier.

After doing some analysis of the binary, I found an interesting function - db_get_template, which is used to retrieve a saved template from the database into a buffer. Why is it interesting? Well, let's take a look at its' signature:
Set sail for fail.
The index parameter is given by the caller to identify the ID of the template we want to retrieve. intidptr can be provided by the user to get information on the internal DB ID of the template. textptr is the output buffer address given by the caller. lenptr can be passed to receive the amount of data written to the buffer.

As you might've noticed, there isn't really a way for the caller to get the template length before calling the function - this looks bad. So, where is this function used? Well, when we wish to insert the template into our SMS. Here's the relevant code:
Iceberg, right ahead!
This is the code called when the user selects a template to be inserted into an SMS message. text, at 0x1C600, is a global buffer of the currently edited text message, text_len is a global int of the current text message length. How large is text, you ask?
Your shipment of fail has arrived,
 And since a template can also be 160 characters... Whoops! We have an overflow past the end of this buffer.

The exploit

Let's see what can we do with this. What's past this buffer? There's a 0x30-byte long structure named screen_input_dialog_arguments that contains data on how an input screen module should be called when inputting a number (when sending a message). While there's a few function pointers that we could overwrite there, there are also a whole bunch of pointers into complex structures. While doable, it's not something I'd like to have to fix up with my exploit in order to get one of the pointers called without crashing. Maybe there's a better attack vector?


The next structure that we can overflow is screen_sms_write, a structure defining the callbacks that are called by the UI layer when we leave, enter, or input data in the SMS write screen. This looks promising! The first callback normally points to sms_write_enter, and is called when we enter the SMS write screen. So, in theory, we could overflow that pointer, leave the SMS text editor, re-enter it and then the code execution would jump wherever we want. Nice, let's try that.

Groovy, Baby! Yeah!
Let's say we make a 160-byte long template, with the last four bytes containing the address we want to write into the first callback at 0x1C6D4. Since the message buffer starts at 0x1C600, this means that our combined message+template text should have 216 bytes. Since the template is 160-bytes long, our message should be 56 bytes long. Here's what I did to test whether this attack works:

  • I created a new template, with 156 'B' characters and 4 'Z' characters. I saved it into memory.
  • I created a new message, with 56 'A' characters. I then inserted the previously crafted template at the end.
  • I exited the message editor and re-entered it.
  • I observed that the UI crashed.
So, we get a crash. If we attach GDB into the qemu stub and break around, we do indeed see a failed jump to 0x5A5A5A5A ('ZZZZ' treated as a pointer). So our smashing works!

Surprisingly, this was the easy part of the exploit. Now onto the hard part, especially if you're new to ARM exploitation....


We need a shellcode. Apparently, all public ARM shellcodes suck, especially if they can't contain 0x00, 0x0A, 0x1A, 0x1B and 0x1C characters. I ended up writing my own, and it's not very pretty:

'shiiii' is the sound I make each time I look at this.
The next step was to automate typing in the shellcode and other long strings into the UI. I wrote a proxy server in Python that would let me connect from a Telnet terminal and also trigger certain automated actions (typing in production token, credentials, template and SMS message). My final exploit looks like this:
  • Create a new template, with 156 'A' characters and 4 bytes of our shellcode address - 0x1C604. Remember, we can't send zeroes, so I had to add 4 to the message buffer address.
  • Create a new message with our shellcode, padded from the left with 4 'Z' characters, and from the right with enough 'Z' characters to make the whole thing be 56 bytes long. Now our shellcode is at 0x1C604 in memory.
  • Insert our template. Now we've overflowed 0x1C64, our shellcode address, into the sms_write_enter callback.
  • Exit the message screen, and re-enter it. Now we're executing our shellcode, which in turn dooes execve("/bin/sh\0", 0, 0).
  • Get flag.
  • ????
The final exploit code can be found at

And here's a video of the pwn happening:

An excellent challenge and CTF overflow. Thanks CCCAC and StatumAuhuur for the challenge, and thanks fail0verflow and pasten for the fierce competition!

But there are two parts left.... stay tuned.