Microsoft Antivirus plans

Ziff-Davis France has an exclusive on MS's AV plans. Further details from Computerworld,New Zealand .

signature scanner

behavior blocking

distributed av network - clients sharing info over secure channel

Maybe it's just me but that last one makes me nervous, though it does have great promise. No mention of a Linux scanner.

Considering Microsoft already has an ARM emulator for their Pocket PC platform I would think they have a good lead in the Windows CE AV market. Neither does Virtual PC hurt them in the PC market.

Pocket PC Emulator

It looks like the Pocket PC 2003 SDK already included the ARM emulator.

Update: I misread the download page for Pocket PC 2003. Only VS 2005 contains the rewritten emulator. Still waiting for VS 2005.

On WinCE and Symbian Emulators

Development on Symbian involves 1 set of source files and two different compilers(x86 & ARM). The situation on WinCE was very similar, with write once and compile with 3-4 diferent backends(MIPS,SH3,ARM,x86). Advantage Symbian.

Recently WinCE had reduced the number of chips supported down to 2(x86 & ARM). Perhaps a tie? No, Microsoft has apparently improved their PocketPC emulator. The emulator was previously x86 based, requiring a separate emulator build(x86) and release build(ARM,MIPS,...). The new version, available with the Visual Studio 2005 beta, is now an ARM emulator capable of running release build software. Build for the hardware and then test on your dev platform. Advantage Windows CE.

A complete emulator allowing you to run suspicious code possibly with debugging and trace support. Why couldn't we have this two months ago? :) Of course, it is as they say 'dual-use'.

The nice thing is that the emulator plays nice in PC emulators like MS Virtual PC. That Connectix purchase may already be paying off dividends to the developer market.

WinCe and Symbian Reverse Engineering Site

ka0s.net started out with an emphasis on Windows CE but has recently increased their coverage of Symbian. Though the tutorials break little new ground for either professional analysts or skilled amateurs, the site does have a good tool section with IDA signature files for CE and a number of small Symbian utilities.

A nice little utility is ERL, Epoc Resource Lister(UPX-packed,VB command line) . Pop it in the same directory as the app and rsc files. Pass it the filename of the app and receive a text file with a listing of all resources with possible types. Very handy, unfortunately it seems to take issue with newer apps, possibly due to Unicode.

Version incompatibilities

I've just installed the verson 2.1 s60 sdk. I haven't gone over the documentation yet but I've heard StartApp is not supported by the upgrade. :)

Three versions of RSC files, well only two active. Maybe still worthwhile.

First Windows CE file infector proof of concept released

First Symbian worm last month and first Windows CE virus this month. Summer's heating up. :)

It 's interesting as the number of different processors Windows CE is capable of running on has shrunk (3 to 1), the first file infector arrives. The single platform certainly reduces costs for developers .

I don't think there is as large a market in pirated Windows CE software as other PDA platforms like Symbian and Palm. Larger traffic in pirated software('warez') provides ready cover for the distribution of viruses and other malware. Until recently with the N-Gage, there has not been a very active Symbian warez market. With newer devices running on a standard platform, we may yet see Windows CE catch up with the other operating systems.

Analyses of WinCE.Duts
F-Secure's - nice pictures :)
Symantec's - good naming, with the OS indicated; without OS implies DOS

Some confirmation from Symbian ver. 7 docs

Finally looked at the UIQ/ver 7 sdk documents. I corrupted the install initially ,trying to get out of installing an earlier Java runtime, and then tried deleting the installed files and install information. Took me a few days, during which I unzipped some of the install packages to get at the Rcomp binary. End result is that the installed2.xml file had to have the bad install entries removed.

Regarding the various RSC formats and offset 0x2, from the sdk....

v5.1-v6.1 legacy Unicode resource format

This two-byte integer (in little-endian byte order) stores 1 + the size of the resource index in bytes. The addition of 1 was to distinguish this resource file format from an older, now obsolete, resource-file format.

The only change was to distinguish between the Unicode and non-Unicode files. "older, now obsolete":) Designing a resource file that uses the same 4 uid header as most of their other system files would have been better, allowing a simpler interface. Good thing that's what Symbian did with the version 7 rsc format.

v7.0 dictionary-compressed resource format

The format is supported by the resource reading APIs, but Development Kits do not currently contain a resource compiler that produces this format.

This version is designed to compress all Unicode strings without the occasional expansion trouble of Unicode standard compression.

v7.0 compressed Unicode resource format

Note that resources in either of these two formats may contain uncompressed Unicode: this is because compressing Unicode using the Standard Compression Scheme for Unicode can, in certain conditions, yield larger output than input, hence such Unicode text-strings will not be compressed as it would not be beneficial.

Comments in the source for Rcomp refers to a "dictionary-compressing program" other than Rcomp itself. This reduces the varieties of RSC files in the wild to two, the series 60 uncompressed Unicode file and the UIQ 4 Uid header file.

Network Security firms moving into the AV space

Pure AV firms are beginning to see some competition in the market...

