Hi, I'm the founder of SourceDNA and I can answer any questions you have. We've built an index of the code in iOS and Android apps, so we can quickly answer det

Hi, I'm the founder of SourceDNA and I can answer any questions you have. We've built an index of the code in iOS and Android apps, so we can quickly answer detailed questions about how they were built. In this case, the Android NDK does not include OpenSSL (libssl and libcrypto), so developers have had to come up with their own approach. The correct one is to statically link your native extension with your own copy of OpenSSL or include a dynamic (.so) copy of it in your APK. But some developers were retrieving the library from a random Android device to link against, but then relying on the OS to provide exactly those same symbols. That assumption failed when Google moved to BoringSSL, Adam Langley's rewrite to improve security. He had to change some APIs and thus break binary compatibility. The problem is, nobody knew which apps have this problem. They will continue to work fine until run on the newest Android devices with Android M, such as the Galaxy S6, Note 4, and Nexus. We scanned our index for apps that had native code, matched each app's binaries against libcrypto.so and libssl.so, and built a graph of each dependency linkage. Then we could trace the graph to find apps that had this flaw and exactly which of their libraries was at fault. If you're a developer, I'm interested in hearing what you think.