Book Review: Practical Malware Analysis

A non-mobile book review today about a book that has taught me a lot about things that are quite relevant in mobile, too. After reading Zero Day about which I blogged here and after I had to come to the rescue to get rid of a malicious program on a friend's PC I decided it was time to learn more about the subject. After doing some research I got an ebook copy of 'Practical Malware Analysis – The Hands-on Guide To Dissecting Malicious Software' by Michael Sikorski and Andrew Honig.

After reading the first paragraphs I became instantly hooked and the material is well laid out from the simple to the complex. The authors first discuss static malware analysis which means having a look at a binary file from the outside with various tools without actually running it. All tools such as the virustotal website, strings, MD5 check, PEid, Dependency Walker, Resource Hacker and the IDAPro disassembler are available for free on the web.

Apart from the main goal about learning about how to detect and what to do about malicious programs, I was especially interested in the chapter on disassembly. It's been a long time since I last worked directly with assembly code and while I still knew the basics I looked forward to using the book also as a refresher course for this. Just looking at assembly programing from a theoretical point of view without having somthing practicable in mind for doing with it would not have been much fun. Malicious program analysis was the perfect use for an assembly language, processor internals and operating system details refresher.

The second part of the book then deals with dynamic analysis, i.e. actually running the malicious program to see what it does. My recent ventures into the virtual machine space paid out handily here as it's absolutely necessary to run malicious programs in a virtual machine with proper separation of host and guest operating system and separate Internet connectivity to ensure other hosts on the network can't be touched by the malware in case it decides to go viral. Also, a virtual machine comes in handy as snapshots of intermediate results can be saved and a clean environment can be restored after performing the analysis by simply deleting the snapshots. Again, all tools for dynamic analysis discussed in the book are freely available on the web.

The book also discusses how C and C++ code look like in assembly code. For me that was a highly interesting topic even outside of malware analysis as I always felt that this was kind of the missing link between my knowledge of higher level programming languages and the assembly world. Especially the inheritance part of C++ always had me puzzled of how that might look like in assembly code. All chapters, including this one has a learning section with sample code provided and it was often quite humbling to do the exercises after reading the chapter. It seemed so clear when reading about it but the real understanding came when actually doing the exercises and working with the code.

At some point I also started working on real malicious code, the stream to my email inbox supplies fresh samples that get past the network based malware scanner almost daily. With the tools and methods learned one can quickly see what the malware does, which files it creates, how it ensures that it is started automatically, how it calls home to the command and control server and how it downloads further malicious code. Once the virtual machine was infected it was also a good test bed to see how my arsenal of virus removal tools dealt with the issue and if all malicious files were found. Sometimes it was, sometimes it wasn't and only a try a week later with updated virus signatures removed the infection.

The hard part with real malicious programs is disassembling the code or running it in a debugger. All samples I got via email contained a multi-stage packer which helps the malware to better hide from antivirus software and also makes analysis of the code a lot harder. Some of the malware contained anti-debugging code which detects that it is looked at and then does something entirely different. Also, lots of packed code I was looking at also only used indirect function calls to the Windows API making it difficult to impossible to statically analyze it with a disassembler. All of these things are discussed in the book and in practice it takes a newcomer a lot of time to overcome.

Further topics discussed in the book, again including examples to dissect, are user space root-kits, kernel debugging, kernel root-kits, shellcode and 64 bit malware code. The book also goes into the details of how stack overflows are used to infect machines in the first place and also discussed countermeasures such as address space randomization and stack execution prevention. These make it harder to exploit a vulnerability but the book also discusses how black hats have found their way around these counter measures.

The one thing I was really surprised about, because I've never heard or seen this is how malicious programs run inside other running processes to hide themselves. This is called Process Injection and removes the Trojan horse completely from view. One real malware I examined copied itself into explorer.exe and the other one spawned a svchost.exe instance and lived in there. There are various methods how this can be done, again all described in the book and backed-up with sample code that can be analyzed and run for better understanding.

It's been a long review and I still haven't touched on all the points that I found interesting in the book. With some background into programming, Windows and how computers work in general, the book is easy to read and the example code sections always start with something easy and increase their difficulty towards the end. In other words a fully recommended read from a malicious code analysis point of view. If you want to learn more about how operating systems and computers work, looking at malicious code is just the practical thing for which you want to go through the general theory.

Before I close, some thoughts on technical books in ebook format vs. print: If I intended to read it only at home I would have ordered the print version. However, since I was traveling at the time and wanted to start with this topic right away I went for the Kindle version. While this was definitely beneficial for where and when I wanted to use it in terms of instant availability and not needing to carry a full book, I have to say that there's still a lot of room for improvement for reading a technical book on an ebook reader. Quickly jumping from one place in the book to another, going to the table of contents and back, taking notes and generally have a visual idea where some information might be found is very hard to come by in electronic version. I don't know if there is a perfect middle ground in the future but the ideal book for me doesn't weigh anything, is instantly available, i.e. downloadable, I own the binary file for lifetime, nobody can take it away anymore, it should be possible to jump through the book like in a print version combined with text search to find specific content, that would be it. We are still far away from this.

