02/10/14. Version 0.1
Millions of malicious applets (.jar files) and apps exist out there. Where do they come from? From which country? At least, from what time zone? It can be useful to know whether they come from Russia, Brazil, China, India, or the US. Let’s see how.
APKs (Android apps) and applets (and Java programs) all come in the same format: a ZIP file. This means that they share a good portion of the PKzip specifications. When a ZIP file is created, the “date” attribute of each file is stored inside the ZIP file. This can be checked simply opening a ZIP file with any tool.
The way in which this datum is stored is interesting. The interesting part is that the “date and time” attribute with which they are stored is the same as the one of the system in which they have been compiled. Also, that there are files created just when the program is compiled, such as the (.mf) manifesto. But no “offset” is given at that time, so that this datum in itself does not reveal which country the apk or jar file is in. A file inside the ZIP file created at 11:45 p.m. does not mean anything in itself. 11:45 p.m. in which country?
Files signed and certified
Some applets are signed so that they can escape the Java sandbox and attack users. APKs are always signed because Google Play and Android say that it must be so. When they are signed, a certificate is added inside the ZIP files. This certificate is in the PKCS structure, which is a file with (among others), the RSA or DSA extension, in the META-INF directory. Certificates may be self-signed. This is free and attackers do not have to demonstrate to anyone who they really are.
Attackers and certificates
Attackers hate certificates signed by CAs, but love self-signed certificates. They are free and disposable. They can create an ad-hoc self-signed certificate for an app and never use it again. For instance, Eclipse helps in this task of creating ad-hoc certificates when the time comes to compile APK files, as a last step before sending it to Google Play.
Certificates are stored within the APK files when they are created. And here is the trick: They are stored in UTC. In the YYMMDDHHMMSSZ format. The Z corresponds to “Zulu hour”, which is UTC or, for practical purposes, almost identical to GMT+0.
Bringing it all together
So, on one hand, we have the system date from the creator and, on the other, the hour GMT+0. We only need to assume that the certificates and files are created just at the same time to make our calculation of the “offset” of the time zone.
If a manifest or signature file (which are the last created in the compilation of a JAR or APK file) contains the system date 4:00 p.m. on 1 January 2014, if we assume they were created at the same time, we could say (unless the attacker has modified his or her system time) that the attacker resides in the GMT+1 time zone.
We have created a tool that makes the calculation. It reads a JAR or APK file and, if it is signed:
- Attempts to extract the UTC file from a certificate.
- Attempts to read the time of the last file created in the compilation (normally the .sf file in the META-INF directory).
- It will make calculations and state in which zone the developer lives, assuming that the creation of the certificate and the compilation have occurred at the same moment (give or take one minute).