Vegas, The Riviera, Hardware Hacking Village, Lock-picking Village, a whole host of talks, iPhone users filling the wall of sheep, fake ATM in the foyer, yep its DefCon17. Here is a quick overview of some of the talks I attended in no particular order.

Locally Exploiting Wireless Sensors & An Open JTAG Debugger – Travis Goodspeed

Travis had two talks lined up this year, “Locally Exploiting Wireless Sensors” and “An Open JTAG Debugger”. It would be an understatement to say that Travis knows a lot about microcontrollers and in his wireless sensors talk he showed how you could extract an encryption key from a device in order to give yourself a foothold on the wireless network. In the break out session there was some discussion about how this could enable someone to break into “smart” land mines. As Travis said, its pretty inconvenient if the enemy blow up your land mines whilst you are crossing them!

The talk on JTAG covered Travis’ open JTAG project for which he has built an open source USB JTAG adapter, named the GoodFET, which can work with multiple different chips through re-flashing. There were clearly a lot of difficulties to overcome during this project, it sounded like this was primarily down to a lack of publicly available information on the hardware. This talk also looked at methods for getting around a blown JTAG fuse. In the breakout session afterwards we saw how it’s possible to use a disposable camera to blow the innards of a chip such that you could no longer use JTAG to debug at all – very cool.

Win at Reversing: Tracing & Sandboxing Through Inline Hooking – Nick Harbour

I saw Nick’s talk last year on pescrambler which was pretty cool so this talk was one on my list of ‘must attend talks’. This year Nick talked about using inline hooks to monitor a function call and demoed a tool he has written called API Thief which uses DLL injection on a process whilst in a suspended state in order to hook functions. The quality of the data output was significantly better than comparative tools, however, I haven’t had a chance to play with it yet.

USB Exploits – Rafael Dominguez Vega

The first thing we learned from this talk is how it feels to be a sardine, it was packed and a lot of people couldn’t get in to see it. Despite working with Raf I hadn’t had an opportunity to see this presentation before the day. You know a good presentation when the powers that be request that it is censored! Nevertheless, Raf presented some excellent stuff which really should get people thinking about whether they should disable USB by default on their new system builds. The slides are on the Labs website so take a peek for yourselves (http://labs.mwrinfosecurity.com/projectdetail.php?project=12&view=publications) – I believe these differ slightly from those on the DefCon CD.

0-day, gh0stnet and the Inside Story of the Adobe JBIG2 Vulnerability – Matt Richard, Steven Adair

Remember the Adobe JBIG2 vulnerability? These guys know a lot more about it than most and set out to answer some key questions, such as who was behind it, but also whether the disclosure was handled appropriately.

Adobe users were exposed to a vulnerability being exploited in the wild for quite some time, and no patch seemed to be particularly forthcoming. So, ShadowServer went down the partial disclosure route making people aware of the issue and a workaround. This inevitably led to full disclosure and PoC code being posted to Milw0rm. This raised questions about the most appropriate methods for disclosing vulnerabilities responsibly. Is it responsible to not disclose fully? Partially? These questions don’t get any easier when something is known to be being readily exploited in the wild.

Router Exploitation – FX

The authority on hacking Cisco was talking… Now, in the past we have seen plenty of Cisco vulnerabilities but a distinct lack of decent exploits; successful compromise of Cisco equipment has traditionally relied on misconfiguration or insecure configuration of the device. FX went through some reasons why this may be the case and covered some of the architectural reasons for the lack of decent exploits and how we can go about writing Cisco shellcode. Perhaps we will start to see more Cisco exploits in the future…