The Byte-BOS Real-Time Multitasking Operating System

Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remains fairly unexplored, such as TinyOS or μOS. Legacy devices, still in used across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS).


Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remain fairly unexplored, such as TinyOS or μOS. Legacy devices, still in use across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS). This short article attempts, based on limited information, to detail this little known system, explore its history, usage and basic composition.


The Byte-BOS RTMOS was initially developed in 1994 by Numerical Services Inc. The company, defunct since 2004, sold the full C source code of the RTMOS to customers for 7495 $USD. Possession of the source code allowed the buyer full customization of the operating system according to the device being designed. The system supported a restricted set of microcontrollers (see table 1) including the Intel x86 and Motorola M68000. Other lesser known microprocessors supported included architectures from Hitachi, Mitsubishi and Texas Instruments, which were used in embedded devices within the medical, industrial and telecommunications sectors. Due to the long life-cycle of these devices, it may still be possible to identify devices leveraging the Byte-BOS RTMOS. Development and support for the RTMOS ceased around 2004. As such, documentation is very scarce, and remnants of information are available only via the Internet Archive [1]. At the time of writing, the domain “” resolves to “Scheumacher Engineering”, owned by the original developer of Byte-BOS. However the website is nothing more than a single page which was last updated in 2013.

Table 1 – Microprocessors supported by the Byte-BOS RTMOS.
Intel 80×86 Coldfire Mitsubishi M16C Texas Instruments
C2x/C5x DSP
Intel 80188/86 Motorola 68000 Mitsubishi M32D Texas Instruments
C3x/C4x DSP
Intel 80×86 (32bit) Motorola 68HC11 Hitachi H8300 ARM/THUMB
Intel 8096 Motorola 68HC16 Hitachi H8300H
Intel i960 Mitsubishi
Hitachi SHX


The Byte-BOS RTMOS is a minimal operating system providing task scheduling management for user applications, along with typical OS activities such as interprocess messaging, memory allocation and prioritization. It performs pre-emptive and non-pre-emptive scheduling of an unlimited number of queued tasks. The system enforces scheduling via interrupt service routines (ISRs) which can suspend and/or resume tasks based on events and their priority. When multiple tasks with a similar priority are requesting resources, the RTMOS assign the resources via a round-robin selection method.

As other operating systems, memory allocation appears to follow a standard process by keeping track of used and free memory chunks via a heap implemented by a double-linked list, which is the data structure used across the RTMOS to store unlimited numbers of objects. Tasks can dynamically allocate and free memory as needed. It also manages events and interaction with devices on behalf of user applications by abstracting the underlying hardware via a Device object (see figure 1). Byte-BOS also provides inter-tasks communications mechanisms for synchronization amongst tasks such as messages and semaphores.  In terms of data structures the double linked list and buffer objects appear to be the main structures used across the RTOS. Memory chunks, tasks and most of the other objects are all managed via the List object.  It also supports the queue structure used to manage tasks. A software stack is also provided and used by tasks to run.

Security-wise, Byte-BOS does not have any authentication or specific security methods for access to memory or special “kernel” functions; all tasks have the same level of authority than the RTOS. Basically, Byte-BOS is completely flat.


The RTMOS is written in C or specific variety of C specification depending on the targeted microprocessor. The 10 main components of the operating systems are represented in figure 1 and provide an excellent overview of the functions accomplished. A simulated “this” pointer to the various “struct”s is made available to the developer to give an Oriented-Object Programming (OOP) feel. This section describes briefly the main components of Byte-BOS, along with some of the features marketed by the original developer.

UML Representation of the different objectsfooun in the Byte-BOS RTMOS
Figure 1 – UML Representation of the different objects defined in the Byte-BOS RTMOS

The Task Object

The main object of the RTMOS is the Task object, which is very similar to the similar concept modern software development. Just as in any C/C++ object, a constructor is initiated prior to executing the body of the task, which is defined by the developer to conduct a specific task. Data of the task is allocated and accessible via the this_data pointer. Tasks also allocate sub-objects, opens required devices, initialize variables and synchronize state machines. Once constructed, the task runs its main function until it returns or is removed. Access to a task is done via the this_task pointer. Both pointers described are always in scope and usable within the task. Once the main task completes, the destructor of the structure is called, which frees memory and pointers of sub-objects. It also terminates any internal state machine.

