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…

Instead of crashing the program, you should wait several days and then change the way the program reacts. For example, in a graphical program when the user of illegal version picks green colour, the program will draw with blue colour.

The intention of this is clear: discrediting the cracker. If he doesn’t notice this additional protection layer and ships his (unfinished) crack, his credit among the cracker community will be degraded.

In reality, though, the one with degraded credit will be you. “Do not use the X program. It’s full of bugs and works in an unpredictable way.”

People do not usually associate bugs in programs with unfinished cracks. If a program works just fine after it was cracked, people tend to forget that the program was ever cracked. All errors that show up after a certain period of time will be automatically associated with you.

If you want to include delayed checks in your protection, make sure they behave in a direct way. You detected that your program is partially cracked? Show a message box‡. Display a message on the application title bar. Inform your users. Do not let them make false assumptions about your program.

† There are many ways how to detect this – a checksum doesn’t match, the registration verification procedure returned true even though the code supplyed was intentionally not valid, etc.

‡ Of course, do not forget to hide the message in the code appropriately. You don’t want to bring the attention to this code, do you?

One code snippet caught my attention in particular. The code went like this:

float sumOfNumbers = 90 - 1 + 0.03 + 50 + 300 + 0.3 - 50;
if (sumOfNumbers == 389.33) {
    // everything's all right
} else {
    // now confuse the cracker
}

The text around this snippet was talking something about making constants in programs more confusing.

Well – in source code, this is really terrifying and confusing. It works well, if you want to protect your source code against modifications by the mystified programmers (or by you). It will hardly confuse a cracker, who sees only the binary version. The reason? Compiler optimizations.

I made a little experiment with this code:

float f = 3.1 + 5.8 + 1.1;
 
if (f == 10)
    printf("Aloha");

I compiled it in Visual C++ with full compiler optimizations (the “release mode”) and glanced at the produced code. The above code was compiled into this:

push Test.004020E4                       ; /format = "Aloha"
call dword ptr ds:[<&MSVCR80.printf>]    ; \printf

Only the printf call was left from the original code. Not very confusing anymore, is it?

Polymorphism first appeared in a computer virus called 1260 as a method designed to hide the virus from anti-virus software. The anti-virus software at that time used patterns to identify malicious code inside of executables. Because polymorphism made the representation of the virus code different in each infected file, the anti-virus creators could not find a unique pattern identifying it.

The concept was simple: at the beginning of the virus, there was a simple decryption routine that decrypted the rest of the virus in memory. Then the actual virus code was run. When the virus found its new victim, it changed the decryption key a little, encrypted itself with this new key and placed its encrypted code together with decryption code into the executable file.

Polymorphism: the easy way

The easiest approach to polymorphism looks like this:

mov al, 12h ; set the key
mov edi, codeEnd ; starting address
mov ecx, codeEnd - codeStart ; length of encrypted block
 
; now decrypt the code, starting from the last byte
decryptLoop:
xor byte [edi], al ; decrypt byte
dec edi ; move to the next byte
loop decryptLoop
 
codeStart:
; put encrypted code here
codeEnd:

This kind of polymorphism is easy to implement and seems as a pretty good weapon. But let’s have a look at this code from a crackers point of view: the code between codeStart and codeEnd is encrypted, so he can’t see what will happen after the loop instruction. The easiest method to go through this problem is to place a hardware or memory breakpoint after the loop instruction and wait for the code to decrypt (BPX breakpoint won’t do here because it would alter the byte after the loop instruction – this would result in garbage after the decryption).

The point of polymorphism is to force the cracker to run our program – to make static disassembly useless. The problem with this polymorphic engine is that it’s too transparent – the cracker doesn’t have to run this code. He just has to look at the decryption routine and write a macro for IDA (or similar disassembler) to decrypt the protected code for him. Then he can NOP the decryption code out of the executable.

Advanced polymorphism

More advanced polymorphic engines not only change the key protecting the sensitive code – they also change the algorithm doing the decryption. A good polymorhic engine usually has these features:

• generates different instructions which do the same thing
• swaps groups of instructions
• creates calls to dummy routines
• generates lots of conditionals jumps
• embeds anti-debugging tricks
• inserts junk instructions into real code

