Comment by Jtsummers | Hacker News Reader

Comment by Jtsummers | Hacker News Reader

Parent Full thread

Learn to use the tooling (Ghidra is nice and also free), learn to read assembly and how to look up assembly instructions and understand the documentation on them (there are a lot of assembly instructions for each platform, you will likely not memorize them all nor memorize every ISA). It can also help to know how to write some assembly.

With your favorite compiler, use whatever flag it offers to spit out assembly listings from its compilation process. On clang and gcc this is `-S`. Typically used like `gcc foo.c -S` and it'll produce a file `foo.S` which contains the assembly listings. Or use Compiler Explorer (aka "godbolt") https://godbolt.org/. Great resource, supports many languages and targets, has good highlighting of what code in the origin language became what assembly.

That last bit will help you gain an intuition for what code looks like when it gets converted into assembly language. This is helpful for going in the other direction, it lets you at least guess at something.

There are probably some books or other resources people can recommend, I just picked it up as I went but I'm also just a "dabbler" in the field. It's not my day job and I have no intentions of making it my day job so I've learned enough to accomplish my goals or satisfy my curiosity.

(An easier way I've found is to compile an entire project with --save-temps, for c, objc, or c++. Makes it easy to instrument a lot of files at once.)

It's unfortunately a day job for none of us. I think we'd all be very elated if there was some way to turn this into a career, but matching decompilation is not really something that companies are asking for. It probably doesn't help that it's such a relatively new method of decompilation.

Having the tools handy means sometimes you'll still get the opportunity to use them.

I was able to fix a 3rd party binary that was broken on our platform via dis-assembly and binary patching. Having the tools in the toolbox to do so allowed us to solve it rapidly when normally it'd take months to work with the vendor.

It’s a day job (or was, lost touch) for a couple people I have known. But it is a small niche.

Definitely still a day job for some people. These DARPA and IARPA programs all have a decompilation component:

1. https://www.darpa.mil/program/assured-micropatching

2. https://www.iarpa.gov/newsroom/article/annotated-malicious-b...

3. https://www.darpa.mil/program/recovery-of-symbolic-mathemati...

There is at least one of us with it as a day job at Nightdive!

If this is for the project I think it is, my understanding was that you all didn't strictly require matching decomp for what you were doing. But I could be wrong about that. I was a bit unclear in my message above in that I really meant matching decompilation in and of itself isn't a career.

Your example is a cool case though. Maybe someday for me :)

Oh, I'm not the one in question, just that we both know of one person doing decomp for a living there. You're right that it was stated that strict byte for byte matching wasn't required, but I would imagine it's still all the same skills, you just don't need to care about regalloc diffs, and the like. No need to do fake matches either. A little freeing, but also it could make it harder to notice subtle diffs if the regs are different in very subtle ways where you don't notice reuse, so I prefer strict matching myself.

Reply on news.ycombinator.com