The Memory Object

This object manages the memory heap and stores the pointer to the heap, the block size and the number of memory blocks. It also exposes various functions for memory management, mainly alloc_fmem and free_fmem. The heap is implemented using a double-linked list in which each node contains metadata about the memory blocks. While details are not available, it can be assumed that the size of the block, its status (free or allocated) and a pointer to the next block is included.

The Semaphore Object

As its name implies, the Semaphore is used for signaling and control between multiple tasks by either being in the Up or Down status. A timeout can be defined as needed.

The MessageBox Object

The MessageBox acts as a central repository for tasks to exchange data. Tasks and ISRs can create messages to initiate other tasks or exchange . The MessageBox basically provides two functions: put and get. When a new message is created, memory is allocated. Similarly, the memory is freed when retrieved from the box.

The Timer Object

Similar to any standard timer in other system, this object is used to create timeouts and schedules of tasks and events.

The Event Object

Events are created by tasks and ISRs to schedule other tasks.

The Device Object

This item abstracts interaction between the user application and the hardware device. It does so by pointing to the memory blocks used by the device and managing input/output to the area.

The List, Queue and Buffer Objects

These objects, as their name implies, are implementation of a linked list, a queue and buffer data structures.


Byte-BOS boasted the following additional features on their website from 2000, providing some extra insight on the internals of the system.

Interrupt Handling

ISRs can make operating systems calls and schedule tasks by including the ENTER_ISR and EXIT_ISR macros at the beginning and end of the routine. Most services are available to ISRs, giving them considerable access over the entire OS.

Critical Section Handling

Byte-BOS provides critical section handling by protecting non-reentrant code sections from both interrupt and task pre-emption. Protection of critical sections appears to be done via the following mechanisms:

  • Disabling interrupts
  • Locking and unlocking code sections
  • Prioritization of tasks

Task Execution Trace

Tasks are provided with a trace buffer configurable at both compile time and run time. The trace buffer contains information about the sequence of calls, the parameters passed, and the return value of the called function. The tracing option is extremely useful for debugging purposes.

System Requirements

The Byte-BOS RTMOS requires very little in terms of resources. While the requirements varies depending on the underlying processor, the size of the kernel is a few kilobytes, while the RAM requirements are less than 100 bytes of globally accessible memory and less than 100 bytes per task and ISR. The detail figures are listed in table 2.

Table 2 – Memory requirements for the Byte-BOS RTMOS according to microprocessor
Microprocessor Minimum Kernel
Size (KB)
Maximum Kernel
Size (KB)
RAM Requirement
for Global Variables
RAM Requirement
per Task (bytes)
Intel 80×86* 4 10 28 30
Intel 80×86
6 15 48 58
Intel 80188/86* 2 10 28 30
Intel 8096 2 8 20 20
Motorola 68000 1.5 12 50 70
Motorola 68HC11 1.2 8 28 20
Motorola 68HC16 2 8 28 20
Mitsubishi M37700 2 10 28 20
Mitsubishi M16C 2 12 64 48
Mitsubishi M32D N/A N/A N/A N/A
Hitachi H8300 1.2 8 28 20
Hitachi H8300H 2 10 38 40
Hitachi SHX 7.8 19.5 72 60
Texas Instruments
C2x/C5x DSP
1.2 8 28 20
Texas Instruments
C3x/C4x DSP
2.3 19.5 28 words 20 words
ARM/THUMB 4 15 50  70

* For Intel-based architecture, the memory footprint reported above is based on usage of the Borland C++ compiler.

Additional volatile memory is required for objects created dynamically. As such, the numbers provided above do not represent the total amount of memory consumed by Byte-BOS.

Compilers Supported

In general, Byte-BOS supports the development tools and compilers provided by the semi-conductor manufacturer. For Intel-based processors, the Borland C/C++ compiler was supported. The complete list of supported compilers is provided in table 3.

