phew. conference is over. i was gone for 4 days, two of which were nearly entirely travel, the time flew like two days, and i'm drained like i've been gone a week.
home sweet home, where 9 degrees fahrenheit is great walking weather and snow is all around.
the RfCat class went great! there were some hitches getting machines working correctly (the most infuriating was caused by the conference-provided wifi filtering out offensive-security.com, required for installation of the pyside library on backtrack), and a couple "bugs" in the courseware that i'm ironing out now, but overall the class was a great first running. the students seemed to love it, they seemed to understand what i was teaching, and they seemed to glom on to the things i think are important for wireless hacking/reversing. i was a little concerned. less than a week before class i decided to flesh out one exercize into 20 pages because of the importance of the lessons it teaches, and it seemed too much. at the end of the course, that exercise was cited multiple times as the most valuable part of the course. yay! i'm sure i can continue to improve upon the class, but overall the people were great and the class seemed to come off well. i look forward to completing the two-day version. thank you all who came and participated! hopefully i'll be able to teach the 2-day course at blackhat in vegas... we'll see.
so the talk went well. timing was about perfect, the reception seemed good, the questions were thought-provoking. oh, and the beard fit pretty well. :) the new york times blog post which followed created quite a stir in the power industry, particularly for power-meter vendors. it kinda made me laugh, kinda made me sad. that wasn't even my target audience. a few candid thoughts on these events...
first off, the press is always pressured to sell media... and that coupled with their natural curiosity and desire to call out lies and problems, can lead to a bit of rough edges in reporting, and the nuance of some communication can be lost. they are also writing to millions of people, which makes it even more difficult to effectively communicate the nuance. and sometimes they get certain details just wrong. nicole perlroth of the nyt appears to be striving to do a good job reporting what's going on. i truly believe that, and that says a lot for a reporter coming from me. i lump her into the category previously occupied only by elinor mills. i'm intrigued at her being an "aspiring hacker", lol. however, nicole got a couple details wrong that i wish she hadn't, partly because i was very careful *not* to say certain things. for instance, i did make a comment about the titanic, and that we may still have rudder enough to avoid the ice-berg... however, that was not directed at the vendor i used to demonstrate hardware-hacking against. it was about a control systems environment which continues to keep valuable security research from happening through lame excuses and overpriced widgets. i stand by that statement. we *must* get to a point, and very soon, where all scada/ics equipment can handle an NMAP scan and *not* fall over, and far far more. i completely understand what's at stake. as an electricity-addict, i demand high availability of electricity. however, the lame excuses of "our environment is too complex to build a testbed" and "you can't change anything or it may break" have got to be stopped. these systems which are part of our "critical infrastructure" need to be treated as critical in a different way... and vendors pressured to make their products more robust, security tested... and utilities pressured to fix or replace devices which suck.
secondly, the power industry is very knee-jerkish about "anything that can cast doubt upon the technology." i fielded several calls the next day from friends and companies in the industry. sadly, it looks like i may have cost one friend a contract to do security research... something about "if he's talking publically, what's to keep you from talking publically?" *bullshit*. the answer? i have no contractual obligations not to talk! if you hire someone to do this work, you will certainly have some nda to keep them "on your side".
power folks do live in a very odd sort of environment, with both private industry concerns and governmental regulatory / funding concerns. newer smart-grid companies get the benefit of impending large purchases of their new products, so they can (if only they all would!) provide security for the 21st century (yes, some of them are that far behind). unfortunately the control systems folks don't have anything quite so new and sexy to get the replacement purchase revenue... thus they have little incentive to do security research. if your stuff cost >$1M and the only reason to replace it was because you wrote shitty code, you might be reticent to make a big deal about it too. utilities could provide such pressure, but they are stuck in a two-faced conundrum as well... their power engineers have had great success for decades using the "if it ain't broke, don't breath on it" approach... and the decision-makers haven't seen any vendor-options with good security to choose from! without the purchasing power of "the new great smart-blah" and po's for 100,000 units, they feel powerless to push the vendors to improve. meanwhile, government regulations can incur great costs if power is disrupted... and the relationship gets stickier from there, including federal governance to protect national interest and the public utilities commissions trying to protect consumers. so what the fuck? who can do anything? it's gridlock... it's the titanic. so yes, they react very poorly to anything that causes negative view from the press. we're stuck in a tight spot, but all hope is not lost.
some AMI vendors seem to have figured a lot of this out. silver spring networks is one of the latest to join the enlightened crowd, as they have been actively engaging security testing from skilled folk for about a year now. others who seem to get the problem include Itron and Elster, both of which have been engaging sec-researchers for several years. they are grokking the importance of continued vigilance, and have been working with reputable hackers to keep improving. many utilities also seem to get this. even some scada folk get the importance, and are working with security researchers to learn and deal with the problems... however we need to keep rethinking about the problem, breaking bad assumptions and teaching the details of exploitation so that we have a hope of doing something beneficial about it. we need to break through the FUD factor about security research. lots of time and money spent will not fix this... only with the understanding of exploitation will any of this money and effort benefit us.
thirdly, regulators have to keep people happy... and they control much of the utility industry... so unless we the people have the gumption and opportunity to tell govies/utilities "yes, we are willing to spend an extra buck a week for cybersecurity", the utilities have limited leverage to demand it from the vendors. to some extent the press can help here.
fourthly, i wasn't saying the "smart grid can be penetrated". that's such an overloaded phrase anyway, with about 16 distinct possible meanings. it's healthy to think that the smart grid can be compromised, and i'm confident that many individual devices that make up the smart grid can be. but nothing i said or did would be considered a compromise by any means.
finally, there was no technical exploit in my talk... it was simply showing some of the hardware reversing that goes on, what it looks like, and the current state of the research. the talk does not call out any specific vulnerabilities except SSN choosing a chip in their older gear that is easy to debug and pull firmware for analysis. while all of this is "hardware hacking", the goal of my research has always only ever been to provide a base whence to actually test the security that *should* be in place in the upper layers of the networking stack.
the purpose of my talk was to:
* show what kinds of things are possible and break down the "black box" nature of lower-level hardware-hacking
* empower the audience to break through the poor assumptions that come from lack of understanding
* encourage control systems folks to build strong devices capable of both providing security and resisting attacks
* encourage utilities to implement strong, multi-layered security with ways to identify, thwart, and react to attacks
* drive all involved to question what they are told... and prove it for themselves... to take responsibility and test.
in the end, i hope that the power industry gets less reactionary and more proactive... and more able to deal with the heat and pressure of their current circumstances, i hope the media will get less inciteful and work with the power folks and researchers in a way that conveys a better message, and i hope that we can turn the titanic before it's too late.
hey, if you are coming to GrrCON or DerbyCon, the folks at GrrCON have
provided a place to preorder RfCat's. you can elect to meet me at either of
the *two* cons (very gracious of the GrrCON folk!) or pay a few bucks more and
have them shipped to you (no guarantees on timing of shipped-delivery).
lots going on lately. to many things to talk about.
ok, so to be totally honest, i did not "win" ctf. i was on a great team that worked really hard, thought outside the box, and overcame lots of obstacles to win ctf. in fact, you may have even seen me walk across stage right at the end of the team, but i really played little role in that. perhaps the role of encouraging, prodding, thinking. turns out, wrffr and i spent a lot of time reversing compiled perl code in a silly but annoyingly insane service called parrot (which, to my knowledge, nobody else landed either). there were times wrffr and i talked about working on something else, and indeed he ended up working on another service for a while called "gallows", but we never landed either. in fact, speaking with cas after the game, wrffr still working in a corner while the rest of us drank ddtek's liquor, i found out that wrffr's service was a red herring... without a vuln. it was apparently to alert ddtek in th event someone popped an 0day and started simply overwriting keys (as if that'd be a bad thing).
parrot was kinda sick (although i give great cred to cas for making it interesting). the service was compiled perl (using B::C), which means that there's a massive initialization phase (placing the program into memory as perly things). connect to the service, it forked itself and provided you with an ever-changing menu with altered characters to make the words in the menu. there were two options, one was a version of Mastermind, the other a version of Madlib. we were able to modify variables using Madlib templates we were able to name, and using that capability, we had to modify the number of Mastermind options there were (the game uses 200, something we could not brute force before timeout-disconnect). once there, you had to play connect-four against some very lame ai (ie. easy win at this point) before actually causing an overwrite memory corruption and gain code execution. this, where parrot's perly-cousin 'dog' forced you to simply play the game and get a key :)
binary ninja junk
wow, fun stuff. vivisect was made public! envi and viv work continuing, good stuff. nothing like grokking systems at a binary level. love seeing others discovering the beauty of the bit (yeah, the manifesto got it wrong). computers are nothing more than a binary pointalism.
so, we're continuing to improve and use RfCat for amazing goodness! i wish i could tell you some of the conversations going on, but some pretty awesome folks are using and abusing the RfCat. again, back to my love of grokking things at a really low level. yes, i realize an sdr is lower level yet, but RfCat is right where it needs to be in order to bring the power of RF to the widest audience. major thanks to Major Malfunction, Michael Ossmann, and others who have provided patches for new functionality and bugs/bugfixes! Andrew recently reported a bug in the Frequency handline which Mossmann then submitted a patch for (awesome)!
ok, so i read an annoying headline the other day. "61 bills: congress is on pace to make history with the least productive legislative year in the post-WWII era".
great. so we are measuring our legislature's productivity in how many bills they've passed. i'm reading that to state "let's make more laws" and that i'm not ok with. how about someone calling out how few laws have come *off* the books? that is a better measure of success in my book, at least at the moment. let's lessen the burden on the american people, reduce the number of laws we have to be unaware of.
had some medical issues but handling it. thanks for your kind words and care. not outta the woods yet. found some bad infection, but looks treatable, not sure if there are other issues at play still. waiting on cardiologist
grrcon and derbycon
so, Derbycon and GrrCON decided to overlap, sorta. however, i'll be presenting at both, as will kevin johnson. come to both! more info following soon about preorders for RfCat to be picked up at either GrrCON or Derbycon!
so another year, another trip to defcon for atlas, full of no sleep, ctf hacking and a fun presentation.
but wait! this year there's more. RfCat is being preso'd and i'm running a workshop at blackhat! it slices, it dices, it makes a ginsu feel inferior! (well, if ginsu could communicate wirelessly...) one of the highlights of my year was when a very well-respected friend told me "it's not a swiss-army knife of subghz wireless. it's the f*ing samurai sword of subghz wireless!"
so all three of my loyal fans! listen up! come to the blackhat briefings! use your company's hard-earned conference reserves and make it happen...
*but* bring a TI chipcon cc1111 of your choosing - either the Chronos Wireless Dongle (must say "cc1111", not the one with 4 or 6 programming pins coming off the back) or the cc1111emk (evaluation module kit) (preferably). they're $49 on the site and they take about a week to get - DON'T DELAY. then, program them using a goodfet (typically free from travis but you have to solder them yourself and provide your own components) or a chipcon debugger (also $50).
i will be bringing 10 RfCat dongles (signed by me ;) that i will be selling for $69, all ready to go.
however, 10 is not that many. so if you want to, please buy them off me (i can't get stuck dropping $500 and not selling any), but if you want to make sure you can get the most out of the workshop, you may want to buy one and have it flashed and ready to go. if you catch me tuesday night with one that you've brought, i'll try to make sure everyone's is flashed with the latest RfCat firmware. if not tuesday, i'll likely have some very intelligent and handsome folks who have volunteered to help who should be able to flash your dongle wednesday morning... if thats what you're into.
if this is too much to ask, *still come!* it will be informative, instructive, and entertaining! much of the information will be similar to shmoocon, although there's been new research since then, the tool has *seriously* progressed since then, and i'll get to finish the talk!
ok, it's over. i have discovered the higgs bosun particle. with it i intend to inspect your computer memory without any network connection necessary. just wait, geolocation has already shown me whereabouts to look... ok, your isp's computers just gave me your address... scanning the area for anything that looks like.. ewww... no, the insides of your dog are now being probed... sorry. ok, there is your computer. ok, and your administrative password is....
wow, flame is amazing! i think it's tied to the death of osama bin ladin! i heard it had something to do with global warming as well! someone who should know talked to someone who should know better, who then talked to someone they went to third grade with (although i assure you that was a long time ago), who talked to their mother, who talked to a reporter. you want chain of custody of informationz! _t_h_e_r_e___y_o_u___g_o_!_!_!_
you know, maybe flame is tied to the "security vulnerability" in those chips used by boeing, or if the two had kids, maybe they'd be able to cross the jtag-ethernet gap that currently has reports looking like complete morons.
holy crap, has any worse reporting been done on anything? why was the word "stuxnet" even muttered about flame, except to gain attention?
i've even seen non-ElinorMills Smart Grid reporting that's better than this (Elinor throws off the curve a lot, so we have to exclude her).
we the people... demand that reporters be paid as part of the NEWS, not ENTERTAINMENT. throw off the yoke of the almighty web-hit-counter!
i will now shut up before i waste further bandwidth on these idiots.
hey all, looks like they'll take anyone talk at blackhat these days! even me.
come see me talk about <GHz radio. heard enough of me talking? wear earplugs and come exploit my IMME screens during the talk!
if you attended my shmoocon talk, you probably remember the "RF ATTACK FORM" slide. well, after talking with some folks after the talk, it became apparent that slide should be fleshed out more and made into it's own document.
so here it is. please review it and let me know if you have any questions at atlas-at-r4780y.com.
there are some specific details of FHSS systems that are fleshed out, including FAST/SLOW fhss, channel hopping pattern calculation algorithms, and sync algorithms which you may not know, but may prove invaluable if you can find out. possible methods of determining these include reversing the protocol manually (doable, but tedious and difficult), pulling and reversing firmware of a target device (downloading updates for firmware can work too!), social engineering (or just plain asking the right people), etc....
sorry, this isn't the changes that show progress in my research, cuz quite frankly, i've been recovering from the last month and a half of research (or rather, helping my family recover while i sleep more).
however, i added the following golden link to the slide on researching with FCC.gov:
the fcc search engines are all disparate and funked up. google doesn't search them either. there once was a tool used by Novell CNE's to research all sorts of stuff, and i used to equate google to the replacement of that... sadly i am mistaken in this case.
but this page will help you find information on products by fccid.
you can find the updated slide-deck here or the odp version here
it was great to see so many friends at once at shmoocon, and make new friends. thank you for the amazing time. now it's time to go to sleep. i've got about 20 hours to make up, and miles to go before i sleep (literally, like 50 miles)
special greetz out to cutaway, mezzy, psifertex, kjo and crew, Q, thing2 and dan, mike ossman and travis, the brothers figueroa, G Mark and dino. thank you dca tsa for not groping me or scanning me this time.
i should probably post *new* slides here within a week. subscribe to the rss feed to be notified when i post them. i'm going to see if i can't nail down a few more details that were bugging me on the demo's, and actually talk to the insulin pump.
ps. thank you for so many kind comments about the talk, they are very appreciated. i'm excited about how many other radioheads there are.
hacking is prime time. whether you are good at throwing metasploit payloads, cracking codes, finding bugs, or writing 0-day there are many interested organizations that would like your acquaintance. such groups include organized crime, nation-states, mega-corporations, terrorists, and boutique consultancies. jobs (legitimate ones) range from penetration testing to exploit-development, and -- apparently -- spy?
- intro to challenge
the gchq (aka british intelligence) recently released a challenge, arguably to generate interest and find smart people to fill the roll of ??spy-related hacker/code-breaker??. i usually gloss over things that don't promise good vulnerability research/exploitation. there's only so many hours in a day, and i have a family to protect (from my own neglect). however, this challenge, hosted at http://canyoucrackit.co.uk, piqued my interest, mostly because of the good hex-pr0n.
the challenge (in case the site is down), seemed to consist of the following png, the message "Can you crack it?" and a web field to enter a Key.
the hex bytes were enough to get me to overcome the time/value dilemma and dive in. intelligence and code-breaking isn't really my strong suit, but i enjoy learning new aspects of my PRECIOUSSSS binary space.
my first thought was 'it looks like x86 instructions'. EB always looks interesting (as it's the first byte to the 'jmp' instruction, something also common in videogame-cheat identification). in fact, EA, EB, E8, and E9 are all interesting, being a combination of 'call's and 'jmp's. also of interest is the various 41 41 41 41 and 42 42 42 42 bytes, which most hackers will identify as the most common bytes to use in fuzzing (although i'm partial to the 40 byte, the @ symbol). a few other things jumped out at me, including that part that solidified my confidence that it was x86 machine code: cd 80 ("int 0x80", the instruction used by user-land code to communicate with the linux or bsd kernel.
i've been working with disassemblers/emulators for a while, mostly based on invisigoth's ENVI disassembly/emulation framework. so i saw this as a great opportunity to play with in an emulator. i've done similar things in the past, but it's always been a one-off solution, slammed together in a frustrating/frantic rush. also, for some time i've been using a hacked-together cli tool which gives me command-line access to x86 disassembly. i decided to take some time and extend the cli disassembly tool to include some rapid emulator-spinup helper code. the result is the new (currently slightly ugly) envi_x86.py addition to atlasutils. note: many of my tools are designed to be used from bash or ipython. note: most the code is ugly.
slapping this in the emulator produced no identifiable results, so i loaded the bytes into a disassembler and did some analysis. the code reads like shellcode, with a jmp/callback method of finding EIP and relative in-memory resources/gchq.
the first four bytes of this decode to "BBBB" (42424242). the next dword make the number 0x32, which is the length of the remaining bytes. i think we found our encrypted portion.
and the output:
added challenge: the bug!
so i plugged all this into the emulator, called emu.runmap:() and when it terminated with the "INT 0x80" instruction (calling SYS_EXIT), the memory location held a whole lotta nothing. i kept plugging away, changing the way things were laid out, debugging, and eventually gave up. something was terribly wrong.
vdb to the rescue
eventually, i decided to use the real machine. to do this, i loaded up a binary in my favorite debugger, VDB. the idea is simple: run a program, attach and stop it with the debugger, copy the bytes into executable location, set the Program Counter to the start of the bytes, and run it. since i run 64-bit linux, i had to find s 32bit binary, since these were 32bit x86 instructions. running "file /usr/bin/* |grep 32" found several usable binaries, and i chose to run "wineserver" which worked great. the last executed instruction of these bytes would terminate the program (and wipe memory) by asking the kernel to SYS_EXIT, so we want to place a breakpoint before that is executed. since VDB is a programmable debugger, i used the following script to load up the bytes and prepare it to run.
and the resulting memory looks like this.
since emulation is so important to me, i wrote a tool that locked the emulator and a debugger in step and compared the registers and memory after each instruction.
if you are only interested in the challenge, move to the next section.
during lock-step emulation, i discovered a bug in the emulation handler of the ROR instruction. intended to ROLL RIGHT (bits shift right, but instead of just falling off the end of the lowest bit end, those bits get placed back on the most significant bit. the handler was written exactly as described in the IA32 manuals, but whereas the manual dealt with size in terms of bits, the handler was written using the size in terms of bytes. fixing this allowed the emulator to work correctly as well.
added challenge: the bug!
so the emulator i wrote worked for the most part. the codeflow for an emulator is simple, and similar from platform to platform. read in the byte(s) necessary to determine the instruction type and decoding pattern, read in any additional required bytes, decode the instruction and its operands, then perform the emulation steps as close to the specification as possible. the emulator was great, but i noticed that the code they provided in the memory variable 'mem' wrote the number of the destination address (offset into the data segment) into the location. this didn't really stick out to me as odd, since the identity permutation (each byte is equal to it's offset from the start) is the first thing that happens in stage1! turns out, i copied and pasted wrong... so i was using the same operand for data and destination... doh!
yeah, but now i'm pissed.
the thing they didn't tell us... the memory architecture is a 16-byte segmented address-space, with a code-segment register and a data segment register. all data references are assumed to be offsets from 16*DS (data segment register). all code references (ie. the next instruction and jmps) are either inferred to be offsets from 16*CS (code segment register), or explicit given in a second operand (in the case of 'jmp r2:r1').
however, when using the 'jmp' instruction variant that provides a code segment, not only are we to recalculate the new instruction pointer based on the explicit code-segment operand, but undocumentedly, we have to update the CS register with the new value. wtf?
however, once we make the changes, everything works out ok. the output looks like this:
so now we get to some fun stuff... finally, a PE binary (run file on it if you doubt). i prefer ELF, but PE is fun. let's see what this thing does.... threw it into the disassembler, and discovered what it does. the executable opens 'license.txt' in the current directory and reads the first line. it first checks the first four bytes against "gchq" (the number 0x71686367 in LSB is 67 63 68 71... or 'g' 'c' 'h' 'q'),
then runs the next 8 bytes through posix crypt() function using a set SALT of 'hq' (see wikipedia for info on SALTs in cryptography).
if they match, the next three dwords are used to create a URL can call back to a provided host. handing in www.canyoucrackit.co.uk, the executable connects and pulls the following url:
two problems. what's the crypted thing??? and what's the next three dwords?!?
problem 1: the crypted 8-bytes... so i started with all sorts of cracking techniques, including wrapping several 'john --stdout' setups to permute different password attacks. after further analysis, however, it because pretty clear that the 8 bytes were simply used for "client-side auth". ie. i just NOP'd out the the comparison and conditional jmp instruction, and skipped the whole mess. insert my favorite 8 bytes, and on to the next problem...
problem 2: the three dwords to be used in the url. i looked around for any hints as to what could be those 3 dwords, finding nothing (except that they compiled it all in cygwin, and had dependencies on a couple cygwin libraries). i tried a few oddities, including nulls, oddities, and other numbers. the trick was remembering unnecessary dwords from previous stages. the first instruction of stage 1 is "jmp 04", skipping over four bytes (af c2 bf a3) that are never again referenced. stage2 has two dwords in the firmware variable.
'firmware': [0xd2ab1f05, 0xda13f110]
so i suspected that if i did an HTTP GET on some permutation of the following URL, i'd finish the challenge:
added challenge: the time!
the twist... it never worked. i tried every permutation of this URL, swapping byte-arrangement for the numbers, and eventually wrote a script that randomly selected from the valid bytes to form new url. i only ever got to determine that i got the right answer by looking up a cheat writeup that detailed the last section.
if i'm not mistaken, the gchq, interested in only british citizens, failed to consider other time-zones in their web app. i thought it was quite considerate that they gave me until midnight in my own time zone... but probably not. as i'm several hours behind GMT, depending on the time of year, when it showed that i had 50 minutes left (when i got around to the answer), the challenge was over for hours. oops.
oh well, so i didn't get it. but i grew some, had a *lot* of fun, and "sited in" my toolset. and since i'm not a british citizen, i'm doubting they'd want to hire me anyway :) especially since i got a lotta irish in my veins.
however... just to recap some lessons learned, and other thoughts i want to leave you with...
* hacking is not a good way to make money.
it is a passion you pursue. money just sometimes ensues...
* never give up
* take good notes along the way... and review when you are stuck. you never know when tidbits of odd info may help you.
* identify your weak points
- fix them
* understanding... grok the planet!
* unit testing! holy crap. both stage 1 and stage 2 in my work would have been improved had i spent the time to write unit tests for each instruction emulated.
if you found this interesting enough to walk through the steps on your own machine, or otherwise enjoy breaking software/hardware, drop me an email at firstname.lastname@example.org.
good. now i can get back to writing my talk for shmoocon and truing up some code.
sitting on a plane, walking through the grocery store, buying a snack at a deli or airport or fruitstand, the tabloids (yes, most mags fit this category) just gush over the latest on kim (or her sisters), brittany, brad, or angelina. we get a front-row seat to the mess that is their lives. and the messier it is, the more coverage it gets.
the thought on my mind as i glance over at seat 4B, is "are we caring about this?! why?"
basically, kim is a human being, or was once, before we made her and her friends into hollywood monsters. i'm sure she was a very nice person. but exactly why am i caring about her awesome marriage or the schwetty (as in bawls) divorce? or "oh no he won't divorce me and it isn't fun any more!"
i'm sure different people have many varied opinions on the people in hollywood, on the cover of magazines, and those cutting cd's. as a Christian, i am called to care about all God's creatures, human or otherwise. that does not mean i have to particularly like them, although i really don't have feelings about kim, except sadness and pity. i'm sure she has had dreams, i'm sure she has had heartache. i'm sure her marriage and subsequent issues are not totally her fault. they never are... and yet, in marriage, you both are responsible for success and failure. this is where careful selection of your mate is vital.
but we set kim and others like her up for failure all the time. me? you? sure. how, you may ask? by reading the trash... by talking about it... we set them up for failure by worshipping them, by giving them all they think they want, for using them and being used by them. that is the whole life of many famous people... to use and be used, and in the end hope you used more than you were abused, and can thus "come out on top". fame is very seductive. it offers a feeling of importance, but unlike McDonalds coffee, doesn't come with the disclaimer: CAUTION! MAY CAUSE SEVERE INJURIES. most famous people are so unaware of fame's treacherous nature that they don't recognize their own peril until they are nearly hopelessly addicted to the feelings, the scene, the life. and that life will pwn you.
as a relative smalltimer in the fame-game, i have still spent considerable time in contemplation, in prayer, and sometimes falling to the addictions. often having to "take off" the many blessings that have been dumped on my head in order to see life soberly. what is the difference between brittany spears and other talented singers/dancers (ok, be nice, i realize she's easily ridiculed at this stage in her scene-addiction)? i look at my own path, and how many things simply "came together" that could have easily gone a different way. i have certainly been blessed with opportunity, and status. for the past six years i have fought to earn the fame and reputation that i still don't deserve... to be a person of integrity, to live up to those expectations of me. during that time i have experimented with different lifestyle changes that may or may not help in my life, but could possibly have helped with my abilities, and sometimes, simply for the sake of the game... to further my already overly-inflated ego and reputation. there have been many times the addictions could have pwned me, and without the wisdom i request from above, and the humility i'm often reminded to strive for, i could be just as screwed up.
but i've been married for 13 years now. more or less happily, but ever committed. i've sacrificed, and caused pain to myself and my wife, and occasionally my kids. and they still love me, and i them. you see, the thing that makes famous people (and their marriages) so interesting to read about is the drama and typical failure that ensues. marriage requires a few things that we entice out of famous people if they let us... humility (true humility), integrity, and commitment. i understand the draw of feeling like a rock-star... i often have good-intending friends pushing that on me, and it feels good... real good. but the rock-star status can make us think too highly of ourselves... get us used to having our own way too frequently... of worship and flattery. sadly most of us don't want to seek out honest criticism, so when it comes it often comes in harsh ways, making it even more difficult to accept, and easier to dismiss without addressing real issues.
on a side note, it would be easy to presume that i believe fame is inherently evil, that it should be avoided at all cost, and that all famous people are stupid or also evil. that is far from the truth! fame is both blessing and burden... powerful, and perilous. but fame is a tool that can be used for immense good. it can provide spotlight for insights into Truth and benefit, provide incentive to excel, and provide the right people with the ability to cause good to happen. how would you use fame for others' benefit? and now back to our regular program....
i once had a close friend tell me "you only show your love by what you sacrifice for something/someone." this person's rock-starness dwarfs mine, and i'm sure he has to deal with these issues every bit as much as i do... but that meant a lot to hear. i have sacrificed for my family. i love them and they me. love is a commitment, to desire their benefit even if i don't like it... and even when i don't like the way the person is behaving. this is the kind of love we are called to have in a marriage and in family.
so i ask you this... how can these famous monsters we've created ever find longevity, success, and fulfillment in marriage? they first must find humility, integrity, and commitment... find kindness in their hearts... and commit to sharing it over the rest of their lives. next, they recognize that it's ok to feel good about yourself, but not beneficial to anyone to think that you are more important than other people. humility. i may be better than most people in certain areas of my life and career. but that does not make me more important than others. i'm thankful for the compliments, and grateful for the praise. but know this: all of us in the limelight have to struggle with pride, with fear of the loss of our fame, with megalomania.
so i'm sorry for misleading you, kim kardashian doesn't really like me. she likely will never even know me. but should we really care? i feel sorry for her and kris, and everyone else drawn into the vortex of fame without the anchor of Truth. focus on your own lives, and leave them to theirs. until they do something atrocious with the spotlight we give them, it really doesn't concern any of us. they will have a hard enough time trying to relate in this world without our paying $3.99 for every magazine smearing them and their personal lives across its pages.
oh, and if she did like me? i'm sorry, but i'm already taken.
sorry all, i've been doing a few releases rapid-fire lately.
as always, quality control is best effort. if you find something that's broke please let me know and i'll try to get around to fixing it quickly.
these updates have seen the updates of vtracenewkids.py (the way i do rapid-fire child-grabbing in vtrace) as well as some interesting 3d stuff using Vpython.
yeah, you read it right. although i have been focusing my efforts of invisigoth's disassebly stuff, i still have some loyal users of disass, so i made some updates recently. most notably this new version doesn't require you to have pyElf installed.
ps. disass is teh suck, but it does make some problems easier... if making many scary assumptions to do so. don't judge me by this code. i shudder to read it. still, if you want something that prints out pretty-like, disass can be a fun tool.
sorry, i'm a few versions behind. not a lot has changed, but got a new toy or two, and fixed a few bugs.
somewhere along the lines i refactored the genformatstring code... and it changed the way it works. this is because different types of format commands handle things differently, and the offset needs to match the type of format function.
there is also a new toy called vtracenewkids.py. somewhat similar to grabnewchildren, but using vtrace and better (imho). it works differently than grabnewchildren. you run "$ ipython vtracenewkids.py ", and it grabs a list of processes. when you are ready to attach to the new kid (possibly not immediately after the kid is available), type "wait()" and return. the vtrace tracer object will be "t"
ps. as always, this is crap, but it's useful to me. anything is in a state of relative brokenness. if you'd like to share what's broken or what should be better, email me at email@example.com
it is official. 1@stplace, the greatest ctf team ever to have existed ;) is coming to an end.
these last 6 years have been some of the best of my life, and the friendships and growth that the team has fostered has and will continue to pay dividends. many of us have changed jobs (for the better, some of us twice), and most of us are closer today than most ever were. the strangest thing is running into other 1@stplace members in the business arena ;)
many other thoughts going through my head right now... but they're better discussed over a beer or shot.
on behalf of other lastplace members, i'd like to thank all who has watched us have all this fun. i look forward to seeing what other amazing things my friends will accomplish. most, if not all of us will be at defcon this year. if you see one, buy them a drink, you might be surprised what conversations may ensue.
let's see, most of these were discovered while driving long distances. not recommended but somewhat highly effective... somehow it's easier to focus on coding when email and phone and other work aren't expected.
i don't remember all the major bugs, but here are a couple i've had to overcome in my own jtag/arm code:
* unsigned long - i rewrote travis' jtagtransn code since his was targeted at 16-bit micros. my code allows for variable bit-lengths, up to 32 bits instead of the static 8/16/20 the original code allowed. apparently i had not used appropriately large variables to shift up to 32 bit positions, and things worked great until i was shifting past 16-bits. doh! unfortunately at this point i was still so green that finding this bug was so very painful. thankfully i was able to use travis' debugging code, add the debughex32 function and print out values quite easily in my interactive python session.
* arm's word-alignment - jtag writes instructions into the instruction pipeline to read/write registers, and just about every other thing it does. the instruction to write to a register is basically LDR Rx, [R14]... load whatever is at the memory location stored in r14 into whatever register you're setting. instead of loading from memory, the jtag interface provides whatever value needs to be coming "from memory". worked pretty good, but while testing i always ended up corrupting it and occasionally when i *wasn't* testing i would dork something up, and rather than writing 0x47145, it would write 0x4714500, 0x45000471, or 0x71450004. it was a real mess. after *much* gnashing of teeth i figured out that if the value in r14 was not perfectly word-aligned (ie. r14 % 4 == 0) the value i handed in was being shifted accordingly. sheesh! before this process i was a jtag n00b, but now i'm rather bruised... but confident i know what i'm talking about.
* dclk timing - i had all the foundational things working, breakpoints/watchpoints, halting, reading/writing registers... everything that had to do with the EmbeddedICE or running instructions at debug speed. unfortunately, the fun stuff really starts to heat up when running instructions at system-speed (the clock everything else like memory and peripherals is running at). rather than handing in information to write in a register, actually having the data pulled from memory, and vice-versa. basically, you insert a breakpoint in a nop just before the instruction you want to execute at system-speed, provide the instruction into the pipeline, then write the "restart" jtag instruction into the jtag instruction register. should be easy as pie. but try as i might, i could not get things to execute at system-speed. it's like that restart just never occurred. in fact, it wasn't. troubleshooting such things is a nightmare. i ended up writing python code to interpret the jtag events out of my oscilloscope... it was really neat when i got done, but wow, the suck. i love doing cool stuff... but when i'm sticking tons o time into something i'm not sure is worthwhile, it's not so fun. as it turns out, i was dragging the jtag state engine through "run-test/idle" haphazzardly. well, when the arm7 chip is in debug mode, each time the state engine passes through "run-test/idle" it provides a tick of the debug clock. without caution, too many hits of dclk can make that breakpointed nop slide right through the instruction pipeline before i set the restart instruction... no worky. so, ultimately, while troubleshooting this bug, i scrapped everything, started a brand new c and python code chain, provided only mandatory functionality into the embedded c code and reimplemented most functionality in python, and cleaned up the handling of dclk... and all was well.
sure, fine, go pick out bugs in the code... i hope you do. the GoodFET is to embedded hardware what vdb is to software.
holy crap, haven't had so much fun destroying things in a while.... a local gaming shop just opened up and they have six battletech pods. sure enough, they are just like i remember them from 15 years ago. only difference is, back then they cost $9 for a 10-minute mission. at the ulx gaming on plainfield in grand rapids, they cost $1.50 for a 10 minute mission. not only cheaper, but i actually can afford it.
anyway, hacking fun hardware stuffs. mostly been doing stuffs that my jtag/arm code for the GoodFET helps with. the jtag/arm is coming along nicely. once i figured out about 4 show-stopper bugs (ie. i couldn't buy a vowel to make things work right) new development is no longer like pulling teeth (like people around my neighborhood have any to spare!). ended up moving the majority of the code into the python side on the host (yes, invisigoth, you were right ;) basic arm7tdmi crap done, now it's just a matter of implementing flash and other chip-specific code. too bad i'm kinda focused on an arm chip that doesn't have built-in flash and i'm having to write code to control external flash... but pretty soon i'll be able to play with some code and make the sam7 chip bow to the GoodFET. (http://goodfet.sf.net/)
"you're sure you're ok with dropping out of the competitiion?" ladyJ asked.
"of course i'm not *ok* with it. but you're more important."
that was the way my saturday morning opened. being forced to choose between my wife and my team and quals. easy choice, but an altogether sucky one.
thursday morning we received a call from her father informing us that her mother, one of my dearest friends, was in the hospital after sustaining what turned out to be a massive stroke. at first we thought the call was about her grandmum who had been in the hospital just a week before. never did it occur to us that this healthy, active, 52yo empty-nester would ever suffer this unpredictable fate.
ladyJ was admirable in her support of my commitment to lastplace, particularly since cutaway and mezzy were coming up to hang out at our pad for quals. when i first heard the news i offered to pull out immediately, but she told me i had made a commitment and i needed to keep it. while my heart was torn, i was happy to hear that. quals has been on my mind for a long time, and my team is very important to me. my thursday was a wreck, but cutaway, who arived early encouraged me to dig into binary and i felt better for it. overwhelmed, but somehow strangely happy.
friday was a mishmash of awesome and grueling challenges (wtf was up with pwnage100?? wrffr and i each owned it 6 ways from sunday including shellcode and rop, even bouncing through their own code to pop a format vuln to gain vis, but couldn't land anything on their box) but we were lovin it. eating raw packets for breakfast? sure why not. indeed, there were like two real categories, sliced up shuffled and arranged into six, with the point value not having the least bit to do with difficulty, but we were on it, all five and a half of us (mezzy's boss chained him to his desk on friday, his flights got delayed, and he ended up spending all night in airports). around 8am i fed the horses and then mezzy, cutaway and i crashed for a couple hours (seperately, i might add.... metr0). at 10:21am i get this call, and it's ladyJ. she'd had enough. she made her way through social engineering the hospital staff and basically capturing their comms (good thing since she's been keeping them in line ever since) but she needed her man. she called, i answered, and as painful as it was, i walked away, leaving mezzendo in charge. now don't get me wrong, lastplace doesn't need much manageement, but i needed to make sure someone had final say in disputes, someone kept track of who was doing what, someone who could make the call when enough was enough (like, 100 points for pwn100?? i needed to quit long before that and move on). someone who could keep the spirits high, focusednot only on the scorfeboard, but on the challenges we were bangin. basically, someone to enable each of the teammates to keep on rockin. we call it the 'buckstopper' and mezzy was teh right guy.
well, saturday came and went. b-Bomb (ladyJ's mom) was getting worse again. friday she has spoken directly with each of her kids and family, showing that the person that is my friend is still in there. but most of saturday she was less responsive, and by the end of the day, both sides of her body were flexing and trying to ball up. while that seems like good news since her left side is not under her control, the doctors explained that the brain tissue was swelling and they needed to remove part of her skull to allow the brain to expand without causing more damage. so at 3:30am the surgeon cut out about 15% of her skull and stuck it in deep freeze for a while. the brain kept swelling, and eventually shrunk back a bit. the surgery was necessary and seems to have done its job, but now she's got to wear a helmet to protect her brain. although i gotta say she looks pretty awesome in her punk-rocker hair-style with half a shaved head. i doubt she'll appreciate my saying so, but oh well, she can get her own damn blog and gripe when she's recovered.
sunday was rough. she was lethargic and fairly nonresponsive. she wasn't talking, although she'd squeeze and wiggle toes on command. good signs, both, but still not what i was hoping to see. i want to see my friend again. so this morning ladyJ sent me home, relieving the fourth babysitter and allowing me to hang with my kids and work most of the day. special perk was that mezzy and cutaway hadn't left yet, so we got to hang for a couple hours and recount the weekend highlights and just enjoy some chill-time (of course, after cutaway did a leisurely 6-mile run).
today (monday) has been pretty good for mom as well. she's miserable. that's good, though... it's promising. she got the breathing tube out today, her throat is dry, and she's miserable... but she's awake enough to be miserable... and as must as that sucks, i'm happy she's awake and responsive.
so quals was kind of a bomb. i'm not sure how good a job they did of measuring hacking ability, but they were fun. quals has progressively grown into its own game over the years. i think this year grew a little too far away from ctf, however. there may come a day when quals will need to be split off and simply run as its own game.
meanwhile, my team will keep hacking. i was very proud of the guys this year. i think each member of the team carried their weight and then some. it was good to see the l@stnewbs doing great things. the veterans did amazing things, and me, well, i got to watch some powerful challenges make and harden friendships. my werk was well paid back.
thank you ladyJ.
hey there sp0rtsfans. defcon ctf quals starts next week friday. one of the most amazing part of ctf since i've been playing it has been quals. a weekend of caffeine, sleeplessness, technology, binary leetness and sheer determination. i only hope my kids 'get it' soon so i can share the time with them a little, rather than have it make my family feel abandoned.
last year we took the year off. seemed a good plan. everyone was burned out, we had major scheduling conflicts, including my own attendance at a good friend's wedding. it was good for all of us.
in case there was any question, lastplace will return to the game this year. be warned, the team has gone through several very huge changes with the loss of a few key members (heck, when there's only 8+-1 of you, everyone is key). this year is a rebuilding year in which we may give credence to the team name. whatever. this was never about winning, it's always been about playing, growing, and having a metric shitton of fun. once rollin i realized how big a deal the comraderie was. we look to have a good team this year, it's just gonna be different, as i say farewell to very dear friends drb, psifertex, and shiruken. drb has been burned out since the first year, and i've been playing on his ctf-addiction ever since. psifertex has had a very difficult choice to make since he works with all the team-awesome guys and staying with us was causing significant difficulties, and shiruken was also burned out.
we've added a few really awesome guys, so we're sure to have loads of fun. we'll see how things turn out, we hope to see y'all at defcon.
so shuffle the shellcode, gentlemen. love comes again.
sorry for the outage these past few days. the r4780y hosting was ripped right out from under us, and my blog was unfortunately affected. the hosting has been graciously provided by psifertex these past few years, but he's found that hacking is more fun than sysadminning his own box. secureideas has offered us a little cubbyhole, may thanks to kjo and the gang!
long time no talk! been very busy working in embedded systems lately. turns out there's a lot of opportunity in embedded hacking these days, particularly in control systems (SCADA).
another exciting thing. i poked at SANS since i saw they offer a leet-looking course (SANS SEC 709), written by my bud, stephen sims. well, you know me and my addiction to teaching... so now i'll be teaching "Developing Exploits for Penetration Testers and Security Researchers" in portland in november! sweet!
so if you have the balls (chicas are welcome too), come on out and hack with me!
Dude, lastplace got sk3wl3d this weekend at defcon. For those newcomers who are lost, I'm referring to defcon capture the flag contest held each year in vegas. ctf has a history of drawing the best of the best from all corners of the world, and this year was even moreso. wowhackers and taekwon-v from Korea came on strong, overcoming the language barrier and doing very well indeed. Up until the last five minutes of the game, taekwon-v had lastplace relegated to fourth place! Thankfully, the lastplace superpowers blasted one last break-through just in the nick of time to finish a solid third-place (indeed, kenshoto even changed our name on the score-board to 3@stplace ;)
Sexy Pandas were sexier than ever this year, taking command of the game very early on. Unfortunately, as they did last year, the pPandas seemed to lose their Gambas around the middle of Saturday. I don't know what's up with them, but I'm guessing they need to learn to cope with more sleep-deprivation :) They were amazing while they lasted though (remember, they drew first-blood last year).
Shellphish was back again after "taking a year sebatical", having not qualified last year. While it was good to see Giovanni Vigna and his team again, I was surprised that they didn't do as well as expected. As I can say the same about our team this year, I totally understand.
IGuardMiLan (sorry, I don't remember their real name), an Italian team from Milan, seemed to be doing very poorly (and unfortuantely I didn't get a chance to get to know them much)... but on Saturday night kenshoto gave out a challenge and ominously indicated it was worth "a couple hundred points" and both Shellphish and these guys nailed it! I'm not sure what it is about these Italians ;) but the challenge turned out to be worth 300 points, which they both got! Rock on! Unfortunately for the Pandas, this placed both of these teams above them. The challenge was this: kenshoto provided a text file with all of shakespeare's works. our job was to find the longest run of bytes which convert to x86 opcodes which don't touch memory. Very cool challenge, I spent a little time on it, and actually found the answer with the tool I wrote. However, without my emulation code in place I also turned up many false-answers, based on conditional-jumps so I dropped it. Bummer too. I wish I would have submitted it.
The Routards were back from last year, and came out of nowhere on Saturday to overtake us as second place, where they remained for the rest of the game. A French/Suisse team, they were really smokin!
And then (sound the Emperial March) came the Sk3wl 0f r00t. Lead by Jon Boss ("BossMan") and driven by Chris Eagle ("sk3wlmast3r"), these guys *completely* rocked our world. For the last two years lastplace has been stealing victory right out of this team's clutches using creativity, game-play, and a slight touch of evi1. This year, Sk3wl returned all we had given them and more. Probably most evi1 was when we used some technical prowess to keep Sk3wl from getting credit for many points last year, for several periods of several hours. This year, Sk3wl multiplied both the evi1 as well as the technical awe of our attack from last year, instead, denying any of our teams the ability to score. How they did this, I can't say specifically, but let's just say they pwned the services themselves and made their own version of a "service-r00tkit", modifying information to either prevent us from gaining shell on the box or changing the contents of keys so we received bogus keys and our overwrites were dorked as well.
I gotta admit, if we couldn't win, I'm ok with Sk3wl winning. Not only did they *totally* deserve it this year, but they're a great bunch of guys. I have a lot of respect for sk3wlmast3r and Bossman and the team they fielded this year was truly outstanding. Their game-place was flawless, their technical leetness was untouched, and they have real character. At the end of the game, they set-up their own projector on the wall over their team and played Guitar Hero... lol... but before they did, Bossman came over and said to me "I know this is going to seem arrogant, but this was not our idea... and I just wanted to let you know." That was pretty cool of them. They had every right to rub it in, but chose not to. rock on guys.
Ah, my dear lastplace.... On a personal note, I think it was really good for us to lose this year (sorry team, it's what I think). We came in as two-time, back-to-back winners, and a third time would have already been difficult to remain humble about. We also had let ourselves get complacent. I'm sorry guys, this one falls completely on me. As the buck-stopper, and as your captain, I failed in many way, the chunks of which I will not spew here. Having succeeded from the very beginning, I knew I/we were doing the right things for success... but I didn't really remember what the right things were this year... so it was a growing experience. Having not been defeated, I personally felt the stress of continuing the winning streak, even as much as I struggled against it. And after three consecutive wins, I was heavily considering "retiring" at least for a year or two. Now? I'm not quite sure what's going to happen. I know some of the guys are happy to field a team again next year. I'm going to hit 'em up in a few months. ctf bears some strong similarities to child-birth . Gradually one forgets how much pain and agony and misery goes into ctf, and for some crazy reason the desire to play again returns :) On the positive side, we played a very good game, aside from a few failings of mine. Most impressive to me is how much our attack-team has improved as a whole. We still have a couple rock-stars, but each of our attack team were "in the game". psifertex, jrod, jesse, drb, and myself, we were all in the same playing-field. That doesn't mean I think we don't need to do some training soon. I've got some very specific things in mind and there are many others I'm sure. But I got to see some of the other, lesser-contributors last year really stepping up, and that encourages me that the team is doing what it's meant to do. I'm also looking forward to our feeling challenged to excel... instead of just being "good enough".
To show up to the game is to be a winner. Each of the eight teams has to qualify in order to play the game (the returning champions don't actually have to play the quals round, but by being champions they already "qualify"). This year, well over 400 teams showed up for quals, and actually answered at least one question. I think at least 150 teams answered two or three. This is pretty significant, considering. Each of the teams I got to chill with this weekend had significant skillz, and it was an honor to be among them.
Ok, here's the (teasing) rant part of this blog post. Each of the teams playing in ctf qualified for the game... except one. One additional Korean team qualified this year, but they dropped out and we ended up with the first runner-up... That wasn't so bad (in fact, I was happy at the time because I have friends on the team which got to come). However, little did I know that this "first-runner-up" team would go on to completely dominate the game, shutting down our ability to score, and run away with the competition. That's right, folks. Sk3wl 0f r00t *failed to qualify*! lol. Oh well. </rant> I'm still glad they came. However, this highlights the reason lastplace has taken part in quals each year even though we didn't have to: ctf and quals are two very significantly different games, each one being amazingly awesome and worth the time and effort. kenshoto continues to deliver top-notch entertainment for the subversively-minded binary-hacker.
Many thanks to kenshoto, and especially to my good friends visi and squires... who did bring a fully-automated nerf-gun into my talk at defcon and launched a massive assult on the stage... that was awesome. In an otherwise draining and sad day, that gave me a great boost. I warned the crowd they might have to wake me up in the middle of the talk. I had bounced all over throughout the country, flying, driving, not sleeping, etc... and was already exhausted when I showed up for the sleep-depriving all-weekend siege of ctf.
BTW - If visi doesn't see fit to keep vtrace/vdb available from http://www.kenshoto.com/vtrace I may be lead to post them here.
sk3wlmast3r rocks. Let me just say that. He's an awesome guy, and one of the most brilliant reversers I've ever met. The last two years when lastplace beat his team, he was exceedingly gracious, meeting me with a (albeit disciplined) smile and congratulations. There's no doubt about the fact that he currently dwarfs me in skillz... but I've always been impressed with the man behind the evi1 :) I got to go see his talk at defcon (after ctf) and it was pretty slick. Keep on, man.
disass-v4.0 didn't make it for ctf. Sadly I had to use a mixture of disass-v3.0 and IDA to work on the vulns. This will continue to consume me for some time, until I have a workable GUI or I give up the whole mess (and mebbe write a CLI). I'm currently considering opening up development to interested outsiders, as it's quickly growing beyond something I can/want-to maintain alone. I'm not a GUI programmer, and would prefer telling someone how I want the GUI to behave and then go write the cool methods the GUI calls to actually do the work. Just a heads-up.
I got to spend time with a smattering of great friends this weekend, too many to list, and way too short a time to spend with each. But I wanted to send a shout-out to my awesome team, drb, wrffr, psifertex, mezzy, plato, shiruken, jrod, apu, and a couple guys who hung with us a bit and helped out some with a couple bins, and all the ctf teams (you all rock). Greetz to sk0d0 and jmfb, Figueroas, Subverted Dave, j0hnny, Thor (even though you skipped out on me :) Travis Goodspeed, GMark, vangelis, kenshoto (inc goons and pj, nice dice), Moose and VirusX (now *with* the Moose! thx for the Braundo dude, it kept me up on Saturday!), and the dudes who came to my Q&A session,
R.I.P. E P I C. I missed you. If we'd won ctf I was going to say it from stage.
Well my friends, CTF Quals 2008 has officially past, and what a wild ride it was. I'm barely awake this morning, not fully recovered from the weekend... but I'm sure some of that has to do with the incredible Paintball-Bachelor party I was called upon to make happen on Saturday. Yes, my team had to do without me for about 12 hours of the competition. I'm the best man, what could I do? Thankfully I have a brilliant team and a very strong co-captain. Even without me, they had to pull back a bit to avoid directing the game. You see, as last-year's CTF winners, we don't have to qualify (place in the top 7 teams), and feel a little awkward about choosing categories which could make or break other teams.
Intro to Quals
For those of you who are unfamiliar with the phenomenon that is Quals, each year Kenshoto, a terribly cool bunch o' hacker puts on the Defcon Capture-the-Flag hacking contest, but to get into the contest your team has to qualify. Quals (ctf Qualifier round) typically takes place a week or two after Memorial-day, and is a Jeopardy-like game with five categories with five challenges each providing from 100-500 points (no, there's no Double-Quals entry where you get to choose how many points to gain/lose). Unlike Jeopardy, in recent years Quals doesn't reduce points for wrong answers, and while each team somewhat chooses their own pace, you can only select challenges that are "available". The team who answers the newest challenge first gets to choose the next challenge, making it available to the rest of the teams. Quals has always been an excellent training-ground, and a worthy game in and of itself. In fact, Quals in 2005 was my entry and training-grounds for hard-core binary hacking.
If you remember last year, all the leading teams made it through all but one of the challenges, and it was the Binary Leetness 500 point challenge. It was insane and incredible, and worthy of spending our time. This year was a bit more of everything (except web-hacking, but more on that in a minute). The only down-side I ran into this year was BinLeet300, a challenge which I feel could have been better scoped or something. The question was "What libc function is this?" and we were given 57-bytes of binary which converted into basically a spinlock and a strlen. The question lead me to believe that I got to see the whole function, although I have heard the answer was inet_aton. what?
However, that's a minor complaint, whereas the whole rest of the game was amazing. First off, let me just pay homage to kenshoto's ability to keep the game stable!
Forensics 500 was quite the challenge, being an image of Kenshoto's logo, requiring conversion to another format and then analysis of the colors to identify an undisclosed form of stego.
BinLeet400 was a BSD kernel module which replaced much of the kernel call-table (yes, rootkit-style) with pass-through wrapper versions.
My favorite of the whole game was RealWorld300, a telnet-based D&D style game. Enter your name, hack your way through (literally, but the game was an RPG about hacking), and if you win, you find yourself the proud recipient of a format string exception. Through that FSE, you have to figure out what address to overwrite and what to overwrite it with. Thankfully, the FSE is great for stack-based recon. Read the write-up on http://nopsr.us to find our nifty stack-address-math-magic. Very fun, and I think the best part was getting to hack along-side drb most of the time. He's a brilliant friend, but we always seem to be working on separate tasks.
One interesting thing was the loss of the WebHacking category. I feel it is a loss indeed, as this is where most vulns are found these days... however, with the inclusion of RealWorld, I think the game was better this way.
Sk3wl0fr00t did not qual this year... perhaps sk3wlmast3r had a Bachelor party to attend as I did. I don't know what happened for them this year, however this is a great example of how different quals are from ctf (not that I'm complaining, they're both amazing). I'm sure that someone will drop out and that this ctf-titan will once again be making the competition difficult for all of us.
Shellphish was among the teams to qualify for ctf. Proven to be powerful in the past, this former-ctf-champion failed to qualify last year for whatever reason. Lead by Giovanni Vigna, Shellphish will make the competition interesting to say the least.
For those with a pair, check out the Quals write-ups over at http://nopsr.us
Sorry, but no GUI yet. Still working on a great deal of changes for disass, including disass-emu, an emulation framework for x86. As you can imagine, these take an immense amount of work. Kenshoto has asked 1@stplace to create a challenge for the impending CTF Qualifiers, and its been eating up a great deal of my time lately.
Well the great and mighty shmoo has left the building. What a weekend. I'm beat.
I couldn't get in until Saturday night, but I hear Friday and Saturday were amazing. Everything from H1kari's FPGAs attacking cellular to hacking Second Life's helper apps (dude, they really hacked quicktime through the game!? sweet!). Jay Freakin Beale had an acapella rap-cameo by his fellow Intelguardian JimmyD! G Mark is always interesting to hear and cool to chat with. Simple Nomad apparently had a picture of him on CNN (Crappy Network News) where they named him Mike and made him look like Winn Schwartau! Unbelievable. All I have to say is WWDKD? ok, just listing Dan Kaminski in a place where Jesus has been is making me step away from the keyboard....
ok. I'm back. No lightning yet... although I've checked my life insurance.
I had a beer scheduled with Moose, but nothing ever came of it (sadly). Hopefully we'll be able to sit down and chat some other time. Same deal with Joe from learnsecurityonline, but at least we hooked up by phone. He's putting together a cool set of binary reversing challenges for his readers and has graciously asked for my input and possibly help. We'll see what comes of it.
And Darren from hak5 was also supposed to catch up with me after my talk (9am was too early for them :) but he got held up as well. I'm thinking the parties were just too good, because by Sunday everybody was asleep. I actually drank red bull just before my presentation to try to regain some kick I had lost. Yes, I went to the shmoo party and got to see Pablos and his gang break it down. What was amazing was the number of folks in blue lock-shirts that cut a rug. Even Ed Skoudis was doin a dance! Jay MFBeale, well, you see there are dancers and there is Jay.... the difference? Dancers get tired and take a break. Jay is a freakin animal! Lara, dude, Lara. But the man with presence, Mike Poor, was dancing the whole freakin night! Whatever they're drinkin at Intelguardians has got to be better than redbull! gimme some-o-dat! I spent most the night over in the corner writing code. No, I'm not completely inept on the dance-floor, but I wanted to get a few things tweaked and tuned before my talk. Just because I gave a talk on the same topic at POC doesn't mean I don't work a lot on it in between. Programmatic Debugging for Vulnerabilities is a relatively new topic (at least for public consumption). Expect the topic to hit BH and defcon this year as well (if they'll have me), and full of untapped potential.
To be specific, and not just another "blogger positing his empty opinion", I was truing up the code which determines heap chunk length. Finding buffer overflows is not a simple task, and at the very core of that search (at least in this approach) is being able to consistently determine interesting values for buffer length. Stack buffers and heap buffers both present their own challenges. At POC I had the concept of measuring stack buffer length by finding a valid return pointer higher on the stack and measuring the difference. For that I developed findRET(), which, once I worked out a few bugs, is quite accurate. For HEAP chunk length, however, I was focused on DL Malloc and relying on HEAP chunks keeping their buffer length at ptr-4 (the 32-bit number immediately preceeding the memory pointer location). Unfortunately, many of the calls to memcpy() are copying portions of a HEAP chunk (since HEAP chunks are often cut to the size of a structure), so the values immediately preceeding many destination HEAP buffers is anything but the length of the buffer. That length may have been implied by the struct used to access the HEAP chunk, but that information is long gone, and must be reversed (another great topic).
So this time around I improved the HEAP length issue by running the allocated HEAP structures (again, DL Malloc, but RTL won't be hard to add). Once I find the HEAP chunk past the HEAP address we're measuring, we take the difference as the length. The odd thing I found was that the HEAP in some binaries (eg. top on linux) doesn't start at the beginning of the HEAP memory map. So, tracing the HEAP means finding it first. So you'll find code in getConnectedChain() that first searches for a connected chain of HEAP chunks before traversing it and returning the start of each HEAP chunk.
I need to mention that these methods are still somewhat archane and unrefined. They will indicate the most fruitful overflows, such as overwriting RET or the HEAP control structures.... They will not indicate overwrites which occur within the same HEAP chunk or between stack buffers.
Slides are here: odppdf New releases of atlasutils (formerly the @ Utility Belt) is coming shortly.
Greetz to visi and squires, alien and hackerprincess, sk0d0 (nice pic!), sk3wlmast3r & son, Toby and joshwright, G. Mark, chris paget, vangelis, beetle, hollywood and jsyn, keith myers!, Intelguardians (choops for supporting the con!) and ASI guys. It was excellent to see you all again!
And thanks to those who came to my talk (for not stepping in front of the wizzing redbull and causing legal headaches!) Dude, Chuck, smile! Seriously, I hope you all enjoyed the talk and got something out of it.
I originally was going to publish a video of me performing the demonstration I included at the end of my POC presentation.
Obviously, that hasn't happened. It took about all the time and energy I had to complete the atlas utility belt when I did, and I'm just starting to recover from the past three months (or rather, my wife is).
I much prefer encouraging others to have their fingers typing anyway, so I'd like to post instructions for doing the demonstrations yourselves.
First download and install vtrace and atlasutils...
This consists of:
$ tar zxf vtrace*gz
$ cd vtrace
$ sudo python setup.py install
(atlasutils is the same process)
Once you have installed vtrace and atlasutils, here are the demos, step-by-step. If you don't get similar results, please email me at here and should be in the local directory)
1. Start up kcalc (only have one instance running)
2. From a shell prompt find out the ProcessID of kcalc by typing "ps ax |grep kcalc"
3. "./memgrep.py 'kcalc'"
4. Many instances of 'kcalc' should show up, along with a virtual memory address in hex for each
(LivePatch is a part of the atlas utility belt)
1. With kcalc still running, pick one of the instances from memgrep.py demo.
2. Type "echo 'atlas' | LivePatch 0x0807ca20"
(LiveOrganTransplant is a part of the atlas utility belt)
1. With kcalc still running...
2. Type "LiveOrganTransplant 0x0807ca20 1"
1. With kcalc still running...
2. From a shell prompt, type "python" and hit enter
3. From the ">>>" prompt, type "from atlasutils.vtraceutils import *"
4. Type "me=atch('kcalc')
5. Type "print printStuff(me)" to display some of the most common details about a thread
6. Type "ni(me)" to execute the next instruction (stepping over calls) and printing summary info
7. Type "si(me)" to execute the next instruction (stepping into calls) and printing summary info
8. Type "stepi(me)" to execute the next instruction for each thread
9. Type "traceme(me)" to step through the process printing the output from "printStuff()" after each step
* note: traceme has many options, allowing you to control when it stops processing, like untileip, untilop, and untilreg
* note: you will want to interact with kcalc (which will appear dead) in order to free up the thread from blocking for input
* from the >>> prompt, type "help(traceme)"
10. Type "CTRL-C" to stop the traceme object
atlasutils 2.2.5 release
Happy Thanksgiving to all those who celebrate it. I have much to be thankful for, and I am.
At long last, here is a new release of atlasutils, formerly known as the @ Utility Belt.
This release includes an increased wealth of command-line utilities (including VulnCatcher.py), poorly documented as always, and several new python libraries, most notably disassutils.py and vtraceutils.py. These libraries require libdisassemble and vtrace, respectively.
What will most likely interest my Korean friends is found in vtraceutils.py and the VulnCatcher.py script. VulnCatcher lays out an infrastructure for leveraging programmatic debugging to identify vulnerabilities, not only providing locations in code, but also key information required to exploit it. For more information, see my presentation slides and whitepaper (in my previous blog entry). There are still some rough spots to iron out, and many more breakpoints to be created.
Vtrace on Ubuntu has been giving me some fits handling some Breakpoints correctly. Invisigoth should have a new release for us soon.
Note findRET() in the vtraceutils library, my first release of a stack-backtracing tool. It seems to be quite accurate, but complaints and bug-reports (and fixes) are always welcome.
Thanks for your support. I hope you enjoy the toyz.
Just flying back from Seoul, Korea, where vangelis and some pretty awesome Korean hackers put on the POC 2007 con (Power Of Community). Very cool conference. A large amount of brain-power in that building. Got to hang with friends vangelis, Dave Aitel, and The Grugq, and many other great hackers. Great talks there including hacking Web 2.0, hacking from a Nintendo DS, some debugging talks (including Dave's and mine), hacking COM (very cool!), and my personal favorite: hacking BIOS and VMware (gee, now that sounds familiar...).
I gave a talk on programmatic debugging using one of several powerful and new debugging API's for your favorite interactive scripting language. It covered several ways that these tools can help in hacking and in particular an approach to make vulnerabilities suddenly appear. The presentation slides can be found HERE and the whitepaper HERE.
My many thanks to vangelis for inviting me to speak at POC2007 and to the many great hackers I got to meet at the conference. Seoul was beautiful and the people very friendly. I was honored by the reception that J and I received by people and hackers alike.
Special choops go out to the following hackers and friends:
Sun Bing - whoa dude, nice work... and in your spare time no less.
AmesianX - you are simply brilliant, nice work
Boem - thanks, friend. I appreciated the chill-time with you
GilGil - Nice work. Keep coding and fighting the good fight. Freedom.
vangelis, Dave, Grugq, Heinrich... it was great. Thanks for making the trip great for both me and J. You all rock.
ps. watch for new releases of the @ Utility Belt as well as some demo instructions for vtrace fun hopefully this week...