0

As far as I can tell, it's a ways of obfuscating/encrypting the shared prefs on your device, that store LVL info about last response, time to next retry etc.

As the salt and deviceId (however you make it, which is the topic of another question i want to ask...) are readily readable via dex2jar/decompiling, and anyone with a rooted device can grab your shared prefs file and then unencrypt/deobfuscate it at will, is the whole purpose just to make things that bit harder for the hacker, rather than actually making it hack proof?

Or am I missing a vital part of something?

Russ Wheeler
  • 2,590
  • 5
  • 30
  • 57
  • The vulnerability is securing the encryption key from an attacker, also if the quality of the key. – zaph Feb 18 '18 at 13:20
  • but that's my point, without calling a server, I can't secure the encryption key, it's always readable from my decompiled code, or from a root-enabled phone taking my shared prefs (and then deobfuscating them) – Russ Wheeler Feb 18 '18 at 13:24
  • There is no easy and/or inexpensive answer to securing keys. That is the problem with encryption in many use situations, the problem just moves. – zaph Feb 19 '18 at 01:16

0 Answers0