Table 3 – Supported compilers by the Byte-BOS RTMOS.
Microprocessor Supported Compilers
Intel 80×86 Microsoft C/C++ (large model)
Borland C/C++
Watcom C/C++
Intel 80×86(32bit) Watcom, Metaware and most of C compilers
Intel 80188/86 Microsoft C/C++ (large model)
Borland C/C++
Intel 8096 IAR
BSO Tasking Compiler
Motorola 68000 Cross-Code
Motorola 68HC11 IAR
Motorola 68HC16 Introl
Mitsubishi M37700 IAR
Mitsubishi M16C IAR
Mitsubishi Compiler
Mitsubishi M32D N/A
Hitachi H8300 IAR
Hitachi H8300H IAR
Hitachi SHX GNU
Green Hills
Texas Instruments
C2x/C5x DSP
Code Composer /
Texas Instrument Compiler
Texas Instruments
C3x/C4x DSP
Code Composer /
Texas Instrument Compiler


Devices using the Byte-BOS RTMOS can be identified by looking at ASCII and Unicode strings in their firmware. In almost all cases, if not all, the firmware will contain a copyright notice identifying it as well as the target microcontroller it was compiled for. For example, by extracting the strings from the firmware for the Seagate Cheetah 10K.6 Disc Drive, either using the simple strings.exe (or strings in Linux) or IDA, the copyright notice string “Byte-BOS 8096 Multitasking Operating System — Copyright 1990 Numerical Services Inc.” can be observed (see figure 2).

Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive
Figure 2 – Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive

While appliances posterior to 2004 will likely use modern RTMOS such as Linux , Byte-BOS can still be found on legacy devices. One such example is the Baxter IPump pain management medical device, which refers to its usage in the manual [2]. Of note, the manual refers to the detection of stack overflows within the Byte-BOS RTMOS. Industrial controls, aircraft, telecommunications systems and other systems designed prior to the 2000s may still harbour this little known RTMOS.


The Byte-BOS RTMOS will likely disappear as legacy embedded devices are life-cycled for newer systems with more processing power and extended memory. Until that moment, for developers of these systems, or simple hobbyists, information remains scarce and limited. While we provided a brief overview of its architecture and features, details about creating user applications remains obscured by the lack of online information such as an API description, code examples or more importantly, the source code. Such data would greatly ease development and engineering efforts of legacy systems.


[1] “Bytebos Home Page.” Bytebos Home Page. Internet Archive, 20 Oct. 2000. Web. 01 Nov. 2015. <>.

[2] Baxter IPump Pain Management System – Service Manual, Baxter Healthcare Corporation, Chapter 4 – Troubleshooting, p.4-8. 2007. Web. 01 Nov. 2015. <Link>

Starting in Exploit Writing – Day 06

Time for tutorial 6 (yeah I skipped #5, as I got the gist of it). After 6 days, I really got the hang of buffer overflows…too bad they aren’t much in use anymore, but everyone has to start somewhere. So below is EIP and SEH being overflowed with 0x0041, indicating that our “A” where translated to Unicode characters.

Buffer Overflow in Trilogic Player
EIP is being overflowed by 0x0041, indicading a buffer overflow with Unicode characters

Mona locates the Metasploit pattern overwriting SEH at 536. So our payload will be something like

And everything falls in place;

Overwriting nSEH and SEH in Trilogic
Both nSEH and SEH are overwritten with the expected values.

This is where it gets tricky. When following the tutorial, I was never able to see that EIP contained 0x00440044. It actually contained 0x00440045 after moving after the Access Violation exception. I can clearly see that SEH has been overwritten with 0x00420042 and 0x00430043. Fortunately according to one comment, I’m not the only one. When I tried to put 534 bytes of junk rather than 536, I end up with 0x0042004D in EIP (difference of 8). I don’t get why it does that.

At least I’m confident I understand the concepts, but that’s pretty much useless if I cannot put it into practice. For this example, mona can find POP-POP-RET addresses that will work when translated to Unicode. From my understanding, [nSEH] will be useless in Unicode-based exploit, simply because there’s no easy way to have a jump matching Unicode encoding. As such, we’ll need to jump to a register which contains a address close to our shell code and either 1) make sure no instruction between the address and shell code will break the exploit or 2) modify the register (add/sub) to have it jump into a NOP slide to our shell code…and then we have to figure out the shell code, but from what I read, talented people have already took care of this for us.

