Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information.

This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful information, because we get an insight into their thought processes. I recommend this to all.

(I note we've just done a round of interviews where we get a nice-looking CV and conduct a technical grilling. Hideous waste of time for everyone involved. All CVs should be regarded, on the balance of probabilities, as works of fiction. Do a remote self-paced test like this. You won't regret it.)

> Here is the first thing i typed in the terminal

root@lisa:~# ./CrackTheDoor

Um. I see at least one security issue already.

This is Intro to Systems homework at UChicago (the course is heavily based on CMU's equivalent.) You're given a personalized binary that asks for a series of passwords to complete each level. If you get a password wrong, it phones home to a server run by the professor and decrements your grade.

The point is to teach you to reason about assembly using GDB. You can pretty trivially set a breakpoint at the phoning-home routine so that you never actually lose any points; then it's just a question of thinking and reading hard enough before the deadline arrives.

Levels range from very simple string comparison, to arithmetic, to pretty weird tricks.

It was about the most memorable homework assignment I've ever done.

I don't know where you find candidates that can even approach this level of skill or desire to solve puzzles. Most people I interview struggle with a few lines C program coding.

Really nice overview of the process. I was hoping to get into debugging and breaking code, but my career took a wild turn away from that part of the job. It's still something I would like to learn, so I'm reading as much about it as I can.

I'm going to take this way off topic here, but it's a curiosity of mine. Please don't take this as an insult; it seems to be very common and as a language learner myself I'm just wondering where it comes from.

At first , it looks...

analyze.Lets...

debugger.Therefore , there...

mode.In my opinion , Intel...

So , those lines will basically scan the memory , if there is a 0xCC , it will crash your program and such ...

Specifically in these examples, I'm seeing a missing space between a period and the next word, as well as a space before a comma. As English is one of my native languages, I'm not sure how people go about learning English or what resources are available to anyone learning English.

I've noticed this with a lot of English as a second language speakers, and it doesn't seem to matter what their original language is. In this case, Spanish, but I've seen native Russian and Japanese speakers with the same thing. Can anyone tell me why this is?

Crackmes (as they're known) can be kind of fun.

The late Katja Kladnik once sent me a diskful of 'crackme' virii. I tried to deadlist one of them; it infected me when I did, and dared me to try a less obvious approach.

Mangled symbol table => buffer overflow in debugger => arbitrary code. Sneaky.

This reminds me of the popular binary bomb lab offered in some computer architecture courses: http://csapp.cs.cmu.edu/public/labs.html

That's some impressive work. But then...

"The company send me another crack me for round 2 :) That's also interesting.."

That wasn't enough to get the job?

Does this guy have any idea how hard it is to come up with good interview questions? By posting the question and solution online (complete with an md5sum and everything!), he has ruined the question, and his employer will now need to spend a significant amount of time coming up with another way to evaluate candidates.

Looks like he was doing this on Linux.

A quick experiment shows me that you can call ptrace(PTRACE_TRACEME,..) on OSX multiple times without it failing (the constant is actually PT_TRACE_ME on darwin). I wonder if that's the same for all BSDs ?

Interesting and educational writeup though, and just the thing to get me tinkering myself!

If this sounds fun, give microcorruption.com a try :-)

I also tried to crack exactly this program a while ago. The company (I believe it is MilSoft, one of the most reputable software companies in Turkey) sent this challenge to university students to hire a part-time CS student. Nevertheless, this was the first time I've ever attempted to crack something and while I had little to no idea what was going on, it was a very thrilling experience. I think I went on 14 hours without taking a break.

I began by trying to run the program in GDB, got SIGSEGV'd. Afterwards I inspected the faulty address and tried to avoid it by changing its value, instead it crashed at somewhere else. After trying this hopeless catch-and-run for several hours, I decided I needed a better disassembly tool and went on to IDA Pro.

This particular program contains a trick that intrigued me very much, and it is the reason why I was getting SIGSEGV'd at different locations when altering the program code.

The main payload of this program is simply XOR-encrypted by some key. The whole thing begins by decrypting the payload and then begins its execution as normal. The gist is, the particular key that encrypted the main payload is the decryption code itself (for the unacquainted, assembly code is also just a byte stream). Here, this exact part:

   0x804762d:   mov    $0xaa,%dl
   0x804762f:   mov    $0x8048480,%edi
   0x8047634:   mov    $0x8048cbc,%ecx
   0x8047639:   mov    %edi,0x80476f3
   0x804763f:   mov    %ecx,0x80476f7
   0x8047645:   sub    %edi,%ecx
   0x8047647:   mov    $0x804762f,%esi
   0x804764c:   push   $0x80476c1
   0x8047651:   pusha  
   0x8047652:   mov    $0x55,%al
   0x8047654:   xor    $0x99,%al
   0x8047656:   mov    $0x8047656,%edi
   0x804765b:   mov    $0x80476e5,%ecx
   0x8047660:   sub    $0x8047656,%ecx
   0x8047666:   repnz scas %es:(%edi),%al
   0x8047668:   je     0x804770a
   0x804766e:   mov    %edi,0x80476eb
   0x8047674:   popa   
   0x8047675:   add    0x80476eb,%edx
   0x804767b:   ret

At the end of every iteration (of something involving this loop which I can't precisely recall now) the program checks whether it is running under debug mode (essentially makes a PTRACE call and reads its output, the OP also talks about it) If this is the case, it makes a jump to random address, so even if you are just neatly watching the program run under debug mode, you weren't going to achieve anything.

The next thing that occured to me is to manipulate how PTRACE returns its value, but I thought it would involve some kernel code fiddling and running the program under the modified kernel, which is WAY beyond my ability for now. I didn't know how to do it, but later by some very stupid trick I managed to pass this decryption part and the program made a jump to something like "__glibc_start". I needed to save the altered program and run it under gdb again (I don't remember why), but I was using the trial version of IDA Pro which prohibits me of such a thing. After making a few more desperate attempts I gave up.

But this "using the code as the key".. I think spending 14 hours to see this done was well worth it.

"Now, I have been told that the best crackers in the world can do this in 60 minutes. Unfortunately, I need someone who can do it in 60 seconds."

Dude?? Did you wait until you go to Spain to post this? Still, it is very fun to read this post and comments here. Actually, I prepared these two crackmes in order to arrange a small competition among universities at Turkey. But, they became very good interview questions also.

It's really good to read these responses. Cracking ability is really rare in CS student community in Turkey. Our intention was increase awareness. Reading these comments showed me it was a really good step.

If you want to try cracking one yourself, there are plenty of crackmes at http://crackmes.de/

Is this company ok with this being posted?

If so, they should say what company they are, because being associated with a clever puzzle like this is great for recruiting (even if it's not being used anymore). Unless they have their own reasons for remaining quiet (government? :)).

If not, they should probably take it down, as having the solutions posted would ruin the evaluative value of what must have taken a very long time to make.

Back when I was in high school, I had a Palm IIIxe. This was the days before app markets and nearly everybody who made PalmOS apps tried to sell them as shareware with a price of $20-50 -- well beyond what I could afford as a broke high school student.

Fortunately, I had learned Z80 assembly programming my TI-83, which had led me to dabble in 68k assembly when I bought a TI-89. I never mastered 68k the way I did Z80, but I knew enough to find the routines that ran the registration key check when the OK button was pressed, and by trial and error, I'd invert conditional jumps until I found the one that would turn a failed registration attempt into a success. Then I'd hex edit the binary to make the switch. Worked like a charm about 80% of the time!

I remember fravia and +orc back in the day... I think he passed away, but there are still archives online: http://www.woodmann.com/fravia/

I spent hours starring at softice & winice, and learning x86 asm

This reminds of this quora post. A nice one for beginners like me. The guy reverse engineered Sublime Text to remove the nagware of registration.

https://ericjang.quora.com/Reverse-Engineering-Apps-a-Step-b...

PS- You should buy ST, it is one of the best code editors out there in the market.

what's a good, simple intro to the basics of this kind of cracking for someone who is an experienced programmer, knows some C, etc, but has little system level or assembly experience?

This is totally nostalgic of the "binary bomb" assignment in CS 107 @ Stanford. You have to run the program from Stanford's network. There are 6 levels and each level has a password you have to enter. If you enter the wrong password, the course server is notified, and a point is deducted from your grade. The correct way to solve each level is to disassemble the program and figure out what it's doing.

Here's Google's cache of this page:

http://webcache.googleusercontent.com/search?q=cache:uGbSzpZ...

...there's even a secret level in the binary.

Should have sent them a password locked program called *DoorHasBeenCracked". The only thing it does is post passwords to an http server that you control. There is a good chance they try their own password on it. New school phishing attack. /s

The post started very well but with the first screen shot, my mind started tingling: What the heck a security engineer is doing in a root shell? An unknown binary sent via an email is run in a root shell. There is also no mention of email source tracking.

Hey you are a security engineer you know about weakness of smtp right?

Even if this is a virtual machine, I would really reconsider employment of him or sit down and do a serious talking about this blog post if I were the employer.

I could not continue reading the post before ranting about it.

Very nice

My approach would be to disassemble, then try to find the strings in the program and see where they're being used and processed.

And kill the CC thing by hexediting the file

I love the way the way m00dy dissected the problem. About 2 months ago, I was watching some advanced LLDB videos from Apple and they went into a lot of the tricks detailed in this post for setting breakpoints and debugging a program. That being said, some of the knowledge about halting commands and configuring gdb to ignore debug mode are just some things only a pro would know.

Great job and thanks for the great read.

So the only way for programs to get data from the outside world is to poll with system calls? I always thought that programs defined a "holding area" that the kernel would write into when it had data - the program still might poll, but it's polling (potentially very small, perhaps a single register) local data rather than making a system call.

Similarly, I had to debug a vulnerability and write an exploit for a vulnerability in adobe reader for a job interview. :)

I have a pretty cool crackme that I programmed and I wanted to offer it as a puzzle to some candidates, but without the proper reverse engineering tools, I think most candidates would really struggle -- especially if you're looking for just general developers.

Haven't given it much thought past this.

You know that by publishing this now YOU will have to write the challenge programme for the next candidate, right?;)

undefined

Password variables stored as constants? In MY binary? It's more likely than you think!

Are there any good resources to learn what is necessary to solve this puzzle?

Then gets fired for revealing the answer to the only test they have.

Just kidding, congrats!

This reminds me of a scene from the movie "Swordfish", starring Hugh Jackman, John Travolta, and Halle Berry. :-)

why doesn't the author use objdump so there is no need to bypass ptrace()?

That, my friends, was a powerful blogpost. Raw, exuberant, and purposeful. I learned much.

Agh wHy is thE capitalization & puncuation. so inconsistent?

If we asked questions like that at our interviews, it would take us 10 years to hire one candidate. Most people fail at basic basic stuff.

How the hell do I have a job? I can't even follow most of this...

I've always believed a test a a fair way of hiring. It takes "the good ole boy", and the whole "my friend is brilliant" out of the equation. Personally, I've never liked, actually despised, the whole networking thing.

nice