1. I don’t know of any malware for the Windows Phone.
2. Even if there was malware that misuses some kind of hole in the Windows Phone security model, this app wouldn’t be able to catch it because of phone’s application model (unless the app itself uses some kind of security hole).
3. After installing it, it claimed it offers real time protection that would suggest it’s capable of running in the background.

I would consider it a joke app, if it didn’t come from a well-known antivirus company. (Spoiler: It actually is a joke app, but the joke is on the antivirus company.)

A look inside

To satisfy my curiosity, I downloaded the XAP file of the app with Marketplace Browser and Downloader for Windows Phone 7 and opened it with Reflector. Surprise, surprise, this app was ported from Android (or at least that’s what *Droid namespace names suggest). Funny how the game has changed and instead of porting antivirus software from a Microsoft operating system to Linux, people started doing it the other way around.

The scanning UI is concentrated in the DroidSecurityPOC.Scan class and gets invoked in the OnNavigatedTo method. The OnNavigatedTo method is actually the first nugget:

    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
        // uninteresting code removed
 
        // do the actual scanning, synchronously (we are scared of threads...)
        (Application.Current as App).malwareCollection.ScanContainingMedia(this.library);
 
        // simulate work in the UI even though the scanning is already completed at this point
        // people will love this
        this.StartScan();
    }

The StartScan method looks at the number of files to scan, divides 5 seconds with that number and starts a timer to update the “currently scanned” file name in the UI. Scanning will always take 5+ seconds to complete (closer to 5 seconds if you have few files to scan) and most of the time will be spent waiting for the next timer event to fire. Because all the “scanning” already happened in the ScanContainingMedia method, long time before the UI was first updated.

The scanning algorithm

The DroidSecurityPOC.Data.MalwareCollection class is where the hilarity starts. The ScanContainingMedia method is where all the “scanning” happens. It’s split up in 2 parts: scanning your picture library and scanning your music library. The method doesn’t look at anything else (but that’s not much of a surprise given a marketplace application really cannot access anything else).

At this point, I was still giving the app a chance. Maybe it’s scanning for damaged files that can trigger known exploits in music players or picture viewers. All my hopes disappeared when I looked at the code:

private void ScanContainingMedia(PictureCollection mediaFileCollectiont)
{
    // uninteresting code removed
    // malwareGroup contains a list of known "malware"
 
    // for each picture in the library
    foreach (Picture picture in mediaFileCollectiont)
    {
        // for each known malware (because HashSet is overrated)
        foreach (string str in malwareGroup.MalwareGroupList)
        {
            // compare malware name with current file name (!!!!!!!)
            // NOTE: We call ToLower() on each string to allocate a new string
            // and never cache the result. This way the garbage collector will
            // be busy picking up redundant trash and we can have some fun time
            // with his daughter.
            // Also, String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase)
            // is for pussies.
            if (str.ToLower() == picture.Name.ToLower())
            {
                // uninteresting code - add malware to a collection of "effected malware"
            }
        }
    }
}

Basically, this code couldn’t be less bothered about the file contents. It only looks at the file name and if it matches the predicate, boom, it’s jailed. No questions asked. Do not pass Go. Do not collect $200.
The list of “dangerous file names” is downloaded from a web service and Rafael Rivera can show you the current “definition file”.

The code also contains an unused method that hints at a future update that will actually look at the file contents, but the method makes me really scared:

public bool ScanEicar(Picture picture)
{
    Stream image = picture.GetImage();
    image.Position = 0L;
    while ((image.Position + 0x44L) <= image.Length)
    {
        // the garbage collector still doesn't seem to be busy enough, so
        // let's allocate an array in a tight loop
        byte[] buffer = new byte[70];
        image.Read(buffer, 0, 0x44);
 
        // BLAM! Potentially triple the amount of allocated memory by allocating
        // a string with the contents of the buffer. Note each character
        // in a string takes up 2 bytes.
        // Except Convert.ToString will actually return string "System.Byte[]"
        // for each and every call. What the author probably wanted
        // is Encoding.ASCII.GetString().
        if (Convert.ToString(buffer).Contains(@"X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"))
        {
            image.Close();
            return true;
        }
 
        // Scanning fail: the call to image.Read() already moved the position
        // by 0x44 bytes. What the author probably wanted to do is
        // image.Position -= 0x43, but if he did that, the while loop would
        // run for each byte in the file, allocating about 210 MB from the heap
        // for a 1 MB file, so the algorithm is probably better off this way.
        image.Position += 1L;
    }
    image.Close();
    return false;
}