Useful sites (a.k.a shit I need to read):


Starting in Exploit Writing – Day 05

Today we’ll be studying “egg hunters” as of part 4 of the FuzzySecurity tutorials. Basically this technique is useful when the buffer remaining for your shell code is too small to do anything useful. So far we’ve been lucky and we had huge buffers to inject the shell code, but some time, you may be left with a couple of bytes only. With a “egg hunter”, instead of storing your shell code, you store a small function that will look for “magic bytes” in memory. Your shell code somewhere else in executable memory and tagged with these “magic bytes” so that your egg hunter finds it and executes it. Pretty straight forward.

Exploiting Kolibri Web Server

So my goal today was to test out the egg hunter example from the tutorial. However I got cocky and try to exploit the web server by smashing SEH rather than a normal buffer overflow. Everything went fine until I had to call the address containing the POP-POP-RET.

SEH Exploitation of the Kolibri Web Server
Exploitation of Kolibiri Web Server using the SEH Techique

The problem I’m running into is when looking for a “POP POP RET”, all the results are within Kolibri.exe, and all addresses starts with a null byte, i.e. “\x08\x89\x51\x00”. That means our payload will terminate at the null byte. I thought this wouldn’t be much of a problem, since [SEH] is an address anyway, the only difficulty would be that I may have to put the payload in the buffer prior to the [nSEH], and have a short jmp into the buffer placed into the [nSEH]. Now for some reason, it seems that SEH catches the exception, but never jumps to my POP-POP-RET address; it just terminates the program.

Pop-Pop-Ret Instructions from Kolibri Web Server
All the Pop-pop-ret instructions are located in Kolibri.exe and contains a null byte.

So I got stuck here for today. More to follow tomorrow

Sending mail directly using SMTP

Since this is another thing I keep forgetting, I’ll just note it here. To send send emails by connecting directly to the SMTP port of a mail server with telnet, use these commands;

  1. telnet 25
  2. HELO
  4. RCPT TO:
  5. DATA
  6. Subject:
  7. Cc:
  8. Reply-To:
  9. <message>
  10. MIME-Version: 1.0
  11. Content-Type: <content>; boundary=”<bondary>”
  12. Base64 encoded attachment
  13. <CR-LF>.<CR-LF>
  14. Quit

Since I’ll likely forget again, I’ve script some Python for it:

A small and quick introduction to ARP poisoning

This article won’t be about something new nor something extraordinary for any experienced computer security or even the average hacker, but since I’ve been ask this question quite often by some of my friends, I decided to explain how to sniff passwords from a network.  Moreover, I’m well aware I haven’t been writing anything for a while, and I want to get back to it once all my personal matters are resolved. I’ll concentrate on WEP wireless networks since they are almost certain to be cracked easily. Although those a deprecated, there are still used in many household as the out-of-the-box default configuration, so it’s still pertinent in my opinion. Then I will explain the ARP (Address Resolution Protocol) poisoning attack, which will be used to intercept packets between the target and the Internet.

Attacking the WEP wireless network

Packets in a WEP network are encryted, so in order to sniff packets off from it, you’ll first need to acquire the WEP key. This can be done easily with a wireless network adapter that supports monitor mode and the aircrack suite. For the adapter, I’m using the Linksys  Compact Wireless-G USB adapter, model no WUSB54GC. Plug your adapter into a USB connector and boot up your machine. Once you have booted up, make sure Backtrack or any other distribution has detected your adapter:

ifconfig rausb0 up

and then put the adapter in “Monitor Mode”

iwconfig rausb0 mode monitor

The goal of a WEP attack is to capture as many initialization vectors (IVs) as possible. IVs are random numbers used with a either 64, 128 and 256-bit key to encrypt a stream cipher. Those are used so that two exact same plain text do not produce the same ciphertext. The problem with WEP is that IVs are very short, and on a busy network, the same vectors get reused quickly. The IV is 24 bit long, therefore there are 16 777 216 possibilities1. Moreover, changing the IV for each packet is optional. The keys are also quite short, therefore opening the possibility of finding the key with some brute force calculation. No matter what is they key length, you will just need more packets.

