Hi, I'm the founder of SourceDNA. We've built an index of the code in iOS and Android apps to quickly answer questions like this about how they were built.<p>TLDR; we created a tool that lets you just search for an app and see if it's affected.<p><a href="https://searchlight.sourcedna.com/search" rel="nofollow">https://searchlight.sourcedna.com/search</a><p>In this case, the Android NDK does not include OpenSSL and considers it a private API, 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.<p>Even more painful is that native libraries that were pulled into your project by some <i>other</i> dependency can also cause the same issue. For example, Baidu's push messaging plugin depends on OpenSSL for crypto, so you wouldn't even know you were affected by this problem just by using it.<p>Affected apps will continue to work fine until run on the newest Android devices with Android M, such as the Galaxy S6, Note 4, and Nexus.<p>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.