Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

191–200 of 309 posts

Re: I was asked to crack a program in a job interview

#191

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 i…

> 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.

That might work on college students.

To me that screams that you can't properly interview your candidates.

> I note we've just done a round of interviews where we get a nice-looking CV and conduct a technical grilling.

You need a better screening process and a better layered.

Re: I was asked to crack a program in a job interview

#192
post #164

Earlier quoted context omitted.

What would the programming equivalent of pulling wire be?

Technical support.

This.

We may laugh, but starting in technical support gives you an idea of how your users are using your product, if your documentation is accurate and helpful, what the pain points for people not in the department you are destined for are, and gives you an idea of how the product works.

It also quickly weeds out the people who can't effectively communicate before they get to the programming team.

Re: I was asked to crack a program in a job interview

#194

Earlier quoted context omitted.

8.8.8.8 Job please 8-)

I would say no! google's DNS address is not its IP address :-)

The question was "show me an IP being used by microsoft or google"

If you are asserting that google is not using the IP of it's public facing DNS service, this company is full of horrible tech people, so nevermind: I don't want the job.

Re: I was asked to crack a program in a job interview

#195

Earlier quoted context omitted.

8.8.8.8 Job please 8-)

I believe that's the IP address of Google Public DNS, not Google.com per se.

I beleive the exact question was: "show me an IP being used by microsoft or google"

Are you really asserting that a google owned, and google operated service is not using the IP with which I access it?

Re: I was asked to crack a program in a job interview

#196

Earlier quoted context omitted.

The point is that you'll only get applicants up to a certain level. Once an applicant has enough skill and knows it, and also values his time, he'll take one look at your 14 hour challenge and laugh. So in the end you're only hurting yourself because you'll mostly get naive and easily manipulated people who are fine for the lower ranks but absolute poison once they move up. That's if they don't wise up and leave firs…

The test I describe should take an hour or two - it's a test of "can you actually do these things your CV claims you can?" Which is nontrivial, but I enjoyed taking it (fix a broken thing!) and feel fine about giving it to others.

>"can you actually do these things your CV claims you can?"

Yeah but how many questions must you ask before you are certain? Otherwise you're rolling the dice that the candidate has simply seen that problem before but has terrible habits otherwise.

Reduce the time required and you risk more false positives. Increase the time required, and you risk the skilled ignoring you.

Re: I was asked to crack a program in a job interview

#197

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…

That's clever, although I would have just pulled the plug. Server handshake so you can't run the program while offline? Well, that can be analyzed.

Re: I was asked to crack a program in a job interview

#198
post #44

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?

I would really suggest purchasing a good book about it. From my point of view, I would go for "Hacking: The Art of Exploitation, 2nd Edition" from Jon Erickson which goes in depth about how to crack programs using gdb and other tools. It's really a wonderful book if you want to learn more about the world of cracking in general, and it doesn't require much prior security experience. Quick link to Amazon: http://www.am…

I've done some of this book. It's good, but you're better off knowing the basics before trying to really learn from it I think. I only knew a little C when I started, so I only got about 4 or 5 chapters after much googling before I drowned.

Learn some ASM and get familiar with gdb before attempting

Re: I was asked to crack a program in a job interview

#199

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…

That program was not nearly as devious as the one discussed in the blog post. It made no efforts to stop us from using gdb, and the password encoding was never as reflective as xor-ing with the program bytecode.

Re: I was asked to crack a program in a job interview

#200
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!

Post reply on HN