The WEP protocol then use the randomly generated IV, the WEP key and pass it throught the RC4 cipher to produce a keystream. The keystream is then XORed with the plain text stream to produce the cipher text, as shown in the picture below:

WEP Encryption Schema
WEP Encryption Schema (from Wikipedia)

So basically, if you get many packets with the same Ivs, different ciphertext, you can now try to brute-force the WEP key. And to get those packets, you need traffic on the network. Now if there are already some people connected and surfing the web, you can easily capture packets and replay them to get more IVs, otherwise, you need to generate the traffic yourself.

Once you’ve tell airodump to capture IVs, we will use aireplay to generate more traffic, and therefore capture more IVs quickly. If you look at the airodump screen, you’ll see it capturing packets.

Once you have the key, you can finally start the poisoning process. As you have seen, I have not detailed how to crack a WEP network as it is widely described all over the net. You can find find good video tutorials from InfinityExists here and here. The last 2600 issue also had a good article about it.

The ARP poisoning attack

The concept behind this is simple. ARP is the protocol that maintains network devices tables up-to-date by associating an IP address with a MAC address. The problem with ARP is that it doesn’t really care about who answered, it will gladly update the tables from whoever says so. Most of the time, it won’t even ask. So the idea behind the attack, is to send the client an ARP answer saying “hey, I’m the gateway, send stuff to me” and a second ARP answer to the real gateway saying “hey there, I’m this guy, send me his stuff”. Then you just have to relay the packets between the victim and the gateway.Those schemas are more simply to understand:

Schema of an ARP Poisoning Attack
Schema of an ARP Poisoning Attack

In Linux, the rerouting can be done using the following iptables commands:

iptables -t nat -A PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

iptables -t nat -D PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

I’m showing those commands because you can do a lot with those. Many web applications such as some Flash applications use RTMP (Real-time messaging protocol) to control web applications, which run locally.  Flash server send commands to the application using message. Using those commands, you can filter the packets send or receive from the Flash server. Simply use a sniffer first, then locate which packets you wish to drop, alter or whatever.

For example, some sites gives you samples of live music or videos for 30 seconds, then nag you to pay. Using a sniffer, analyze the traffic and find that RTMP Invoke packet that closes the connection with the server. Code a quick proxy that will let all packets go to the flash application except for the connection closing RTMP packet. Then use the commands above to redirect traffic to your proxy.

00 03 0d 4f c0 6d 00 11  20 a8 32 8b 08 00 45 00 …O.m..  .2…E.
00 b2 7e 52 40 00 78 06  d0 a1 50 4d 74 05 43 c1 ..~R@.x. ..PMt.C.
ab 3e 07 8f d0 d8 9b a6  b0 eb ea 61 49 3d 80 18 .>…… …aI=..
fe 4a 76 52 00 00 01 01  08 0a 00 ef a6 d0 02 43 .JvR…. …….C
f4 32 43 00 00 00 00 00  76 14 02 00 0f 63 6c 6f .2C….. v….clo
73 65 43 6f 6e 6e 65 63  74 69 6f 6e 00 00 00 00 seConnec tion….
00 00 00 00 00 05 02 00  57 32 30 38 20 46 72 65 …….. W208 Fre
65 63 68 61 74 20 61 63  74 69 76 69 74 79 20 74 echat ac tivity t
69 6d 65 6f 75 74 2e 20  49 66 20 79 6f 75 20 77 imeout.  If you w
65 72 65 20 61 20 6d 65  6d 62 65 72 2c 20 74 68 ere a me mber, th
65 20 66 72 65 65 20 63  68 61 74 20 77 6f 75 6c e free c hat woul
64 20 6e 6f 74 20 74 69  6d 65 20 6f 75 74 21 20 d not ti me out!

Example of a RTMP Invoke packet to close a connection.

Of course you could just use Ettercap, which does exactly what have been mentioned above. Start Ettercap with the following:

sudo ettercap -G -W 128:p:25AAAAC18DEADDADA433332B65

