About how VKontakte collects information about us. Part 2

[DronVR]

About how VKontakte collects information about us. Part 2
(c) Vladislav Veljuga

Update 2
And let's go right away, that's what Andrei Rogozov answered (somewhere) about this information.

My article on collecting information about users of the official VKontakte application for Android has already gone too far on the Internet. I noticed that not so few people do not care about the confidentiality of their data and took the material quite "warmly".

Discussions in the comments under my post in VK also turned out to be quite interesting. The former developer of this application came there. Grigory Klyushnikov and the developer of its modification Eduard Bezmenov . Both of them told a lot of interesting things. Well, I also became interested in what else I could not encrypt on a real device and what exactly they were talking about.

Our tools for today
There is an installation APK-file of the application version 4.12.1. There are its sources (code) obtained by decompiling the application (roughly speaking, the installation file was parsed and the code in the program language was recreated from it, in our case, Java). Decompiler - Jadx .

Small educational program
In a Java project (and the Android application is such), all code is divided into classes; classes are grouped into folders - packages (package, package), the package may be in another package. Each application can have an unlimited number of packages that can "communicate", interact with each other.
​

By decompiling the application, we see the following

com.my.tracker - the same MailRu tracker that Edward and Gregory spoke about; com.my.target - package associated with the tracker; com.vkontakte.android - the application itself and ru.mail.libverify - another package from MailRu

Decompiled code will be more difficult, since not all variables and classes will be named by names that will be understandable to humans. Basically, these names are somewhat reminiscent of a hexadecimal number, for example, C1998a.java. I have one more assumption that the code could be specially obfuscated ( obfuscate - make non-obvious, confusing, confusing). But some "clues" remain, by which you can understand what kind of code it is, what it is responsible for and what exactly it does.

results
I will not torment, right to the point.

com.my.tracker
Let's start our journey with a class file com.my.tracker.builders.C1998a ..

On the left is the code, on the right is the previous article and the screen of Andrey, about which he said that the application merges Wi-Fi access points.

Now we follow the train of thought: in line 298 (just above the line with "around", litter, truncated the numbers in the screen), the variable c2002d2 is declared with the type C2022d obtained from the iterator (roughly speaking, collection / array / list). Class C2022d defined in package com.my.tracker.providers in the class C2023d . The definition is not interesting to us, because it does not contain human-readable field names. In the same class there is a declaration of this class and filling this class with data.

Gather information about the current access point.

Here, by the log after declaring and filling the class instance with values, we understand that C2022d - This is a class (and to be more correct, a structure) that stores data about a Wi-Fi access point. A little lower data is collected about all the surrounding points.

In the loop, the scan result is scanned (160), the class C2022d = Wi-Fi AP information (175-178) is created and populated and added to the list (179).

And even lower, we see how they are trying to collect data about CID and LAC.

<wikipedia>
Cell ID, CID - “cell identifier”. This parameter is assigned by the operator to each sector of each base station and serves to identify it.
LAC, Local Area Code - code of the local zone. A local zone is a collection of base stations that are served by a single BSC - a base station controller.
Base station - a set of equipment of one operator installed on one site (tower, building) and intended for direct communication of the network with mobile terminals of subscribers
</wikipedia>​

Coarse location - approximate location

Going back to C1998a.java ...

Also interesting ... apps (applications), first_install_time (time of first installation) ...

... Does it also send a list of installed applications? C2015a - another structure in com.my.tracker.providers.C2016b . Definition is not interested, use right there ...

Getting the list of applications (84), creating your own list of applications with your own structures (88), traversing the entire list with a loop (90), getting information about one application (91), if it is not system-wide ([DLMURL="http: // anonym. to? https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#FLAG_SYSTEM "] proof [/ DLMURL]), it is added to the list.

Back to again C1998a.java .

Here, from somewhere, lists of email addresses, classmates ID, VK, ICQ (lol), and other IDs are going ...

... sim_loc (?), ID and name of the operator, information about the connection and its type (Wi-Fi / mobile connection), BlueTooth inclusion ...

..., information about the device, the name and version of the OS on the device, manufacturer, device MAC address, language, time zone, ... and a couple of little things.

And so we gathered it all ... And why? In the class com.my.tracker.async.commands.C1990f it is all sent.

73 - an instance of the collector is created, which collected everything that we looked above. 83 - (without a screen, believe me a word) a JSON string is generated with all the data, 85 - the data is sent ...

Method m1919a ... where is he? He is in the genitive class C1988c

Roughly speaking - a request is made on the Internet here at the address ... specified in the constructor of the C1988c class, but it was not created above!

Deeply rummaging through the search for the entire project (by field name f1295b , by inherited classes), came to a method C2013a.m2085a ..

And here is the address where the information was sent
That's enough with MyTracker ...

ru.mail.libverify
en.mail.ibverify.requests.C4109e

Class C4109e, at the very beginning of the line containing the mail.ru domain, where requests will be made.

Right in the same class (see Sublime heading), the C4109e contains data on IMEI, IMSI, phone, operator, latitude / longitude, and location accuracy.

In C4109e: the mo8472d method selects a host from f2386b (through one screen above) where to send data

In C4109e: in the m3158u method, the full URL for the request is generated using the mo8472d method, which is described above.

That's all for now.

Summary
The VKontakte Android application, in addition to its metrics and telemetries, sends the same, and even more, data volume for third parties: MyTracker and MailRu LibVerify.
In C4109e: in the m3158u method, the full URL for the request is generated using the mo8472d method, which is described above.