Stealth Trojans
by Commander Crash
You upload a Trojan to a deserving lamer's BBS which simply uses BIOS calls to write random junk to his hard drive. You call back a week later and his BBS is still up. What gives?
It never fails, there is always another anti-virus program, or another environment that stops your Trojan dead in its tracks. There are many things which could have caused your Trojan to have been detected. Either your Trojan's activities are caught by an AV program, or it causes an exception error in a Protected Mode environment. What is usually detected in both of these cases is disk I/O that seemed suspicious or shouldn't have been occurring. In order to prevent such a thing from happening, it is necessary to use "Stealth" disk I/O.
In the early days of the XT, it was easy. AV programs were far from commonly used, and simply calling DOS or BIOS interrupts was enough to do with your target's data as you pleased. Soon, there were hundreds of viruses circulating around and it wasn't long before AV programs were widely used. Most of these, however, relied on searching for a sequence of bytes which identified the virus. This method worked reliably for most of the commonly known viruses once they were discovered, but wouldn't ever detect a home brew virus it didn't know. No matter how many direct sector write BIOS calls it did, it would go undetected. Getting back at a lamer by uploading a Trojan always worked.
Several years later anti-virus programs were developed as TSRs. These programs would intercept any disk I/O and alert the user in the event of anything suspicious. Things suddenly got much more difficult. No longer is disk I/O possible with guaranteed invisibility from the user. To add to this aggravation, Intel adds "Protected Mode" into its latest generation of processors.
Protected Mode was meant to be just that. No program running in Protected Mode could ever get at something it wasn't supposed to. The operating system was the highest level, and would dictate to the applications running under it what they could or could not do. If an application wanted to write directly to the disk, it would have to deal with the operating system. If an application tried to modify memory that didn't belong to it, it would also be denied access. You can see why the future of the PC looked grim for virus writers.
Protected Mode was considered very virus unfriendly. It would be easy for an operating system designer to prevent any virus from ever spreading under it without being detected. Then Windows became the standard Protected Mode environment. A Windows application doesn't have access to BIOS or DOS interrupts at all, so we are unable to do I/O at all using that method.
Windows also doesn't allow an application to directly access the disk using I/O ports without first dealing with Windows itself either. Soon after its release, Windows AV programs detecting everything from INT 13h by DOS apps, to detecting undocumented calls to access the disk were released. It seemed as if detection was inevitable if an AV program was used at all.
In order to hide your Trojan's activities from the computer, it is necessary to make your disk I/O's hidden from the entire system. You can do this by using a technique I am about to describe called "Stealth" disk I/O. By doing this, you not only hide yourself from these aggravating AV programs looking for suspicious disk access, but you also prevent Protected Mode operating systems such as Windows from stopping your program from getting at the hard drive.
Nothing will know that your program is even accessing the disk drive at all!
There is a security hole in Windows we will take advantage of to do this. There is also an undesired feature in standard disk controller cards which will also be used. Windows seems to have no problem giving applications full control of all ports which are unknown to it. This was a big mistake on Bill's part.
But how does this help us? Windows knows about ports 1F0h-1F7h, so clearly disk I/O using these ports will be noticed. If an application tries any I/O to 1F0h, Windows knows you are poking around with the disk drives.
What about port 81F0h? You can read and write to that port all you want, because Windows doesn't care. Because Windows doesn't know what the hell port 81F0h is for!
If you try to do a write to port 81F0h, the processor will send the signals out on the bus telling all the cards that data is being written to port 81F0h. Most cards, however, only look at the lower 16-bits of the address to see if they are being accessed.
What does this mean? Our output to port 81F0h is magically transformed into an output to port 1F0h. Does Windows know? Nope. As far as the processor sees, you just wrote to port 81F0h. Pretty sneaky, eh?
There are ways which AV programs could be written to detect this, however, but none have been written as of yet. What such a program would do is track all access to ports above FFFh, and would be installed in Windows as a virtual device driver.
To demonstrate a practical use of "Stealth" disk I/O, here is a sample Trojan using the technique. It will work undetected in DOS or even in Windows with any AV program installed. It uses two routines you can use in your own programs. hdRW will write or read a buffer to a physical sector, and hdWait will wait for completion of the previous command to the hard drive. Both of these routines use "Stealth" I/O, so they will not be detected.
To install the program, simply run it on some lame PC. It will copy an encrypted version of itself into the boot sector on hard drive 1. The original boot sector is stored in sector 7.
When someone, such as a RadioCrap representative, reboots the machine, the Trojan program is decrypted into memory and run. It will simply decrement a counter in the boot sector, and boot his machine as normal. When this hits 0, look out! The hard drive will be wiped clean, but you'll be long gone.
All attempts to reboot will result in the message "HDD controller failure" and the hard drive will be shut down. The actual motor will be turned off to give that added effect that the data was destroyed by "just another hard drive crash."
If you accidentally run this program, you must replace your boot sector (physical sector 0) before you reboot 10 times, or you're in trouble.
The installer must be run under DOS (you can make a DOS boot disk to bring with you to the target) but it will work with any OS that happens to be running... UNIX, OS/2, etc.
One thing to note, adding 8000h to disk I/O instructions is not needed in Real Mode to do undetected disk I/O. Most AV programs rely on capturing the INT 13h or the DOS interrupt vector to detect disk access. Ports aren't even looked at.
Most people seem to be afraid of poking around with the disk controller directly, but there is nothing to it at all. I guess AV software writers thought nobody would try direct disk I/O. All that would have to be done is to write a program that searches for anything like out 1f4h, al in the EXE files on your system and alert the user. A DOS program will not normally do anything like that, and a Windows program that does anything like that should never be run. I guess it was too complicated for them to do.
BYE_BYE_BBS is just one of the many things one can do with "Stealth" I/O. Does anyone use such techniques in viruses today? As far as I am aware of, no. And it's a good thing, seeing as how undetectable such accesses are with today's AV software.
If someone were to write a mutating stealth virus that used stealth disk I/O, it would be very difficult to detect, and us PC users would be in big trouble. I hope you anti-virus programmers out there take this article as a warning, and add detection for this in your programs.
I also hope Microslut wakes up and learns what Protected Mode really means. In the meantime, here's another way we can give those deserving lamers who cross us some payback!
If you work for an anti-virus software company, and would like some suggestions in adding "Stealth" detection to your software, you can leave a message in my 2600 mailbox. Have phun, and be careful with this info!
Code: BYE_BYE_BBS.asm
Code: BYE_BYE_BBS.exe