This will open the graphical interface (-G), that is if you have installed the GTK interface to Ettercap. -W specify to listen for wireless networks and to use a 128-bit key with key found earlier. I don’t know what the p is really for. You can also use the text mode.


Then select Sniffing > Unified Sniffing > select on which interface you want to sniff. Then start the sniffing: File > Start Sniffing. Now let’s specify which targets you wanna sniff. Go to Hosts > Scan for hosts. That will locate the hosts on the current network. Then popup the hosts list, Hosts > Show Hosts List.

Ettercap - Hosts Found on the Network
Ettercap - Hosts Found on the Network

On the list, add the router to target 2 and the hosts you wanna sniff to target 1. Only one step left: MITM > ARP poisoning.  Select Sniff Remote Connections > OK.

Ettercap ARP Poisoining Options
Ettercap ARP Poisoining Options

Then you wait for users to connect to pages like MySpace or Hotmail etc…and Ettercap will find out the sensitive information for you.

See also:

Wireless Networking, Praphul Chandra, Alan Bensky, Ron Olexa, Daniel Mark Dobkin, David A. Lide, Farid Dowla

RFC 826 – Ethernet Address Resolution Protocol, David C. Plummer, November 1982,

Wired Equivalent Protocol, Wikipedia,


U.S Army Infected by Worm

Wired reports that the U.S Army network is under assault by a variant of the SillyFDC worm called Agent-BTZ [1]. In order to restrain the infection, the U.S. Strategic Command has ban the use of every portable media on its network, this include USB keys, CDs, flash cards, floppies etc… Both the SIPRNet and NIPRNet are affected by this directive.

The SillyFDC worm infects systems through replication, i.e. by copying itself to various locations such as these folders[2]:

  • %System%
  • %Windir%
  • %Temp%
  • %UserProfile%
  • %ProgramFiles%
  • %SystemDrive%
  • %CommonProgramFiles%
  • %CurrentFolder%

Computer Virus Looming
Computer Virus Looming

It will also try to copy itself to any drive connected to the machine by scanning drives A:\ to Z:\, which is why the U.S Army is banning the use of portable media for the time being.  According to F-Secure who first discovered the worm[3], the variant in question will also create these files[4]:

  • %windir%\system32\muxbde40.dll
  • %windir%\system32\winview.ocx
  • %temp%\6D73776D706461742E746C62FA.tmp
  • %windir%\system32\mswmpdat.tlb

It will then install itself into the registry to make sure the worm starts every time the computer is booted. It will also attempt to download a JPG file from[REMOVED].jpg and create an AUTORUN.INF file on each drive on the computer, which contains the following:

shell\open\Command=rundll32.exe .\\[RANDOM].dll,InstallM

[RANDOM] is a randomly generated filename for the malicious DLL. Each time a new partition or a new drive is plugged in, Agent.BTZ will infect it immediately.

The SillyFDC worm doesn’t have any payload, as it only replicates itself through systems it finds using physical medias only. But its variant, the Agent.BTZ is a known Trojan dropper. A dropper is the kind of Trojan that will look to download and execute other malware. It’s surprising that it found its way into the U.S Army network. So that might be a tip for any worm/Trojan writer: add physical media replication to your malware like in the good ol’ days before e-mail, as it seems sending it by e-mail or click jacking is pretty well filtered in military networks, but peripherals such as USB keys are still often used by personnel. And this will surely open the eyes of the network admins of the U.S Army: scan anything plugged into the network.

Also, Graham Cluley, senior technology consultant at Sophos advises:

“… that users disable the autorun facility of Windows so removable devices such as USB keys and CD ROMs do not automatically launch when they are attached to a PC”

With whom I agree.


Since so many people asked me about this worm, I looked deeply into Internet and found this code, which seems to be part of the script of the Silly FDC worm (that’s the best I could do for now). This script basically copy files from one directory to another, renames the core of the worm and put it into another directory and add registry keys. I cannot confirm this as I found this on an Indonesian blog, so if anyone can look into this, please let me know. Thank you. Blog :

See also:

“US Army bans USB devices to contain worm”, John Leyden, The Register, November 20, 2008, (accessed on November 20, 2008)

[1] “Under Worm Assault, Military Bans Disks, USB Drives”, Noah Shachtman, Danger Room, Wired, (accessed on November 20, 2008)

