I have an Android APP with millions of users, but some users are malicious users (robot, fake, privilege escaped, etc). The common solution is to detect & block those "bad" accounts controlled by hackers. But, here, I aim to detect & block those hardware controlled by hackers. In another word, "fingerprint" the malicious mobile phone hardware.


I want to find a way to uniquely identify each mobile phone device (running my APP), in order to blacklist malicious mobile phone (hardware).


I meet some technical challenges to fingerprint mobile phone. But Google has strict privilege controls due to privacy concern, especially the new Android 10 version.

I summarize the following ways of unique identification:

  1. Permanent IDs (such as IMEI, serial number) need READ_PHONE_STATE permission to access. But from Android 10's design, access is forever DENIED even have READ_PRIVILEGED_PHONE_STATE permission, due to privacy reason.

  2. Semi-permanent IDs (such as device ID) will change if the phone is reset or escaped. Malicious users can reset/escape the phone to avoid detection. Google also provides Advertise ID, GUID, etc.

  3. Variable IDs (such as MAC address) can be easily changed via malicous software by malicious user to avoid detection.

Summary and Question:

I read many websites of strategies how to uniquely identify mobile phone hardware, based on above situations. Most stretegies tell:

  1. Need to diffrentiate "Android 10" and "Android 9 & below".
  2. From Android 10, most APPs cannot access permanent IDs (which is the ideal solution). Hence, we need to collect as more information as possible (permanent & semi-permanent & vaiable IDs, etc..), and compute the possibilities (%) of identical mobile phone, even hacker intentionally change some ID values.

Assume malicious users are able to change some IDs, but always do NOT change all the IDs.

I am still looking for better solutions. Please advise your ideas.

  • @multithr3at3d: nope, different. my question is how to generate a Android mobile device fingerprint, and more importantly, verify the fingerprint accurately. – TJCLK Jan 20 at 6:21
  • What is the definition of "malicious"? Don't CAPTCHA and mobile phone number verification prevent most robots? – usr-local-ΕΨΗΕΛΩΝ Jan 20 at 13:03
  • @usr-local-ΕΨΗΕΛΩΝ: robot users is one type of malicious users. CAPTCHA can help prevent partial robot users, but not all. There are many technicals of CAPTCHA and different ways to defeat CAPTCHA (another topic). In a simple word, I want to identify/block the hardware of hacker that behind malicous users. (more people choose to block the accounts controlled by hackers) – TJCLK Jan 21 at 3:07

There will always be a way to spoof the data even if you could use imei.. it can be spoofed... I usually use a unique ID, UsrName, MAC, IP, operating system, screen size and a long 'transaction token' (this token changes over time, in each login and when other values change it gets reset every login also) this is used to verify the users identity and as an ssrf token also, think of big games... They ban your mac, usrname, or ip... And still hackers can spoof them out... The only solution seems to be double step authentication!! Try implementing this out... And still... This can also be worked around by hackers.. The point here it to make it more time consuming for them. By the way how do you detect malicious users.. Maybe the true fix relies within that answer

| improve this answer | |
  • IP address for mobile devices changes rapidly over time, every few minutes typically if used on a 4G network. So never rely on that. MAC address can easily be spoofed. – jwenting Jan 21 at 4:44
  • make sense. btw, imei as an exmaple, how could hackers spoof imei? previlege escape? and is it possible to change in a high frequency? every time when APP send request to read a different imei. – TJCLK Jan 22 at 3:54
  • As jwenting said... Yes ip is not reliable because it changes a lot but it could be a parameter to keep an eye in... And that imei spoofing issue is not that easy but it can be done... Since the 'user' has your app installed it can reverse engineer it and modify the source code so dont keep sensible information in the apk... After gaining acces to the source a malicious user could just replace the imei parameter to any string he wants, no root permision needed. – a161803398874 Jan 22 at 5:15

I have an Android APP with millions of users, but some users are malicious users (robot, fake, etc) ... I want to find a way to uniquely identify each mobile phone device, in order to blacklist malicious mobile phone (hardware).

While your underlying problem is not really known (see XY problem) I think your approach to solve it is wrong in the first place. You want to detect and block "malicious phones", whatever this exactly means. And you are trying this by relying on information reported by the client (phone or robot) itself. But these could be spoofed since you don't have any control about the endpoint.

Instead you should define what you regard as expected and what as malicious behavior and then block the clients which behave the wrong way. If you need to distinguish different phones for this you can simply generate a unique (unguessable) identifier on installation, independent of the OS and hardware.

| improve this answer | |
  • and hope that an attacker isn't going to spoof those unique identifiers and present himself as another installation of the app... – jwenting Jan 20 at 9:30
  • @jwenting: If the attacker can spoof the id of a valid client then the attacker must somehow have access to this client since the unique id should not be guessable. In this case it would probably correct to block this client since it is either owned by the attacker or compromised by the attacker. – Steffen Ullrich Jan 20 at 9:57
  • Pretty much the only thing you can use for the ID is a GUID, everything else has some level of guessable data in it that can be spoofed. And a GUID can just be regenerated. The idea there is to match the GUID with a set of known GUIDs issued by the server. – jwenting Jan 20 at 11:56
  • @jwenting: I'm not following your arguments. A GUID is nothing magical but it is just a random bit sequence long enough so that it is unlikely to get generated again. Any long enough random number will do and like a GUID it has "some level of guessable data in it" - only that it is too small to actually be guessable in practice. – Steffen Ullrich Jan 20 at 12:30
  • 1
    @TJCLK: I understand that you want to block the hardware but as I said in my answer: this is likely the wrong approach to solve your problem in the first place. Unfortunately you don't give enough information about your original problem X but instead keep asking how to solve it with your approach Y. – Steffen Ullrich Jan 21 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.