Everything (including the release date) hints at this being some kind of a summer intern project at AVG (if it’s not, it’s very disturbing). But AVG, c’mon. Interns do all kinds of wonky stuff. You really don’t need to ship all of it…

But getting my hands on the CLR JIT-generated code disassembly on the Windows Phone was not easy. If you think it’s as easy as breaking into the Visual Studio debugger and pressing Ctrl-Alt-D, you’ll be disappointed:

No disassembly available.

Luckily for us, at least the Memory window in Visual Studio still works. Getting our hands on the JITted code will be hard, but not impossible.

Let’s write a method that will be easy to spot in the memory window:

public partial class MainPage : PhoneApplicationPage
{
  // ...
  public uint Foo()
  {
    return 0xDEADBEEF;
  }
}

Now add a call to this method in PhoneApplicationPage_Loaded and set up a breakpoint after the method call to make sure it’s JITted when the breakpoint is hit. Deploy your project to the emulator and break into the debugger. Now let’s find the method in memory.

Because we can’t use unsafe code on Windows Phone, and the System.Runtime.InteropServices.Marshal class is off limits, we have to turn our hopes to reflection. Luckily for us, the System.Reflection.MethodInfo class contains a field named MethodHandle whose Value points to some kind of internal CLR runtime structure (MethodDesc?). Even though it’s undocumented, we can probably recognize pointers in it and try our luck disassembling memory they point to.

Open the Immediate window in Visual Studio and type:

?typeof(MainPage).GetMethod("Foo").MethodHandle.Value

Executing the above statement in my debugging session gave me 0x0658c910. Looking at that offset in the memory window gave me this:

0x0658C910  e8 a0 b6 03 b8 c5 58 06 0e 00 00 06 01 00 86 00

Following the first pointer to 0x03b6a0e8 (remember, little-endian) will give you this:

0x03B6A0E8  5a 89 55 08 83 c4 d0 89 2c 24 8b ec b9 e8 a0 b6
0x03B6A0F8  03 33 c0 89 45 14 89 4d 0c 89 6e 14 89 45 2c 05
0x03B6A108  00 00 00 00 05 00 00 00 00 ba ef be ad de 89 55
0x03B6A118  2c 05 00 00 00 00 05 00 00 00 00 8b 55 2c 8b 6d

See the string ef be ad de? That has to be our code! Dump the contents of the memory window to a file and save it.

Now fire up your favorite ARM disassembler and load the dumped bytes at offset 0x03B6A0E8. Does it look like trash? It is trash! That’s because the code you are actually looking at is x86, not ARM. How is that possible? The JIT compiler in the Windows Phone emulator produces x86 code. It actually makes sense, because running native code is faster than emulating ARM code. This is probably the reason why the Phone emulator needs hardware virtualization and can’t run under Hyper-V. Most of it runs as i386 code! To see the actual ARM code of the method, you have to dump it from your physical device.

But because we already have the x86 code dumped, let’s have a look at it:

loc_3B6A0E8:                            ; DATA XREF: seg000:03B6A0F4
                pop     edx
                mov     [ebp+8], edx
                add     esp, 0FFFFFFD0h
                mov     [esp], ebp
                mov     ebp, esp
                mov     ecx, offset loc_3B6A0E8
                xor     eax, eax
                mov     [ebp+14h], eax
                mov     [ebp+0Ch], ecx
                mov     [esi+14h], ebp
                mov     [ebp+2Ch], eax
                add     eax, 0
                add     eax, 0
                mov     edx, 0DEADBEEFh
                mov     [ebp+2Ch], edx
                add     eax, 0
                add     eax, 0
                mov     edx, [ebp+2Ch]
                mov     ebp, [ebp+0]
                add     esp, 34h
                mov     [esi+14h], ebp
                jmp     dword ptr [ebp+8]

You’ll probably quickly notice 4 things:

