Hacker News Reader

Comment by stuxnet79 | Hacker News Reader

As someone who is not very knowledgeable about the field, I find reverse engineering fascinating. One thing I've been curious about is the economics of the security industry and the role reverse engineering plays in it.

To my novice eyes it seems that reverse engineering is more of an academic exercise and I don't see any direct ways to commercialize that skillset. How do you make a living doing this? Are you essentially paid a stipend to conduct fundamental research (finding zero days) that is inherently risky (no exploits = no return on investment)?

View on HN

I see the reverse engineering skillset as not essentially different from low level systems programming, and as such it's very valuable even outside of "pure" security research.

I work as a Python programmer building scientific apps (so not security-related or systems programming at all), but at work every so often we're confronted with legacy code in binary form, or particularly nasty segfaults, etc. The thing with abstractions is that every so often the lower levels bleed through. At times like these, if you know your way around gdb, the ELF format, linking conventions, and can reason in assembly, you'll find yourself highly sought-after.

It gets even more fun when things work nicely on Linux and go haywire on Windows. Often there are no docs on Windows, so you need something who is ready to crack their knuckles, fire up IDA pro, and descend into the 7 circles of hell.

Vulnerability research & exploit dev. To break a system you must first know how it works.

There are also things like anti-cheat which requires reversing the cheats that are used and reversing the os to figure out methods you can use for detection.

Somewhat related to that, there's antimalware which is based upon the same principles.

Competitive analysis, reversing someone else's product so you can determine how they do stuff compares to how you do stuff. Some companies will even analyze a competitors product and then reimplement parts of it, you just have to be careful with copyrights and patents.

Fixing compatibility issues is also a thing. For example, GOG hires reverse engineers to get old games running on modern versions of windows.

Reverse engineers are also sometimes hired to make two pieces of software interoperate. Take for example, an oscilloscope that saves traces in a proprietary format, and a data visualization tool that uses a different proprietary format. A reverse engineer could reverse the details of the two formats and make a tool that converts in-between.

There are plenty of money to be made, just not in the way you typically do with other kinds of software. For example, a company named Bossland reversed many popular games and made bots for those. Their most recent effort was Pokémon Go. Nobody has reversed the newest versions of Pokémon Go and I believed you can make millions off it if you play your cards right.

Not really ethical though.

Some companies have security departments that analyze malware that targets their employees or the users of their services. Penetration testers might also use reverse engineering because people who hired them don't have the source code of some relevant thing, or because they want to see what an attacker who didn't have it could do, or because for some kinds of attacks looking at the actual binary might be more informative than looking at source code.

There are also antivirus developers who reverse engineer malware that doesn't necessarily target a particular class or group of users.

I've also met a reverse engineer who works with cases where proprietary software publishers have lost their old source code (this is really a thing!).

Reverse engineering can be as simple as, hey this code is supposed to be fast but it's slow, and I wonder what the compiler is doing to my code. So you compile the code, reverse engineer it and see what the compiler is emitting. That way you can steer the compiler into the right path. This is very useful for micro optimizations.

Just save the intermediate assembly files, with all helpful annotations, and analyze those. Much easier!

Once you are used to reading assembly, there's not much difference between reading the output of objdump -d and gcc -S.

Reply on news.ycombinator.com