On why my tbreak tracing trick did not work

By Gynvael Coldwind | Thu, 02 Feb 2017 00:10:38 +0100 | @domain: favicongynvael.coldwind.pl
On yesterday's livestream (you can find the video here - Gynvael's Hacking Livestream #8) one viewer asked a really good question - while analyzing a rather large application, how to find the functions responsible for a certain functionality we are interested in? For an answer I've chosen to demonstrate the simple trace comparison trick I've seen years ago in paimei (a deprecated reverse-engineering framework), however my execution was done in GDB (though any other tracing engine might have been used; also, if you understand some Polish, I've pointed at this presentation by Robert Swięcki on last year's Security PWNing Conference in Warsaw). As expected the trick didn't yield the correct result when compared with another method I've shown (backtracking from a related string) and I kept wondering why.

The general idea behind the trick goes like this: you set up tracing (and recording), start the application, and then do everything except the thing you are actually interested in. Then, you run the application again (with tracing and recording), but now you try to do only the thing you are after, touching other functions of the application as little as possible. And in the end you compare the traces - whatever is on the second list, but is not on the first one, is probably what we've been looking for.

In case of GDB and temporary breakpoints (which are one-shot, i.e. they become disabled after the first hit) it's even easier, as you can do this in a single run, first exploring all/some/most of the non-interesting functions, and then hitting the exact function you need, which in turn will display temporary breakpoint hits for whatever remaining breakpoints were still set.

So here's what I did (with pictures!):

1. I've generated an LST file of the target application (well, the target was actually GDB as well) from IDA (which is basically a direct dump of what you see in the main screen of IDA).

2. I've grepped for all the functions IDA found.

3. And converted the addresses to a GDB script that set temporary breakpoints (tbreak).

4. Then I run GDB in GDB, executed some commands and waited for all possible temporary breakpoints to hit (and become disabled). After that, I've executed the command which's implementation I was looking for (info w32 selector) and only one tbreak executed - 0x005978bc.

5. Using the known related string backtracking method I found the implementation at a totally different address - 0x0041751c. Oops.

So what did I do wrong? The answer is actually on the last screenshot. Let's zoom it in:

As one can observe, the addresses are dark red (or is it brown?), which means that IDA didn't recognize this part of code as a function. That in turns means that a breakpoint for this function is actually not on the list of temporary breakpoints, so there was never any chance for it to show up.

How to correct the problem? There are two ways:
1. If using this exact method, make sure that all the functions are actually marked as such in IDA before generating the tbreak list.
2. Or just use a different tracing method - e.g. branch tracing or another method offered by the CPU.

I've re-tested this after the stream adding the missing function breakpoint, and guess what, it worked:

(gdb) info w32 selector

Temporary breakpoint 1, 0x00417414 in ?? ()

Temporary breakpoint 4544, 0x005978bc in ?? ()
Impossible to display selectors now.

And that solves yesterday's the mystery :)

Fixing Atari 800XL - part 1

By Gynvael Coldwind | Thu, 19 Jan 2017 00:10:37 +0100 | @domain: favicongynvael.coldwind.pl
So my old Atari 800XL broke and I decided to fix it. Well, that's not the whole story though, so I'll start from the beginning: a long time ago I was a proud owner of an Atari 800XL. Time passed and I eventually moved to the PC, and the Atari was lent to distant relatives and stayed with them for several years. About 15 years later I got to play with my wife's old CPC 464 (see these posts: 1 2 3 4 - the second one is probably the most crude way of dumping ROM/RAM you've ever seen) and thought that it would be pretty cool to check out the old 800XL as well. My parents picked it up from the relatives (I currently live in another country) and soon it reunited with me once again! Unfortunately (or actually, fortunately) technological development moved quite rapidly through the last 20 years so I found myself not having a TV I could connect the Atari too. And so I ordered an Atari Monitor → Composite Video cable somewhere and hid the Atari at the bottom of the wardrobe to only get back to it last week.