1. It’s a particularly chatty way of saying mov edx, 0xDEADBEEF; ret.
2. The method has a weird prolog and epilog.
3. The method doesn’t follow the Intel ABI.
4. The method uses a rather big add eax, 0 instruction as a nop. A nop with side effects.

First point can partially be explained by the fact that I was running an unoptimized version (the Debug project configuration), but is closely related to the second, third and fourth point: what we are looking at is code generated by an ARM code generator that was hacked to generate x86 code! The last instruction in the listing is a dead giveaway.

Now let’s look at the code dumped from my actual device (disassembled with standard 32bit ARM instruction encoding):

                ADD     R9, SP, #0
                STR     PC, [R9,#0xC]
                MOV     R2, #0
                STR     R2, [R9,#0x14]
                STR     R9, [R11,#0x14]
                STR     R2, [R9,#0x2C]
                ANDEQ   R0, R0, R0
                ANDEQ   R0, R0, R0
                LDR     R1, =0xDEADBEEF
                STR     R1, [R9,#0x2C]
                ANDEQ   R0, R0, R0
                ANDEQ   R0, R0, R0
                LDR     R1, [R9,#0x2C]
                LDR     R9, [R9]
                ADD     SP, SP, #0x34
                STR     R9, [R11,#0x14]
                LDR     LR, [R9,#8]
                BX      LR

This code feels much more natural than its x86 version. Now let’s look at how the code looks if we enable optimizations (the Release configuration):

                STR     LR, [R9,#8]
                SUB     SP, SP, #0x2C
                STR     R9, [SP]
                ADD     R9, SP, #0
                STR     PC, [R9,#0xC]
                MOV     R2, #0
                STR     R2, [R9,#0x14]
                STR     R9, [R11,#0x14]
                ANDEQ   R0, R0, R0
                LDR     R1, =0xDEADBEEF
                LDR     R9, [R9]
                ADD     SP, SP, #0x30
                STR     R9, [R11,#0x14]
                LDR     LR, [R9,#8]
                BX      LR

You’ll probably notice the code is still not very optimal. As it turns out, the JIT code generator heavily favors code generation speed against code quality. To get most of your CPU cycles, you have to be very careful about how you write your code.

I hope this short post will be useful to you when doing your own Windows Phone .NET code generation investigations. I plan to follow up with some notes on what optimizations you can expect from the Windows Phone CLR code generator that I gathered while optimizing my GameBoy emulator to run on my phone.

Two more useful thing to note: when dumping the method to a file, look at the bytes preceding the method body. Every method has some kind of a header that has (apart from other stuff) 2 pointers in it: pointer to the end of the method body and a pointer to the end of method body including the literal pool. It seems like the header is different depending on whether you deploy a retail or debug configuration.

Many times it’s easier to just dump the whole JIT code heap instead of doing it method by method. After you find the address of your method, just scroll up in the Memory window until you hit uncommited memory region (filled with question marks). Then dump everything starting from there to the end of the heap (a big block of zeroes or question marks).

When it comes to choosing a disassembler, you can try GNU objdump, but if you want something painless, IDA Pro is probably your only option. Get the demo and use this workaround to open raw binaries in it.

Singularity is a prototype operating system coded almost entirely in managed code. It’s written using Sing#, a language derived from Spec#, which itself has roots in C#. Spec# adds Eiffel-like contracts (loop invariants, preconditions, postconditions, etc.) to C#. Sing# extends Spec# with low-level constructs required for operating system development and channels required for communication within Singularity’s microkernel.

Okay, now what does this mean?

• Singularity’s code can be mechanically proved correct. This can easily reduce number of possible programming errors by orders of magnitude.
• Singularity’s strong typing creates impenetrable memory boundaries within operating system components and processes. This allows execution of everything, including user processes in ring 0. No more CPU cycles wasted by context switching.
• And much much more :)

Other projects attempting to create a CLI-based operating systems are SharpOS (which unfortunatelly uses the aggressive GPLv3 license) and Cosmos (released under a BSD license).

EDIT: I almost forgot the download link for Singularity; you can get it from Codeplex.

Nice. This means no more uncommented disassemblies of extended .NET classes from Lutz Roeder’s .NET Reflector (even though it’s a wonderful tool when you don’t have the source code, having the source code is better).