3 ms·
Do you plan to make the tool available to general application development, e.g. outside of apps available on Google Play/AppStore? If I understand correctly, y
by bdamm 11y ago
Do you plan to make the tool available to general application development, e.g. outside of apps available on Google Play/AppStore?
If I understand correctly, your architecture translates the binary code into an intermediate language (effectively a reverse compiler) so that patterns across different build targets can be recognized as the same API use? Can you translate from platforms like Java? Can your platform recognize a call to a poor native API if done through a platform like Java? (e.g. a Java program calls a function that the JVM translates into a native call, but the parameters are setting up the caller for a vulnerability?) Does your platform handle transitive data identification? My point is that the call itself may be generalized, and specific sources of that call may be the source of the problem, but that may be abstracted by several layers of functions.
How does your product differentiate itself from the other static code analyzers available in the market place?
- NateLawson 11y agoWe're focused on applying our engine to solve problems in the app stores, so no plans to make it a standalone software product. Yes, we track JNI links from Java -> native. Yes, we do data flow analysis as well, but it's targeted via control flow analysis. In other words, first we identify a code path of interest and then target the data values/types that appear on that path. This way we're not wasting time analyzing data that is unimportant. We're not a static code analyzer, we're a service for helping developers improve mobile apps. We'll never tell you "Here are 8488 potential integer overflows to investigate." Instead, we've pre-processed the issues to give targeted recommendations that any dev can understand. Quality over volume, in other words.