On searching for an app on the app store by name, the app store shows the matching list in the descending order of rating. There is a tendency of installing the first one.

By installing the original app and uninstalling it with a poor rating, many times, the original app can be pushed to the bottom. Whereas by giving the highest rating to the rogue app, it can be pushed to the top of the list.

Since the rogue app is a 100% functional app, the user can go through the registration process and carry out a transaction on the app, as usual. Broadly, this rogue app can do one the following.

1. In the process, the app can collect all the required data to carry-out a transaction as the user and the user's registered device. This data can be sent to the thief using http-client.
2. Or the app itself can change the data and submit. For example, by changing the entered "account to" and the "amount" , the transfer can be made to some other account.

The thief can substitute this stolen data at the point of stealing in another copy of the original app, without bothering app logic. Thus, the app will always consider it data generated by the app itself.

This way the thief can carry out transactions impersonating the user’s app, the user’s device, and the user.

For a mass theft, the thief can execute transactions by substituting data of users in a loop and running it under a simulator.

The thief can use the existing functionalities of the app to make it more lethal. e.g. by regularly checking the account balance and transferring out the balance as soon as a credit appears in the user's account.

The thief can take a copy of an organization app and launch a rogue app by changing the package name, organization name, logo, etc. Here, the thief is using some other brand but is actually using the APIs of the organization. This will make it impossible for a rogue app monitoring service to detect this rogue app. The thief can also upload this app on a website, which is beyond the reach of a rogue app monitoring service.

Thus, the thief can steal data using some other brand and use the stolen data to target the organization.

The decompiled java code may show errors, but it is very unlikely that classes required for data stealing will give errors. By selectively modifying the required class and replacing its byte code, the result can be achieved.

Alternatively, changes can be made in dex files, as they never give any compilation errors.

Typically, app signature or classes.dex are used as reference objects for detecting tampering.

Checkpoint/Signature, based on any external property like timestamp, size, CRC, memory allocation, can always be extracted from the object of the original app and can be substituted at a proper place in the java code of a rogue app to fool the system.

The simplest way is to copy the original objects like classes.dex, RSA signature in asset folder and change the reference in java code to point to asset folder. This technique will always get the correct value of the original app, thus ridiculousing the whole anti-tampering mechanism.

1. If C++ library in-turn is making calls to underlying application or android classes to get the reference of the app signature or classes.dex object then the underlying android/java classes can be modified and be included as a part of the APK. Values of the original object can be substituted in these modified classes using techniques discussed earlier.
2. If C++ library in-turn is not making calls to underlying application or android classes to get the reference of the app signature or classes.dex object then C++ module can be patched to read signature/classes.dex file from asset folder. It is very easy to crack/patch disassembled C++ code using utilities like “IDA Pro”.
3. If C++ library is not making calls to java library to get checkpoint and the output of C++ module is checked against the webserver, the output can be changed at java level before it is submitted to the webserver. Or, the response from webserver call can be changed at java level to indicate no tampering.
4. “proc/self/map” gives memory allocation in 4K block. Memory allocation mainly changes on the introduction or on the removal of a new class, method, or public object. There is a high chance that introduction of a stealing code won’t change memory allocation. Even if there is a change, it can be adjusted by adding/removing a few lines of code.
5. Any hardcoded encryption key always gives the same output. Similarly, if the encryption key is passed to the C++ module, it always gives the same output corresponding to the key.
   The thief can always obtain the output of C++ module from the original app, by running the original app in debug mode under an emulator. If required, the thief can root his/her device. This output can be substituted in the rogue app as the output of C++ module, thus fooling the whole system.
6. If the output of C++ module is encrypted and data contains some dynamic data like time to make output dynamic, then the encryption key can be easily extracted from C++ module. Please see the next point to find out how to extract the encryption key.
   The checkpoint/signature based on any external property like timestamp, size, CRC, hash, can always be extracted from the object of the original app and it can be substituted at an appropriate place in the decrypted output of C++ method at java level of the rogue app to fool the system. Before substituting, the output can be re-encrypted using the extracted key.
7. The call to C++ module can be bypassed in java code, in case anti-tampering check is performed within the C++ module. Thus, breaking the complete anti-tampering check chain.

Similarly, any other tampering check can be bypassed externally without understanding or changing the C++ code.

Any hardcoded encryption key always gives the same output. Similarly, if the encryption key is passed to the C++ module, it always gives the same output corresponding to the key.

1. Instead of tampering encrypted output data, tampering of input data to C++ module can be carried out.
2. It is very easy to extract either passed or hard-coded encryption keys by cracking disassembled C++ code using utilities like “IDA Pro”. It is because parameter name, function name, class name, local variable name, return value, switch statements, etc. are never changed in assembly code. By searching de-assembled code using parameter name or function name, the exact line where encryption is taking place can be reached. Once the key is extracted, the output data of C++ can be decrypted, modified, and re-encrypted for futher processing.

1. Rogue app monitoring service can scan only app stores. Whereas, the thief can upload rogue app on a website. Thus, defeating rogue app monitoring service.
2. It is difficult to identify and remove copycat (similar looking) rogue apps as they do not violate Google policy.
3. Rogue app monitoring service can't identify a rogue app if resource images and texts are encrypted.
4. There can be a substantial time difference between when a rogue app is uploaded and when it is removed by an app monitoring service from the app store. In this period, a large number of users can download the rogue app, as social media messages spread at a very high speed.
5. On bringing down a rogue app, the thief can upload another copy of the rogue app with a different package name.
6. Using URL forwarding, the pointer of the link in a social media message can be changed to the download link of the new package.
7. App store has to put back the app on App store if the app owner protests. Then, it can be removed only after a long legal process. Thus, giving a very long window for users to download the rogue app.

External fingerprint (like Aadhar) is just another piece of data. It can be stolen and substituted exactly in the same way as any other data.

Built-in fingerprint reader check can be bypassed by changing the return value of the fingerprint check method in java to “true”.