Added basic support for i960 in ghidra. Didn't have use myself, but some of the Sega model 2 seemed interested. To some degree I think they used it for some of the House of the Dead remake
Got interested in amd29k for about a week before finding something else to mess with. Quick attempt at ghidra support, but never really RE'd with it, so no clue how does on larger projects.
Pcodetest is more about validating the implementation of the instruction, sure it has to decode, but the benefit is most a base level set of logic that can be emulated. And definitely not a fan of the setup to get it going (also only helpful if you have a semi recent C compiler)
Oh nice, it wasn't clear from the test suite if that was the case, I'll give it a closer look.
Judging from the python scripts, it seems to expect a whole binutils toolchain (so not just compiler but also objdump, readelf...) and that would be a blocker for me.
Compiler (gcc) and maybe assembler (as) are used. I think the other binutils executables are unused but still built-in to their logic. Due to it's age and being removed from gcc, I was unable to cleanly setup pcodetest for 80960 (had to hack it all together and scripted their java portion to work with hack), but was super useful for improving tricore (pcodetest wasn't released when I submitted original PR) and writing risc-v.
It's pretty dumb this continues to come up years later. You're the NSA delivering source code to the cyber security community. The exact community that: doesn't immediately trust NSA, knows how to find bugs, would love to find any sort of bug in their code (regardless if malicious), people you want to apply for your jobs, people you partner with (academia/other govt orgs/other country cyber security groups).
So your thinking is: yes, this is the crowd we'll attempt to insert backdoor java code.
Okay fine you still don't trust them? Run in a VM without network connection. What security risks/threat are you even talking about?
And yes people have heavily audited the source. You either trust the community catches thing or not. I'm the end of your still tin foil about it, don't use, nobody cares.
2. The audits I've seen don't evaluate the threats
3. Link me to the audits if you want to convince me
I. The risks - airgapping is not enough
1. If the software has zeroday beacons in it, it can communicate with zeroday beacon repeaters embedded in VM, OS, or hardware (see: cache side channels: https://dl.acm.org/doi/abs/10.1145/3133956.3136064 )
2. The beacons wouldn't have to look like exploit code, they could just be timing bugs sprinkled into the codebase at random. There are plenty of random little warnings and defects in the code that nobody is ever going to check or fix, see this audit:
https://github.com/NationalSecurityAgency/ghidra/issues/382
4. Low bitrate data leaks, like "ghidra is running in this org, decompiling files named....." may be accumulated by the NSA
This is just zero-day warehousing and passive signals collection with embedded zerodays. It would be hard for security researchers to detect this. I'd happily change my mind if you showed me an audit that looks for beacons and other side channels.
This audit tells us that the code is janky, but doesn't tell us if it's secure. It's just a dump of thousands upon thousands of static analysis errors.
There's no threat anaylsis in this audit. But it does suggest the code has so many defects that a serious audit would be very expensive.
III. Change my mind with evidence
Please link me to the heavy audits of the code. If you can.
tldr;; I think the code is less heavily audited than you can support
Added basic support for i960 in ghidra. Didn't have use myself, but some of the Sega model 2 seemed interested. To some degree I think they used it for some of the House of the Dead remake