Is it realistic to make money on a mobile application for viewing ads for money?
An article is an analysis of one of the applications on the list . The article was written immediately after the vulnerability was detected in the application. The developer received a report and confirmed the existence of the problem, promising to fix it soon. At the moment, an application update has been released on both platforms.
For several years, AppNana (AppJoy) has been on the wave of popularity, because they provide an opportunity to download paid applications from the application stores for iOS and Android for free, without SMS. What is the catch, you ask? Where are the pitfalls hidden? Everything is very simple: you spend your time watching ads, installing left-handed, unsigned applications via direct links, and also share your personal information with half a dozen advertising aggregators for mobile phones, passing them all the information that AppNana has access to (including personal email).
Everything seems to be clear. Free cheese is only in a mousetrap, there is also a fee and it is not commensurate with the reward. To be precise, the minimum amount for “withdrawal” is 45,000 nanas (domestic currency, 45,000 nanas = $ 2), starting capital of 10,400, daily active users receive 400 nanas (if they were able to collect 4,000 nanas one way or another in the previous day) , one “task” is paid from 20 (most) to 450 nanas (while there was only one such task), while users receive the largest amount of nanas through referrals (2 500 nanas to the inviting and the invited).
Now it’s getting clearer. The application itself is used not for scanty bonuses for downloading anti-viruses for free without SMS, but for inviting everyone and everything. It turns out that all users (500,000 - 1,000,000 according to the Google Play metric) only do what they create several accounts and in turn send themselves invitations? Not so simple, Max Guan (a Chinese developer living in San Francisco) thought this through beforehand. In order to use the referral code, which will bring 2,500 nanas, you must first earn 15,000 nanas, which in itself is a feat.
Okay, let’s leave the “legal” ways of earning alone. Let's try from the other side. Install Fiddler2 and proxies for Android. We configure proxies for AppNana and look at requests. And they turn out to be very interesting. For example, this one:
POST to appnana2.mapiz.com/api/nanaer_login email = someone% 40example.com & password = 1234567890 & source = Android & android_id = abc
SUCCESS will be returned and you will be given a cookie with session ID. It seems everything is just right? But this script alone does not limit the number of requests. Brute Force provided. Unfortunately, if you check all the email and password combinations, the server will simply fall off. Although it turns out that it can fall off with a five hundred error if android_id is a space character ...
Let's try to solve the problem of email selection. To do this, we need the following query:
GET appnana2.mapiz.com/api/get_nanaer_info/?email=someone%40example.com
In response, you will receive a complete list with input_invitation (the number of referrals accepted) b paypal_email (AppNana gets it when withdrawing money to PayPal), redeem_times (how many times the reward was received), login_times (how many times the input was made), bitcoin_address (used to output to BitCoin), offer_nanas (the number of "earned" nanas), register_ip (IP used during registration), devices (contains a list of all the devices from which you were logged in, along with their mac addresses and ios identifiers), email (address used during registration), lastlogin_ip (last IP), nanas (account balance), sent_invitation (quantity invitations sent by “referrals”), gift_email (additional address for sending a gift code). And a couple of not relevant fields.
What we have? An API that issues all user data without authorization. How will he help us? It is enough to google AppNana hack and we will immediately get an almost complete list of people who are trying to collect as many nanos as possible through referrals. You can find blog entries with one and a half thousand comments, each containing a referral code and ... almost everyone is tied to a Google account, since the blog runs on Blogger. Our task is simplified at times: we parse the issuance of Google, we find all references to the referral code (one letter, then 8 digits), next we look for links to a Google profile or email for communication. In a couple of hours, such a parser will be able to create a high-quality dictionary for brute force attacks on the aforementioned script.
Now we have a database of hundreds or even thousands of users with the balance of their personal accounts. What can we do? All. Everything. You will say that this is impossible, but I have not yet revealed all the cards! Next, we need two more APIs:
POST to appnana2.mapiz.com/api/invite_verify
POST to appnana2.mapiz.com/api/redeem
First, it activates the referral code and charges 2,500 nanas to the account. Second, displays nanas in Bitcoin or PayPal. Both work without authorization.
First of all, you will create pairs of accounts that have more than 15,000 nanas in your account. Then we will take the referral codes linked to the accounts and cash them out for all accounts. When everything is ready, it can be assumed that with 1000 codes and associated accounts, you can get 999,000 valid links. Given that many actively use the codes of others to receive referral rewards, it can be assumed that 25% of the connections have already been used, this leaves with almost 750 new connections to the account. Each link brings 5,000 nanas to the system. By cashing out all the referral codes available to us (750,000 requests), we get 3.75 billion nanos distributed throughout the system.
If we take the most expensive reward (1,200,000 nanos for $ 100 PayPal), then we will generate $ 312,500 or if we prefer anonymity and are willing to not pay, then we can withdraw all the money in Bitcoins, which as a result will give us $ 267.857 in bitcoins for conversion day. This does not take into account already available user balances. All we have to do is use the Redeem API to transfer money to our PayPal account or Bitcoin wallet.
Of course, it is unlikely that a startup with one developer, who is also the head of those support (information from the LinkedIn profile), has a PayPal account or bitcoin wallet with $ 312,500, but if the whole process is automated and does not raise strong suspicions, you can easily withdraw a round sum .
Most interesting, this is not a direct violation of the public offer of the service. It contains clause 8a which prohibits the collection and storage of personal information of users, while its analysis, without subsequent storage is supposedly allowed, you can also ignore personal information, and save only the username, account balance and referral code. Clause 8k prohibits interference with the protection system, including disabling it, in this case there is no protection system as such, that is, using the API without authorization, I do not violate this point. Point 8r is the most extensive. It prohibits the use of automatic software to access the service bypassing their protection system and / or the robots.txt file (they don’t have either), and the modification and use of modified versions of software for unauthorized access to the AppNana infrastructure. It is still simpler here, no software modification is needed, and API requests are not closed by the robots.txt file in any way.
I have withdrawn 90,000 nanas from an account with more than 1.5 million nanas. Then I sent a technical support letter asking me to cancel the transaction and return the funds to the user, or at least return the funds to the user if the transaction was already completed. The next morning I received a response from Max himself (the owner of the company) that he already knows (!) About the problem and it is being solved. Interestingly, this API has been operating since at least May 2013. In the application up to a million people. Advertising revenue should cover all costs and still be enough for one programmer who closes all the holes.
Fortunately, or unfortunately, this is the only application of the 20 that I installed from the Google Play top that contained a clear vulnerability. Almost half of the installed applications were built on one “engine”. Requests were like a carbon copy, well, respectively, they were protected by the session key and at the slightest intervention required re-authorization. A couple of applications could not load ads for display. Another, apparently, was not going to pay money, since the balance was kept in SharedPrefrences, and requests were sent only to get a list of advertisers.
For several years, AppNana (AppJoy) has been on the wave of popularity, because they provide an opportunity to download paid applications from the application stores for iOS and Android for free, without SMS. What is the catch, you ask? Where are the pitfalls hidden? Everything is very simple: you spend your time watching ads, installing left-handed, unsigned applications via direct links, and also share your personal information with half a dozen advertising aggregators for mobile phones, passing them all the information that AppNana has access to (including personal email).
Everything seems to be clear. Free cheese is only in a mousetrap, there is also a fee and it is not commensurate with the reward. To be precise, the minimum amount for “withdrawal” is 45,000 nanas (domestic currency, 45,000 nanas = $ 2), starting capital of 10,400, daily active users receive 400 nanas (if they were able to collect 4,000 nanas one way or another in the previous day) , one “task” is paid from 20 (most) to 450 nanas (while there was only one such task), while users receive the largest amount of nanas through referrals (2 500 nanas to the inviting and the invited).
Now it’s getting clearer. The application itself is used not for scanty bonuses for downloading anti-viruses for free without SMS, but for inviting everyone and everything. It turns out that all users (500,000 - 1,000,000 according to the Google Play metric) only do what they create several accounts and in turn send themselves invitations? Not so simple, Max Guan (a Chinese developer living in San Francisco) thought this through beforehand. In order to use the referral code, which will bring 2,500 nanas, you must first earn 15,000 nanas, which in itself is a feat.
Okay, let’s leave the “legal” ways of earning alone. Let's try from the other side. Install Fiddler2 and proxies for Android. We configure proxies for AppNana and look at requests. And they turn out to be very interesting. For example, this one:
POST to appnana2.mapiz.com/api/nanaer_login email = someone% 40example.com & password = 1234567890 & source = Android & android_id = abc
SUCCESS will be returned and you will be given a cookie with session ID. It seems everything is just right? But this script alone does not limit the number of requests. Brute Force provided. Unfortunately, if you check all the email and password combinations, the server will simply fall off. Although it turns out that it can fall off with a five hundred error if android_id is a space character ...
Let's try to solve the problem of email selection. To do this, we need the following query:
GET appnana2.mapiz.com/api/get_nanaer_info/?email=someone%40example.com
In response, you will receive a complete list with input_invitation (the number of referrals accepted) b paypal_email (AppNana gets it when withdrawing money to PayPal), redeem_times (how many times the reward was received), login_times (how many times the input was made), bitcoin_address (used to output to BitCoin), offer_nanas (the number of "earned" nanas), register_ip (IP used during registration), devices (contains a list of all the devices from which you were logged in, along with their mac addresses and ios identifiers), email (address used during registration), lastlogin_ip (last IP), nanas (account balance), sent_invitation (quantity invitations sent by “referrals”), gift_email (additional address for sending a gift code). And a couple of not relevant fields.
What we have? An API that issues all user data without authorization. How will he help us? It is enough to google AppNana hack and we will immediately get an almost complete list of people who are trying to collect as many nanos as possible through referrals. You can find blog entries with one and a half thousand comments, each containing a referral code and ... almost everyone is tied to a Google account, since the blog runs on Blogger. Our task is simplified at times: we parse the issuance of Google, we find all references to the referral code (one letter, then 8 digits), next we look for links to a Google profile or email for communication. In a couple of hours, such a parser will be able to create a high-quality dictionary for brute force attacks on the aforementioned script.
Now we have a database of hundreds or even thousands of users with the balance of their personal accounts. What can we do? All. Everything. You will say that this is impossible, but I have not yet revealed all the cards! Next, we need two more APIs:
POST to appnana2.mapiz.com/api/invite_verify
POST to appnana2.mapiz.com/api/redeem
First, it activates the referral code and charges 2,500 nanas to the account. Second, displays nanas in Bitcoin or PayPal. Both work without authorization.
First of all, you will create pairs of accounts that have more than 15,000 nanas in your account. Then we will take the referral codes linked to the accounts and cash them out for all accounts. When everything is ready, it can be assumed that with 1000 codes and associated accounts, you can get 999,000 valid links. Given that many actively use the codes of others to receive referral rewards, it can be assumed that 25% of the connections have already been used, this leaves with almost 750 new connections to the account. Each link brings 5,000 nanas to the system. By cashing out all the referral codes available to us (750,000 requests), we get 3.75 billion nanos distributed throughout the system.
If we take the most expensive reward (1,200,000 nanos for $ 100 PayPal), then we will generate $ 312,500 or if we prefer anonymity and are willing to not pay, then we can withdraw all the money in Bitcoins, which as a result will give us $ 267.857 in bitcoins for conversion day. This does not take into account already available user balances. All we have to do is use the Redeem API to transfer money to our PayPal account or Bitcoin wallet.
Of course, it is unlikely that a startup with one developer, who is also the head of those support (information from the LinkedIn profile), has a PayPal account or bitcoin wallet with $ 312,500, but if the whole process is automated and does not raise strong suspicions, you can easily withdraw a round sum .
Most interesting, this is not a direct violation of the public offer of the service. It contains clause 8a which prohibits the collection and storage of personal information of users, while its analysis, without subsequent storage is supposedly allowed, you can also ignore personal information, and save only the username, account balance and referral code. Clause 8k prohibits interference with the protection system, including disabling it, in this case there is no protection system as such, that is, using the API without authorization, I do not violate this point. Point 8r is the most extensive. It prohibits the use of automatic software to access the service bypassing their protection system and / or the robots.txt file (they don’t have either), and the modification and use of modified versions of software for unauthorized access to the AppNana infrastructure. It is still simpler here, no software modification is needed, and API requests are not closed by the robots.txt file in any way.
I have withdrawn 90,000 nanas from an account with more than 1.5 million nanas. Then I sent a technical support letter asking me to cancel the transaction and return the funds to the user, or at least return the funds to the user if the transaction was already completed. The next morning I received a response from Max himself (the owner of the company) that he already knows (!) About the problem and it is being solved. Interestingly, this API has been operating since at least May 2013. In the application up to a million people. Advertising revenue should cover all costs and still be enough for one programmer who closes all the holes.
Fortunately, or unfortunately, this is the only application of the 20 that I installed from the Google Play top that contained a clear vulnerability. Almost half of the installed applications were built on one “engine”. Requests were like a carbon copy, well, respectively, they were protected by the session key and at the slightest intervention required re-authorization. A couple of applications could not load ads for display. Another, apparently, was not going to pay money, since the balance was kept in SharedPrefrences, and requests were sent only to get a list of advertisers.