dmayer

Yes, often times that can be sufficient. If you just want to study the protocol or build a custom client. Often times one would like to modify messages of the protocol in order to find flaws in either the server or the client and the ability to man-in-the-middle the protocol makes that easier, in my opinion.

For completeness, the whitepaper is here: http://matasano.com/research/bypassing_openssl_pinning.pdf

(Disclaimer: I'm the author of the blog post)

I think, there is two things to that.

First, for dynamic C/C++ libraries like OpenSSL, some degree of symbols have to be maintained in order to relocate the library and find the entry point to the corresponding function.

Second, Objective-C is a dynamic language and as such the binary will always include the Objective-C method names. The reason is that they are resolved at runtime (via so-called "selectors"). In fact, Objective-C doesn't technically call methods but they use a message passing system. So if you pull any app from the app store, you can determine all classes, methods, and mostly arguments of the methods.

Yea, I think a better term would be application security assessment where one tests the application for security flaws. Penetration testing stems originally from network security where one actually tries to penetrate a network. It's not a great term for software, I agree.

They also have a software solution in the form of a floating overlay (similar to Facebook Messenger). I saw the feature recently and it allows you to trigger both the sleep and the home button.

Ah, did not see that. It's confusing since the Falcon 9 Wikipedia page also has the Falcon 9 Reusable: https://en.wikipedia.org/wiki/Falcon_9#Falcon_9-R

This is a reusable Falcon 9 not the Grasshopper. The Grasshopper program ended last year and used a smaller rocket (AFAIK).

There is a CVE (CVE-2012-6636) [1,2] related to the general issue they are mentioning. Basically one could use reflection to call any public function on any class in the app. Since Android 4.2 one now needs to add the @JavascriptInterface decorator to explicitly expose methods. At least this is my current understanding of this.

If the app then uses HTTP or HTTPS without certificate validation, it is easily possible to inject JavaScrpipt code even when no Cross-Site Scripting vulnerability exists in the app.

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-66...

[2] https://labs.mwrinfosecurity.com/advisories/2013/09/24/webvi...

I'd assume that if this were an actual break-through result it would be published in a reputable academic conference and not a random journal..

I thought his is one of the reasons they have backup keys which you can use when your phone is not reachable. I haven't actually tested the new system though.