well spotted, sir.
Are you familiar with the halting problem?
It can be avoided by careful design. Not on third-party code analysis, but we donât even really need that. We donât need a perfect solution, we canât get a perfect solution. We need a good-enough solution, first for simple restricted problems (small microcontrollers, firmware on easier architecturesâŚ), and only gradually get to generic computers. We can even develop the methods hand in hand, designing secure architectures around the visualisation/auditing system that will make it easier to inspect the code and the binaries - and pieces of malware intercepted in the wild that would attempt to attack the systems. If the visualisation system works only for Harvard architectures at this moment, without in-memory code overwriting, avoid the code overwriting and use only the Harvard CPUs for now. We are giving up some capabilities then, but in turn we didnât have them yesterday anyway.
If it works, theyâll outlaw it.
And? So weâll buy over the internet from places in the world where they did not outlaw it, or rely on distributed manufacture from common-enough-to-not-be-banned chips, and the easy-to-do auditing serving to hinder the adversaryâs attempts to contaminate the tor-based software repositories.
If you can buy a gun or hash over the Silk Roadoid, you can buy a secure router hardware and download the auditing software and the firmware.
Weâre in a war, weâre skilled, weâre pissed, weâre international, and weâre many. We will win at the end.
Thatâs already happening.
Cisco has had multiple backdoor issues in the last few years.
No
Is IDA Pro not enough for some reason?
Iâve tinkered with it, and it is really quite amazing. Sure, you have to be highly trained to catch the tricky stuff, but that would be true regardless.
IDA is a little pain because they have focused so much of their grey matter on an impossible problem. Making it better suited for mid level analysts (like me, to be honest) could be hugely beneficial. I am not arguing in opposition to @shaddack, just that there are few techniques that havenât been applied to the actual analysis of suspect code.
But an ios style rethink of debuggers and tracing could be the next billion dollar biz.
I am not a professional reverser, but myself and many programmers I know consider static analysis, indeed, to be an impossible problem to automate.
I wrote a whitepaper at my old company (that might almost have got me fired) on why application compatibility is complete garbage:
http://software.dell.com/products/changebase/
So maybe more the thrust of my question is: how do you solve that impossible problem in a meaningful way, in which is hasnât been solved before?
A good way to tackle impossible problems is to restate/reformulate them into a closely related slightly different but possible problem. Or to add input constraints. Not sure how to apply that here, though.
And then China is destroying the US industries.
A Shadowrunesque dystopia of corporate government. Data balkanisation FTW.
This kind of cynicism borders upon acceptance, which is why I donât give in to it.
Acceptance is the first step of dealing with an issue like this.
Citation needed.
Yep! Itâs the only way to go these days. Even before the bad guys got AI and botnets 10x the size of Google it was best practice, now itâs an absolute requirement! As a general rule one may assume penetration at any point internally. Given that this will happen at some point, then the only sensible design is one which mitigates that impact. Or, putting it more simply, âDonât keep all your eggs in one basketâ.
I just googled that string and Sun Tzu was the first result⌠thaâ heck?!
Nobody cares that youâre not surprised. Whether or not youâre personally shocked or like-totally-saw-it-coming has no impact on whether or not this is significant.