54 ms·

I know nothing about Android development (this service isn't available for iOS yet, according to the article). Does the OS give you low enough level control to

I know nothing about Android development (this service isn't available for iOS yet, according to the article). Does the OS give you low enough level control to overwrite specific memory locations, say with random data? In other words, could the snapchat app shut this down with a simple update?

HorizonXP 13y ago
Sure. Just pass a reference to the Java-land object down to C++ via the Java Native Interface (JNI) and use memset to wipe out the memory in that location.
georgemcbay 13y ago
Even if they did this, there's still a huge problem on Android in that it is trivial to root virtually any Android phone and a rooted phone can be running a background app with READ_FRAMEBUFFER_ACCESS and constantly polling the framebuffer, so anything you see on the screen is leaked out of any app. And you can do this all at the app level without even getting into kernel driver hacks. Anyone who thinks the photos passed along through these apps are in any way safe from being saved and leaked by the receiver is very technically naive. All of the old rules about all bets being off if someone has physical access to a device in the chain still apply.
- Sprint 13y ago
  I find it extremely positive and beneficial that I have root access on my smartphone and I would not like to buy a device I cannot hack like that.
- rajivm 13y ago
  You could draw the photos in a SurfaceView with a "secure" flag (see http://developer.android.com/reference/android/view/SurfaceView.html#setSecure(boolean) http://developer.android.com/reference/android/view/SurfaceV...). This would prevent other apps from reading them out of the framebuffer, or even taking a screenshot of them. If Snapchat isn't doing this, well their developers should do some research...
  - georgemcbay 13y ago
    That flag only exists in the very newest JellyBean MR1 release (API level 17). The best they can do is set it if the user is running an Android device at 4.2 and higher, which is a VERY small minority* of all Android devices right now. Until they are willing to limit the app to devices running Android 4.2 and above (and there is no way anyone would do this right now, it would be commercial suicide) the easy escape hatch remains. * 2.3% as of this writing according to http://developer.android.com/about/dashboards/index.html http://developer.android.com/about/dashboards/index.html

HorizonXP 13y ago

Sure. Just pass a reference to the Java-land object down to C++ via the Java Native Interface (JNI) and use memset to wipe out the memory in that location.

georgemcbay 13y ago

Even if they did this, there's still a huge problem on Android in that it is trivial to root virtually any Android phone and a rooted phone can be running a background app with READ_FRAMEBUFFER_ACCESS and constantly polling the framebuffer, so anything you see on the screen is leaked out of any app. And you can do this all at the app level without even getting into kernel driver hacks. Anyone who thinks the photos passed along through these apps are in any way safe from being saved and leaked by the receiver is very technically naive. All of the old rules about all bets being off if someone has physical access to a device in the chain still apply.

Sprint 13y ago
I find it extremely positive and beneficial that I have root access on my smartphone and I would not like to buy a device I cannot hack like that.
rajivm 13y ago
You could draw the photos in a SurfaceView with a "secure" flag (see http://developer.android.com/reference/android/view/SurfaceView.html#setSecure(boolean) http://developer.android.com/reference/android/view/SurfaceV...). This would prevent other apps from reading them out of the framebuffer, or even taking a screenshot of them. If Snapchat isn't doing this, well their developers should do some research...
- georgemcbay 13y ago
  That flag only exists in the very newest JellyBean MR1 release (API level 17). The best they can do is set it if the user is running an Android device at 4.2 and higher, which is a VERY small minority* of all Android devices right now. Until they are willing to limit the app to devices running Android 4.2 and above (and there is no way anyone would do this right now, it would be commercial suicide) the easy escape hatch remains. * 2.3% as of this writing according to http://developer.android.com/about/dashboards/index.html http://developer.android.com/about/dashboards/index.html