A combination of these techniques makes debugging of the decryption routine really hard and painful.

Generating different instruction which do the same thing

As a programmer you already know that there is always more than one way to do one thing. As an example, let’s solve this task: set the EAX register to value 100h.

; simple assignment
mov eax, 100h
 
; using stack
push 100h
pop eax
 
; first zero register, then do a binary or
sub eax, eax
or eax, 100h
 
; this will even hide the assigned value from cracker's eyes
mov eax, 12345778h ; 12345778h = 100h xor 12345678h
xor eax, 12345678h

Intermediate languages

Implementation of this is pretty straightforward. To represent the polymorphic decryptor, we create an intermediate language (a language of an abstract machine) represented by triplets. The internal representation of the decryptor will look like this:

[move, eax, 100h]
[jump, label_id, null]
[increment, eax, null]

Code generator will then go through the intermediate code and generate native code for each triplet. Each triplet will have one or more native code alternatives and the code generator will always pick one at random.

The representation using an intermediate language can also assist us in another tasks like swapping instructions or inserting garbage code into real code. Theory behind intermediate languages and optimizations (i.e. modifications of existing code while preserving the functionality) is explained in every book about compiler design.

Problems with classical polymorphism

The biggest problem with classical polymorphism is that after the polymorphic decryption routine finishes, the sensitive code is left naked in memory. This means that if the cracker manages to get thought all the weird and hard-to-debug computer-generated code, he will find clean and comprehensible original code. This is something we need to prevent.

To avoid this, we can divide our code into smaller modules and put each of them into its own polymorphic envelope. This will make crackers life harder, because he will never see whole code at once and he will have to trace through the polymorphic decryptors annoyingly often.

But even this approach has its downside: it is the fact that the cracker is still given the opportunity to see the comprehensible original code.

Metamorphism as an effective weapon

The solution of this problem is called metamorphism. From the outside it is similar to polymorphism – it creates different code for each application. But the key difference between polymorphism and metamorphism is that while polymorphism encrypts the sensitive code and creates a unique decryptor for it, metamorphism morphs the sensitive code to make it almost impossible to understand by a human.

With metamorphism it’s possible to create kilobytes of morphed code from several bytes of original code. Manual tracing of such code can easily take days or even weeks of hard work, with poor results (the cracker will never see the original code as with polymorphism).

Metamorphism – an example

Metamorphic engine first takes existing code, analyzes it using an internal disassembler, morphs the internal representation of code and then generates morphed native code. Let’s have an example:

mov eax, 1h
mov ecx, Ah

The resulting morphed code can look like this:

xor eax, eax
inc eax
sub ecx, ecx
inc ecx
sal ecx, 2
inc ecx
sal ecx, 1

Implementation details

The main difference between implementation of polymorphism and metamorphism lays in the fact that polymorphism doesn’t change the original code. It only hides it.

On the other hand, metamorphism changes the original code and thus has to cope with several problems:

• Code flow: because each instruction is replaced with several new instructions, the length of code blocks changes. Engine has to detect and repair all jumping coordinates or function calls within the code to match new positions of code blocks.
• Registers used as pointers: the same problem as with code flow.
• Detecting data in code: most compilers today place some data in the text section of executable, together with code (e.g. between functions). An attempt to handle data as code (i.e. mutate it) could have fatal consequences.

This is the reason why metamorphism is never used for whole application, only for the protection itself.

Partial and full metamorphism

Because of great complexity of the task of writing a metamorphic engine, many commercially available protections resort to partial metamorphism. They decide not to write a full morpher but select only a small subset of instructions that will be morphed. The other instructions are left without change.

This approach fulfills the goal of metamorphism only partially. While it’s still harder to understand the generated code, it’s not as hard as with full metamorphism. The reason for this is that the subset of affected instructions is usually too small to generate sufficient amount of confusing code.

The complexity of writing a full metamorphic engine is also proven by the fact, that at the time of writing this article, the only commercially available protection offering full metamorphism was SVKP 2.0. You can find it at www.defendion.com.