Algorithms of attack and protection of mobile advertising network
I would like to talk about mobile advertising networks, about their protection system and ways to circumvent it. Ways to bypass the protection systems were used only for educational purposes. Also note that the attack algorithms presented here are valid for all platforms, but the example shows the work of Android, because attacks on its code are the easiest to describe.
What is a mobile ad network? This is a client-server application in which the server receives reports from the client applications on launching the application, making clicks on advertising and performing actions, and also sends them an advertisement for display to the user. Client applications are libraries that can interact with the server, which are usually embedded in mobile applications of third-party developers.
The power of the advertising network is measured in the number of users of applications that show advertising, which is logical - the more advertising the network can show to users, the more money it will earn and the more attractive it will be for other advertisers.
To increase the number of applications that show ads, networks are trying to attract third-party applications instead of writing their own. They provide developers with their own advertising SDK, able to communicate with their servers. For this, they give such developers a certain% of the money earned for showing clicks or actions taken from a third-party application. In this honest collaboration, everyone is happy: the advertising network receives a new application with a ready-made audience with which to advertise, a third-party developer gets money from this advertisement, and the advertiser receives a large audience.
')
Any partner of the advertising network is given a pair of appId - the application ID in the database of the advertising network and the secret is the secret key for signing actions. Anyone - ideally, because Some ad networks only give it to advertisers.
What happens next? When the application starts, this pair enters the advertising SDK and that's it, the work of a bona fide integrator at this stage ends. If this is a marketing application, it makes a request to the server, sending all its parameters (various identifiers, such as imei, openudid, udid, serial), device and platform information, and its appId. She signs all this with a secret, usually making a sha1 hash of the parameters to be sent and adding it to the request. The server, after authentication, gives the application advertising. Each advertising unit is accompanied by a set of two links. This is a link to now (which is not all ad networks) and a link to click. When an advertisement appears on the screen and the user actually sees it, the link to the show is pulled and the fact of the show is sent to the server. If the user becomes interested and makes a click - the fact of the click will also go to the server via another link.
As a result of these actions, the advertising application from which the actions were performed will receive money.
What will happen if the developer is dishonest and wants to get money just like that? In this case, it also registers in the advertising network, integrates the advertising SDK into it, and brings the application to the market. Next, he needs to send a fake request for real advertising, send the fact of display and click and get money. To do this, you need to examine what parameters are required for the request and their format. Some ad networks themselves write this information in the documentation, others have the source code of the SDK. Still others supply their SDKs as closed source libraries. The attacker must obtain an ad network library, then change the mechanism for generating an ad request so that device identifiers are not collected, but generated randomly.
As a result, the attacker sends a request for advertising with the appId of its advertising applications and non-existent device. Then he receives advertising and pulls links to commit actions. It's simple.
It is impossible to protect against such fraud on the side of the SDK, so ad networks refuse to advertise with views and clicks and move on to the next type of advertising - adverts for installations.
It is more difficult to fake installations, since The advertised application participates in them. With fair use immediately after clicking on an advertisement, the interested user starts installing this application. When the application is installed, it also uses the advertising SDK to send the fact of installation to the server. In the case of advertising for the action - the fact of installation is not enough. After installation, the user must perform a certain action in the application, which will also be reported to the advertising network.
An attacker needs to know the secret key of the advertised application in order to send a fake fact of installation or action.
How to do it? It is necessary to download the application 1 time, decompile and get the secret key. For the Android platform, this is easy.
Packages of applications under Android OS are delivered in the form of archives with the apk expansion. The archive contains application resources, media files, other files and a dex file with compiled application classes.
That he is interested in the attacker. Using the dex2jar application, an attacker can get a jar-ahriv with the compiled source code of the application and then proceed to decompile to get the secret code.
If the application developer did not pay attention to the protection of the application and did not obfuscate the code, the secret parameters of the application will be stored in clear text in the code. All you have to do is search through the class and function that calls the ad SDK.
In most cases, application developers try to complicate hacking by transferring the secret and id of an ad network application from code, where it can be easily reached, into resources and obfuscating the application to confuse the attacker.
Application resources are located in the apk-package in the resources.arsc file. This is a special file containing a table of application resources. The figure above shows that the attacker's goal - the secret and id of the application in the advertising network are hidden in files with resources, and the code that calls them is obfuscated.
The secret and id of this application were hidden in the resource file. At the same time, all resource identifiers when compiling an application for Android are entered into R.class, which generates the Android SDK. Therefore, an attacker can spy on the id the name of the resource that is being called. In the id code fragment, the application corresponds to the code 2131165201, and to the secret - the code 2131165202.
A search for these codes in the R class shows that a resource called tapjoy_amazon_app_id and tapjoy_amazon_secret_key is being used. All the attacker now needs is to access the strings.xml resource file, encoded in resources.arsc.
To do this, you need to decode the apk-package of the application using the apktool utility, after which all the application's resources will become available and the attacker can simply open it with a text editor and find the resources by previously obtained names.
As soon as the attacker received the secret key, he can send the fact of a false installation from the fake identifiers that he sgenerated during the advertisement request stage.
What is a mobile ad network? This is a client-server application in which the server receives reports from the client applications on launching the application, making clicks on advertising and performing actions, and also sends them an advertisement for display to the user. Client applications are libraries that can interact with the server, which are usually embedded in mobile applications of third-party developers.
The power of the advertising network is measured in the number of users of applications that show advertising, which is logical - the more advertising the network can show to users, the more money it will earn and the more attractive it will be for other advertisers.
To increase the number of applications that show ads, networks are trying to attract third-party applications instead of writing their own. They provide developers with their own advertising SDK, able to communicate with their servers. For this, they give such developers a certain% of the money earned for showing clicks or actions taken from a third-party application. In this honest collaboration, everyone is happy: the advertising network receives a new application with a ready-made audience with which to advertise, a third-party developer gets money from this advertisement, and the advertiser receives a large audience.
')
Any partner of the advertising network is given a pair of appId - the application ID in the database of the advertising network and the secret is the secret key for signing actions. Anyone - ideally, because Some ad networks only give it to advertisers.
What happens next? When the application starts, this pair enters the advertising SDK and that's it, the work of a bona fide integrator at this stage ends. If this is a marketing application, it makes a request to the server, sending all its parameters (various identifiers, such as imei, openudid, udid, serial), device and platform information, and its appId. She signs all this with a secret, usually making a sha1 hash of the parameters to be sent and adding it to the request. The server, after authentication, gives the application advertising. Each advertising unit is accompanied by a set of two links. This is a link to now (which is not all ad networks) and a link to click. When an advertisement appears on the screen and the user actually sees it, the link to the show is pulled and the fact of the show is sent to the server. If the user becomes interested and makes a click - the fact of the click will also go to the server via another link.
As a result of these actions, the advertising application from which the actions were performed will receive money.
Views and Clicks
What will happen if the developer is dishonest and wants to get money just like that? In this case, it also registers in the advertising network, integrates the advertising SDK into it, and brings the application to the market. Next, he needs to send a fake request for real advertising, send the fact of display and click and get money. To do this, you need to examine what parameters are required for the request and their format. Some ad networks themselves write this information in the documentation, others have the source code of the SDK. Still others supply their SDKs as closed source libraries. The attacker must obtain an ad network library, then change the mechanism for generating an ad request so that device identifiers are not collected, but generated randomly.
Hacking a closed library
The closed Android SDKs are usually distributed as a jar archive with compiled classes. The source java-code can be obtained using a Java decompiler, for example, jd gui. There may be a problem with masking methods in nested classes. A Java compiler, in the case of nesting a class in a class and calling a top-class method from the bottom, changes the method call to the generated method ID $ access. In this case, the attacker needs to guess which method should be invoked by meaning and by the passed parameters. This inconvenience does not greatly complicate the actions of the attacker, but it can make it difficult to automate the hacking SDK.
As a result, the attacker sends a request for advertising with the appId of its advertising applications and non-existent device. Then he receives advertising and pulls links to commit actions. It's simple.
It is impossible to protect against such fraud on the side of the SDK, so ad networks refuse to advertise with views and clicks and move on to the next type of advertising - adverts for installations.
Installations and actions
It is more difficult to fake installations, since The advertised application participates in them. With fair use immediately after clicking on an advertisement, the interested user starts installing this application. When the application is installed, it also uses the advertising SDK to send the fact of installation to the server. In the case of advertising for the action - the fact of installation is not enough. After installation, the user must perform a certain action in the application, which will also be reported to the advertising network.
An attacker needs to know the secret key of the advertised application in order to send a fake fact of installation or action.
How to do it? It is necessary to download the application 1 time, decompile and get the secret key. For the Android platform, this is easy.
Packages of applications under Android OS are delivered in the form of archives with the apk expansion. The archive contains application resources, media files, other files and a dex file with compiled application classes.
That he is interested in the attacker. Using the dex2jar application, an attacker can get a jar-ahriv with the compiled source code of the application and then proceed to decompile to get the secret code.
If the application developer did not pay attention to the protection of the application and did not obfuscate the code, the secret parameters of the application will be stored in clear text in the code. All you have to do is search through the class and function that calls the ad SDK.
Decompiled class
In most cases, application developers try to complicate hacking by transferring the secret and id of an ad network application from code, where it can be easily reached, into resources and obfuscating the application to confuse the attacker.
Application resources are located in the apk-package in the resources.arsc file. This is a special file containing a table of application resources. The figure above shows that the attacker's goal - the secret and id of the application in the advertising network are hidden in files with resources, and the code that calls them is obfuscated.
Obfuscated class
This can be judged by the fact that instead of a line like TapjoyConnect.requestTapjoyConnect (paramContext.getApplicationContext (), "appId", "secret"); there is a loop that passes 1 time and receives the application id and secret from the resources. In this case, the attacker has to search for the fragment of code he is interested in throughout the application and analyze the entire code obfuscated by the obfuscator.
This can be judged by the fact that instead of a line like TapjoyConnect.requestTapjoyConnect (paramContext.getApplicationContext (), "appId", "secret"); there is a loop that passes 1 time and receives the application id and secret from the resources. In this case, the attacker has to search for the fragment of code he is interested in throughout the application and analyze the entire code obfuscated by the obfuscator.
The secret and id of this application were hidden in the resource file. At the same time, all resource identifiers when compiling an application for Android are entered into R.class, which generates the Android SDK. Therefore, an attacker can spy on the id the name of the resource that is being called. In the id code fragment, the application corresponds to the code 2131165201, and to the secret - the code 2131165202.
A search for these codes in the R class shows that a resource called tapjoy_amazon_app_id and tapjoy_amazon_secret_key is being used. All the attacker now needs is to access the strings.xml resource file, encoded in resources.arsc.
To do this, you need to decode the apk-package of the application using the apktool utility, after which all the application's resources will become available and the attacker can simply open it with a text editor and find the resources by previously obtained names.
Found resources
As soon as the attacker received the secret key, he can send the fact of a false installation from the fake identifiers that he sgenerated during the advertisement request stage.
Ad network recommendations
Protecting the advertising SDK is not enough in this case. Even if you use the native library instead of Java, you can only make it difficult to hack (and make compatibility problems), because it is distributed freely and will always be available to the attacker. To catch fake facts - you need to use the following:
In the case of logical protection you need:
Compliance with the recommendations for logical protection will significantly reduce the rate of falsification of facts by the attacker, but if he also guesses to see this spoiler, then the ad network will need more complex protection.
You need to check the actual number of installations for advertising applications. Unfortunately, at the moment, application stores do not provide this information to third parties. However, you can look towards Google Analytics. If the number of devices on which there is advertising, exceeds the number of installed, the partner is an attacker.
You can also monitor all devices that send facts of installations / requests for advertising. And if within a month no action was taken from these identifiers - consider such a device as an accidentally generated intruder and non-existent.
If the ad network has enough traffic, then you should not send the same ad to the same advertising application. This will significantly reduce the rate of hacking, because the attacker will always get advertisers secrets slower than the advertising rotation will occur.
And finally - require your advertisers to obfuscate the code without fail and enter a secret change once in a while or for a certain number of fact signings.
In the case of logical protection you need:
- do not count clicks if there was no request for advertising
- do not consider clicks, if before that there was no fact of viewing
- do not take into account the installation, if too little time has passed after the click (depending on the size of the application being downloaded)
- remember which ad was given in the ad request and prevent ad views / clicks on the ad that the user did not receive
- after clicking to prevent clicks on other advertisements from the same issue
Compliance with the recommendations for logical protection will significantly reduce the rate of falsification of facts by the attacker, but if he also guesses to see this spoiler, then the ad network will need more complex protection.
You need to check the actual number of installations for advertising applications. Unfortunately, at the moment, application stores do not provide this information to third parties. However, you can look towards Google Analytics. If the number of devices on which there is advertising, exceeds the number of installed, the partner is an attacker.
You can also monitor all devices that send facts of installations / requests for advertising. And if within a month no action was taken from these identifiers - consider such a device as an accidentally generated intruder and non-existent.
If the ad network has enough traffic, then you should not send the same ad to the same advertising application. This will significantly reduce the rate of hacking, because the attacker will always get advertisers secrets slower than the advertising rotation will occur.
And finally - require your advertisers to obfuscate the code without fail and enter a secret change once in a while or for a certain number of fact signings.
Next steps
This spoiler is not a recommendation to attackers. His goal is to show networks that not only piece hacks are possible and that they have something to fear.
If an attacker takes the issue of hacking seriously, he can easily automate it. Searching even obfuscated code is not a difficult task, since The class name and method of invoking the advertising SDK is always open. And if you consider that a sufficiently large percentage of developers do not obfuscate the code, then you can automatically get a sufficiently large number of secrets.
The scheme by which attackers can act is to create several applications whose task is to collect a large number of advertised applications for hacking. As soon as a sufficiently large amount of data is accumulated, you can run an application that uses the collected databases to send falsified data.
If an attacker takes the issue of hacking seriously, he can easily automate it. Searching even obfuscated code is not a difficult task, since The class name and method of invoking the advertising SDK is always open. And if you consider that a sufficiently large percentage of developers do not obfuscate the code, then you can automatically get a sufficiently large number of secrets.
The scheme by which attackers can act is to create several applications whose task is to collect a large number of advertised applications for hacking. As soon as a sufficiently large amount of data is accumulated, you can run an application that uses the collected databases to send falsified data.
Source: https://habr.com/ru/post/262097/
All Articles