How Large Is A URA?

After my recent discovery that three mobile network operators in Germany now use Release 8 Fast Dormancy to reduce signaling overhead and power consumption of UMTS devices and  also to improve responsiveness to user input from a more power efficient state I wanted to dig a bit deeper to see how each one makes use of the feature. This post is about the network that uses URA-PCH instead of Cell-PCH like most networks do today as the more energy efficient state.

The difference between Cell-PCH and URA-PCH is that the mobile does not have to send a Cell-Update message whenever it moves from one cell to another. Instead, an update is only necessary when the mobile reselects to a cell that is in a different URA (UTRAN Registration Area, 3GPP TS 25.401). This saves signaling overhead and power when a mobile is located just between two cells and thus frequently switches between them. It is equally beneficial for fast moving users in cars or trains where mobiles select a new cell quite frequently, often several times a minute.

The big question for me was how large a URA actually is. Just one cell, several cells or even much bigger? As I am a frequent public transportation commuter, the answer was not too difficult to come by and actually quite surprising. On a 30 km trip on a train, all cells, and I estimate there are around 25-35 cells on that route (based on Cell Logger traces) are in the same UTRAN Registration area as I didn't observe a single update message being sent to the network. So an URA is quite large in that network, perhaps as large as a whole Location Area which usually includes a major city such as Cologne or Bonn and it's surroundings.

The downside, of course, is that for incoming data packets the mobile has to be paged not only in a single cell but in all cells of the URA. For devices not using the fast dormancy trigger mechanism on their side such as UMTS/LTE sticks, for example, this is not a big problem as the network timer to go to URA-PCH state (from Cell-FACH) is set to 30 seconds. For mobiles that are using the Release 8 Fast Dormancy Functionality (Signaling Connection Release Indication) things could be different. Triggering it too early could result in a state ping pong and frequent paging in all cells of the URA until all data has been exchanged. From my practical experience with the feature, however, that seldom happens.

To summarize: Using URA-PCH instead of Cell-PCH can be quite advantageous for network operators as no signaling required when the user moves. For the user URA-PCH has the advantage over Cell-PCH that less power is used for non user-data related signaling while they are in trains and cars. Let's see, perhaps it will be a growing trend.

Release 8 Fast Dormancy Now In 3 UMTS Network In Germany

Two and a half years ago I wrote a lengthy post about power consumption problems of smartphones and one remedy for it, referred to as 3GPP Release 8 Fast Dormancy. This feature enables the mobile device to inform the network that it thinks that no further data will be transferred for the moment and that it likes the radio link to be downgraded to a more energy efficient state. This way, the timeout period during which power consumption is high can be significantly be reduced. This is very beneficial in cases when only background traffic such as keep-alive pings and email push/pull services communicating with a server produce short bursts of traffic while the mobile is not actively used. Also, another benefit is that the connection is put into a semi-dormant state (Cell-PCH / URA-PCH, see the post linked above) from which it can be reactivated much more quickly than from a fully idle state. Shortly after that post one German network operator actually switched on the feature.

So when I recently made a check of the state of the networks in Germany I was very positively surprised that three out of four networks have the feature implemented and activated by now. Two of them switch the connection to the Cell-PCH state while one uses URA-PCH. Only one laggard remains, incidentally the least performing one in recent network comparisons.

So what's the difference between Cell-PCH and URA-PCH? In Cell-PCH state, the mobile needs to send a cell update message whenever it changes from one cell to the other so the network can send a paging message for incoming voice calls, SMS messages or IP packets via the right cell. When users are moving or are located just in between two cells this results in increased cell update signaling. URA-PCH on the other hand groups several cells into a common registration area (URA = UTRAN Registration Area) thus reducing the cell-update signaling. If this is better than Cell-PCH depends, of course, on how many cells are in an URA.

How Antennas Change Over Time

New-and-oldAntennas and base station sites, they can be seen everywhere these days but it's pretty difficult to see how they change over time. When I recently came home and looked out the window I could at first not  exactly say what it was but I had the impression that something had changed at the antenna site on the building at the opposite side of the street. But I couldn't quite figure out what was different. Then I remembered that I took a picture two years go so it was easy to compare.

And here's the result: The left part of the image (click to enlarge) shows how the antenna construction looks today and the right part shows how it looked like two years ago. Before the configuration was changed there were three antennas covering each sector. One antenna was installed on top and two antennas were mounted below closely side by side. Today, there's only a single antenna casing with at least two antennas inside as can be deducted by the number of cables at the bottom of the antenna casing. Furthermore, a second microwave antenna has been installed on the main mast below the one already used two years ago.

