I was asked to crack a program in a job interview, part 2(erenyagdiran.github.io)
erenyagdiran.github.io
I was asked to crack a program in a job interview, part 2
http://erenyagdiran.github.io/I-was-just-asked-to-crack-a-program-Part-2/
10 comments
It is sad to know that even after this much worked he did, he was asked to switch and work on something he was not hired for !!
Could be a great meme.
"Got the job as a security software engineer, ended up writing CSS"
"Got the job as a security software engineer, ended up writing CSS"
It's pretty accurate for most software engineering roles out there. You whiteboard code to solve theoretical problems with algorithms you learned in college. The real job typically involves trying to get code from various languages, frameworks and platforms to work together. There may be one or two times where you actually use some obscure algorithm but that's it.
the inverse would be funnier in a scary kind of way.
I don't know what to call it, maybe the contrapositive, but if you do this for a living it's kind of surreal when you interview for a dev position and fail because you go too in-depth with underlying details.
I've been told, "you're a bit too paranoid about security, we'd recommend you memorize some of the answers to interview questions on StackOverflow if you're really interested in this."
I've been told, "you're a bit too paranoid about security, we'd recommend you memorize some of the answers to interview questions on StackOverflow if you're really interested in this."
The inverse is true in a lot of technology companies sadly. I once worked with a "network security expert" who got the job after 2 years as a front end web dev and zero real training in network security. He knew what SSL was so got promoted...
I was a Java Web Gui developer, typical stuff, so the architect of the project asked me to implement better security by reversing SHA512.
Specifically SHA512 he said, dont use SHA1 or SHA256 thats not good enough. And he explained several times how the security solution work, it would be based on reversing a hash function. As I shrugged it off, people say weird things sometimes, and offered a real solution he kept pushing for his solution. Weird but anyway maybe he just means what I mean but is using different words, so I implement a real solution, and then days later he questions my judgement and the solution because I didnt use his. Thats when I said "you cant reverse a hash function, in fact thats the point of it" and then point to the diagram he made see there, thats not mathematically possible. His title was Security Architect.
Specifically SHA512 he said, dont use SHA1 or SHA256 thats not good enough. And he explained several times how the security solution work, it would be based on reversing a hash function. As I shrugged it off, people say weird things sometimes, and offered a real solution he kept pushing for his solution. Weird but anyway maybe he just means what I mean but is using different words, so I implement a real solution, and then days later he questions my judgement and the solution because I didnt use his. Thats when I said "you cant reverse a hash function, in fact thats the point of it" and then point to the diagram he made see there, thats not mathematically possible. His title was Security Architect.
Yes... All that for writing java and doing CSS. Laughable.
I find it hilarious, I'm happy for him. He seems to be working on things he likes now.
yaa, and sharing his experience :)
Does Google still do this too? Last thing I knew Google would stick you wherever they decided, not necessarily where your strengths were and where you wanted to be.
I was under the impression (possibly wrongly) that you could relatively freely change teams at Google assuming you weren't entirely unsuitable for the job, and were reasonable about not changing team too frequently and actually getting stuff done.
From what I have heard, "not too frequently" means once every 18 months, so some people have complained about sticking on a team they don't like for a year and a half.
The "Computer Systems" course that was started at CMU has a similar project commonly called the "bomb lab": http://csapp.cs.cmu.edu/public/labs.html
I TAed a Computer Systems course at a different university, and it was a great exercise to get the students to really understand what was going on in their programs - and to force them to use the powerful tools (disassembler, debugger) available to them.
I TAed a Computer Systems course at a different university, and it was a great exercise to get the students to really understand what was going on in their programs - and to force them to use the powerful tools (disassembler, debugger) available to them.
Are there any positions in the industry where this is part of the average work day? It seems awesome and I really want to get into it.
(the above is copied from a dead post on this thread, possibly by a hellbanned user. i'm reposting it because it's a reasonable question)
(the above is copied from a dead post on this thread, possibly by a hellbanned user. i'm reposting it because it's a reasonable question)
I imagine this sort of reverse engineering is common for malware analysts and people who work in the AV/security industry.
Personally I work at a software security shop, where we aim to prevent this sort of reverse engineering. So we also end up doing a lot of this to be familiar with attacks, test our own protection, debug issues etc...
If people want to learn more about this kind of stuff, tuts4you is great: https://tuts4you.com/
Specifically, the lena151 tutorials are great for beginners with 0 experience: https://tuts4you.com/download.php?list.17
Personally I work at a software security shop, where we aim to prevent this sort of reverse engineering. So we also end up doing a lot of this to be familiar with attacks, test our own protection, debug issues etc...
If people want to learn more about this kind of stuff, tuts4you is great: https://tuts4you.com/
Specifically, the lena151 tutorials are great for beginners with 0 experience: https://tuts4you.com/download.php?list.17
Except for the security industry where I guess this would really be your day job, any job with embedded programming close to the metal is not really far from this.
Granted, you don't have an adversary so you won't find any anti-debugging tricks dropped into the code, although at times you'd be forgiven for thinking they had.
Granted, you don't have an adversary so you won't find any anti-debugging tricks dropped into the code, although at times you'd be forgiven for thinking they had.
> I'm not working for that company now , I moved to Barcelona.
> i live in Barcelona and have a great life
In both cases living in Barcelona is positioned as the contrary of working -for that company-, so I'm confused. Are you working? Is it a security-related position?
In both cases living in Barcelona is positioned as the contrary of working -for that company-, so I'm confused. Are you working? Is it a security-related position?
J2EE+CSS company was in Turkey, he quit and got a different job in Barcelona
[deleted]
Stuff like this deeply fascinates me. However, I can't help but feel like a lot of it could be improved with the help of some automation tooling.
Is there anything out there for like a "language" of sorts (or API, etc) that can automate some of the debugging things required? Like I imagine very "active" debugging and code modification like "When we are at this location, and the past few instructions exected were X, Y, and Z at addresses A, B, and C, pop this item off the stack and push this hard coded value on the stack" Things that would take forever to do manually, especially when called in a loop, but would be fairly trivial to formalize into a programming language
Is there anything out there for like a "language" of sorts (or API, etc) that can automate some of the debugging things required? Like I imagine very "active" debugging and code modification like "When we are at this location, and the past few instructions exected were X, Y, and Z at addresses A, B, and C, pop this item off the stack and push this hard coded value on the stack" Things that would take forever to do manually, especially when called in a loop, but would be fairly trivial to formalize into a programming language
A lot of debuggers and disassemblers do exactly that. They're getting smarter every day, but they still take some knowledge of assembly and lower-level computer science concepts.
IDA Pro [0] is a good example of an excellent debugger with plentiful features and productive disassembling tools.
[0]: https://www.hex-rays.com/products/ida/
IDA Pro [0] is a good example of an excellent debugger with plentiful features and productive disassembling tools.
[0]: https://www.hex-rays.com/products/ida/
Most people here (and people I know in the industry) use programmable debuggers --- Ruby and Python libraries that implement the OS debug hooks.
If you're on a Mac, like most people who do software security, Hopper.app is a fantastic alternative to IDA.
If you're on a Mac, like most people who do software security, Hopper.app is a fantastic alternative to IDA.
gdb actually has amazingly good python scripting built in if you're using a reasonably new version of it. Redhat lead the charge[1] with what they called 'Project Archer', which was merged into gdb mainline as the python scriptability.
[1] http://sourceware.org/gdb/wiki/ProjectArcher
[1] http://sourceware.org/gdb/wiki/ProjectArcher
That's pretty interesting. I'll have to look at that more
It all went downhill, when compuware bought numega and killed softice. yes, ollydbg and windbg work fine, but still...
Hehe.. I worked for Numega back then. I did tech support and I still remember how often we got tech support requests from people and companies wanting a way to prevent SoftIce from being used to crack their software. So many times I tried to explain to people that there just wasn't really a good way to detect that it was happening that couldn't just be circumvented by the debugger.
I handled the website at the time. Watching the referer entries in those logs would give you a who's who list of cracker sites from around the world.
One thing to keep in mind is that there are only a handful of really good disassemblers and that anyone semi serious about keeping you away can throw in code that will confuse and/or crash them.
Disassemblers aren't at all hard to write. Tripping up IDA might be a decent bang-for-the-buck countermeasure, given how straightforward it can be, but it's a speed bump.
It's possible to confuse or crash IDA Pro, Ollydbg, and Cheat Engine? If one tool won't work, just switch to another.
It's very possible. Recently I had to manually patch code that was (in assembly) a conditional jump on conditions that at runtime were always true or always false, so the "conditional" part was a red herring.
The fact that the conditional was there confused IDA such that it miscalculated the stack usage for many of the functions in the binary and refused to designate them as procedures (which can be decompiled).
The telling part was that these conditionals had no other purpose other than to confuse IDA, so you could see the intent was malicious.
That's just one example. You REALLY have to know what's going on with the hardware and the intentions of malware authors so you don't blindly accept what your tools are telling you. That's what makes the difference between someone who can do reverse engineering for a living and someone who is good at it.
EDIT: One more thing...debugging malware is a last resort; it's very easy to behave one way for a debugger while doing something completely different elsewhere. If you start with automated detection/debugging tools you spend most of your time working around debug detection.
If you'd like to know more my email address is in my profile.
The fact that the conditional was there confused IDA such that it miscalculated the stack usage for many of the functions in the binary and refused to designate them as procedures (which can be decompiled).
The telling part was that these conditionals had no other purpose other than to confuse IDA, so you could see the intent was malicious.
That's just one example. You REALLY have to know what's going on with the hardware and the intentions of malware authors so you don't blindly accept what your tools are telling you. That's what makes the difference between someone who can do reverse engineering for a living and someone who is good at it.
EDIT: One more thing...debugging malware is a last resort; it's very easy to behave one way for a debugger while doing something completely different elsewhere. If you start with automated detection/debugging tools you spend most of your time working around debug detection.
If you'd like to know more my email address is in my profile.
That's very interesting. Thank you for correcting me. I'd like to know more, but everyone else probably would, too. Personally, I'm curious about the backstory behind that particular piece of software, and also about any other tricks you've noticed.
The backstory is pretty simple; I analyze malware and this was a sample. It's difficult to talk about publicly because if you reveal too much, it's a chance for the malware authors to recognize they've been made and change what they're doing.
What's interesting is that if you've seen enough samples, you can make educated guesses about the authors, their intentions, and level of competence. In this case, the authors were obviously aware that someone might try to reverse engineer the software so they threw that little red herring in. I have no idea why, and it was only in certain functions and not others. But you do know the authors had a clue about IDA and similar static analysis tools and were trying to make it more painful to analyze. It certainly wasted a couple of hours of my time.
Fortunately the obfuscations make software like that easier to detect, so it's a balancing act the author has to play.
If I ever stop analyzing malware there might be a very interesting blog series on all the boneheaded mistakes malware authors make when they obfuscate their code. I could teach a six-month course on what not to do with crypto just from all the approaches I've seen.
What's interesting is that if you've seen enough samples, you can make educated guesses about the authors, their intentions, and level of competence. In this case, the authors were obviously aware that someone might try to reverse engineer the software so they threw that little red herring in. I have no idea why, and it was only in certain functions and not others. But you do know the authors had a clue about IDA and similar static analysis tools and were trying to make it more painful to analyze. It certainly wasted a couple of hours of my time.
Fortunately the obfuscations make software like that easier to detect, so it's a balancing act the author has to play.
If I ever stop analyzing malware there might be a very interesting blog series on all the boneheaded mistakes malware authors make when they obfuscate their code. I could teach a six-month course on what not to do with crypto just from all the approaches I've seen.
I played around in the cheat scene as a kid and what you are describing sounds like someone who didn't know what they were doing either a) copy-pasting from or b) using a toolkit provided by someone that did.
What would someone who knew what they were doing do?
Sure see http://www.exploit-db.com/exploits/23524/ and https://forum.tuts4you.com/topic/28804-ollydbg-numberofsecti... for instance.
> My English is not that bad.
I'd say it's quite good. However, I'd quit it with the space after the comma thing, and the no space after the period thing you're doing:
>But I'm sorry , i would like to correct some misunderstandings.
Should look like
But I'm sorry, I would like to correct some misunderstandings.
> And finally , please read the end of the post.I'm sure you will like it.
Should look like
And finally, please read the end of the post. I'm sure you will like it.
Great article though! Really enjoyed reading it.
Edit: formatting
I'd say it's quite good. However, I'd quit it with the space after the comma thing, and the no space after the period thing you're doing:
>But I'm sorry , i would like to correct some misunderstandings.
Should look like
But I'm sorry, I would like to correct some misunderstandings.
> And finally , please read the end of the post.I'm sure you will like it.
Should look like
And finally, please read the end of the post. I'm sure you will like it.
Great article though! Really enjoyed reading it.
Edit: formatting
[deleted]
Really wish baby-level software analysis posts would stop hitting the top.
metacorrector(11)