1. How closely would you have to look to notice something like a weak crypto setup or other “accidental” change less obvious than sending everything to “all-your-bytes.nsa.gov”?
2. How many people other than blackhats actually have the time to do this for every single automatic update?
I tried understanding the APIs several phone apps are using, (the apps are heavily obfuscated), so I decompiled them and hacked my own small deobfuscater where I could rename stuff half-automatically.
Then I went through the code of Google Apps with this, and it’s actually really nice. Although kinda surprising how many Google Apps have hardcoded API keys for their services floating around, for example there is one Google App which has a hardcoded key that allows full unthrottled API access to all of the Google Maps APIs. For free.
I just did this out of fun, as I’m mostly working on Android OpenSource apps, but it was quite easy and interesting to see how Google obfuscates their apps.
Finding predictable things like hard-coded strings is a significantly easier task than proving that none of the code is doing something sneaky. It's much easier to look for something like an access key than confirm that the numeric constants being passed to a crypto function are the correct ones or that it's not leaking something which would make it much easier to crack.
This is encryption and obfuscation on multiple levels, classes passing each others state through hashing and encryption schemes on multiple levels, added bytecode hackery, etc.
Exactly my point – it's unreasonable to expect that higher level of reverse engineering will be done reliably for every release of even a small percentage of the apps being published.
2. How many people other than blackhats actually have the time to do this for every single automatic update?