There are millions of malicious applets (JAR files) and Android apps (APK files) out there. Have you ever wondered where do they come from? Which country? At least, which is its time zone? In forensics, it may be interesting to check if this malicious app is made in Russia, Brazil, China, India or United States. Let’s see how.
The files inside the ZIP files
APK (Android apps) and applets (Java programs) are all the same format: a variation of a zip file. This means they share most of the PKzip specifications. When you zip a file, the “modification time” attribute of each file is stored inside the zip file. If you want to check, just open a zip file with any unzip tool.
The way zip files store files’ time is quite funny, and we will talk about it in some other post. The interesting part is that the time they store is the hour and date of the system they are compiled in. There are also files created just when the file is compiled with the system time associated. So, the system time of the creator is stored in files like the manifest (.mf), and some other. But, no “offset” is given with it. So, with this data by itself, we can’t tell which is the APK or JAR creator’s time zone. A file inside the zip modified or created at 23:45, means nothing by itself. 23:45 in which country?
 |
| Modification time in files inside an APK |
Signed files and certificates
Some applets are signed, so they can escape from the Java sandbox and attack users. APK files are always signed, because Goolge Play and Android says they have to. When they are signed, a certificate is added inside zip files. This certificate is a PKCS structure in the META-INF folder. Inside there’s a RSA or DSA file (between others). Certificates may be self-signed. This is free and attackers do not have to prove to anyone who they are.
Attackers and certificates
 |
| Certificate date… “Valid from…” |
Attackers hate CA signed certificates, but they love (and they have to use) self signed certificates. Because the can be disposal. They can create a self-signed certificate ad-hoc for an app and never use it again. For example, Eclipse and other platforms helps you creating an ad-hoc certificate when compiling an APK file, as a last step to upload it to Google Play.
Certificates store the date when they were creatd in a field. And here is the trick. They store it in UTC time, no matter what the system time is. Here is a certificate’s creation time and date in UTC time in “YYMMDDHHMMSSZ” format. Last Z corresponds to “zulu time” which is UTC or, practically, GMT+0 time zone.
 |
| ASN.1 view of a certificate date |
As a funny thing, if the certificate contains a date further than 2049, they use generalized time format, which is the basically the same but with four digit year: YYYYMMDDHHMMSSZ.
Putting it all toghether
So we have the system time of the creator, and the GMT+0 time. We just have to assume files and certificate were created almost at the same time to make the math and calculate the time zone offset.
If a manifest or signature file is created at system time 16:00, Jan 1st 2014, and certificate UTC time is 15:00, Jan 1st 2014, assuming they were created at the exact same moment… we can say (unless the attacker changed its system time) that the attacker lives in GMT+1.
|
| UTC Time – ZIPs file… gets the offset and thus, time zone (map from timeanddate.com) |
The tool that makes it all for you
We have created a tool that calculates this for you. Just reads a .jar file (apk or applet) and, if signed:
* Will try to extract UTC time from the certificate.
* Will try to read the modification time of the last file created (usually signature file under META-INF folder).
* Will do the math and tell you which time zone the developer lives in, assuming certificate creation and compilation have been done at the very same moment.
Here are some examples:
 |
| A fraudulent app from Spain |
 |
| Malware from U.S.A |
 |
| Fake app from Hong Kong |
 |
| This APK is a fake of an Indian app, Teen Patti poker |
The tool is available in Python and a compiled C# .NET version. They both may be downloaded from http://elevenpaths.com/downloads/gmtcheck.zip
We encourage you to use it.
Sergio de los Santos
ssantos@11paths.com
