- First of a series
First of a series
This day way actually the first of a series of themed regional events for the BCS Cybercrime Forensics SIG. The four conferences were interesting but I really enjoyed the last one. I love seeing code snippets in a talk! There were some technical demonstrations which was a good thing too. I went to visit Cambridge at the end of the day. By the way the legend is true; it is a beautiful place! But enough chit chat, let is dive into the real content of this day.
eMMC Flash Memory Forensics
The day began with a talk untitled eMMC Flash Memory Forensics given by Kevin Mansell. He gave a small overview on the field of forensics by giving a smart comparison between computer forensics and mobile forensics. Indeed according to his opinion, computer forensics are easier than mobile forensics, especially thanks to standards and forensics of disk storage. As a matter of fact, with computer forensics, it is possible to remove the hard drive thanks to standard interfaces. There is no such thing for mobile fun. However, mobile forensics is growing massively.
The talk then dealt about what was really an eMMC (Embedded Multi-Media Card). To put it in a nusthell, it is a chip and is used in a plenty of devices like mobile phones, handled computers, navigational systems and of course for other industrial uses. A lot of manufacturers (like Samsung or SanDisk) are producing eMMC flash memories. There is a also a difference between an eMMC and eMCP; the first one is a flash memory and the second one is also a flash memory but contains a RAM too.
There are four different acquisition options:
- Logical extraction: naive
- Bootloader (physical)
- JTAG (physical): more agressive
- Direct eMMC (physical)
- Chip off (physical)
Finally, the speaker gave some tools he was using for his work:
A great post for capturing RAM dumps and imaging eMMC storage on Windows tablets is available here.
Malicious Web Backdoors and Script Injections in the Payment Card Industry
The second talk, given by Benn Morris and Andrew Bassi both from Pen Test Partners, was about “classical” web vulnerabilities. They well illustrated the 0-day in Magmi database client. They presented quickly a PoC in Python called
Then they gave some other examples of their daily work, pointing the fact that most of time, there was no sanitizing for uploads. For instance, without checking user’s upload, an attacker might upload a shell that can give access to the content of the webserver and possibly upload corrupted PHP commands. Furthermore, there are no specific logs as the web shell access is the only artifact recorded. They talked about the famous C99 shell and showed how to hide a
.php file inside a
They concluded by giving some examples of “classical” vulnerabilities like SQL injections, the problematic of storing (weak) passwords in clear and showed quickly what was the purpose of the password recovery tool Hashcat in a penetration testing’s context.
Peer to Peer (P2P) Botnets - Technology and Takedowns
After a lunch break, the next talk, by Stewart Garrick, was about the Shadowserver Foundation. I knew no thing about these guys. In short, they are capturing malware and using sinkholes. In other words, they are replacing C&C servers to redirect the traffic into a sinkhole in their own IP space. They are also performing spam collection.
The talk was then more focused on malware analysis (without too much technical, unfortunately). The examples of XcodeGhost, Gameover ZeuS and Dridex were illustrated. They are also helping a lot of companies and government agencies by performing static analysis but also automation, unpacking, polymorphic tests, anti-virus testing and usage of tools like YARA, etc. They are using Cuckoo as sandbox in the background.
The three examples the speaker gave have one common point; those botnets are extremely complex. Unfortunately, law enforcement is too big, too expensive and inefficient against those threats. Indeed the complexity of banking trojan business is impressive.
Also their blog seems pretty good! Finally, as a small anecdote about the Shadowserver Foundation, they are capable of scanning all IPv4 addresses in 70 minutes. But tools like ZMap are also providing this kind of services.
Malware Reverse Engineering or Mobile Application Forensics
The last talk was given by Alex Caithness. The introduction was about cryptography, how it was widely used today and became a selling point for the average user. Furthermore decryption is always easier on the end-point than it is during transmission. Indeed if the device is able to view or access the data, at least part of the keys must be stored locally.
So a lot of applications like App or File Lockers or Secure Messaging are using cryptography and are available on stores. However, are they truly secure? The answer is to this question is security is in really just an appearance. The speaker illustrated his point by reverse engineering the Telegram application.
In a more global way, he showed which methods and tools he was daily using. To analyze an APK, it is necessary to acquire the
.apk file, decompile it, search for useful code like the functions or variables names, continue to source review to find key functional code and finally reverse engineer it. By the way,
classes.dex are the compiled Dalvik byte-code.
Here is a small list of the tools:
- smali/baksmali: assembler/disassembler for the
.dexformat used by Dalvik
- jadx: a tool to convert
.dexfiles in Java
- dex2jar: another tool to convert
- CFR: a Java decompiler
- JEB: a disassembler and decompiler for APK
- dnGrep: a tool that can run regular expression searches over a source folder
So basically, there are three ways to convert Dalvik to Java:
He then gave a second case study with Clean Master. In this application, the “encrypted” files were given a simple
.pl extension at the end of their file name. A string contained actually the details of the encryption scheme which was AES with a CTR and no padding.
So basically, even if the encryption algorithms are strong, they are often bad implemented. At last but not least, decompiling apps is sometimes an inexact science. Use the tool which works best each time seems to be the only rule.
I was a bit disappointed that the author dealt only with Dalvik. Indeed the latter was replaced by Android Runtime (ART) and I was expecting more things about it.