After connecting 800XL via Composite Video to my TV tuner card (WinFast PxTV1200 (XC2028)) it turned out that the Atari was alive (I actually thought it won't start at all due to old age), it boots correctly, but the video is "flickery":

So I decided to fix it. Now, the problem is I have absolutely no idea about electronic circuitry - my biggest achievement ever in this field was creating a joystick splitter for CPC 464 (though I am actually proud of myself to have predicted the ghosting problem and fixing it before soldering anything). Which means that this whole "I will fix the Atari" statement actually means "I will learn something about electronic circuits and probably break the Atari and it will never ever work again and I will cry" (though I hope to avoid the latter).

This blog post is the first of an unknown number of posts containing my notes of the process of attempting to fix my old computer. To be more precise, in this post I'm actually describing some things I've already did to try to pinpoint the problem (this includes dumping frames directly from GTIA - this was actually fun to do). Spoiler: I still have no idea what's wrong, but at least I know what actually works correctly.

Part 1 - Debugging, some soldering, more debugging

My guess is that fixing electronic equipment is like fixing a nasty bug in unknown code. You need to familiarize yourself with the code in general and then start the process of elimination to finally pinpoint the cause of the problem. After you have done that, you need to understand in depth the problem and the cause. And then you fix it.

So from a high level perspective I expect the problem to be in one of four places:

1. The Atari motherboard itself.
2. The Atari Monitor socket → Composite video cable I'm using.
3. My TV tuner card.
4. The application I'm using for the TV tuner.

Starting from the bottom I first tried VLC to get the image from the tuner - this worked but I still got the same artifacts and I wasn't able to convince VLC to actually use the parameters I'm passing to it (I suspected the tuner is selecting the wrong PAL/NTSC mode). So I switched to CodeTV which actually did allow me to set various PAL and NTSC modes, but it turned out to not to fix my issue - actually after seeing the effect of decoding the signal as e.g. NTSC I decided this has absolutely nothing to do with my problem. So that's one point off the list.

4. The application I'm using for the TV tuner.

Next was the TV tuner card. My card - WinFast PxTV1200 (XC2028) - is a few years old and I never had much luck with it, so I ordered a new one - WinTV-HVR-1975. It should arrive next week, so whether it fixes anything will be revealed in the next part. I'll also play with some other options once I'm add it.

The second point on the list is the cable, and I'm yet to order a replacement, so I'll update this debugging branch in the next part as well.

Which brings us to the fun part - the motherboard itself.

I started by pestering my Dragon Sector teammate and our top electronics specialist - q3k - about what oscilloscope should I buy (I have some limited oscilloscope training and I figured it will be useful) and he recommended RIGOL DS1054 + a saleae logic analyzer (I got the Logic Pro 16 one) + some other useful pieces of equipment for later.

The second thing I did was to desolder all of the old electrolytic capacitors (making quite details notes about where they were and what types they were) as it seems to be a pretty standard thing to do when it comes to old computers. Once that was done (and I was able to read all of the labels, as some were initially hidden, especially in case of the axial ones) I ordered new ones and patiently waited a few days for them to arrive (along with some IC sockets which I plan to use later).

Once they did, I cleaned the motherboard around where they were at and soldered them in (I'm obviously not going to show you a hi-res photo of this as my soldering skills are that of a newbie) and connected the Atari to test it. It did boot, but the video problem was still there.

Chatting on IRC a colleague (hi skrzyp!) mentioned that it might be a GTIA problem (Graphic Television Interface Adaptor - the last IC in the line that runs Atari's video) so I decided to dump the video frame right at the moment it leaves GTIA. Researching the topic on the internet I learnt that Luminance Output 3 (i.e. pin 24) actually should be the Composite Video output (or what later becomes Composite Video); I also found out that pin 25 is Composite Sync Output, which meant I had all I needed to start.

Given that I didn't know much about Composite output I started by connecting my oscilloscope to the Composite Sync Output pin in hopes it will tell me something.

And indeed it did. It seemed that the sync signal is high for about 60μs and then low for about 5μs - this gives a cycle of 65μs, and 1/65μs seems to be about 15625 Hz. Now, this is meaningful since my Atari was PAL, and PAL is actually 25 FPS of 625 scanlines. Surprisingly 25 * 625 is also 15625, so there seems to be a correlation here - i.e. I figured that the signal goes low at the end of the scanline and goes back up at the beginning of a new one. Furthermore, after inspecting some "random flickering" on my oscilloscope I found that there is a series of 3 much shorter high states from time to time - I assumed this was the end-of-frame marker (or start-of-frame, didn't really matter to me).

After this I connected the second channel's probe to the Luminance Output 3, set the trigger to channel 2 and got this:

It took me a few moments to figure out that what I'm actually seeing is the top pixel row of the classic "READY" prompt, but yup, that was it. So it seemed that getting a frame dump shouldn't be a problem.

The next step was to connect the logic analyzer and acquire some samples. The one I have is actually 6.25MHz in case of analog data - this sadly meant that my horizontal resolution won't be good at all, as it leaves below 400 samples per scanline (6.25M / 25 FPS / 625 lines == ~400). Still, I figured it will be enough to see if there are any artifacts in the frame at this point.

A single frame in Saleae Logic looked like this (this was taken when Atari's Self Test was on):

I've exported the data to a nice 400MB CSV file and written the following Python script to convert it into a series of grayscale raw bitmaps (each CSV file contained about 50 frames):

import sys

def resize(arr, sz):
fsz = float(sz)
arr_sz = len(arr)
arr_fsz = float(arr_sz)
k = arr_fsz / fsz
out_arr = []
for i in range(sz):
idx = int(i * k)
if idx >= arr_sz:
idx = arr_sz - 1
return out_arr

def scanline_to_grayscale(scanline):
MAX_V = 7.0
scanline = resize(scanline, 400)
scanline = map(lambda x: chr(int((x / MAX_V) * 255)), scanline)
return ''.join(scanline)

if len(sys.argv) != 2:
print "usage: process.py <fname.csv>"

f = open(sys.argv[1], "r")

# Ignore headers

FRAME_BOUNDARY_COUNT = 100 # Actually it's ~21 vs ~365. 100 is an OK value.

scanline = None
clock_high = None

ST_LOW = 1

state = ST_INIT
frame_sync = 0
frame = -1

fout = None

for ln in f:
ln = ln.split(', ')
t, clock, composite = map(lambda x: float(x), ln[:3])

clock_high = (clock > CLOCK_BOUNDARY_V)

if state == ST_INIT:
if clock_high:
state = ST_LOW

if state == ST_LOW and clock_high:
state = ST_HIGH
scanline = []

if state == ST_HIGH and clock_high:

if state == ST_HIGH and not clock_high:
state = ST_LOW

if len(scanline) < FRAME_BOUNDARY_COUNT:
frame_sync += 1

if frame_sync == 3:
frame_sync = 0
frame += 1
print "Dumping frame %i..." % frame
fout = open("frame_%.i.raw" % frame, "wb")
if fout is not None:
fout = None
elif fout is not None:

The script generated about 50 frames for a dump of "READY" screen and a similar amount for "Self Test" one. All the frames looked more or less like this:

So, apart from the low resolution and lack of color (both expected) they actually did look correct.

Which means that the GTIA I have is probably OK. One thing to be noted is that my script actually had access to the composite sync clock and the TV tuner doesn't - so if the timing slightly off my script would not catch it.

Nevertheless it was a pretty fun exercise. The next thing on my list is to read more about Composite Video and verify that all the timings at GTIA output, and later on the Composite Video cable, are actually OK. Once I do that, I have to learn analyze the circuitry that lies between the GTIA and the monitor output socket, check if all the paths look good, etc. Should be fun :)

And that's all in today's noob's notes on ECs and old computers. Stay tuned!

P.S. Please note that there are probably several errors in this post - as mentioned, I don't know too much about this field, so errors/misconceptions/misunderstandings are bound to occur. There might be some updates to this post later on.

Hacking Livestream #5 - solving picoCTF 2013 (part 1)

By Gynvael Coldwind | Wed, 23 Nov 2016 00:10:32 +0100 | @domain: favicongynvael.coldwind.pl
Tomorrow (sorry for the late notice) at 7pm CET (GMT+1) I'll do another livestream on CTFs - this time I'll try to show how to solve several picoCTF 2013 challenges in the time frame of the stream (2 hours). PicoCTF 2013 was an entry-level CTF created by the well known team Plaid Parliament of Pwning - so expect the challenges to range from 10 points (or 30 seconds) to 100 points (several minutes). The first stream will actually be a really good opportunity for folks wondering what are CTFs about and how to start with them to have some of their questions answered (at least I think so). Anyway, the details:As always, the stream will be recorded and will be available immediately after the stream on my channel.

See you tomorrow!

Slides about my Windows Metafile research (Ruxcon, PacSec) and fuzzing (Black Hat EU) now public

By j00ru | Tue, 15 Nov 2016 14:12:22 +0000 | @domain: faviconj00ru.vexillium.org
During the past few weeks, I travelled around the world to give talks at several great security conferences, such as Ruxcon (Melbourne, Australia), PacSec (Tokyo, Japan), Black Hat Europe (London, UK) and finally Security PWNing Conference (Warsaw, Poland). At a majority of the events, I presented the results of my Windows Metafile security research, which […]

Django. Restricting user login

By sil2100 | Wed, 05 Oct 2016 19:52:00 GMT | @domain: faviconsil2100.vexillium.org
For a Django-based sub-project I'm working on, I had the need to restrict user login to only one session active and logged-in at once. As currently I am almost a complete newbie in this framework, I tried finding a ready solution around the web and failed, as nothing really fit my needs. After gathering some bits and pieces of information from around the internet I wrote a quick and very simple piece of auth code to do the login restriction I wanted.

Windows system call tables updated, refreshed and reworked

By j00ru | Mon, 15 Aug 2016 13:07:11 +0000 | @domain: faviconj00ru.vexillium.org
Those of you interested in the Windows kernel-mode internals are probably familiar with the syscall tables I maintain on my blog: the 32-bit and 64-bit listings of Windows system calls with their respective IDs in all major versions of the OS, available here (and are also linked to in the left menu): Windows Core (NT) […]

Launchpad API. Confusing binary builds

By sil2100 | Thu, 11 Aug 2016 20:29:00 GMT | @domain: faviconsil2100.vexillium.org
Another post on Launchpad API - will try to make it my last one, no worries. It's just that recently I've been dealing with it so much that I feel like sharing some of its caveats and my experiences with it. Today's post will be a short story about a certain edge-case one would need to watch out, titled: "accessing source packages through binary builds can be confusing".

Hacking Livestream #4 - DEF CON CTF (Friday)

By Gynvael Coldwind | Tue, 09 Aug 2016 00:10:22 +0200 | @domain: favicongynvael.coldwind.pl
I'm back from Black Hat / DEF CON, so it's time to do another live hacking session! The next one will be Friday, 12th of August, same time as usual (7pm UTC+2) at gynvael.coldwind.pl/live-en (aka YouTube). I'll talk about this year's DEF CON CTF (while it's still fresh in my memory), i.e. the formula, the tasks, the metagame, etc. I'll also show a couple of bugs and exploit one or two of them (i.e. whatever I can fit into 2h of the stream).

Where: gynvael.coldwind.pl/live-en
When: August 12, 19:00 UTC+2
What: DEF CON CTF 2016

See you there!

P.S. Feel free to let whoever might be interested know, the more the merrier :)

Live sec/hack session #3 - Thursday

By Gynvael Coldwind | Tue, 26 Jul 2016 00:10:19 +0200 | @domain: favicongynvael.coldwind.pl
Just a short note - I'll attempt to finish solving bart's CrackMeZ3S reverse-engineering challenge on Thursday, 28th of June, 19:00 UTC+2 (i.e. usual time).

Where: http://gynvael.coldwind.pl/live-en (YouTube - yes, I decided to move there)
When: June 28, 19:00 UTC+2
What: CrackMeZ3S part 2 (see part 1 announcement post / video)

See you then :)

P.S. The linear disassembly view I've mentioned I'm lacking in Binary Ninja? Seems it's already there in the new version - sweet!

Disclosing stack data (stack frames, GS cookies etc.) from the default heap on Windows

By j00ru | Mon, 25 Jul 2016 09:29:02 +0000 | @domain: faviconj00ru.vexillium.org
In the previous blog post, I discussed a modest technique to “fix” the default process heap in order to prevent various Windows API functions from crashing, by replacing the corresponding field in PEB (Process Environment Block) with a freshly created heap. This of course assumes that the attacker has already achieved arbitrary code execution, or is […]

LiveCoding or YouTube? Input needed

By Gynvael Coldwind | Sun, 24 Jul 2016 00:10:18 +0200 | @domain: favicongynvael.coldwind.pl
As I mentioned on Friday's livestream, I'm considering moving my streams to YouTube due to several factors (quality, less technical issues, etc). Keyword here is "considering", however I would like to make a decision before the next stream - thus this post and my request for your feedback.

The table below presents things I will take into account when deciding:

  • Resolution: 1080p
  • Bitrate: 3000kbps
  • Unlogged users don't see chat.
  • Rewind-during-live feature.
  • Adjustable quality during live for the viewer.
  • High delay between recording/streaming (20-50 sec).
  • HTML5 player by default.
  • Just works, or at least I did not receive a significant amount of negative feedback about crashes/lags/etc.
  • Has an API, chat is custom, but has REST API.
  • Around 2/3 of my viewers would prefer to move to YT***.
  • Resolution: 720p
  • Bitrate: 1500kbps (2500kbps said to be rolled out in 2-3 weeks)
  • Sound quality is lacking; might improve after 2500kbps rollout.
  • Unlogged users don't see chat.
  • Fast support, direct contact with project owner*
  • Very low delay between recording/streaming (~2-5 sec).
  • Flash player by default. Can't enable HTML5 player without disabling Flash in the browser.
  • Several reports of crashes or player not working (on last stream the player/stream crashed, even for me).
  • Strictly a coding service**. I.e. easier for people to randomly discover my stream just by going to livecoding.tv when I'm streaming.
  • Has an API, chat is XMPP.
* One might point out that given that I actually work at Google I would have direct contact with YT's engineers as well - while that is true, I prefer not to bother them with personal projects, unless it's a valid bug report or valid (in my head) feedback for a given feature of course.
** One might argue that my streams are not strictly speaking coding (well, it's security/hacking/reverse-engineering with a large dose of coding) but I would say it still fits and I did not hear otherwise.
*** Based on a Twitter poll as well as chat responses during the stream.

Another thing one might point out is that LiveCoding has a neat dark layout, which is better at nighttime. It turns out, that youtube has a similar one - just change the "www" to "gaming" in the address when you watch the stream (e.g. https://www.youtube.com/watch?v=SaUMQp2VWgg vs https://gaming.youtube.com/watch?v=SaUMQp2VWgg).

There are probably more tiny details here and there, but they are either not as obvious as the things listed above, or not really important in my case.

At this point I'm leaning towards moving to YouTube, as I did with my other live streams. Is there anything I missed and should take into account? Please let me know in the comments down below - thanks!

Live security/hacking/coding session #2

By Gynvael Coldwind | Wed, 20 Jul 2016 00:10:16 +0200 | @domain: favicongynvael.coldwind.pl
I'll be doing more livestreaming this Friday, same time (19:00 UTC+2) on gynvael.coldwind.pl/live-en (which at this moment points to livecoding.tv/gynvael, but looking at this poll I'll probably move to YouTube with my next streams). There are two items on my list for Friday's:
  • Either "Zippy" (WEB 300 from CONFidence CTF 2016, by mlen) or "Revenge of Bits" (STEGANO 200 from the same on, by me).
  • And CrackMeZ3S by bart after that. Please note that I might be struggling a lot with this one, as I did not solve/see it before, and I plan to keep it this way (a couple of viewers requested that I show my approach to unknown targets - well, that's the plan for this stream).
Apart from that one more thing: we actually have an IRC channel for my streams (well, Polish-language streams so far), but there is no reason for English speakers not to join; it's #gynvaelstream @ freenode. Or perhaps I should make a separate channel for the English streams? Let me know what you think in the comments.

In any case, see you Friday!

After live session #1 - how did you like it?

By Gynvael Coldwind | Sat, 16 Jul 2016 00:10:15 +0200 | @domain: favicongynvael.coldwind.pl
So my first livestream in English took place yesterday evening (i.e. evening in my timezone) and it went rather smoothly - nothing crashed, broadcasting was not interrupted at any time and I even was able to go through both ReRe (Python RE 500) and EPZP (x86-64 Linux RE 50) challenges. The archived video is already up on YouTube (see also below) and what's left to do is ask about about your opinion: what do you think? Or, to be more precise, what do you think about stream quality, the content, the way I was presenting things (i.e. talking about what is happening, but sacrificing speed due to that), the chat, and so on? What topics would you like to hear about next (another CTF challenge or maybe something else)? Please use the comment section below - your opinion is welcomed!

EDIT: see also this twitter poll: LiveCoding or YouTube?

Livestream starts at 15:20

See you next week!

Windows user-mode exploitation trick – refreshing the main process heap

By j00ru | Tue, 12 Jul 2016 09:53:51 +0000 | @domain: faviconj00ru.vexillium.org
During the weekend of May 21-23 (directly after the CONFidence CTF that we organized with Dragon Sector), qualifications to the famous DEF CON CTF 2016 took place. We obviously participated in what is probably the most binary heavy, challenging and competitive CTF of the year, eventually ending up 9th on the final scoreboard, which was sufficient […]

Live security/hacking/coding session #1

By Gynvael Coldwind | Mon, 11 Jul 2016 00:10:14 +0200 | @domain: favicongynvael.coldwind.pl
A few days ago I've posted a short note on Twitter asking if anyone would be interested in a livestream about hacking/security/coding in English - I figured that since I'm already doing them in Polish, I might as well try to do one in English. The response was overwhelmingly positive (thanks!), so it seems time has come to set a date:
  • When: 15 July 2016, 19:00 UTC+2
  • Where: gynvael.coldwind.pl/live-en - the link is not yet working, but it will lead to https://livecoding.tv/gynvael (the platform might change for the next episode, depending on whether everything runs smoothly and the quality if good).
  • Topic: a CTF challenge or two, probably exploitation or reverse engineering; since this is the first episode I'll take it easy and go with something I'm already familiar with - either a challenge created by me or one I've already solved in the past.
  • What to expect: Broken Slavic-sounding English (I'm not a native, my accent is far from perfect and my vocabulary is scarce - you have been warned). Since I'm used to tutoring, I'll try to explain everything that I'm doing in a clear way.
Feel free to pass the link to this post to others whom might also be interested - the more, the merrier (plus, we get to do a stress test of the streaming infrastructure, which is a good thing for future episodes).

See you Friday!

Details on a (not so recent now) stack-based buffer overflow in the Adobe CFF rasterizer in FreeType2 (CVE-2014-2240, CVE-2014-9659)

By j00ru | Tue, 07 Jun 2016 13:53:14 +0000 | @domain: faviconj00ru.vexillium.org
This blog has experienced a long time of inactivity, as I’ve recently used it only to publish slides from conferences I presented at, with many months-long breaks in between. I am planning to change things up and start posting again in the upcoming weeks, starting with this blog post, which I originally wrote in early 2014. I haven’t […]

Sources of ReRe, a Python RE500 challenge

By Gynvael Coldwind | Fri, 15 Apr 2016 00:10:02 +0200 | @domain: favicongynvael.coldwind.pl
The CONFidence Teaser CTF 2016 by Dragon Sector is now over and the results are in (congratz 9447!). Therefore I decided to share the sources of my task called ReRe, which was a Python rainbow-heavy obfuscation-heavy bytecode-all-around challenge. I won't spoil too much in case you would like to try to solve it (crackme/rere.py in the archive), but if you would like to read more on it, just see the SOLUTION.md file in the zip file. I'll add, that the obfuscation used self-modifying bytecode, some bytecode-level obfuscation and minor string obfuscation as well, so if you would like to learn more about Python 2.7 internal code representation, try your luck with ReRe :) It was solved 5 times btw.

Download: confidence-teaser-2016-ds-gynvael-rere.zip
"Video": rere_anim.gif (a 3 MB gif, you have been warned)
Have fun, good luck!

System Image Server Explained

By sil2100 | Wed, 23 Dec 2015 19:34:00 GMT | @domain: faviconsil2100.vexillium.org
Ubuntu System Image is the name of the client/server infrastructure used for Ubuntu Touch and (currently also) Ubuntu Core for image-based upgrades. In certain scenarios the standard apt/dpkg package-based upgrade mechanism is simply not good enough, so the whole Ubuntu System Image initiative was started a few years back. The purpose of an s-i server is to generate and export new images for selected use-cases whenever needed, allowing the client to notice and do the upgrade. Anyone can setup their own system-image server, in which case it's good to know what is what and how to prepare your configuration - along with some useful tricks.

Video: Python in a hacker's toolbox (PyConPl'15)

By Gynvael Coldwind | Fri, 23 Oct 2015 00:09:32 +0200 | @domain: favicongynvael.coldwind.pl
PyConPl'15 logoJust a short note that the video from my talk "Python in a hacker's toolbox" (PyConPl'15) is already available on youtube. The slides can be found here.

A classical language set used by a security specialist included assembly and C, sometimes joined by C++ and usually quite a lot of Bash as well. A few years ago it seemed that Perl, and later Ruby, will become the scripting language of choice in the security field, however another contender - Python - was gaining user base too. Today it's rather obvious that Python won its place in the hacker's toolbox, especially given that a great deal of important tools of trade allow to be instrumented/scripted using it - examples include even the most basic utensils - IDA, GDB and Burp. Furthermore, Python with its set of standard libraries makes it extremely easy to create ad-hoc tools whenever they're needed. At the same time, due to rich introspection mechanisms, the language itself is an object of fascination from the security scene. The talk will focus on a few selected cases of Python intertwining with the security world.

The talk is basically a mix of Python related topics I've touched during other talks I gave (commonly with j00ru) - this includes:
■ "Data, data, data..." (English, blog post + video)
■ "On the battlefield with the dragons" (English, blog post + video)
■ "Ataki na systemy i sieci komputerowe" (Polish, slides)
■ "Pwning (sometimes) with style - Dragons' notes on CTFs" (English, slides)



44CON slides and details about further Windows kernel font vulnerabilities are out

By j00ru | Thu, 17 Sep 2015 10:17:25 +0000 | @domain: faviconj00ru.vexillium.org
Since my last blog post and the REcon conference in June, I have continued working on font security, especially in the area of Windows kernel and font engines derived from the Adobe Type Manager Font Driver. More specifically, I moved from manually auditing PostScript Charstring implementations to running automated fuzz-testing of the overall font-handling code; after […]

Status update. LP API, release process and Qt5 QPA shortcuts

By sil2100 | Mon, 31 Aug 2015 13:01:00 GMT | @domain: faviconsil2100.vexillium.org
Things are very busy as always - not having enough time to write a full-content article I decided to at least post a quick update on what I'm working on currently. Most of it is of course Ubuntu related: besides preparations for the next Ubuntu Touch update (OTA-7) and dealing with the finalization of the previous one (OTA-6), I'm also working on two Ubuntu User articles and, additionally, working my way to becoming an Ubuntu Core Developer. I'm also investigating a bug related to Qt5 QPlatformTheme keyboard shortcut handling.

Results of my recent PostScript Charstring security research unveiled

By j00ru | Tue, 23 Jun 2015 18:38:51 +0000 | @domain: faviconj00ru.vexillium.org
Some months ago, I started reverse engineering and investigating the security posture of the Adobe Type Manager Font Driver (ATMFD.DLL) module, which provides support for Type 1 and OpenType fonts in the Windows kernel since Windows NT 4.0, and remains there up to this day in Windows 8.1. Specifically, I focused on the handling of […]

Binary to source name. The Launchpad API

By sil2100 | Sat, 06 Jun 2015 15:22:00 GMT | @domain: faviconsil2100.vexillium.org
It's been a while since I wrote a programming-related post. Today I'd like to share with you a very simple, but useful, thing in the 'devel' version of the Launchpad API. When using LP or writing Python tools that need to deal with Ubuntu repositories, packages and their versions, frequently the need appears to get the source package name from its resulting binary package name as published in the selected archive (usually the main archive). It's a rather new addition, but really really useful.

Open Source Days. DWO 2015

By sil2100 | Mon, 27 Apr 2015 22:19:00 GMT | @domain: faviconsil2100.vexillium.org
A quick post this time. A week ago I have briefly attended an open-source conference in Bielsko-Biala, Poland. Due to a Canonical sprint overlapping, I was only able to arrive for the last day - Sunday, so I missed out on many interesting presentations. But at least I was able to meet some very interesting people and do a short talk about the Ubuntu Touch release process, quickly overviewing what tools we use and what processes we follow.

When in Wroclaw - Piwnica Quest

By Gynvael Coldwind | Fri, 27 Mar 2015 00:09:22 +0100 | @domain: favicongynvael.coldwind.pl
A couple of hours ago I found myself, together with a couple of friends, locked in a small vault in a basement of an old tenement house in Wrocław/Poland. Objective: escape the room in 60 minutes (+ complete a side quest). To do this we had to look for clues, solve riddles, break codes (not unlike some crypto challenges I've seen on CTFs, though much simpler) and do quite a lot of creative thinking. In the end we failed (we were so close it's painful!). But we had A LOT of fun on the way anyway :). This kind of game is called "Live Escape Room" and the one we went to, which I strongly recommend, was the room "Vault" by Piwnica Quest.

While I shouldn't write anything about the room (it would just spoil the fun for others and that's definitely an anti-objective of this post), I'll mention that our group was 5 people (which is the max. for Piwnica Quest as far as I know) and that I was really amazed by some of the riddles they created there.

And yes, the riddles are in English as well, so you don't have to know encryptedPolish.

So again, a link to their site:

And I wish you the usual HF GL!

P.S. Full-disclosure: No, this is NOT a sponsored post - there are no sponsored posts on this blog. I really had fun and that's why I'm recommending it :)
P.S.2. I've been told there are more Live Escape Rooms in Wrocław as well - seems to be a good city for fans of this kind of activity.