Quite a significant change and I can only speculate why it was done!? I am pretty sure the top antenna belonged to a different network operator than the lower antenna. So does this absence mean that this operator no longer uses the tower? It's likely as I am not aware of any antenna sharing deals between network operators. And how could the lower antennas have been changed at the same time as the upper antenna of presumably a different company was removed? Coincidence? Cooperation?

Questions over questions. But one thing is for sure: I don't remember my surroundings in as much detail as I always thought as otherwise I would have immediately noticed the missing top antenna instead of having to compare today's state with that of two years ago. That is interesting as well.

P.S.: Note that the sky is grey on both pictures. I'll let you draw your own conclusions…

The QUAM Story

Whenever I look at how the mobile space has developed in the US and how it could be so different to Europe, I easily forget that over here, very strange and incomprehensible things have happened as well. A very good case in point was the UMTS action a decade ago that yielded a total of around 50 billion Euros in spectrum license fees to the German government from the 6 winners of the auction.

While the 4 incumbents subsequently built their UMTS networks, the two new entries spectacularly failed and not only lost all those billions spend on licenses but also the little money that was left after the auction for actually building the networks. And it's not that the backers of those two newcomers should not have known better as those were Telefonica (Spain), Sonera (Finalnd) and France Telecom. The story of Quam, backed by Telefonica and Sonera can be found in this recent article. Google offers a handy translation to English here.

The article is very informative but I still have the same questions I had before: How could they have spent all those billions and then run out of money… Incomprehensible.

Wi-Fi Tethering Not Used On My Train A Lot – Yet

Wi-Fi tethering has been in Android and other mobile operating systems for quite some time now and as of late I've become quite fond of it, having exchanged my 3G dongle with Wi-Fi connectivity to a phone or tablet. It seems, however, that for the moment, I am pretty much alone with this approach on my daily commute as I don't see any other Wi-Fi hotspots with a strong signal in the train in which, by the way, the carriages are openly connected, i.e. my PC could see any Wi-Fi signal from at least 4 or 5 carriages. Just a note on the blog for a moment so I can come back to it over time should this change in the future.

The Additional Antenna in Korea

Every now and then there is a note in the press about the success of mobile TV in Asian countries such as Japan and Korea in combination with bewilderment of how it could have taken off there while it wasn't a success at all elsewhere.

In retrospect I can confirm this. When I was in Korea recently, I noticed that all phones of Samsung I know from Europe as well look very much the same, BUT, they have a retractable antenna for television reception at the top. One doesn't see it at first as it's nicely integrated in the design but it is there. And I think the big difference to the approach tried in Europe, for example, is that TV reception on the mobile phone seems to be free. No extra monthly charge, who could say no?

I am not sure if they receive the normal TV program on their mobile or if it is special content, however. From a technical point of view I wonder if there's a separate chip for TV reception or if that is integrated somehow in one of the other chips? And I wonder what the motivation is for manufacturers to put this into the Korean version of their devices? If it's not revenue generating it must be quite popular as otherwise I am sure the companies wouldn't go the extra mile and extra expense to include it. As usual one question answered, several new ones being raised 🙂

Three Network Operators Are Not Enough

In most countries in Europe, there are four mobile networks for customers to choose from. To me from a consumer point of view it seems to be the "lucky" number as in countries with fewer network operators, real competition often doesn't get a chance and network quality and prices are not where they are in other countries.

A case in point is France, where until last year there were only three network operators served the market with pretty much the same prices. Not a lot of competition as could have been clearly seen in the prepaid market which was one of the most unattractive ones in Europe, with validity dates of only 1-3 months for top-ups. 

A lot has happened in the 12 months since Free has started, however, and prices have come down quite considerably to a more "European" average level. Lots of complaints could have been heard in the time since, including parliamentary hearings, etc. And it seems feelings are still running high, according to the following quote from Stephane Roussel, SFR's CEO:

'The number of mobile operators in France is clearly excessive,
unreasonable in my opinion.’

I find the words "excessive" and "unreasonable" quite interesting. So the situation in a lot of other countries, in which the four network operator system works quite well is clearly excessive and unreasonable? Further, in his opinion, to quote the article linked to above, three network operators would be ideal. Hm, for the network operators or for the customers?

Measuring VM Performance with SunSpider

In my previous post I’ve been using the SunSpider JavaScript test in an attempt to get a feeling for the performance of smartphones compared to PCs. On my PC I am using quite a number of virtual machines and guest operating systems for various purposes. Using the SunSpider test is also quite revealing of how virtualization impacts performance of the guest OS.

