I was asked to crack a program in a job interview
erenyagdiran.github.io
erenyagdiran.github.io
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.)
I know many so called sysadmins who could not pass this test in a reasonable time. Sometimes people without even basic script-fu or networking knowledge are considered sysadmins. And this drives me crazy.
"devops" is fighting words in our team. Damn, if I could get our devs who'd like "devops" on their CV to give a hoot about the "-ops" half of that buzzword ... when a dev shows awareness of ops issues with their shiny new thing, I make a point of mentioning their name positively to the dev manager. "X knows their stuff. Give them more good stuff."
Always the ops guys are in fault.
I think every developer should be given sysadmin 101 and 102 lessons.
I'm not sure how to educate devs to think ops. Perhaps have their phone ring at 3am when stuff breaks? I think that would close the feedback loop nicely.
(Let me note again: I LOVE the devs who think operational issues, who think end-user issues - what customers are actually like - who think "developer of the whole thing from go to whoa" and not just "coder on my PC." As I'd hope we all do here.)
I don't remember how many times I had to debug instead of them or design better for them.
By the way, hacker news developer quality is really better than average or even better.
(Ahhh, the BOFH stories ...)
Sometimes you just need to hire more people or ask the rest of the team to accommodate someone that's that one random oddball. A management book I read mentioned Phil Knight talking about how the Bulls had room for one Dennis Rodman and only one, and made it clear that nobody else can pull the stunts he does without disrupting the harmony.
There's a huge difference between a dev that does something a bit out of ignorance and one out of indignance.
Some companies have developers spend some time in SRE (I believe Google practices this sometimes) so they can gain some insight, but it may not be the best idea for a lot of orgs. It's part of why most orgs that do some form of devops well tend to remove a lot of concerns off the table by using stuff like AWS. Meanwhile, silozation helps people maintain some sanity and focus in larger orgs where there's so much BS work on top of your technical duties.
Sometimes the culture is short-sighted and people are at odds with goals though. I've been penalized by managers and peers for not paying enough attention to my dev duties (which were pretty meh) when I was busy helping support and sales help bring in and retain $2 million in accounts that they later named me on calls as their informal engineering MVP.
But really, being aware of what other people care about in their job is a contentious issue that I mostly think boils down to personality and general ideas of teamwork.
And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.
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 first, costing you time and effort to find and train replacements and scramble to rediscover and distribute the lost knowledge they left with.
But then again, such a long duration challenge is already very telling of the company culture. If you can't respect other peoples' time, then your company is already on shaky footing.
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.
These things shouldn't be designed to take 14 hours. They should be designed to take one, maybe two or three . . . if you know what you're doing.
One of the other posters took so long because he didn't know what he was doing. Well, perhaps that is an uncharitable way to say it, but you know what I mean. :)
Your objection is a fair one, but having come into the company through the process I describe I am fond of how it let me (a) show that I could actually do the stuff I claimed to be able to (b) show my thought processes and how I would deal with having received a box in this condition. So I was quite pleased to do it as a candidate. Certainly less of a waste of time than a clashing interview.
The way I do this is the real coding test is only administered to final candidates. That's a bit kinder since only a few people with a serious shot at the position end up having to commit the extra time and since we observe the whole process (and discuss) it doesn't waste tons of our time either. Whiteboard and discussion can reveal a lot but IMO there's nothing so revealing as actually watching someone work.
As an aside I would much rather be interviewed this way than at a whiteboard. At least for me there's a certain amount of my programming skill that's nonverbal and flows easier for me at a keyboard.
A cook is someone who can be hired with very little experience. A chef is someone who is trained professionally. And plenty of chefs are hired without a "taste test" based on their academic and employment history.
They're hired on a provisional basis, true, but they are paid while they prove themselves.
Have a computer setup and running (all properly configured). Pull the network cable out of the jack a little bit (so it looks like it's plugged in but isn't). Ask the person being interviewed to show me an IP being used by microsoft or google. (so ping/dig/nslookup/etc)
Let the person know that (a) the computer is in working condition (i.e. no drivers are missing) (b) the network works (i.e cables are good, switch is good, DHCP is enabled, etc.) (c) tell them that this is a test to determine their troubleshooting skills
It is always disappointing to see how few ever open a term/cmd window (depending on the OS). 90% of participants just try to open a web-browser and type in "what is the IP address of google"
Job please 8-)
Sloppy work 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.
Are you really asserting that a google owned, and google operated service is not using the IP with which I access it?
Easy question
So you lie to them? I don't understand what the point of this test is. My first inclination is to open up a term and ping google but I would be pretty annoyed that your "first-wave" test involved actively lying to a candidate.
Yes, I agree. Are we supposed to also assume that our bosses and interviewers lie to us, too? At no point does he say that he is emulating a user that needs support help.
It's just testing the basics really
This means - to me - that the network... well, works. And it clearly does not. If this was a Windows machine I'd probably wonder what the hell was going on with the Ethernet (!) sign in the bottom right of the tray and if it was a decent version of Ubuntu (11.x or earlier) then you'd also notice it quickly.
But still. He's pretty obviously leading the person astray by giving him the solid impression that the machine is in good working order. (which it is not) If you mean to say that he didn't CLEARLY specify that the "cable was fully seated..." I don't know what to tell you. That's a "gotcha" question. Not a good diagnostic one. Unless this is for a $12/hour CSR position. In which case, OK fine.
If you can't solve a problem with only some information, and some of it incorrect, then how are you supposed to be able to help?
Oh god.
Windows key + R / "cmd" / Return / "nslookup google.com" then when that fails, "ping 8.8.8.8" and when that fails, "Ipconfig /ALL", then ask "Do you use Dhcp or are ip's assigned?" as I reboot the computer and check the physical connections at the same time.
win+R, ping -t google.com, return"ping goo.gl"
A good hacker is a lazy hacker.
You should always remember that hiring is as much about persuading the best person to say yes to a job offer as it is about weeding out the bad people.
As an interviewer I've done something like this when needing to hire for a very straightforward job with very little time and an effectively endless supply of candidates.
This addressed the problem of our time crunch, but I doubt it helped the selection process overall.
I think this sort of testing is subject to all the same issues as most any other method of interviewing, but limited to a much smaller sample size.
Basically, it's arguably good for the interviewers and a coin flip for everyone else.
As an interviewee, I haven't encountered a test like this, but I expect my response would almost surely involve questioning the architecture decisions that led to such a problem in the first place.
In this case, as a sysadmin I was pleased to be able to show my chops in a realistic test. And our previous hire was also quite pleased to get a real test. But of course, there is potential to abuse it.
Given how fast things change, even if you imagine the person staying for only a year or three, learning abilities are nontrivial.
I am going to go ahead and challenge the assumption that your willingness and eagerness to learn on the job is not really correlated with how you spend your time outside your working hours.
I agree, but only if you're allowed to use references/google/etc and given a reasonable amount of time to accomplish it. I've had a "real-life" test where I wasn't allowed to verify or look up information, or where I'm giving a very short time to execute, and I've always thought those were absurd.
The idea that you would ever have to do something like this in a bomb-diffusing type of scenario with no internet and a ticking clock, would only test if you have already solved the problem before, not whether you could investigate a new problem.
Of course, there's tests like user:B5Geek's, where the candidate gets a PC with a slightly-unplugged network cable and has to realise this fact.
In a lot of ways, it's a matter of identity crisis for software developers. We're all, industry included, not quite sure whether we're mechanics, carpenters, architects or scientists.
I confess I don't know how I'd apply this to developers. They pass fizzbuzz, OK - what do you do next?
For example, an IBEW apprentice will do a lot of gruntwork on the job site. Pulling wire, for instance. But they'll get exposed to how things are done, to trade industry expectations, and what a project looks like from start to end. Part of the week, they spend in a classroom learning the specifics of their trade. Not just the high level theory, but the nitty gritty, based on real world applications and problems. This apprenticeship lasts from 2-5 years depending.
I don't see why this model wouldn't work really well with programming.
You don't get constant mentoring at the company, but can ask one of the developers or fellow apprentices when you're stuck with one of the tasks you get assigned. Or for example, any time a developer had a small task that he felt, I couldn't do by myself, or it was too time critical he just asked me to sit beside him and watch, listen and take notes while he did the work. How it works is different in any company but the outcome should be the same: real world experience on real projects with real clients and their time/budget constraints.
That means, once your finished and a professional yourself, it isn't a question of interest but a completely normal thing to help out the apprentices. Because that's how you got to the point where you are.
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.
I have only seen it (co-op) used in the last few years.
I know what I would do, just have a 10 minute conversation with them about technology. I can easily figure out just where a person is in regards to their development as a programmer just by listening to them talk about what they're paying attention to in the tech landscape. If they don't blink when I mention Hacker News, I know they're on the right track. Do they know what Go is, or Haskell? Do they have an opinion about Node.js?
These criteria are intended to gauge motivation and enthusiasm in the absence of an impressive track record. If they're capable but not highly motivated, then that's fine so long as you're only hiring them to do stuff inside their comfort zone. We have a Microsoft guy just like that. If they're motivated but not capable, then with coaching they'll be able to do anything. The best way to discover someone's motivation is to get a gander at what they're thinking about when they aren't working.
If you're looking for someone who is motivated and capable, you can eventually find someone like that, but you'll have a hell of a time keeping them. Developers have so many options these days that you need to have at least 3 of: competitive salary, decent perks, fun work environment, a glamorous field; in order to hold on to them for longer than a year.
Most companies are lucky to manage one, if they're very lucky two. Since salary is often the easiest thing to manipulate and honestly the most important to the employee, err on the side of paying too much. It's expensive but not having competent developers is far more expensive.
Programming is a wide field, there's much more to it than the front page discussions on HN can cover.
Of course, if you're looking for a Web developer to make "cool new stuff" for the latest fadgets..
Algorithm tests only measure the number of man hours the candidates spend on career cup daily. Or how good they are rote memorizing things.
There are many ways to check how good a candidate is at doing their actual work. For instance you can take a candidate to a code review and see what kind of inputs they contribute to the discussion. This alone will give you good deal of idea on how well they understand code and quality. There are other ways, like say asking them to write unit test cases for a class- That would give a lot of idea on how they think with regards to breaking and fixing things.
One more way I have after doing basic checks is pair programming, or picking a totally new problem and working with the candidate to see how they think, how they work and how good their communication skills are.
There are many other ways too. Recently I've been given coding assignments for very practical applications, though those turn out to be a little difficult and time consuming. And at times the expectations are very high. Like asking the candidate to complete a whole application in very short times. It can be hectic with your current job, and a family. But generally those are a good indication of how good the candidate will do at their actual work.
The ability to solve common problems acts as a good proxy for experience, If they can't google how to fix a retain cycle or a broken constraint, we know they probably don't know what they're talking about.
The ability to build a good, small system on top of the broken app acts as a good proxy for development talent. If they can't easily set up a dead-simple delegate to do an asynchronous web call, they can't hack as a mobile developer.
Most importantly, if they don't care enough about the job to take two hours to whip up a super-simple app, then we don't have to waste our time interviewing them.
Surely there's more efficient ways of evaluating that.
I know I am far less tolerant of bullshit interviews than I once was, and would have far fewer qualms vocalizing what I'm thinking - "I don't know. If I saw this in real life I'd check Google, because it reads exactly like the sort of contrived problem used in interviews and thus is well documented, and likely solved quickly by those who have memorized it. I am not one of those. I'll take a stab at it now if you just want to see how I reason through it, but if coming up with an efficient, correct implementation is part of your criteria we can probably save both of us the trouble" - is that considered acting like an ass?
Employers that do this are ridiculous. As are educators, too. What is this, preparation for when coders are kidnapped by terrorists and forced to recite how to tar/untar stuff on command? (relevant xkcd, of course)
In my experience, they're usually startups or smaller companies that are trying to "copy google" in their hiring practices, but don't fully think out how they're doing it. It's not a good sign.
:-D you never know!
Unless they are trying to hire a mentat.
>>I've had a "real-life" test where I wasn't allowed to verify or look up information, or where I'm giving a very short time to execute, and I've always thought those were absurd.
You certainly haven't worked at major IT services firms here in India. I spent early part of working years (around 2006) coding by purely reading books and discussing things with folks on internal mailing list. Because only managers and levels above were allowed internet access.
>>The idea that you would ever have to do something like this in a bomb-diffusing type of scenario with no internet and a ticking clock, would only test if you have already solved the problem before, not whether you could investigate a new problem.
This is unfortunately true even for coding interviews. Most algorithm questions are impossible to answer unless you have rote memorized the algorithms and their implementations.
By complex, I mean the question should be difficult enough that you can't easily hold every parameter, case and step in your head: I want to see how you deal with situations that you have to mentally walk through and issues that you might lose track of.
By potentially elegant, I mean both brute-force and optimal solutions should be able to fit on a small whiteboard, without requiring more than 2-4 variable declarations and no more than a nested for loop (or some sort of recursion). The optimal solution shouldn't require putting together pieces that they aren't really expected to know/use, i.e. no more complex than arrays, maps, strings and ints, and any other "data structures" the candidate ought to know, given their background. For instance, if they claim to be a crypto expert, they should know how to use a black box that gives them private and public keys.
By straightforward I mean, you don't want the candidate to have to have an "aha" moment. If you're asking for them to write a max-flow variant, you'd better be explicit that you don't mind a really brute-force solution, or most of the interview will be spent trying to remember complex algorithms. Is the algorithm one that you can understand by walking through test cases/figuring out what steps you took in your mind to go from input to output? If it takes more than that, you're going to get a few false positives, i.e. "Wow she was great! No one's answered this so fast!" (because she just spent 20 hours doing this on a homework), and many false negatives.
The candidate was kind enough to avoid posting the name of the company (to hopefully hide the walk-through from Google queries for "crack me hiring test company name", but an HN discussion might then arise around the walk-through, in which the company would be named, and well, there goes your test.
It's hard to accurately run "take home" tests when hiring because of just this.
You're asking a potential candidate to spend hours cracking your program but you can't be bothered to change it for each batch?
I expect any company applying this interview technique to at least put some effort into it and even then it pays off since a batch could contain hundreds of candidates and you only have to build the program once.
I strongly suspected that sometimes goals of the person responsible for hiring are not quite aligned with the company they work for. Example:
Company's goal: Hire an exceptional candidate.
Lazy or overworked hiring manager's goal: Reduce the size of the stack of 1000's of resume's I have to go through using any means possible that will make it appear like he/she actually did the work to find the candidate.
"Lemme see, use keyword search to ditch the ones without 'Github' on their resume'. Now ditch the ones who don't have a college degree. Still some resume's left? OK, how about tossing the ones without a CS degree?"
Run a filter with enough conditions and you can get that pile down to nothing pretty fast. If that is still not enough filtering, ask the candidates to do something very time consuming. This a great way to weed out people who are very busy or exceptional at what they do and don't need to jump through your hoops.
I'm surprised they didn't make him sign an NDA for it...
Make it slightly wrong, or obviously fingerprinted.
Personally, I think it's as absurd as writing shell scripts on a computer with no `man`, or without being able to refresh your memory with `<command> --help`. Good luck with that!
I was in an interview where they asked me to configure specific firewall rules on a notepad with no access to a terminal, so I couldn't check man iptables for stuff like how to match certain sources/destinations hosts/IPs. And I was not too familiar with the opts (was it --dest, --dst, or -d? and how do calculate the network mask for this range of IPs?). It was also for a junior position so I thought they were taking a piss at me and simply told them so.
I believe there is a happy synergy here, by the way. A candidate who welcomes this type of test -- who sees a direct work sample as the easy and efficient way to prove themselves to you -- is probably someone who knows their work is good.
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.
root@lisa:~# ./CrackTheDoor
Um. I see at least one security issue already.
Even if this is inside a VM, it might give the wrong message to someone wanting to try this for themselves.
http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...
Then a compromise would need to be:
Local VM user -> root VM user -> local LiveCD user -> root liveCD user -> hardware exploits
https://opensource.com/business/14/9/security-for-docker
Or as solomon hykes, the docker creator himself said recently:
https://news.ycombinator.com/item?id=7910117
"""When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly."""
http://opensource.com/business/14/7/docker-security-selinux seems to have some information. But to refuse the points there, on my system: a) docker containers do not have a /dev/mem b) /sys/fs is mounted read-only c) /dev/sd* is not visible
And so on. What's the thing with cgroups? Can a container delete the host's cgroups? Can it overwrite it's own cgroup constraints?
Can you or someone tell me if there is something I can try out on my own to understand actual issues? I run my containers unprivileged (which is the default) if it matters.
Again, all I am asking is for some material to educate myself on what actually the flaws are. All I have seen are vague articles claiming it's insecure.
But nothing is stopping you from creating a binary and running it as root that perhaps mounts those filesystems, or sends ioctls / badness to the kernel.
I'm just shooting from the hip here and might be wrong, but I'm almost certain devices aren't namespaced. If you were to mknod a block device with the right major / minor numbers as the host's sda/sdb/etc, what would stop you from mounting the host's root filesystem and making changes?
Granted the "work around" is to drop the privileges of the containers as much as possible, use sVirt (via SELinux), drop as many capabilities as possible, don't run untrusted containers, etc. But this isn't a theoretical security problem, it is a real big attack surface.
Edit:
http://www.projectatomic.io/blog/2014/09/yet-another-reason-...
Thanks for the info.
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.
There could easily have been a secret embedded in each bomb, reported on defusal or detonation, to prevent people from detonating each other. The project was graded on an absolute rather than relative scale, so there was little incentive to spend time on something other than defusing your own bomb.
(The project was called "the binary bomb." We all had a great time telling our friends that we were up all night at the library defusing a bomb.)
Presumably no one would want to, but people still like messing with one another for fun. Also, if you discover a vulnerability like that, you could plausibly claim that someone exploited it to bomb your grade, particularly if you used it against a bunch of people.
Definitely worthy of glory, but probably harder than just doing the project.
Something like : "As much as I am good in making programs I am not good at all in reverse engineering them."
Another dynamic at play is the fact that those who don't have useful skills apply more often as they continue to be out of work, that doubtless accounts for some of it.
Still a bit strange.
Or they've never touched either C or an embedded system in their life, but somehow it ends up on their CV and they tell you about how passionate for learning they are. Which may well be true, but it raises questions about your honesty and/or capacity for introspection. Also, bare-metal embedded really isn't the place to learn C[1], given that most failure modes are "It doesn't work. And maybe something caught just fire."
[1] Ask me how I know...
You could try either relaxing the degree requirements, or reaching a wider audience -- I generally don't see firmware jobs advertised on HN and StackOverflow and those are basically the only two places I ever pay attention to job ads. Depending on your existing volume of applicants you might also ask them to attach a semi-trivial C assignment to their application. Yes, this is accessible to anyone who can google, but you might weed out the disengaged who don't care enough to read the instructions that way.
"Oh I have to stream data into my processing routines with not nearly enough bandwidth? No problem."
I've also had smiles of delight when devs got 100% raw access to every little bit of hardware. Discovering DMA controllers is /fun/ for them. We came super close to getting a decompression routine running completely by our DMA controller!
So, it seems you need to either accept a recent CS grad who seems adept at programming and can learn, or pony up the 200k+/yr to poach someone if you want to hire quickly. Most people I know that have done embedded work tend not to move around a bunch and aren't motivated by small amounts of money to move jobs, so you'd have to offer a large incentive to find the good people.
If you describe a really hard programming job, people self select out. If you describe an easy one, everyone applies.
iOS developer? Floodgate.
Crypto expert? Trickle.
You're comparing a fun job to a job where at best nobody ever says anything to you and at worst, you're taking the blame for the whole company's servers being down.
Most programmers don't need to know how to do this. As it says in the blog he is applying for a security position.
It all comes down to how well you can translate assembly code.
Or send me an email. We're an expensive group to hire though. :-)
The market for programmers is really inefficient for pay. Google has exploited that to the max and succeeded hiring a lot of very talented engineers at rates you pay for average tax accountants and attourneys. Just like the way they exploited Free software licensing by expempting themselves from the publish part by distributing access to the software not the software itself. That's their two best tricks right there.
Where they crossed the line massively is when they engaged in a criminal conspiracy with Apple et al to act in a cartel keep those wages down. This in addition to all the other legal ways they try pushing the market down when it really should be a sellers market. Andrew Moreton paid less than a football player of similar standing? How about 2 orders of magnitude less.
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?
But people struggle with this. I distinctly remembering practicing this in class when prepping for matura (Slovenian version of SATs) so I guess it isn't inherently obvious to everyone.
";" is surrounded by space left and right
":" has no space on the left in English, but it has one in French> Modern style guides recommend no space before them and one space after.
And that's really interesting about French. Personally I think a colon surrounded by spaces looks funny, but then again, I've never learned a language where that wasn't the correct way.
edit: my French girlfriend says French puts spaces on both sides of all punctuation except commas and periods. Like this !
Weirdos O.o
http://www.lemonde.fr/football/article/2014/09/17/ligue-des-...
Looks like it's indeed like she told you.
More often than not it's a dead giveaway...
(Another fun pedantic remark: French typography rules require that you apply the rules of a foreign language whenever you quote text in that language, so that the English rules should be respected for English quotations within a French text.)
And I agree with akx -- being French, I've seen my share of French people writing in English with the French rules, and I always thought that it could be used as an indicator by a careful reader.
(As an example, there used to be an ads campaign in the Parisian subway some years ago which advertised "I speak Wall Street English !" or something or the kind. As this was for an English class, I always found it funny that they couldn't get their English typography right.)
In English, Em-dashes have a couple of different uses, but in the most common use they are usually set closed (no spaces on either end), though some styles set them with a space on either end. En-dashes have one use (similar to that of em-dashes, which is used varies by house style) where they are usually set open, and a number where they are usually set closed.
Given that the rules for these marks aren't particularly consistent, or even fixed, in English, I think its safe to say they aren't consistent for the same piece of punctuation across all uses in all Indo-European languages.
Actually, the en dash has more than one use: http://cddc.uchicago.edu/qanda/data/faq/topics/HyphensEnDash...
In Spanish you put a space after periods and commas, so that's not it.
The OP is Turkish. Ankara is the capital of Turkey. His name is Turkish. Punctuation is the same as in English.
"As an official language, Spanish is understood almost universally in Barcelona. In addition, 95% of the population understand Catalonia's own native Catalan language, while 74.6% can speak it, 75% can read it, and 47.1% can write it"
A writing literacy of less than 50% sounds pretty poor.
The spacing around punctuation in Turkish in the same as English. It's just that OP failed to spellcheck his writing.
This is not to suggest that this structure indicates dyslexia of course, the rest of this thread has plenty of other good reasons for non-native english speakers and otherwise.
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 thread is bringing back a lot of memories :)
http://spth.virii.lu/coderz1/lucky.html http://www.st-news.com/rex.htm#lucky
The e-zine this is from (http://spth.virii.lu/coderz1/ / http://vxheavens.com/vx.php?fid=177) was pretty interesting, too. Harks back to the time of small, independent online communities with dark webpage backgrounds.
A couple of years ago I did a (mostly) full walkthrough of the Binary Bomb, and it still gets a lot of hits during the semester. If anyone is curious: http://www.vedranb.com/post/19338235616/phase-1
"The company send me another crack me for round 2 :) That's also interesting.."
That wasn't enough to get the job?
By the way, if this sort of thing interests anyone, look into security CTF competitions. You'll probably have to read some tutorials to learn, but CTF's will give the opportunity to apply what you've learned.
(I never did pass level 2)
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!
The nice thing about microcorruption was how you didn't need much more than familiarity with assembly and C (and language of choice in the end game). This interview challenge on the other hand... I wouldn't even know where to start.
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.
Could you change the jmp into a nop? That should let you attach in debug mode.
The reason this is clean and convenient is because nop is a single byte (0x0f or 0x90), which lets you replace any instruction of any size with nops. But if you had to transform jmp into an instruction of a different size, things could get hairy if the byte sizes don't line up. But you could still replace several instructions with other code.
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 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.
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 spent hours starring at softice & winice, and learning x86 asm
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.
The lena151 tutorials are especially good:
Quick link to Amazon: http://www.amazon.com/Hacking-The-Art-Exploitation-Edition/d...
Learn some ASM and get familiar with gdb before attempting
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.
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.
I agree with the root point only because the company could have easily done something like `echo "I just rm -rf'ed your / because you ran me as root"` as part of the test.
Why would you consider it still an issue if it was a VM he used only for this purpose?
Looking from probability perspective, yes you are right, this is a low threat vector.
Also I consider working root in a vm an issue because security 101 lesson 1 is "avoid privileged accounts as much as possible". Why not work in a unprivileged shell account and use sudo whenever needed? VMs are not bullet proof and they can leak memory, can make host machine unstable or even crash it. There are hardly any poc's out there but VM's may be exploited to switch context to host machine. Aside from these low probable threats, while working with unknown originated binaries, losing your whole work is a big probability. In this case it would not matter if you are inside a vm or not. VM's can be recovered but lost time can not be.
But what about screw up vectors or being careless stack up in this?
People are sloppy. It's easy to do mistakes and loose everything. Working with crackme binaries needs more attention.
Second, instead of a VM, it could be a livecd with no permanent storage attached. That's what I'd do if I had to debug potentially malicious binaries.
It's fine to ask, but it's wrong to assume.
I told I am being picky. Most of my concerns may be handled but their are not shown to be.
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
Great job and thanks for the great read.
There is mmap[1] (controlled, unsurprisingly, by syscalls), which will give you a memory region that may be updated transparently for you by the kernel, but in general, it's all syscalls.
The other nice thing about the syscall interface is that it gives the kernel an opportunity to suspend the calling process and schedule something else if it can't fulfill their request right now (hence, blocking IO), so you're not actually polling. Of course, a preeemptive scheduler (like everything actually is) can step in and suspend you anyway, but the syscall is a nice place to do it cooperatively.
Haven't given it much thought past this.
Just kidding, congrats!