Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rock appround the clock

4,672 views

Published on

<br />
<iframe allowfullscreen="" frameborder="0" height="714" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/key/IDtEqlnsCuqyLb" style="border-width: 1px; border: 1px solid #ccc; margin-bottom: 5px; max-width: 100%;" width="668"> </iframe> <br />
<div style="margin-bottom: 5px;">
<b> <a href="https://www.slideshare.net/elevenpaths/emule-siempre-una-fuente-de-archivos-maliciosos" target="_blank" title="eMule: ¿siempre una fuente de archivos maliciosos?">eMule: ¿siempre una fuente de archivos maliciosos?</a> </b> from <b><a href="https://www.slideshare.net/elevenpaths" target="_blank">ElevenPaths</a></b> </div>

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Rock appround the clock

  1. 1. 1 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Rock appround the clock Tracking malware developers by Android “AAPT” time zone disclosure bug… and other hour-related tricks Sergio De Los Santos / Sheila A. Berta labs@11paths.com
  2. 2. 2 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Table of contents INTRODUCTION.............................................................................................................................................2 AAPT TIME ZONE DISCLOSURE BUG .............................................................................................................3 Analyzing source code ..............................................................................................................................3 Analysis in runtime....................................................................................................................................5 Why this GMT offset? ...............................................................................................................................6 Offsets Table ...........................................................................................................................................10 GMTZONE CERTIFICATE CALCULATION ......................................................................................................10 The files inside the ZIP files.....................................................................................................................10 Signed files and certificates ....................................................................................................................11 Putting it all together..............................................................................................................................12 The tool that makes it all for you............................................................................................................13 ANALYZING APK’s WITH BOTH TECHNIQUES..............................................................................................13 TIME ZONE LEAKAGE AND MALWARE........................................................................................................14 Is there any relation with malware?.......................................................................................................14 FROM TIME ZONE TO COUNTRY.................................................................................................................18 Analyzing text strings..............................................................................................................................18 Metadata, metadata, metadata .............................................................................................................20 CONCLUSIONS AND FUTURE WORK ...........................................................................................................22 INTRODUCTION In the world of Threat Intelligence, determining the attacker’s geographical location of is one of the most valuable data for attribution techniques, even if not perceived like that, this information may lead a research one way or another. One of the most wanted information is where the author comes from, where he lives in or where the computer was located at the time of an attack. We focused our research in taking advantage of this kind of “time zone” bugs for tracking Android malware developers. We will describe two very effective ways to find out the developer's time zone: the first one is related to a bug inside the Android-SDK's packager (aapt), that relies in not properly setting the value of a variable used as an argument for localtime() function, when setting the "Last Modified" field for the APK's files; the second one is based on a calculation of times extracting the GMT timestamp from the APK files and the UTC timestamp of the disposable certificate added to the application. We will detail these techniques in this document, aside some other complementary methods that will allow us to adjust even more the information obtained so we can be more accurate about the country
  3. 3. 3 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. where the app was probably created. We have calculated if these circumstances has some real relation with malware, diving in our 10 million APKs database. AAPT TIME ZONE DISCLOSURE BUG The Android app development kit (SDK for Android) comes with a tool called “aapt”. This program packs the files that are going to compose the application and generates an .apk file which basically corresponds to a zip format. If the aapt tool is used directly by command line or maybe via a developing plugin outside Android Studio, the files composing the APK will be generated with a date following this format: 1980-01-01 <offset_GMT>:00:00. Where <offset_GMT> represents the time zone corresponding to the operative system configuration time zone where the app is being packed. The figure represents a simple .apk generated by command line with aapt in a computer with time zone configured to GMT +3. Offset GMT in the modified time field As observed, the modification time of the files is 01-01-80 and “03”, which corresponds to GMT +3. We observed this issue with different real apps and time zones. Analyzing source code How is this possible? Source code of the aapt tool is available here: https://android.googlesource.com/platform/frameworks/base.git/+/master/tools/aapt. We have analyzed it and found some problems in the function that sets the modification date for files in the .apk file. In particular, a variable not properly set causes this “leakage” about the operative system it has been packaged in. During the process where aapt adds a new file to an .APK, (ZipFile.cpp – line 358), you may observe in line 500 a call to “setModWhen”, using variable “modWhen” as an argument.
  4. 4. 4 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Calling setModWhen in aapt source code But when going back in the code, there is no part in the code where “modWhen” gets an useful value. It just keeps its “0” value, initially set in line 367 in the same file (ZipFile.cpp – line 367): Setting modWhen in aapt code Function setModWhen will then be called (always) like: pEntry->setModWhen(0); Inside this function (ZipEntry.cpp – line 340), the modWhen variable (from now on referenced as “when”) is used in line 351 as part of this operation: even = (time_t)(((unsigned long)(when) + 1) & (~1)); Which will be called like this, taking into account “modWhen” value: even = (time_t)(((unsigned long)(0) + 1) & (~1)); The result is (obviously) “0”. This value will be stored in the variable “even” that will be later on used as an argument for “localtime” function. This function allows to create the structure for “tm * ptm” date and will be used to set date an hour for the modified field in the files added to the .APK itself.
  5. 5. 5 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. setModWhen function inside aapt source code. Because of the timestamp (“even” variable) used as an argument for localtime is not valid, the date generated for the files is not the real one, but 0. There is a correction for the years (it is set to 80 if lower) and it finally gets the format already described: “01-01-80 <offset_GMT>:00:00”. Analysis in runtime When debugging aapt we may alter variable even value in runtime and experiment with the results. Next figure shows how “even” is set to 0, just before localtime function receives it as an argument. Variable “even” in runtime If we going on executing the process without altering it, we get the “usual” aapt result, where files will come with “modification time” impacted by the operative system offset time zone. GMT +3 in the example.
  6. 6. 6 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Results of aapt without altering values in execution However, if in runtime we alter the “even” value, setting it with the current timestamp (that means, the right value that localtime function would expect)… Modifying “even” variable in execution time, setting the right timestamp Result would be the expected: aapt’s result as expected. Why this GMT offset? To figure out why this time zone offset is added, we check the aapt source code again and try to recreate the part where the value is wrongly configured.
  7. 7. 7 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. This is the code in aapt that leaks the time zone If this part is extracted, compiled and run in a computer configured with GMT+3 time zone, for example, we get: Function result. As we can see: “tm_hour = 3”, which corresponds to the time zone in the computer itself again. When debugging this simple code, we may detect the one that adds this time zone. We set a breakpoint before calling localtime. The instruction where the program stops moves the EAX value to the ESP (Stack Pointer). Just before calling localtime function. The value pointed by Stack Pointer in that moment, is 0, as defined in the source code.
  8. 8. 8 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Argument for localtime function The program goes on and localtime is called. When returning, this function leaves a value in EAX registry that represents a pointer to the beginning of the structure which is the result of all the operation. Memory address in EAX where the result returned by localtime starts. The code goes on, and now it splits the data (day, month, year, hours, minutes and seconds) so they can be used separately (in this case printed separately in the screen). Every one of those variables allocates 4 bytes in memory, although only one is used. Thus, the program calculates the position in memory where it expects to find the data is about to use, and takes the corresponding 4 bytes from there. The order in which localtime returns the result is: seconds, minutes, hours, day, month, and year. That is, for example, in the first position (0x006A0E10) you may find 4 bytes for the seconds, and in the last one, (0x006A0E24) we can find another 4 bytes for the year. Result from localtime function as in memory Following the colors in the figure, the information returned goes like this: 01-00-70 03:00:00 So definitely, localtime function is the one returning this offset (in this case: +3), taking it from the operative system. Aapt will later round up the numbers to 01-01-80 because this is the “Epoch” for PKZip standard. The reason may be that localtime times to adapt every date to your own time zone where the computer is supposed to be located. Honoring the documentation of the localtime function, this should not happen because it is specified that if this function gets a null or “0” value as an argument, return value should be null. So, when is localtime getting the GMT offset and returning it? When checking Microsoft documentation about this function, we notice something interesting:
  9. 9. 9 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. localtime official Windows documentation. For Windows System, if TZ variable (time zone) is not set in the application itself, localtime function will try to extract time zone information from the system itself and the function will go for this data when receiving a (real or not) argument value. An invalid timestamp like “null” or “0”, will just be taken as a “0” hour and the returned value will contain the GMT offset, that ends up cleanly added to the place where the hours should be. In UNIX/Linux this particularity exists as well. If a developer uses aapt by command line, the GMT offset for his/her time zone will be “added” to the modifying time for the files inside the APK. Focusing in aapt source code, setModWhen function uses localtime_r instead of localtime (code is the same, but depends on the system where it is run), but the argument passed to it is still “even” variable (with a value of 0). This function is basically the same as in Windows, but there is no TZ variable to decide: it will always add the time zone set in the operative system. If tested with a simple program in Linux, this is confirmed: Localtime_r is able to get the time zone even with a null argument. Result of the PoC in Linux. What to conclude then? localtime is not handling errors as it should. When receiving a 0 or null argument, it should return null, not 0 plus whatever your GMT (TZ for Windows) is, added to this value. On the other hand, aapt makes a mistake using 0 as a “constant” argument for feeding this function. It should use current timestamp instead. In this current scenario whatever developer using aapt will still leak his time zone when packing Android app’s.
  10. 10. 10 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Offsets Table The GMT value (developer time zone) depends on the value returned by localtime or localtime_r. But some correspondences are not trivial. This is how the values returned by aapt and a real GMT value correspond each other. 1980-01-01 00:00:00 = GMT +0 1980-12-31 12:00:00 = GMT +12/-12 1980-01-01 01:00:00 = GMT +1 1980-12-31 13:00:00 = GMT -11 1980-01-01 02:00:00 = GMT +2 1980-12-31 14:00:00 = GMT -10 1980-01-01 03:00:00 = GMT +3 1980-12-31 15:00:00 = GMT -9 1980-01-01 04:00:00 = GMT +4 1980-12-31 16:00:00 = GMT -8 1980-01-01 05:00:00 = GMT +5 1980-12-31 17:00:00 = GMT -7 1980-01-01 06:00:00 = GMT +6 1980-12-31 18:00:00 = GMT -6 1980-01-01 07:00:00 = GMT +7 1980-12-31 19:00:00 = GMT -5 1980-01-01 08:00:00 = GMT +8 1980-12-31 20:00:00 = GMT -4 1980-01-01 09:00:00 = GMT +9 1980-12-31 21:00:00 = GMT -3 1980-01-01 10:00:00 = GMT +10 1980-12-31 22:00:00 = GMT -2 1980-01-01 11:00:00 = GMT +11 1980-12-31 23:00:00 = GMT -1 GMTZONE CERTIFICATE CALCULATION As said, .APK (and jar, for this particular technique) follow the PKZIP standard. That is, they are .zip files for what is worth and share most of the PKZIP specifications. In the case the APK is built not directly using aapt, there will not be a chance to know the creator time zone and all the “modification time” fields for the files inside the zip should be the “right ones”. However (a few years ago), we have found another factor that will allow us to know the time zone where the developer compiled the application, just as interesting as the one mentioned and as a complementary method. The method is about calculating the difference between the right timestamp of the files and the timestamp of the certificate inside the APK to sign it (this date is stored in UTC, so we have references enough to calculate the time zone). The files inside the ZIP files APKs and applets (Java programs) are all the same format: a variation of a zip file and when you zip a file, the "modification time" attribute of each file is stored inside the zip file. The interesting part is that the time they store is just the hour and date of the local system they are compiled in. There are also (of course) files created just when the file is compiled with the system time associated (like manifest.mf, and cert.sf). So, all in all, the system time of the creator is stored in files like the manifest (.mf), and some other. But, no GMT "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?
  11. 11. 11 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Modification time in files inside an APK. Signed files and certificates Every single .APK must be signed, and so some applets (so they can escape from the Java sandbox and attack users). Android apps are always signed, because Google 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 (and actually most of them are). This is free and attackers do not have to prove to anyone who they are. Certificate data. Attackers do not like CA signed certificates, but they love self-signed certificates because they can be disposable and… free. They can create an ad-hoc self-signed certificate for an app and never use it again. For example, Android Studio and other platforms helps you creating an ad-hoc certificate when compiling an APK file, as a last step to sign the app and upload it to, for instance, Google Play. Certificates store the date when they were created in a field. And here is the trick. They store it in UTC standard (for what is worth, same as GMT), no matter what the system time is. Here is a certificate creation time and date in UTC standard in "YYMMDDHHMMSSZ" format. Last Z corresponds to "zulu time" which is UTC or, as mentioned, GMT+0 time zone.
  12. 12. 12 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. View of a certificate date. As a curious thing, if the certificate contains a date further than 2049, they use generalized time format, which is basically the same but with four-digit year: YYYYMMDDHHMMSSZ. Putting it all together So, we have the system time of the creator (taken from the “modification time”), and the GMT+0 time (taken from the UTC standard from the certificate). 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. For instance, if a manifest or signature file is created at system time 16:00, Jan 1st 2018, and certificate UTC time is 15:00, Jan 1st 2018, assuming they were created at the exact same moment... we can say (unless the attacker changed its system time) that the attacker comes from GMT+1 time zone. UTC Time - ZIPs file gets the offset and thus, time zone (map from timeanddate.com).
  13. 13. 13 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. The tool that makes it all for you We have created a tool that calculates this for you. Just reads an .apk or signed jar applet and: - 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. In the example above, the diff between UTC in certificate and latest file modification time is +3 which correspond to GMT+3 time zone. As an interesting data, you may notice that they used email for the certificate, comes from gdf.er domain, which is Eritrea, a country which official time zone is GMT+3. ANALYZING APK’s WITH BOTH TECHNIQUES How many .APK’s do contain this time zone leakage in either one or another way? We have checked against more than 10.000.000 APKs in our Tacyt database. This database collects Android apps from different markets and makes it possible to search for nearly any imaginable attribute. In this case, Tacyt is able to check for “oldestDateFile” which will allow us to know about the first described leakage technique, and “gmtInfo” which is the internal implementation of the gmtcheck program we have previously described. So, this are the numbers over ~10M apps analyzed: 1980-01-01 00:00:00 = GMT+0 (Timestamps leak) = Both techniques = 61056 1980-12-31 12:00:00 = GMT+12/-12 (Timestamps leak) = Both techniques = 6 31708 1783 3082 3 1980-01-01 01:00:00 = GMT+1 (Timestamps leak) = Both techniques = 23479 1980-12-31 13:00:00 = GMT-11 (Timestamps leak) = Both techniques = 2 43189 293 914 0 1980-01-01 02:00:00 = GMT+2 (Timestamps leak) = Both techniques = 10640 1980-12-31 14:00:00 = GMT-10 (Timestamps leak) = Both techniques = 10 51002 588 421 0 1980-01-01 03:00:00 = GMT+3 (Timestamps leak) = Both techniques = 9219 1980-12-31 15:00:00 = GMT-9 (Timestamps leak) = Both techniques = 21 33358 276 412 0 1980-01-01 04:00:00 = 1228 1980-12-31 16:00:00 = 5298
  14. 14. 14 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. GMT+4 (Timestamps leak) = Both techniques = 11408 GMT-8 (Timestamps leak) = Both techniques = 15528 56 156 1980-01-01 05:00:00 = GMT+5 (Timestamps leak) = Both techniques = 10216 1980-12-31 17:00:00 = GMT-7 (Timestamps leak) = Both techniques = 647 16812 33882 690 102 1980-01-01 06:00:00 = GMT+6 (Timestamps leak) = Both techniques = 3238 1980-12-31 18:00:00 = GMT-6 (Timestamps leak) = Both techniques = 1884 10708 13932 796 30 1980-01-01 07:00:00 = GMT+7 (Timestamps leak) = Both techniques = 18479 1980-12-31 19:00:00 = GMT-5 (Timestamps leak) = Both techniques = 5930 62863 17470 2969 382 1980-01-01 08:00:00 = GMT+8 (Timestamps leak) = Both techniques = 11944 1980-12-31 20:00:00 = GMT-4 (Timestamps leak) = Both techniques = 391 24491 18657 439 42 1980-01-01 09:00:00 = GMT+9 (Timestamps leak) = Both techniques = 9226 1980-12-31 21:00:00 = GMT-3 (Timestamps leak) = Both techniques = 2953 51365 12437 204 141 1980-01-01 10:00:00 = GMT+10 (Timestamps leak) = Both techniques = 532 1980-12-31 22:00:00 = GMT-2 (Timestamps leak) = Both techniques = 2375 19808 4569 8 87 1980-01-01 11:00:00 = GMT+11 (Timestamps leak) = Both techniques = 276 1980-12-31 23:00:00 = GMT-1 (Timestamps leak) = Both techniques = 72 293 1439 0 0 As noticed, some of the time zones are not so common. For example we were able to find just 6 apps with UTC-11 (1980-12-31 13:00:00) which correspond to America Soma in the middle of the Pacific. This is a total of 179.122 apks with the time zone disclosure aapt bug and 477.849 apps with disposable certificates. Many of them have both which is some way means these techniques are consistent. TIME ZONE LEAKAGE AND MALWARE Is there any relation with malware? So, we have extracted some files from those sets and check them as a hash against multiple antivirus systems, as a way to (more or less) make a relation between:  Malware/adware creators and the way APKs are compiled (using aapt in command line).  Malware/adware creators and the way ad-hoc and disposable certificates are created. For this experiment, we have taken 1000 files (unless stated otherwise) from the ones with the leakage in every flavor, and then combine them all. AAPT disclosure bug:
  15. 15. 15 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Columns in green are not representative becouse of too few samples. Certificate disposable disclosure:
  16. 16. 16 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. So we can conclude that, basically, GMT+4, GMT+5, GMT+8, GMT-6 and GMT-7 are the time zones producing more malware. Why this little difference between techniques? For example, with the first aapt bug, predominant time zones producing malware are: GMT+4, GMT+8 and GMT-7. With the certificate technique, GMT+5, GMT+8 and GMT-6 are the ones producing more malware. These GMTs correspond to some parts of Russia, China, and United States West Coast. We think that this difference is because of the Daylight Saving Time. These techniques are tied to DST so some countries may use +-1 hour difference depending of the season. China does not use DST (and Russia either since a few years ago). To have another view, we did it the other way around. We took all the samples detected as malware that had this leakage with the aapt bug, and checked its time zone:
  17. 17. 17 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. So we did with the certificate bug: But, to be sure about how malware is related with these characteristics, we have to clarify:
  18. 18. 18 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018.  Because of false positives, we cannot really trust that APKs detected by less than 3 engines are really malware. This is a tricky matter, but our experience with this kind of detections (Hack in the box conference, 2015), the different sensitiveness with adware by some AV vendors, and some other circumstances, recommend to use more than three engines to statically detect an .APK to really be considered malware or, at least, “more than adware”. So, once we have presented different granularities that may give us a hint about how many engines detect some of the applications, we will discard detections lower than 3 engines.  We have to consider our own database characteristics. We have more than 10 million hashes but, to be really accurate, we have to know which is the “ground truth” about detections. To achieve this, we have taken two different sets of 1000 different samples that do not have any of these characteristics. We have checked results against multiple antivirus systems and these are the results. 1000 APKs sample w/o any of the characteristics described 1 AV 2 AV 3 AV +3 AV Set 1 130 26 13 58 Set 2 85 24 11 59 What we can conclude from this information is that our database contains about a 6% of malware in any set without these characteristics we may find. So, we will use this as a “correction factor” to compare. So, finally, these are the relevant numbers we find: FROM TIME ZONE TO COUNTRY Using some of the techniques explained earlier, we may have determined the time zone where the developer lives or where the computer is configured and the Android app has been compiled. However, there are some time zones that hold lots of different countries from North to South, so… How to shrink the circle to some country or region? We explain here two maybe useful ways, developed by us, to get this information in an easy way. Analyzing text strings Of course, a way to differentiate between countries in a same time zone or countries in general is because of the language used by their population. We may find lots of strings in an Android application… activities, internal use strings, urls, constants, variables, etc… and, which is more interesting, comments
  19. 19. 19 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. made by the same person that wrote the code itself. This is the case where the mother language of the person may be revealed while the code around the app may be written using English or other nominative standards. If we are able to extract comments or texts that we know the developer himself has written, we have more chances to be sure about his original country. Android Studio, just like any other IDE adds lots of components automatically, like translation for several languages for the app to cleanly adapt to the “device language”. So, searching for this kind of strings may just add confusion. This is an example of the output when executing: ./aapt d --values strings app.APK Extracting all strings from an Android app. It does not matter how simple the app is, there are a lot of languages “hidden” in there. So, the only interesting strings for our stand point are the ones written “personally” by the developer himself, not the ones added by the IDE. We can differentiate them verifying the resource they belong to. To achieve that, we extract all the resources, and we will use a regular expression to filter text strings. All the strings automatically generated by Android Studio are in specific components created by the IDE itself, while the text strings written by the developer are found in other files, not associated to a specific component. For example, let us see the output when executing ./aapt dump --values resources app.APK | grep '^ *resource.*:string/' --after-context=1 > output.txt
  20. 20. 20 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. Extracting all the resources of an Android application, filtering by text strings. The strings in a red box are automatically generated by Android Studio, while in green, we can distinguish the ones written by the developer. It is not that difficult to tell them apart because of the resources they belong to. In this case, all the strings are in Spanish so we can determine the exact country where the developer comes from, aside another hints like the time zone we have discussed before and that may be shared between several countries. Aside, we may consider that the mother language of the person behind the application code (revealed by this script, for example) may be different from where the app itself has been compiled and the time zone the computer where the app is compiled is configured with. Metadata, metadata, metadata Most of the Android applications contain multimedia files like images, videos, sounds or documents. It is interesting to notice that IDEs (even Android Studio) do NOT remove metadata in the files added by the developer. If extracted and analyzed, we may find some useful information not only related with the place where the developer lives but even the software used during the creation of the app. RTF files contain information not only about the author, but the configuration of the software used to create the RTF itself. Moreover, if created with Word, we may find which is the default language of the Office installation where the document was created, which may give us a more accurate idea about the person behind the .APK.
  21. 21. 21 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. For example, in Korean malware, all the files, no matter the language they are written in, uses English, Korean and Arabic as metadata "Language" for RTF files:  Arabic is present if you have a specific version of Word (deflangfe is the keyword for "Default language ID for Asian versions of Word".) It does not mean this language is configured as predetermined in Word for corrections. It means you use a specific kind of EMEA version of Word, very common. You can tell if your RTF files have adeflang1025 in them.  Korean is the language in deflang which defines the default language used in the document used with a plain control word. That means, he has Korean and English as default "usual" languages in Word  English is present because of how Word works. If you set your Word with Korean as default language, it will always be set with English as well. Seems like a Word feature. This is the typical raw data "inside" the RTF. rtf1adeflang1025ansiansicpg1252uc2adeff31507deff0stshfdbch3150 5stshfloch31506stshfhich31506stshfbi0deflang1033deflangfe1042 So it means the creator of this RTF uses some kind of EMEA version of Word (very common) and Korean is the default language for typing in Word. And this could go on and on with certificates information, software versions and so many other interesting metadata hidden in the .apk. Because, unless the creator takes the time to remove all this information from the files themselves before compiling the app, the IDE will not handle that. We implemented a tool that will be coming soon, to show all this information.
  22. 22. 22 Rock appround the clock Innovation and laboratory. Presented at DEFCON26, August 2018. CONCLUSIONS AND FUTURE WORK We have presented two techniques to leakage time zone from an app. One of them, related to an aapt bug, does not only shows a bug in the way dates are handled, but a possible problem of a system function (localtime) not honoring the specifications. This may affect other programs in some other ways. By studying these techniques, we have a new way of possibly detecting automated malware creation by analyzing when and how certificates are created to sign these apps. Aside of the statistics about where the malware comes from analyzing its time zones, this may be used as an important feature in machine learning systems to early detect Android malware. Aside, we have shown some tools and tricks for a quick view of all this useful information around APKs metadata. Future work should be more accurate about DST, taking the season into account to classify malware, and maybe using more samples to get better conclusions.

×