ICSA Labs, Virus Lab located in Mechanicsburg, PA U.S.A.
Malicious Code Security Analyst

Internet Security Systems, based in Atlanta, GA U.S.A.
Researcher, Ref 010612 - Job search Engine

Websense, based in San Diego, CA U.S.A.
Malicious / Reverse Code Research Engineer

Foundstone, based in Mission Viejo, CA U.S.A.
Senior Virus Analyst

And with perhaps no better understanding of how our industry works, under the heading Careers-Marketing :) --

Zone Labs, based in San Francsico, CA U.S.A.
Security Researcher

Rcomp versions

Just noticed this in the list of packages on SymbianOS.org.

"NOTE! The generated output is AFAIK only compatible with Symbian OS 7.x
which contains a 16-byte UID header (invoked with the external
program uidcrc) and compressed Unicode characters.
For Nokia 9210 and Nokia Series 60 platform SDKs you will need
rcomp v6.00 which is as of today only available as win32 binaries."

Explains the part in the source where a standard 4 uid header is written to the RSC file. the Rcomp versions appear to match the OS version.

The source is only one version removed, shouldn't be that hard to find the differences in the binary. :)

Updated Import Function Labels for DmpE32

I've updated the function labels used by DmpE32. If you've already installed DmpE32, just unpack the archive(importfn.tgz) and overwrite the files in the importfn directory. For a new install, create a subdirectory named importfn in the same directory as DmpE32.pl and unpack as above.

All functions are imported solely by ordinal in Symbian executables; the import function labels provide information that is readily available on the Win32 platform but lacking by design on Symbian. The labels don't really provide the greatest benefit to the DmpE32 script. Its larger brother DumpE32 also disassembles executables. The labels are used to comment the disassembly in a manner similar to IDA. I may integrate Eberhard Mattes' ARM disassembler from EpocEMX since it handles thumb instructions.

It occurred to me that since there is very little overhead in the RSC file format, there is no reserved space for future expansion. Symbian changed the UID for version 2 sis files so that they would not be recognized as installation files by older versiona of the OS. I suspected that if rcomp always adds 1 to the index size it may be as a cruder version of the UID change.

Older versions of the Resource loading functions would fail on attempts to load the new modified RSC files. I modified a few RSC files and attempted to run the associated programs under the emulator. Even values at offset 0x2 bring up an error message regarding corrupt resources. So, apparently new versions of the Resource loading functions fail when attempting to load older RSC files.

I haven't yet verified this from the rcomp source.

Rcomp differences

The format for RSC binary files as mentioned in the series 60 SDk calls for offset 0x2 of the file to be the size of the file index in bytes. Each entry in the index is two bytes long. It follows that offset 0x2 can never be odd. I added this into dumprsc as something suspicious. Emxrsc also tags this as suspicous, so i assumed this was correct. Then I looked at a few actual RSC files. Offset 0x2 is always equal to 1 byte more than the size of the file index.

Perhaps this was due to a mistake in implementation of the latest version of Rcomp. I put together a few simple RSC files to see what the current version places in offset 0x2. 1 byte more, every time. I hunted down my Symbian ver. 5 SDK disk to get the previous rcomp. It produces RSC files with the proper size at offset 0x2.

More spelunking in the Rcomp source is necessary. Meanwhile even at offset 0x2 means Symbian OS 5 and odd means OS 6+.

From the mention of xpetran in the emximage sources I assume it was started after the XSDK.

Emxrsc does not build on my W2K system. A number of error messages. If it doesn't compile using Msys, I no longer bother. Regardless the source is a lot cleaner than that of Symbian's Rcomp.

I should look into Python, as it's the new official scripting language for Symbian. I wonder how long it will be before the first bittorrent clients appear.

Just noticed the press release regarding Cabir on Symbian's site. Good info, with some interesting bits. "Should Cabir actually infect your phone, you should report it to your service provider and your handset manufacturer." - not sure what that has to do with cleaning your phone. Your service provider will possibly wipe the memory down at their service center and Nokia as manufacturer only warrants the hw. It does follow immediately with instructions on cleaning your phone manually, negating any need to notify provider.

Another nice quote from the press release:
"Q - How is Symbian OS protected from malware?

A - Symbian OS provides a numbers of elements that make it secure. This includes protection from malware through signature checks and virus scanners."

Symbian provides digital signature checks but they have a hands-off policy with regard to security software.

RSC fun

Looking at the fun that some have had porting the Symbian resource compiler(rcomp)to Linux.

The conlcusion seems to be that a rewrite is in order to get something sensible working. One should note at this time that Eberhard Mattes rewrote most of the Symbian toolchain in order to port EMX to Symbian. The entire EpocEMX sdk is licensed under the GNU GPL and is available at SymbianOS.org. The SDK existed prior to Symbian's release of their build tools. I'm not sure if it is contemporary with the XSDK.

Emxrsc, from EpocEMX, includes a RSC dumper. It should build under any system with the GNU tools.