Hacker News new | ask | show | jobs
by ShepherdKing 1802 days ago
I would be curious to know if anyone has audited this for malicious code, or how one would go about doing that in the first place. Is that kind of software auditing a use case for Ghidra? A demo of using Ghidra to audit Ghidra would be interesting I suppose.
2 comments

Reflections on Trusting Trust is worth a read.

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Not really. TLDR: You cannot trust code you did not botch up yourself.
Never thought I'd see the day where someone on HN is suggesting Ken Thompson isn't worth reading.

If you've never read it I highly encourage you to do so.

I did read that article, my tldr is what I said.

Perhaps in 1984 what he writes was groundbreaking, but to me it wasn't. Do I need to apologize now for not being bamboozled by Ken's genius this time?

Its used to reverse engineer an unknown binary without the matching source code. Since Ghidra already is open source it be no use to audit Ghidra itself except for learning purposes. It might be useful to reverse engineer a closed source driver so you can write an open source one from scratch.
A security audit is still useful when you have sources to the program. There may still be some intended or just accidental security problems with it. Having the sources makes such an audit a lot easier to do.
Is there a standard process anywhere for vetting some software for information leakage? I would imagine that someone would deploy the software behind an MITM proxy and then look at the traffic, but it would be nice if there was some standard process or framework for this somewhere.
It's a huge code base, of course there are security issues. Same way IDA and radare have security issues. People who reverse malware take that into account.
I would expect there to be self-mutating code such that when the open source code is compiled with a particular compiler it activates a different code path (written into the compiler itself) such that the final resulting binary does not correspond to the source code if it were compiled with another compiler.

And if this resulting binary is distributed, audits of the source code wouldn't catch these modifications.

1) There are many java compilers with diverse origins. Try more than one.

2) The binary (or jar) can't lie about what it contains. Take it into an air gap and reverse engineer it, what's there is there. This includes compilers.

3) see posters comment about the impracticality of stopping someone with the money, talent, skills, and patience of the NSA :)