My hypervisor of choice is VirtualBox and it seems that the operating system it handles best as far as CPU performance is concerned as a guest OS is Windows XP. On the host system running Ubuntu 12.04 the SunSpider benchmark results in a score of around 420 ms with Firefox 16.0.2. Running the same test with the same browser in the virtualized Windows XP results in a score of 455 ms, i.e. only slightly slower.

On a Windows 7 guest OS, however, the score drops to 604 ms, quite a bit slower. And finally, an Ubuntu 12.04 guest also only reaches a score of 607 ms.  In other words, while the Windows XP guest almost incurs no slowdown, Windows 7 and Ubuntu are 50% slower. That is very strange and I haven’t figured out the reason for this yet.

Also, I can rule out that the SunSpider tests gives different results in different operating systems running natively. On another computer I have Windows Vista and Ubuntu 12.04 installed natively and the SunSpider results with Firefox 16.02 give almost exactly the same value.

Comparing CPU Power Between Smartphones and Notebooks with SunSpider

ARM based smartphone CPUs are getting more and more powerful but so far I found it difficult to compare their performance to notebooks in a meaningful way. But now I found SunSpider, a benchmark available on pretty much any platform that will help in this quest. In essence, the SunSpider test benchmarks the JavaScript execution speed and can be used for various things, such as for example comparing the JavaScript implementation of different web browsers running on the same machine or to compare different devices running the same web browser.

When comparing smartphones with notebooks both the device and the web browser implementation changes which is not ideal. However, when testing the JavaScript engines of Firefox and Chrome on a PC and Opera Mobile and the native Android browser, their results only differed in the order of 10%. That's an indication that highly optimized JavaScript engines of different browsers do not have a significant impact on the general result when comparing smartphones with PCs this way. The following list shows the result of running SunSpider 0.9.1 on different devices:

  • 175 ms, Notebook, Intel i5-2520M CPU, 2.5 GHz, Firefox 16.0.2, Windows XP, (2012)
  • 266 ms, Notebook, Intel Centrino 2, Firefox 16.0.2, Ubuntu 12.04, (2009)
  • 269 ms, Notebook, Intel Centrino 2, Firefox 16.0.2, Windows Vista (2009)
  • 301 ms, Notebook, Intel Core 2 Duo, Firefox 16.0.2, Windows 7, (2009)
  • 410 ms, Notebook, Intel i3 2367M, 1.4 GHz, Firefox 16.0.2, Ubuntu 12.04, (2012)
  • 690 ms, Netbook, ARM, Exynos 5 Dual 1.7GHz, Chrome OS (result from here), (2012)
  • 1034 ms, Netbook, Intel Atom N570, second generation, 1.66GHz, Chrome OS (result from here), (2011)
  • 1194 ms , Android 4.0 based high end Smartphone, ARM, native browser (2012)
  • 1266 ms, Netbook,  Intel Atom N270 (first generation), 1.6 GHz, Firefox 16.0.2, Ubuntu 12.04, (2009)
  • 1279 ms, Lava X900, Android smartphone, Intel Atom based (result from here), (2012)
  • 1400 ms, Samsung Galaxy S-III International, ARM, native browser (result from here), (2012)
  • 2000 ms, Android 3.0 based tablet, native browser, ARM, (2011)
  • 6100 ms, Legacy Android based high end smartphone, native browser, ARM, (2010)
  • 11062 ms, Nokia N8, Opera Mobile browser, (2010)

(approx. device release date in brackets)

When comparing the results there are a number of interesting conclusions that can be drawn:

First, my current Intel i3 based notebook is significantly faster than the Intel Atom based notebook I used for my daily work while traveling until only recently. No surprise here, one can feel the difference.

Second, the latest iPhone's CPU single core performance is better than that of my 3 year old netbook running the latest Ubuntu and latest Firefox browser. They are still sort of in the same ballpark when it comes to performance and I wouldn't want to exchange my i3 based notebook with my netbook again. However, the point is that the latest smartphone processing power is in the area of first generation Atom based notebooks.

Third, the latest Chrome OS netbook (the XE 303) uses an ARM processor and while the performance is not quite the same as that of my Intel i3 based notebook, it is still twice as fast as my 3 year old Atom based netbook. It comes close enough to my current notebook, however, that I'd really like to try it with an Ubuntu installation once there's an ARM version that supports that device.

Fourth, Heat: Notebooks used to get pretty hot. But even my Intel i3 based notebook remains surprisingly cool (with a fan running).

In summary, the list shows clearly how close ARM processors have come in the SunSpider performance test to Intel based devices and the performance difference between low power desktop devices and smartphones is getting smaller. In another two or three years, perhaps even sooner, slim tablets will have enough processing power and acceptably low heat creation for that amount of procesing power that they are fast enough to become full desktop replacements with operating systems that have desktop like functionality when needed.