|
Various PDA systems - such as those sold by Palm, Handspring, IBM and Sony - utilize the Palm operating system (hereafter referred to as Palm OS). Since its introduction several years ago, very few malicious codes for the Palm OS platform have appeared. Considering that there are more than 10 million Palm OS-based devices in use, it is surprising that only four malicious programs have been seen for this platform. One possible reason for this is that, compared to more established platforms, common infection vectors haven’t been introduced in Palm OS platforms. Some such common infection vectors could include:
- access to networks and network shares;
- access to removable storage devices;
- mail programs;
- easy exchange of installed palm applications;
That said, infection vectors may soon be in place. Support for establishing a networking environment has emerged and, as a result, wireless LANs (WLANs) are either currently available or are planned for the Palm OS-based systems. Furthermore, the networking and general socket functionality that may be required for infection has been built into recent Palm OS operating system releases.
So will this necessarily facilitate the emergence of Palm OS as a site of virus or worm infection? This article is the first of a two-part series that will attempt to establish to what degree Palm OS-based systems represent a suitable platform for malicious code. This installment will examine the operating system in general, as well some of the types of malicious code that could be used to infect Palm OS platforms.
For the purposes of this discussion, an IBM c3 workpad and the POSE emulator were used with Palm OS 3.5 and Palm OS 4.0. Several examples of malicious code discussed below are derived from the Amiga platform. (Detailed analyses of the AMIGA viruses can be found at Virus Help Denmark. Malicious codes for the Palm OS platform will be typically implemented in C/C++ or assembly language. It is unlikely to see a Java-based malicious program on the Palm OS platform. The Java sandbox itself can be seen as reasonably secure and the replication mechanisms are heavily limited in a Palm OS environment.
The Palm OS PDA
First, let’s have a look at the processor of a typical Palm OS PDA itself. The DragonBall processor is based on the Motorola MC680x0 family and therefore it’s assembly language is easy to learn and extremely powerful. The MC680x0 processor family is based on a CISC architecture. The DragonBall processor has eight 32bit data registers (d0 – d7) and 8 address registers (a0 – a7), whereby a7 is also the stack pointer (SP). In contrast to x86 based systems, the MC680x0 family is big endian and the addressing within assembly operations lists always the source and then the destination parameter. For example:
move.l #0x42, d0
This operation writes the 4 byte value 0x00000042 in the data register 0 (d0).
The maximal jump destination for Palm OS applications is limited to 32KB and the stack area for Palm OS is limited. The memory management is based on a flat model.
At this point we will have a closer look at malicious code techniques that have been implemented in the context of other MC680x0 platforms like AMIGA, Atari or Macintosh and can be theoretically implemented on the Palm OS platform in its current state (version 3.5.x and 4.0/1).
Reuse of Code/Data
This technique is mainly thought to make a debugging process harder and was introduced on the MC680x0 processor platform several years ago. Similar techniques have already been used in a couple of Palm OS programs to hide critical parts. The idea behind this technique is to reuse code, which is part of other instructions. For example:
Offset: Label: Opcode 0x00 move.l #$20012002, d0 0x203c20012002 0x06 move.l Label+2(pc), d1 0x223afffa 0x0a jsr DoSomeThingBasedOnD1
The example shows how the initialization value of the register d1 can be masked. Basically at offset 0x00 the long word #$20012002 will be written in data register 0 (d0). Then at offset 0x6 the longword from offset 0x04 (actually the $20012002) will be copied as long word in dataregister 1 (d1).
This masking can be utilized to fool heuristic analyzers. Simple heuristic engines could e.g. expect, that the Palm OS code located at position “DoSomeThingBasedOnD1” is performing a harmful operation, if register d1 is equal to $20012002. Simple approaches could simply search for the opcode representation of “move.l #$20012001, d1” and obviously fail.
Without an emulation, the operation at offset 0x06 would obviously cheat this type of heuristic analyzer. Furthermore this trick makes the analysis of the functionality much more complicated.
Self-Modifying Code
This technique depends heavily on the memory management of the operating system (e.g. write protection of single resources). If the code resource/section is writeable, this technique is an effective way to make debugging and heuristic analysis more difficult. Malicious code on the Palm OS platform could utilize these techniques. For example:
Offset Opcode 0x00 Label: 0x00 Rts 0x4e75 0x02 // Some malicious code … 0x3a Label2: 0x3a lea Label(Pc),a0 0x41faffc4 0x3e move.w #$4e71, (a0) 0x30bc4e71 (0x4e71 = NOP) 0x42 rts 0x44 EntryPoint: 0x44 jsr Label2(pc) 0x4ebafff4 0x48 jsr Label(pc) 0x4ebaffb6
This shows a typical example as seen in a couple of other samples on the Amiga platform. The entry point of the code is located at offset 0x44. Heuristic engines typically follow the program flow. First the routine called Label2 will be called. At offset 0x3a a pointer to the address referenced by “Label” will be stored into address register a0 (the addressing is handled relative to the program counter (PC)).
Then this is routine is modifying a small part of the own code and exits again. The modification located at offset 0x3e overwrites the previously existing “RTS” (opcode 0x4e75, “return to subroutine”) value, where address register a0 is currently pointing to, with an “NOP” (opcode 0x4e71, “no operation”), so that the malicious code placed at offset 0x2 can be executed.
Then the routine called “Label” is activated and the malicious code is started. Modern heuristics (without memory emulation) following the execution path would not be able to detect the execution of the malicious code as they would recognize only that offset 0x0 there is a “RTS” operation placed.
Stack Tricks
There are a couple of possible tricks to make the life of a debugger or an emulator harder. As mentioned before, the stack size on Palm OS systems is quite limited; still, a decryption routine placed within the stack area is realizable. Such routines would make a CPU emulation very tricky.
Utilization of Unused Bits in Opcodes
MC680x0 Opcodes contain unused bits in certain operations. (For example, a byte-orientated “Exclusive OR” (XOR) operation, bits which are set to 0.) A lot of disassemblers are not able to handle this kind of modification and display misleading information. Obviously this is indicative of programming problems for the disassembler software, but more significantly, it generally makes the life of a researcher much harder.
Polymorphic/Metamorphic Techniques
These techniques have been developed on a variety of other platforms to make detection of malicious code as complex as possible. Polymorphism can be seen as the step before metamorphism. A typical polymorphic decryption header can contain different encryption keys and logical operations, but the number of operations is constant. A decryption header based on metamorphic techniques typically always contains the same functionality, but the operations found in the code differ heavily. For example:
FirstVariant: Offset: 0x00 Move.l #4095,d7 ' 0x2e3c00000fff 0x06 Move.l #$100, d0 ' 0x203c00000100 Loop: 0x0c eor.l d0, (a0)+ ' 0xb198 0x0e dbf d7, Loop ' 51cffffc
At offset, ‘0x00’ the value 0x0fff will be written to data register d7 as 4 byte value. At offset ‘0x06’, the value 0x0100 will be written to data register d0 (again as 4 byte value). It is expected that address register a0 will be pointing to a data buffer. At offset ‘0x0c’, a 4 byte value will be read from the address to which address register a0 is pointing. This 4 byte value will be manipulated using an "exclusive OR" operation where data register d0 is the second parameter. The result of this exclusive OR operation will be stored back at the address, to which address register a0 is pointing. Then this address pointer will be increased by 4. At offset ‘0x0e’, the value of the data register d7 will be decreased by one. As long as this value is not negative, the code will jump back to the address “Loop” (offset 0x0c). This means, that this loop routine will be executed 0x1000 times.
A possible next generation of metamorphic routines could look like this:
SecondVariant: Offset: 0x00 Move.l #4095,d7 ' 0x2e3c00000fff 0x06 Move.l #$120,d0 ' 0x203c00000120 0x0c Move.l #$20, d1 ' 0x223c00000020 0x12 Sub.l d1,d0 ' 0x9081 Loop: 0x14 Move.l (a0),d1 ' 0x2210 0x16 eor.l d0, d1 ' 0xb181 0x18 Move.l d1,(a0)+ ' 0x20c1 0x1a dbf d7, Loop2 ' 0x51cffff8
Basic functionality is the same as in the first variant. At offset 0x12 there is a new operation. The content from data register d0 (0x120) will be subtracted by the content of the data register d1 (0x20). The result (0x100) will be stored in data register d1.
The example above shows two hypothetical generations of a metamorphic generated decryption routine. There exists a buffer referenced by the address register a0. The first 4096 * 4 = 16384 bytes of this buffer will be decoded using an exclusive OR operation with a static key, which is stored in data register d0 and has a value of 0x100 in this example. By looking at the sources, the corresponding opcodes and offsets it is quite obvious that such decryption loops cannot be detected by checksums or simple scan strings technologies. Such decryption routines have to be detected using algorithmic approaches.
These techniques could be adapted to the Palm OS platform, but really make only sense if classical link viruses appear on this platform. Additionally, the complexity of such routines would slow down the infection process drastically. Complex polymorphic/ metamorphic MC680x0 engines can be found in Amiga/HitchHiker 5.00.
All of these techniques can be implemented on the Palm OS platform for use in conjunction with malicious code. Looking at the processor, the Palm OS-based systems appear to be a good platform for malicious code, despite the fact that the memory and the processor speed are quite limited. Generally speaking, the good programming abilities of the processor also enable the generation of complex polymorphic/ metamorphic code.
Next Time…
That concludes the first part of our two-part look at malicious code for Palm OS platforms. In the next installment, we will look at file system viruses, non-overwriting link viruses, compressing link viruses, existing Palm OS malware and virus scanners for Palm OS.
Markus Schmall is currently working at T-Mobile Germany in the IT Security department. .
|