Machine code is well known to be complicated, subtle, and difficult to understand, and as such, finding flaws can be time-consuming, without sufficient help from an automated tool. CodeSonar for Binaries helps engineers who might not know all of the subtle details of machine code by providing English explanations about what’s happening in the code at the particular point of a detected error. When paired with CodeSonar’s code visualization features, it also provides a unique advantage for understanding where vulnerabilities exist in your code. With multiple viewing options for visualizing metrics, defects, and sources of input data, you can quickly gain a high-level understanding of what the code looks like.
Find Defects In Your Own and Third-Party Provided Code
Most software that runs embedded devices is now developed by external sources, not in-house development teams. Some of this is open-source, but a significant proportion of code is third-party commercial software, so the source is often unavailable. Because Codesonar for binaries doesn’t rely on debugging or symbol-table information, it can examine the stripped binary executables that third-party software vendors typically ship. With this capability, the technology enables you to perform a security audit on software without any cooperation from the vendor.
We are very pleased with our choice to work with Valbrio and CodeSonar,” said Cyril Rochard. “CodeSonar has allowed us to significantly reduce bug-related problems and improve the overall quality of our devices. Our customers are very happy with the improvements and other areas of our own business are keen to start using it as well.
Analyse Libraries With Mixed Mode Analysis
In CodeSonar’s unique Mixed Mode, our binary code analysis technology is integrated with Codesonar’s source code analysis technology, allowing you to analyse third-party libraries at the same time as you analyse your own code.
You might be interested in:
- Finding defects in your own code due to misuse of libraries, which might occur because documentation isn’t always explicit and there may be error cases that the third-party library handles differently than expected.
- Finding defects in the libraries themselves that manifest in the way you use the code (for instance, you might call their API with a particular value that should work, but might sometimes cause a memory leak).
- Performing an audit of the third-party library to make sure it doesn’t have important defects.