[2] “W32.SillyFDC”, Symantec, (accessed on November 20, 2008)

[3] “Troj/Agent-EMB”, Sophos, (accessed on November 20, 2008)

[4] “F-Secure Malware Information Pages: Worm:W32/Agent.BTZ”, F-Secure Corporation, (accessed on November 20, 2008)

High-tech Cheating

One man and a woman, Steve Lee and Rong Yang, were convicted last week to eight months of prison after helping two Chinese men cheat their immigration exams, according to a news report from the Metropolitan Police Service[1].  The duo was monitoring the examination from a vehicle outside the building with laptops, transmitters and other equipment.

“Lee and Yang were clearly involved in a sophisticated operation using some of the best surveillance technology available worth thousands of pounds. When we first arrived at the scene it was very confusing as to what exactly was going on.”

It’s hard to tell what was the “best surveillance technology available worth thousands of pounds” since no detailed equipment list was given, but we might expect this to be largely exaggerated. The report states that Zhuang, the examinee, was given “tiny buttonhole cameras sewn in, a microphone and a small ear piece”. With this equipment, the information was transmitted back to Lee and Yang, who told Zhuang the answers to the questions.

“Best surveillance equipment” found into the car
“Best surveillance equipment” found into the car

I decided to look the equipment needed to conduct such an operation. The following material can be found without looking very hard on the net:

· Wireless Button Camera – £226.37

· Wireless Microphone – £133.13

· Wireless Earpiece – £134

· Laptop – £429

· Wireless Router – £51

Total: £973.5

Unless I’m forgetting something worth more than £1000, this is far from being “thousands of pounds”. And I’m quite sure you can get these items cheaper if you look on eBay.

Anyway, the cheaters were caught after a member of the public reported seeing them sitting Lee and Yang in a silver BMW with wires running from under the hood to the inside the car.

According to Sergeant Dominic Washington who first responded to the call from the public, said:

“However, working with colleagues from across the borough and the Met we believe that we have uncovered an established criminal enterprise that may be in operation in other parts of the country.”

No, I don’t think so… but this might give ideas to the others. And why were there wires under the car?

[1] “Two convicted for immigration test scam”, Metropolitan Police Service, November 14, 2008, (accessed on November 17, 2008)

Survey Points to Energy Sector at Risk of Cyber Attacks

A survey of 200 leaders from the critical infrastructure industries revealed that the energy sector is the most likely to be victim of a cyber attack. The survey was completed by IDC was conducted in August and October in Canada, the U.S and Europe[1].

The reasons to explain this phenomenon are the cost, apathy and government bureaucracy according to the survey. Also, industries are adding more and more possible access points to the internal network by connecting new sensors, meters and other equipment to their networks.

“]Percentage of respondents prepared and not prepared by industry sectors

Of course, energy industries networks are valuable targets, and would probably be the first victims in a case of a full-scale cyber attack. And as the events of 2003 shown[3], only a few power plants need to go down in order to create chaos on a wide region.

If costs are the main factor to wait before securing networks, security is not likely to be in the priorities of managers during the economic crisis that’s coming on the horizon. Unfortunately, those who take the risk of not hardening their security now may pay the price later…And according to Rick Nicholson, research vice president for IDC’s Energy Insights:

“Most utility CIOs [chief information officers] believe that their companies will be compliant with relevant standards, but still have a long way to go before being adequately prepared for all cyber attacks.”

Another interesting point, all these news come right after a newly president-elect enters the Whitehouse… see Whitehouse Hacked by Chinese Several Times, Both U.S Presidential Campaigns Hacked.

[1] “Survey: Critical infrastructure risks cyber attack”, Miya Knights, IT PRO, November 10, 2008, (accessed on November 11, 2008)

[2] “Energy industry at risk of cyberattack, survey says”, Elinor Mills, November 11, 2008, (accessed on November 11, 2008)

[3] “Blackouts cause N America chaos”, BBC News, August 15, 2003, (accessed on November 11, 2008)

Fake Anti-Virus Brings in 158 000$ a Week

