Who's Online

DEFCON 16

So I got back from DEFCON 16 yesterday with both my laptop and me all in one piece (which is surprising given some of the antics over there). I managed to catch some cool talks as well as hang out with some interesting people. Of the talks I went to see, my favourite was probably on RE:Trace. RE:Trace is basically a Ruby frontend to DTrace that makes it much more usable for reverse engineering tasks than in its standard form. The guys that created it have got a pretty good introduction to DTrace and RE:Trace in the papers section of their site.

I also spent a bit of time in the lock picking village, which had some cool tutorials, and wandering around in the CTF area. The CTF itself was a bit of a surprise for me, primarily because of the sizes of the teams. When SkewlOfRoot went to pick up their prize it seemed like 20+ people were crowded onto the stage. It’s fairly impressive they managed to co-ordinate that many people although it did make me wonder if an upper limit on team sizes might be a good idea to give smaller groups a chance.

On a slightly less cool note were the number of people attending that seemed to have the cognitive abilities of a lettuce and the attention seeking mentality of a 12 year old. Yes, we get it…you’re dressed in black, you’ve got a coat hanger on your head and you’re the loudest person in the room, you’re quite obviously the hacks0rist hax0r in town. Now…could you please stop shouting about how much you love badgers? Kthx.

My own talk, titled “VoIPER: Smashing the VoIP Stack While You Sleep”, went fairly well and you can get the slides here. As I mentioned during the talk, I’ll be uploading an alpha version of the development branch later this week. It has lots of new fuzzers, runs quicker and has better crash detection.

UPDATE
Cheers to Sandro for directing me to this list of tools released at DEFCON 16. There’s everything from collaborative pen testing kits to kiosk pwning tools.

Stuff worth remembering

In the past 6-12 months I’ve learned quite a lot and come across plenty of fun new libraries and applications. Out of fear I’ll trip, bang my head and forget it all I’ve decided to document what I can before my rather fickle brain decides to clear up the clutter and leave me a dribbling mess. You might find this useful, you might not; either way feel free to add your own insights and comments (yes, I’m still not over the fact that I finally got a content wotsit that supports comments)

1. Research is *really* important before starting a new project. At a minimum (and assuming it’s an area you are already familiar with) allow yourself a week or two of googling and pouring over research papers etc. Google Scholar is incredibly useful and allows you to find citing and cited papers once you’ve found one of interest/relevance. Prior research allows you to avoid spending hours agonising over problems other people have already solved and means you can get onto the real value adding stuff much sooner. In terms of building a product this means you get to spend more time working on what sets you apart and ahead of the competition, and I’m fairly sure that’s a good thing.

2. Research is important for supporting your ideas but don’t let it unnecessarily restrain you. By this I mean, don’t let the ideas in the papers you’re reading completely take over your thoughts. Allow room for your own original ideas. In a similar vein, reading paper after paper without applying any thought to them is essentially useless. Have a pen and paper ready and document *every* idea you have before, during and after researching a topic. You’ll probably cross a lot of these off as you go but some of them will be invaluable.

3. As a last point about research, don’t believe everything you read. Peer reviewed articles are usually of a high standard but not always and sometimes when it comes time to do some implementation you discover a number of areas in which papers have ignored potential sources of error or have brushed them off as inconsequential. As I said, research is a useful prop but is no replacement for your own brain.

4. Everyone should have a pen and paper. They’re wonderful things. Ideas come and go and writing them down now is always going to be better than trying to remember them later.

5. Design is important at all levels. From high level component interactions to pseudo-code documenting an algorithm. If you can’t design something on paper then chances are it’s too complex to do it for real. Often times when a design doesn’t quite seem right it’s easy to say “Ah, sure I’ll it out when it comes up”. The problem with this is that if you can’t sort it out now when you’re clear headed then how could you possibly hope to solve it when you’re up to your eyes in implementation details. An inability to design something on paper can either mean you’re too tired/distracted or the solution is sub-par. In both cases it can be useful to go away from the problem and do something else for a while.

6. The Zen of Python should be renamed The Zen of Everything and made mandatory reading for everyone over the age of 5. Once that is done it should be beaten into every Java programmer that has ever written ‘} catch Exception {’. As soon as they’ve been soundly trounced, we’ll deal with the C++ folk and their use of assert().

7. Test! Test! Test! I know…it can be boring…really boring in fact, but it is absolutely critical for any serious application. Unit tests give you confidence in your application which is just as useful as the quality they add. Having the discipline to write tests for everything is something that still evades me but even with the amount I do I can see the benefits. Believe it or not, testing actually allows you to be more productive as you spend less time worrying and manually running code. For Python I’ve found the inbuilt unittest module to be excellent and fulfills most of my unit testing needs. The only place it falls down is the lack of mock object support and this gap is filled nicely by pymox from Google.

8. Write your tests *first*. This was an odd one for me when I started doing it but was one of the most profound revelations in my programming career. Writing the tests first is somewhat related to the design I mentioned in step 3. If you can design an algorithm completely on paper and then have the mental clarity to write a test that documents the results you expect, then chances are you’re on to a successful solution for your problem.

9. There’s more to testing than unit testing. Just because your algorithms are correct doesn’t mean your results are. Higher level design problems aren’t the target of unit tests and can easily go unnoticed. Test the entire system from a set of known inputs with known results. This can be more difficult and tedious to set up than unit testing but without it it’s hard to be fully confident in a solution.

10. Expand your knowledge beyond whatever field you currently specialise in. RSS feed conglomorates like PlanetPython or one of the others are excellent for this. By following these you can find a wealth of information on subjects related to your interests but slightly away from what you might delve into yourself. Looking into these other areas can keep your mind ticking over and provide plenty of new problems to think about and tools to solve them with.

Righty, well that’s that taken care of. As I said, comments are welcome. In my next post I’ll go through some of the cool new apps and libraries I’ve come across in the last few months.

New blog system

Righty, I’ve changed the blog software and move the old content to the ‘Old Content’ menu for now. I’m hopefully going to get this place looking slighlty more respectable in the next few weeks but for now this will do. Comments and suggestions are welcome.