I was asked to crack a program in a job interview, part 2
erenyagdiran.github.io
erenyagdiran.github.io
"Got the job as a security software engineer, ended up writing CSS"
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."
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.
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.
(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)
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
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.
Totally great read! :)
Well, I wonder what company that is? :p
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?
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
IDA Pro [0] is a good example of an excellent debugger with plentiful features and productive disassembling tools.
If you're on a Mac, like most people who do software security, Hopper.app is a fantastic alternative to IDA.
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.
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'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