Russian criminals who are selling a fake anti-virus, “Antivirus XP 2008/2009” among others, have made more than 150 000$ in a week, according to the Sydney Morning Herald[1]. If you ever seen those annoying popups warning you that you might be infected with one or more viruses, then you probably came across this scam.

Fake Spyware Detection Alert
Fake Spyware Detection Alert

“For most people they might just be browsing the web and suddenly they don’t know why this thing will pop up in their face, telling them they’ve got 309 infections on their computer, it will change their desktop wallpaper, change their screen saver to fake ‘blue screens of death’,” said Joe Stewart, from SecureWorks said.

The software is sold for 49.95 $US and will “detect” various viruses and Trojans on the computer. Stewart shows that Antivirus XP still has some basic anti-malware functionality, but as he explains, it’s mostly in case the authors are brought to court “they might try to claim the program is not truly fraudulent – after all, it can clean computers of at least a few malicious programs[2]“. Only 17 minor threats can be removed, far from the 102,563 viruses the anti-virus claims to clean. And don’t expect a refund for the software.

The entity behind this fraudware is called Bakasoftware, a Russian company that pays affiliates to sell its anti-virus to users. Affiliates can earn between 58% and 90% of the sale price. Criminals are therefore using everyway to trick users into installing the software, including scaring the user into believing that he is infected, even using botnets to push the program into the users’ computers.

Since it is not hacking people’s computers and only runs the affiliate program, Bakasoftware does not have to worry about being shut down by police“, Stewart said[3].

Affiliate ID

Affiliate Username

Account Balance (USD)

4928 nenastniy $158,568.86
56 krab $105,955.76
2 rstwm $95,021.16
4748 newforis $93,260.64
5016 slyers $85,220.22
3684 ultra $82,174.54
3750 cosma2k $78,824.88
5050 dp322 $75,631.26
3886 iamthevip $61,552.63
4048 dp32 $58,160.20
Table 1.0 – Top earners in the Bakasoftware Affiliate Program[4]

Screenshots took from the administrative panel of which was hacked by NeoN:

Bakasoftware Registred Domains
Bakasoftware Registred Domains

Bakasoftware All Socks Controls
Bakasoftware All Socks Controls

(Screenshots are from “Rogue Antivirus Dissected – Part 2”, Joe Steward, SecureWorks, October 22, 2008,

By the time of this writing, was not accessible. Another interesting fact, if the Russian language is installed on your computer, there’s a good chance you won’t be considered as a target because of Russian legislation. Apparently the creators have been sued anyway[5].

Many other fraudware are available, always proposing anti-malware software. Their ads are oven seen on torrents, warez and cracks/serials sites. What’s particularly dangerous is that they can come with other legitimate software or by drive-by downloads. Once they are installed in your computer, they get annoying very fast and can trick you into buying fraudware. Popups can appear that you are infected. Other types of fraudware are those “boost your computer” software.

P.S “baka” means “stupid” in Japanese. A totally appropriate title for the operators of this company.
See also:

“Fake software nets hacker $158,000 in a week”, Stewart Meagher, The Inquirer, November 5, 2008, (accessed on November 5, 2008)

“Antiviral ‘Scareware’ Just One More Intruder”, John Markoff, The New York Times, October 29, 2008, (accessed on November 5, 2008)

“Crooks can make $5M a year shilling fake security software”, Gregg Keizer, ComputerWorld, October 31, 2008, (accessed on November 5, 2008)

[1] “Russian scammers cash in on pop-up menace”, Asher Moses, The Sydney Herald, November 4, 2008, p.1, (accessed on November 5, 2008)


[2] “Rogue Antivirus Dissected – Part 1”, Joe Stewart, SecureWorks, October 21, 2008, (accessed on November 5, 2008)

[3] “Russian scammers cash in on pop-up menace”, Asher Moses, The Sydney Herald, November 4, 2008, p.2, (accessed on November 5, 2008)

[4] “Rogue Antivirus Dissected – Part 2”, Joe Steward, SecureWorks, October 22, 2008, (accessed on November 5, 2008)

[5] “Infamous vendor of “AntiVirus XP” badware sued”, Adam O’Donnell, ZDNet, September 30th, 2008, (accessed on November 5, 2008