Hacker News Reader

Comment by dataflow | Hacker News Reader

How dooyou tell something is dodgy from the call graph? Don't you have to decipher what FUN_918243 represents, or whatever?

View on HN

Generally you can click around some code and see what functions it calls, what strings it references, etc. to get a basic understanding of what it does.

You can see imported library, strings and possible network calls, working backwards you going to see red flags if it's a basic app.

Easy: all nonfree software you have to decompile to view the 'source' is dodgy by design.

Tools like Ghidra et al. merely lay bare the truth you already know.

What if someone gives you a binary that they claim is built from a particular source code? If you don't decompile it, how do you know if that's true or not? Or what if you can't trust your compiler (a la https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html)?

I could never trust a bin I didn't build myself (with my own C compiler ofc).

Did you build that C compiler yourself? Using what compiler? Unless you bootstrapped it from a handwritten assembler, you'll need to consider the attack outlined in Reflections on Trusting Trust

I did but I foolishly relied on GCC before it was self-hosted now I guess I should scrap the whole thing and build by hand.

There's actually someone out there who has done some impressive work on this, believe it or not!

https://savannah.nongnu.org/projects/stage0/

Reproducible builds. Sure not every project can be built in a reproducible manner, but it at least reduces the chances of getting shady binaries

Check out `guix challenge` for a concrete example of how tidily this can be done with a system that supports reproducible builds well!

https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...

Reply on news.ycombinator.com