- Table of Contents
- Overview
- Web Application Security
- Operating System Security
- Network Security
- Hardening Your System
- Wireless Security
- Mobile Security
- Windows Mobile Autorun
- Does Windows Mobile Code Signing Help or Hurt Microsoft Security? (Part 1)
- Does Windows Mobile code signing help or hurt Microsoft security? (Part 2)
- Cracking the Encryption of a Windows Mobile Application
- Prodding PocketMoney
- Top Ten Cell Phone Security Problems
- Wireless Gadget Vulnerabilities: The Nikon Coolpix P1
- Abusing the Nikon Coolpix P1 Picture Transfer Service/Protocol
- Caller ID Security: Hacking like Paris Hilton
- Stealing Your Family Vacation: Memories of a Media Card
- Pimp My N800
- Designing an Enterprise Handheld Security Policy, Part I
- Designing an Enterprise Handheld Security Policy, Part II
- Designing an Enterprise Handheld Security Policy, Part III
- Designing an Enterprise Handheld Security Policy, Part IV
- BlackBerry Firewall
- Virtual Lock Picking of Windows Mobile Password Managers
- Bypassing the CodeWallet 6.14 Password Validation Routine
- Building a Password Cracker
- Exploiting Systems through ActiveSync
- Mobile Platform Malware Threat Overview
- A Case for Mobile Security Software
- Data Forensics
- Legal and Ethical Issues of Security
- Home User Security
- Additional Resources
- Job Security for the IT Security Industry
- A Biased Book Review: Chained Exploits: Advanced Hacking Attacks from Start to Finish
- Security of Mechanical Locks
- Information Security in Academics
- Holiday Security: Hackers Don’t Take Holidays
- Gary McGraw on Building Secure Software
- Gary McGraw on Exploiting Online Games
- A Student-Hacker Showdown at the Collegiate Cyber Defense Competition
- The Collegiate Cyber Defense Competition Year 3: Revenge of the Red Cell
- Questions from RSA 2007
- How to Steal 80,000 Identities in One Day
Windows Mobile Autorun
Last updated Nov 25, 2004.
Almost any user, from the most experienced to the complete beginner, knows that when you place a game or application CD in the computer it will automatically launch a program that allows you to interact with the data on the disk. This is a result of a magically concept known as the autorun.
The autorun has some definite advantages. It simplifies the installation routine by automating the necessary steps to unpack and execute files on the inserted media. By doing this, the user is kept at an abstract level from the actual data, which is arguably a good thing for many of the computer users in the world. In general, the more the computer automagically operates, the happier the user.
Unfortunately, the simple fact that an autorun process executes a program WITHOUT user interaction is a security nightmare. There is no guarantee that the programs processed by the autorun are actually safe. They could just as easily contain malicious code as they could the launcher for Doom 3. Not to mention the program executed by the autorun may run hidden and give no indication it has executed. This is where the true danger lies.
To compound the autorun threat even more, CD-ROMs are not the only form of media that can automatically trigger a program to launch. External hard drives, USB thumb drives, DVDs, and more can elicit a program execution. So, thanks to the combination of providing the end user with a brainless computer experience with the increasingly connected and integrated computer, we now have yet another vector by which viruses, trojans, and other forms of malware can be transmitted. Oh, and all this not only applies to the desktop PC, but it also applies to mobile devices, such as PDAs and cell phones.
The PDA Threat
The PDA is a great tool. However, it is one of the most highly underestimated computer devices on the market. Most people see a PDA and think of a digital day timer. They recognize it is a mini-computer of sorts, but fail to realize that though the size of the device might be small, the computing power contained inside is basically the same of a computer purchased in 1996-1998, and in some cases more powerful.
In today's PDA, you can find up to 256MB of built in memory, a 624mhz processor, built-in 802.11 & Bluetooth wireless connectivity, plus the ability to plug in external drives, run multiple operating systems, and more. While the resources available on the PDA speak to their potential, the programs these devices can run further illustrate their power. Word, Excel, games, Power Point, FTP servers, web servers, email server, full ssh daemons and more run on these devices. In fact, with the Familiar Linux operating system installed, it is hard to tell a PDA from a regular computer when connected remotely (granted data space, memory allocation, and other hardware specifics will give it away to the curious user).
With all this power and storage ability, an attacker may consider the PDA a target too good to pass up. The question is then, how can an attacker gain access to and install any malicious programs that can help achieve their goal. This is where the power of the autorun can come in handy.
To illustrate, how often do you see a PDA user on a subway or in a coffee shop? What would happen if you sat next to this user, pulled out your PDA and started up a conversation about how your PDA rocks. Next pull out your Atari games SD card, and show the victim the games your PDA can play, and then offer it to them to try. Congratulations, you now own their PDA. What the victim didn't realize is when the SD card was inserted into the PDA, it automatically executed a file on the PDA that placed a trojan/backdoor in their startup folder, replaced their keyboard with a version that logs everything typed, copied out everything in their My Documents folder to the SD card. All this by simply inserting the innocent looking SD card into their PDA.
The Detailed Threat
Autorun on a PDA is not as simply to execute as it is on a desktop PC. As per the MSDN, each major brand of PDA processor is associated with a particular numerical value as defined by the winnt.h file. The number is then used as a folder naming convention, in which that processor would expect to find its personal executable. This is due to the simple fact that each processor understands a different assembly language, which means a program compiled for a StrongARM will not execute on a MIPS processor. The following list provides you with the association table.
HITACHI_SH3 10003 // Windows CE HITACHI_SH3E 10004 // Windows CE HITACHI_SH4 10005 // Windows CE MOTOROLA_821 821 // Windows CE SH3 103 // Windows CE SH4 104 // Windows CE STRONGARM 2577 // Windows CE - 0xA11 ARM720 1824 // Windows CE - 0x720 ARM820 2080 // Windows CE - 0x820 ARM920 2336 // Windows CE - 0x920 ARM_7TDMI 70001
In other words, if you obtain a SD card, create this folder structure on the card, and drop a file called AUTORUN.exe inside each folder that is compiled for the appropriate processor, you can be fairly certain your AUTORUN program will be executed. To make it even more simple, the folder 2577 covers all versions of the ARM processor, from the XScale used in the newest releases from Dell and HP, to the older StrongARM used in the original iPAQs.
When the media card is inserted, the autorun.exe file is actually copied to the \Windows directory on the PDA. It is then 'installed' (I.E. executed). When the media card is removed, the program is 'uninstalled', and then deleted from the \Windows folder. This has several indirect affects. One, your PDA must have the memory space needed for this program to launch, and there must not be another 'autorun.exe' program in the \Windows startup folder or it will be deleted.
To demonstrate, we created the following simple program that can easily be placed on a SD card. This program can be compiled by placing the autorun.s file, make.bat file, two programs from the EVC++ package named armasm.exe and link.exe, and coredll.lib into a folder. Then double click on make.bat and autorun.s should compile and create two new files; autorun.obj and autorun.exe. Place the autorun.exe file in a folder named 2577 on your SD card, remove it and reinsert the card. You should be greeted with a popup box similar to the one in figure 10.
Make.bat: armasm.exe autorun.s link.exe coredll.lib /entry:"start" /subsystem:windowsce /machine:arm autorun.obj pause autorun.s: IMPORT MessageBoxW ;Calls MessageBox function IMPORT ExitThread ;Calls ExitThread function EXPORT start ;Exports start code AREA .text, CODE start eor R0, R0, R0 ;Sets 1st parameter = 0 ldr R1, =message ;Sets 2nd parameter = message ldr R2, =msgtit ;Sets 3rd parameter = mestit mov R3, #0 ;Sets 4th parameter = MB_OK eor R4, R4, R4 ;Sets 5th parameter = 0 bl MessageBoxW ;Calls message box function eor R0, R0, R0 ;Sets R0 = 0 bl ExitThread ;Calls ExitThread ALIGN message dcb "A",0,"u",0,"t",0,"o",0,"r",0,"u",0,"n",0,0,0 msgtit dcb "A",0,"u",0,"t",0,"o",0,"r",0,"u",0,"n",0,0,0 END
Figure 10: Autorun program in action
Protection
As previously stated, the autorun process copies a file from the media card to the \Windows directory. This provides a user with an opportunity to block this file copy by creating an autorun.exe file and placing it in the folder with the READ-ONLY permissions set. Therefore, when the autorun program tries to copy, it will fail. While this is an indirect method for blocking the autorun program, it is effective!
Note: When testing, it was discovered that if you manually put a file named AUTORUN.EXE in the \Windows directory, it would be executed each and every time a media card was removed from the PDA.
Summary
The Windows world has long dealt with autorun. In the desktop PC, this feature can be disabled with a registry setting. At this point, the PPC does not appear to have this option. Combine this with the fact that most people do not know about autorun on the PDA and you have a potential security risk. While it can be blocked with a read-only file, the threat still exists.


Account Sign In
View your cart