[ethteck]

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.

[upon_drumhead]

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.

[Jtsummers]

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

[bkallus]

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...

[foldor]

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

[ethteck]

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 :)

[foldor]

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.