Let's participate at Boston Key Party CTF 2016.

The CTF will begin on 04 March 2016 22:00 UTC and ends on 06 March 2016, 22:00 UTC.

As usual, we will play as team sec.se. The team communicates through the CTF team chatroom.

| |
  • 2
    who can play on the team? I wouldnt mind a CTF – TheHidden Mar 4 '16 at 14:44
  • The link is dead. – PyRulez Mar 10 '16 at 13:01
  • @PyRulez because the CTF is over. Check it out on wayback machine – HamZa Mar 10 '16 at 13:03

Here is a solution along with the hows and whys this worked:


We were given a web application with a very simple interface, a background image and a text box allowing for an input.

The web application was a JavaScript front end which connected to a python flask application on the backend over a web socket. This python backend then connected to a database to upload our answers and also retrieve a single entry from the database.

What we learnt from examining the code:

  1. The replies and requests were made over socket as a json array
  2. The data was handled and escaped by a self implemented function
  3. The database was MySQL
  4. The statements are being loosely prepared (string being created and variables added after)
  5. The encoding for the back end script with shift_jis

What does this tell us?

This tells us that we will not be able to use an overly simplistic injection attack (using special characters such as " / ' and so on).

("\\", "\\\\"), 
("\0", "\\0"), 
("\n", "\\n"), 
("\r", "\\r"), 
("'", "\\'"), 
('"', '\\"'), 
("\x1a", "\\Z"), 
def mysql_escape(s): 
for find, replace in MYSQL_SPECIAL_CHARS: 
s = s.replace(find, replace) 
return s

The only way to connect to the back end is the web socket so we will need to find away to call this socket directly (without the slow user interface and user experience getting in our way).


After much thought, it was concluded the best form of attack would be MySQL injection but taking the approach of exploiting character encodings.

after much research, trial and error a usable encoding was found, we used a Japanese Yen symbol. taken from : https://www.ipa.go.jp/files/000017321.pdf

The Japanese Yen symbol when processed by a SQL statement in hand with the shift_jis encoding is first handled as 00A5 (the symbol its self ¥ = 00A5) while a backslash \ is 005C when converted to shift_jis the Yen symbol becomes 5C thus logically becoming a slash and escaping the sql statement.

from the image you see below you can notice our final solution discovered by @hamza to capture the Flag.

enter image description here

| |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .