22 comments

[ 2.9 ms ] story [ 57.9 ms ] thread
Curious, are there specific security engineer professionals that do this type of work day to day? Doesn't seem like a regular security analyst type role. Seems very specialized. What is the field like, compensation and is this generally for consultants?
Reverse engineering is one of the core skills employed in vulnerability research. If I'd glance behind the shoulder of a security researcher and not see an IDA or OllyDbg window open, I'd be very surprised.
Immunity debugger is quite useful as well.

Of course, if you really hate yourself, GDB on Windows is a thing...

If you're looking for a tool professionals actually use every day that requires you to hate yourself, WinDbg scores higher on both counts
What's wrong with WinDbg?
The same thing that's wrong with GDB. It's command based and most of the commands are hard to remember.
That's understandable. Recent versions of windbg have improved a bit in that regard. Most of the new functionality has been added to a more regular data model that you can browse through, and querying the data can be done using a "linq style" syntax so you can use programming knowledge instead of learning some arcane debugger commands. You still need to know the basics of flow control, but the shortcut keys for those are common with a number of other tools (e.g. F5 to run)
Their scripting engine is probably the worst programming language I have encountered (perl is readable by comparison).

That's why I was really extatic when Windbg devs introduced a standard script engine, only to learn later on that was JavaScript ...

Any specific complaint with JavaScript as the choice? The biggest downside I'm aware of it's the lack of direct support for 64bit numbers. What language would you have preferred? Python maybe?
Javascript is actually a sane choice for extending a debugger (event-based, async calls builtins, etc.) it's just that I'm not familiar with :p

I would have expected Windows to go with Powershell as their scripting engine, that's why I was surprised with Javascript.

It's "real" security work. Not related to the 'cyber security' degrees and certificaitons that have come up in recent years
If you don’t think defensive security is “real” security work, then you’re using a definition that very few people use.
Defensive security engineers I know very much employ RE on a daily basis.
It's real work, I think you misread the intent on the comment you replied to. While the work is real, it's not on the same scale of complexity and expertise as reverse engineering.

an analogy:

The school nurse putting a band-aid on your knee is "real" medical work, but that same nurse has no place in spinal surgery operating room.

The school nurse is every "certified ethical hacker" and "certified cybersecurity expert". The spinal surgeon is the reverse engineer. We need nurses, but we also need spinal surgeons more. Every spinal surgeon can practice as a school nurse, but (perhaps) 0.1% of school nurses can practice as a spinal surgeon.

If you search, there's a comment tptacek wrote here about the high daily rate professional consultant reverse engineers charge, considering how difficult it can be to problem solve around protections like codesurfer obfuscation https://news.ycombinator.com/item?id=3682361
Outside of defense, which is probably where 99% of it is still done, malware analysis is the biggest area. Some consulting firms will hire some people. Sounds neat and mysterious, but if you want a high paying career, learning C# or Java and grinding leetcode problems is going to be a far better use of your time. (Yes, yes, I'm sure we all "know a guy" that makes millions selling exploits)

Defense burns through reverse engineers as it gets the same type of people that want to make games for a living. Relatively easy to replace them after they leave.

Reversing is an art more than a science, and the most important things to learn are not tools of the trade but habits of thought and approaches to problem solving.

I appreciate what this guy is doing by documenting his learning process, it will help him without doubt, but... as an audience - perhaps we should not learn a difficult skill from someone who started their own journey into this subject a few days ago?

There's another demographic who I think would find this useful: people who used to do reverse engineering decades ago but moved on to software development. Cracking software I couldn't afford as a kid was what got me into programming and I'd love to pick it back up but time is limuted. Figuring out which tools to use by scouring Russian forums and random little hole in the wall RE sites was fun but it's great to have an up to date resource. That it comes with a beginner's perspective is quite useful since it's less likely to skip small details that an experienced reverse engineer would find second nature.
Except the tools he recommends are definitely not the standard ones professionals use these days.