141 replies to this topic

[Swami]

Hi All,
I'm not coming here for help (it's too late for that) but i want to warn everyone about a new trojan/virus that is out in the wild and has claimed at least one victim already.

It has the full package, a real trojan's trojan including: a Keylogger, a virus that attacks .exe, .com, and .vbs files, the hidden server, the ability to create ISO files (using exe2bin.exe), and the topper is a hidden "read only" file system containing a boot image and hidden modules that are embedded into your systems ramdisk (BIOS), and infects Windows on every re-install also any hard drive that is connected to the mainboard (before or after infection).

TROJAN INFO-
It attempts to phone home to 239.255.255.250 (a bogus IP) on port TCP 1900 as an instance of svc.host ... has language support for Korean, Japanese, and Chinese...I found 3 website URL's as well, piaodown.net and piaodown.com and a crsky.net ... all out of China.

piaodown.net = [ 218.30.29.186 ]
Registrant:
liwenquan (ODCIORZQDD)
harbin
harbin Heilongjiang 150070
CN

piaodown.com = [ 218.30.29.186 ]
Registrant:
wenquan li (CDXHQTKOFD)
daoliqushangjiangtoudaojie2hao3-2-2-3shi
haerbin Heilongjiang 150070
CN

crsky.net = [ 218.92.244.234 ]
Domain Name: crsky.net
Registrant:
jian pan
RM.502 NO.11 PUHUA ALLEY BAIXIA DISTRICT NANJING CHN
210002

I am no stranger to trojans ... this one is one high tech piece of code. It seems to use a flaw that Microsoft supposedly fixed and that is faking Microsoft digitally signed certificates for drivers (like i386.cab) and it also creates a multitude of hash rules for all group and local policy settings on the victims PC (essentially taking ownership).

It also controls your disk controller (unfortunantly mine was built-in) so you can't use your Floppy or CD-Rom drives to try and combat the trojan, and sets up an ADMIN account.

To make an even longer story a bit shorter ... It can infect AT LEAST Windows XP Home/Pro w/SP1 and most of the pre-sp2 patches installed, and no scanner (TDS-3, Tauscan, NOD32, Sophos, Hi-Jack This, Kaspersky, Trojan Hunter, Spybot, or Trojan Remover to name a few even detects it at all in the slightest fashion. I am working on getting Gavin from DCS the makers of TDS-3 the files from this thing for study when i get going again.

You may wonder how i found it then ... well that is a long story, but it basically started with finding some strange files and file exstensions and ended up with me looking at all the hidden modules and the bootloader and failing to be able to remove anything without the password, at which it then retaliated and filled my drive up to the MAX with temp files (and locked it) forcing a Windows re-install and a re-infection ... this time it would not allow any AV's, Firewall's, or Disk Cleaner's to be installed.

I just bought a new board on E-bay today to replace this trojanized board and some new memory just to be extra safe ... But right now i am using a very weak backup PC and i am not too happy with the money it's costing me.

Edited by Swami, 15 June 2004 - 10:58 PM.

[stockkbroker]

Read about this trojan in a Chinese Newspaper.

Supposedly stole a bunch of money from some Taiwanese businessman.

Have you any idea how you got infected?

Any suspicious websites or downloads lately?

[Misereor]

You don't necessarily have to throw away the old board.

Try booting in safe mode, and running a bios update.
(Safe mode so the motherboard isn't infected again immediately afterwards. Bios update because they normally just overwrite the whole bios rather than "updating" it.)

Reboot in safe mode, enter a command prompt and run a format /mbr
(Format with Master Boot Record option, just in case the boot sector is infected as well)

No idea if it works, but it's worth a shot...

[Swami]

Thanks for all the help offerings i have tried format/MBR and fdisk/MBR to try and clear the rails but its a no go - Just like its a no go trying to kill it in Linux with CF Disk and even the hackers best friend SF Disk and thats while being root (super-user) ... i can see the modules (devices) but when i try to delete them it asks for the password and i don't know any Chinese, nor do i have a keyboard to generate the proper characters. But its not a real disk at all its a RAMDISK Boot Image - but your OS and partition managers see it as a partition and unmountable read only file system.

Here is the type of program used to inject this file system into my boards memory or at least the trojan uses the same theory that allows this program to function - make sure and read some of its features on the users manual link ... scary stuff if its used for evil.

http://cenatek.com/product_ramdisk.cfm
http://www.cenatek.com/User_manual/RAMDiskXP Users Manual.html

RAMDisk is a software driver that emulates as fully as possible the low-level functionality of a hard disk with system RAM. RAMDisk speeds up applications because RAM is much faster than mechanical hard disks for storing and retrieving data. Applications that do a lot of reading and writing to storage, like database queries, will show the most improvement with RAMDisk. 

RAMDisk can be configured to automatically load a disk image at startup and
save the image to disk at shutdown. This allows the RAMDisk to function almost exactly like a hard disk; no data is lost when the power is turned off.

I think the board must die!! not only for my suffering but for its own good.
conventional theory says a "Ramdisk" can't survive without power (voltage) until i read about this software from Cenatek i beleived that, but i still took every single component out of that case including the fans, Power Supply, CPU and disconnected all cables from the board and removed the onboard battery. It still Lives on ... and it's looking like forever at this point.

It has the potential to be very deadly as far as stealing information that is for sure, I feel sorry for that Taiwanese man and glad i noticed it in time ...sometimes it pays to be a geek I have a CD of this trojan/virus full of files ... dll's, cpl's, drivers ... you name it. I will be submitting it to any/every AV/Trojan company that wants it.

To answer on how did i get infected ... i hate to admit it but i know when it happened, and i should have definantly known better. Without divulging too much un-necessary info lets just say i like movies and i also occasionally downloaded them (never again) ... my browser (Opera) warned me that i was connecting to a site with a username and not a web address - i figured its probably this dudes personal server ... it was and it served me up nicely with a fireball straight to the heart of my PC... NOD 32 went off saying i was being attacked by the "small.gl.trojan" (i deleted the infected file - NOD couldn't) ... then i ran Spybot SD and it found a trojan dropper (i deleted that) then it just vanished from all scanners forever including Hijack This and every trojan scanner in existance.

Edited by Swami, 15 June 2004 - 11:17 PM.

[Misereor]

"RAMDisk can be configured to automatically load a disk image at startup and save the image to disk at shutdown. This allows the RAMDisk to function almost exactly like a hard disk; no data is lost when the power is turned off."

I gotta admit I haven't followed the link yet (as I'm at work), but the above quote may describe your problem.

Conventional cmos'es don't save information if you pull the battery and leave them alone for a day or two.
(some keep enough of a charge to retain "soft" data for more than 24 hours.)

Humm...

How about disconnecting the harddisk and doing the bios update from a write protected floppy or USB key.

You should now have a clean bios, regardless of any other factors.

Reconnect harddisk, power up machine with network boot floppy and ghost the harddisk from clean machine via network, assuming you have a viable clone.
(Ghost doesn't work on file level. It simply copies disk sectors, which should enable you to get rid of the modules you mentioned.)

Even if you don't have a viable clone, do it anyway with any image harddisk to screw up the infected disk.
(Your clean bios will be able to autodetect the disk, even if said disk is completely screwed up.)

Then format /mbr from write protected floppy.



P.S.
And sorry if I come off patronizing. I don't mean to, but I've learned to cut out in cardboard everything I explain, rather than risk not getting my point across...

[Swami]

Well since your at work here are some snippets from the manual:

RAMDisk is a kernel level driver that presents a standard disk drive to the OS, however, it stores and retrieves data  from  the system RAM on your motherboard instead of an actual, physical disk. 
Along with the Kernel Driver is a GUI that talks to the driver and allows the user to set various options as well as start and stop the Driver (create or delete a RAMDisk).
The Driver has been written to WDM standards and creates a low-level disk object that Windows Device Manager and Disk Management are able to "see" and manage. 
You can partition, format, mount a volume, and assign multiple drive letters to RAMDisk

You can use RamDiskXP to create a bootable disk image. The following example will create a disk image that can be used to create a bootable CD-ROM.
This simple example will just load the 2000/XP bootstrap, and can be used to start your 2000/XP installation.

To begin with, start RamDiskXP with the "NT/2000/XP Boot Sector" option enabled (under the "Memory Settings" tab).  

Go to the root directory of your 2000/XP system disk and do the following (assuming r: is your RAM disk):

attrib -r -s -h ntldr
copy ntldr r:
attrib +r +s +h ntldr
attrib -r -s -h boot.ini
copy boot.ini r:
attrib +r +s +h boot.ini
attrib -r -s -h ntdetect.com
copy ntdetect.com r:
attrib +r +s +h ntdetect.com

This will install the basic files necessary to bootstrap Windows NT/2000/XP.  For more information, see the Windows NT Workstation 4.0 Resource Kit, p.697.
Save the disk image. RAMDisk can save and load the entire contents of the RAMDisk to any other system disk.


Use "Background Update" when you have a RAM disk whose contents don't change frequently, or has bursts of activity (followed by periods when the driver can catch up).
Otherwise, consider using the "AutoSave" or "Save Image on Shutdown" features.
Selecting Background Update will cause the RamDiskXP driver to spawn a thread that will track changes to the RAM disk and automatically update the disk image file specified

Identify as a true RAMDisk: If selected, the driver will identify the drive as a RAM disk rather than a hard disk.


Sounds like the same technology in RAMdisk has been slightly modified to work for this trojan/virus ... it's similarities are vast.
It leaves the temp files,.dat files, and .config files in the same folders as this ramdisk ... and the whole boot image implanted in the motherboard thing is a big red flag ... even though its been done in Linux for awhile now (not as a trojan).

When i install any Linux it sees the .img file at block 0 and also the read only file system ... but nothing can root it out of my board. The hard drive isn't the problem that's why Fdisk and CFdisk can see it but can't access it and what made me originally think the trojan was in a hidden partition containing a bootloader.

I have an exact replacement board i am looking at on my desk right now ... and 2 new sticks of R-Dram. Unfortunantly i couldn't spring for a new hard drive right now. I am not sure how deep this thing goes or what its capable of ... for all i know it may be the first trojan that infects firmware and i have to destroy every component

Edited by Swami, 16 June 2004 - 02:23 AM.

[Misereor]

Fair enough, but how is the boot image saved on the motherboard?

Is it in the cmos or in some separate firmware memory somewhere on your PC? Or is it on the harddrive?

The first quote seems to indicate that it is loaded from a disk, runs in the ram, and is saved to the disk when shutting down.

RAMDisk can be configured to automatically load a disk image at startup and save the image to disk at shutdown. This allows the RAMDisk to function almost exactly like a hard disk; no data is lost when the power is turned off.

If, when the power is turned off, the infection is only present in the harddrive, then a wipe of the harddrive should suffice.
(Which is why you boot from a writeprotected floppy and clone the harddrive. Or use a refrigerator magnet for all I care... Just don't let the PC read from the harddisk, or the ramdrive will activate.)

If the ramdrive is in cmos or some separate firmware memory, then a floppy cmos/firmware reinstall should suffice. If the ramdrive reinfects before you reboot, then yes you have a problem and will have to figure out a way of physically resetting the memory to factory settings while the power is turned off. (usually described in the hardware manual.)

If that's not possible, then I'm prepared to consider it a lost cause

[Herr_Floyd]

hey Swami, i'm new to this site, but not to the tech/security scene, i was wondering if you could perphaps send me a copy of the trojan that you got hit with to examine?
I am curious about it, and if you have anymore insight besides what you have posted, i would be interested in hearing it.
Good luck getting your new computer online.
-[FCT] Herr Floyd

[Swami]

I am still fighting and still losing ... I replaced the motherboard, hard drive, and memory and put it all in a new case ... and it still lives on. The only common components shared by both builds is the CPU, Nvidia Geforce card, soundblaster live card, and a continuity rim (for R-DRAM memory) which isn't an actual memory stick just a dummy to fool the board so it will boot (Rambus must be used in pairs).
So unless this thing lives in the electricity in my wall then it has to be in the CPU ... right? ... the continuity rim possibly? ... i know how crazy it sounds, but its in one of them for sure. Unless its in the firmware of some of my hardware (DVD, CDRW)

I am beginning to think about just burning everything and leaving this nightmare trojan behind ... but i have too much time and money invested now and have become so determined on defeating this thing that i hate to give up and let it win.

So i ordered another CPU and it should be here by Tuesday or Wednesday ... then i will burn the midnight oil once again tearing down and then rebuilding ... If it's still there after this operation then i am done for good this time

As far as sending out copy's ... i haven't been able to get to the main loading modules (or find them location-wise for sure) i only have files its created or installed (drivers etc...) i am unsure if they are infectious alone or not.

I can see the modules but not where they are ... originally i thought they were in a hidden partition on my Hard Drive and then next i thought in my Motherboards Ramdisk (and or bios) and now were down to the CPU ... it may be prove to be all of them.

I know it changed the geometry of my Hard Drive by reducing the amount of Cylinders and Sectors per track ... I know it took over my bios and drive controller within my Motherboard and enabled some settings and disabled others (such as ECC memory) ... now what did it do to my CPU? ...who knows. It is definantly something you don't want to get loose into your system be it Linux or Windows and especially since it's capability's are still unknown ...But if it can be captured (a big if) i will be looking forward to somebody studying it.

I will update.

Edited by Swami, 25 June 2004 - 06:22 PM.

[macaroo]

Pile every thing in your yard and burn it. If this thing gets loose in the wild everybody is going to be dead!!!

[Herr_Floyd]

Yes burning everything would stop the trojan from spreading, but if you can figure out if anything you have left is salavagable, then you have one up on the coder who made it.
I would like to study it, but witgh a risk of infection like yours, well, it kinda of makes me sit back, and go "Shit, that could have been me". so ya.
and before you burn everything, would you be interested in selling me the old board and the infected stuff. I would like to try it off of that.
good luck with the system

[Herr_Floyd]

btw I found a article on some site while looking up boot sector stuff.
http://www.itsecurit...ecs/aug3001.htm

[Swami]

Pile every thing in your yard and burn it. If this thing gets loose in the wild everybody is going to be dead!!!

Since i used a new board + memory + hard drive = and it lived ... there isn't really a way to infect a processor (that i know of) it has no bios instructions or changeable drivers like most other hardware ... but a videocard does have updatable drivers that could remain on the videocard forever just waiting to be installed or used ... right?

Plus isn't the video bios the first thing that your sub system loads when you startup your PC? ... maybe we possibly have an Nvidia card trojan? ... or the supernatural is at hand?

Any comments or opinions welcomed ... were nearing the end of the line.


Help My PC has Cooties!

Edited by Swami, 27 June 2004 - 01:40 AM.

[awatson]

Hi,

I just signed up for access to this forum after reading your post, swami. I *really* feel for you... especially since I think I have been battling this same trojan for over a YEAR now, if you can believe it. I just wanted to add that it is also capable of infecting MacOS X, and add my story for others to (hopefully) read and learn from. Who knows, maybe by now, a fix has been found and someone will let me know... In reading through your post, it seems like you have taken the same route of troubleshooting as I have, so unfortunately I cannot add to any of your posting for possible help. I believe that it is able to live in the memory and/or bios flash memory space of many different types of hardware (ie video cards, sound cards, mainboard CMOS, routers, etc), and that it may be propagated in an encrypted source or pseudo-code format... this would explain its ability to avoid scans that typically are based on binary signatures and/or fingerprinting. It would also be easily updated this way, since all it would have to do would be to grab some sorce patches for the 'Net. Finally, this would also explain the seemingly infinite number of processors and platform OS's it is able to exist on. I could be wrong, though -- I've learned that this thing is quite the shapeshifter, and that just when you think you have a handle on how it operates, all of the rules change.

Pile every thing in your yard and burn it. If this thing gets loose in the wild everybody is going to be dead!!!

Too late. This virus / trojan has been around for long enough now that it has most likely infected countless numbers of systems, of which probably only a few small percent of the system operators know anything is wrong.

For me, everything started on May 13, 2003. I had recently moved into a new house, which had previously been occupied by the homeowner and 2 roommates. Before I lived there, the 3 of them each had computers that were all networked to a single Linksys router for shared cable access.

To make a long story short, soon after I had networked the 2 of our computers (along with 5 others of mine - I am a software developer and also have a music studio), I began noticing extra network activity when no net-based processes were running on my machine. Being security-concious, I began a search for what would become one of the most sophisticated, elusive, and downright SCARY virii I have ever known. I have tried everything you mention in your post, along with a slew of other things, all for naught.

It has been a nightmare. Because this virus is so elusive, and because no scanner I have been able to find can detect it, it has been EXTREMELY difficult to find any information regarding it. I have been able to capture and study a long list of its actions and methods, but it able to learn and modify its behaviour over time, even past reinstalls. I almost wonder if its many copies that have infected other machines around the world are doiing some sort of collaborative information-sharing that is collectively shared with the whole - akin to how the "Borg" on Star Trek TNG would operate...

Worst of all, I have become quite experienced at detecting its presence on other machines... but trying to explain to someone that they have a virus that nothing can detect - especially other IT professionals, is not an easy thing. In fact, several times it has cause me to even doubt my own knowledge and experience of the computer systems and OS's I have worked with for many years... a very humbling and disturbing experience. Several times over the course of this last year, I have literally thought I was losing it...!

Thanks for reading and sharing... and please share any more details you have, publicly or privately. Also, I have plenty of machines (and parts), CD, and DVD backups of systems crippled by this thing, and would be willing to help in any way I can to find a viable solution to its removal and destruction.

This is truly the scariest thing I have ever seen in the trojan / virus world. I have suffered countless hours of downtime (not to mention stress) because of its effects, and would not wish its infection on even my worst enemy. I am very curious to know who is behind its development - whomever it is has one hell of a gift for programming, that's for sure - too bad they used it in such a maligned way. I hate to imagine what the consequences will be for the world-at-large when future iterations of this nasty creature get deployed... because I no longer think this battle is just about your home pc systems anymore...


Adam
adam (at) atombang (d o t) com

[gibbonsl]

how can i find out if a person has this virous?

first time poster here long time poster at AMDMB.com and short-media and EB

nice lay out you have here

[Misereor]

This is getting more interesting all the time. Assuming that you have made no mistakes, what you are saying is very scary...

Swami, I don't know if your hardware supports this, but have you tried physically resetting firmware memory on all units to factory standards?
Assume it infects *everything*, and do a full sweep.

Firmware is not dependent on the OS, the OS is dependent on the firmware, and it is stored in offline memory. My guess is that you've encountered a highly sophisticated piece of code that takes advantage of that.

AFAIK, not even all hardware allows a physical reset, so there may be no way of removing the infection without the host immediately becoming infected again, until industry standards are changed.


I would start looking for professional help if I were you.
Talk to someone at a major AV/antispyware provider, and see if you can figure something out.

Having a dozen machines that can be sacrificed for the cause in order to figure out how this malware is spread may not be something you can afford, but I doubt the prospect would scare Symantec or Computer Associates...

<edit>
It's an old adage in computing that physical possession is the absolute trump.
That may just have changed... :eek:
</edit>

Edited by Misereor, 28 June 2004 - 12:51 AM.

[Misereor]

Hmm...
Another thought just occurred to me.

After the new components were added, when did you realize that the machine had been infected?

Was it before or after installeing the OS.
If after, where did you get the CD you are installing from?

[downripper]

Hi, I am new here and very surprise with your post and register just for that.

After reading all the posts, I found no info about how you know you are infected. Please advise.

I have thinking after reading all the post.

If the trojan does infect firmware, then it must work the same way as those software flash updaters like the one supplied for the motherboard and etc. I do not know how the newer flash writer works on Windows. In the old days, we have to boot into dos to do it. So, the trojan is not actually exploiting a bug/hole/flaw in Windows!. Once, it reaches the firmware, it copies the old firmware which usually has space unused and wraps it inside and writes back to flash. But, the unused space will be different depending on the hardware and the manufacturer, if the space is not enough, it will spread into different hardware. I guess there is some sort of reconstruction algorithm if one piece is missing. So, it can write back the bit to a new hardware flash if that piece is missing. When it runs the trojan use the ramdisk to grab a legitimate range of memory for its use and modify it so that it can use it for running and storage.

very clever and scary!!!

BTW, is the prompt for password in Chinese? can you post it here? May be I can help to translate.

[cr42h]

Hi there,
this topic sounds like out of a Sci-Fi-story, I am really interested in this trojan. Would you mind sending me a CD with the files found on your system? I also would like to have a look at your infected machine. Don't burn it, isolate it and study it, with or without proffessionel help its important to gain knowledge about your enemies.
Well please contact me via email trojanex@gmx.net so I can send you my address.
Good luck removing that trojan.

CU cr42h

[Herr_Floyd]

Swami, can you send me a cd with the infected files on it also?
if you can e--mail at Jef.Spence @ Telus.net, and I'll give you my address
thanks
-Herr Floyd

[novaflare]

I am still fighting and still losing ... I replaced the motherboard, hard drive, and memory and put it all in a new case ... and it still lives on. The only common components shared by both builds is the CPU, Nvidia Geforce card, soundblaster live card, and a continuity rim (for R-DRAM memory) which isn't an actual memory stick just a dummy to fool the board so it will boot (Rambus must be used in pairs).
So unless this thing lives in the electricity in my wall then it has to be in the CPU ... right? ... the continuity rim possibly? ... i know how crazy it sounds, but its in one of them for sure. Unless its in the firmware of some of my hardware (DVD, CDRW)

I am beginning to think about just burning everything and leaving this nightmare trojan behind ... but i have too much time and money invested now and have become so determined on defeating this thing that i hate to give up and let it win.

So i ordered another CPU and it should be here by Tuesday or Wednesday ... then i will burn the midnight oil once again tearing down and then rebuilding ... If it's still there after this operation then i am done for good this time

As far as sending out copy's ... i haven't been able to get to the main loading modules (or find them location-wise for sure) i only have files its created or installed (drivers etc...) i am unsure if they are infectious alone or not.

I can see the modules but not where they are ... originally i thought they were in a hidden partition on my Hard Drive and then next i thought in my Motherboards Ramdisk (and or bios) and now were down to the CPU ... it may be prove to be all of them.

I know it changed the geometry of my Hard Drive by reducing the amount of Cylinders and Sectors per track ... I know it took over my bios and drive controller within my Motherboard and enabled some settings and disabled others (such as ECC memory) ... now what did it do to my CPU? ...who knows. It is definantly something you don't want to get loose into your system be it Linux or Windows and especially since it's capability's are still unknown ...But if it can be captured (a big if) i will be looking forward to somebody studying it.

I will update.

Question first off do you have a older programable keyboard one of the ones you can program text macro into? If its a older one and stores the programable keys key strokes on the key board this could very well be the source of your reinfection.
Another possible source is your video card remember it has a bios that is flashable. Remember back when 3dfx had just went under and some jerk made a "bios update" that ruined 3dfx voodoo4 and 5s? Was also a unconfirmed rumor that a virus was wrote that infected the bios of the card.

Another possible and far more likly source is your installing something from a burnt cd that you think is safe and clean and isnt.
Cpu is not even remotly possible to infect with a virus
harddrive controller board on the hd is remotely possible to infect as is the cd burners bios.
I highly doubt it will be a bios infection though Smell like reinfection by burnt cd to me personaly.

Ive not read this entire post yet so if this is coming back on just your os install and your os install is not a pirated copy or a copy of xp with a activation crack applied then please forgive me.

At any rate this could be something new and very intresting to find a solution for that doesnt involve swaping out all your hard ware. If it turns out to be some bios thats infected barring it is infact a key board a reflas should get rid of the virus perm. But it may be wise to send off the infected component to a av manufacture or 2 who knows.

[Swami]

Well it feels good to know i am not insane and someone else with some experience has had contact with this THING! ... I used to be the guy that removed this type of stuff from friends and family's PC's ... but i feel so totally beaten up by this virus/trojan that i seriosly doubt if i know anything anymore.

I lost my battle ... I got infected on Memorial weekend and tried killing it all the way up to last week when i gave up. I have built an all knew system using no parts (including cables or cd-roms) from my old one ... yea i know trojans aren't supposed to live in hardware especially a cable ... but beleive me if you ever meet this THING face to face you will begin to act erratically too after about 7 or 8 weeks and begin to believe it has super-powers ... i put absolutely nothing past this THING!

I honestly thought about contacting "Homeland Defense" or some branch of the law/government about this as i believe it has the potential to be a major security risk if it found its way onto a sensitive machine (government, law enforcement etc...) I like you think that 90% of people that have it probably are unaware ... i would be too if i wasn't a super geek.

Hearing it also runs on Mac/osx as well as the latest Windows and Linux sends a shiver down my spine ... it has to be one of the most intricate and smartest piece's of coding i have ever seen ... maybe that anyone has ever seen.

I actually chuckle at the thought of running an AV and trojan scanner and firewall now after i used to rely so heavily upon them ... useless resource stealers are all they are to me now. There is no defense and no cure except not getting it at all.

This thing has cost me my whole summer so far and about $850.00 dollars ... And i am so shellshocked now that when i go to fire up my new PC it won't surprise me if somehow someway it is in there too.


To answer the post regarding possible re-install of already infected discs ... All the Linux discs were downloaded and burnt by me last summer .... but i didn't even try using them until after my Windows infection (just to try and kill it) and that's when i found out it works on Linux as well.

My XP Pro with SP1 is from Best Buy and as far as i know it's a good copy ... i have ran it over a year with 2 or 3 re-installs prior to ever metting up with this infection and never had any problems. I also have Windows Server 2003 i bought to try and install over the infected XP and it refuses to install ... Error message saying: Trap Error ... Installation Aborting.

This thing is brutal on it's nicest day ... i would be willing to box my whole infected PC up and ship it to Symantec or any other AV/Trojan company if they wanted to study it at work. My guess is ... if i have ran acrossed it then i am sure they have heard of it by now but may be as helpless as i am against it. I honestly feel deep down that if you get this your finished for good ... or at least that PC is.

Like i stated earlier ... It wouldn't surprise me if it was living in the electric in my wall.

Edited by Swami, 12 July 2004 - 10:49 PM.

[Swami]

Now that i read everyones ideas and see all the posts i am thinking more and more that it is a firmware trojan ... I find it very hard to believe that one piece of code could work flawlessly on every OS platform.
The common threads are my keyboard, cd-writer, monitor, video card, and the install disks.
I have ruled out the mainboard bios because i installed a new board with a clean and higher numbered bios on it, and this board was also brand new in the box ... and the trojan was still there.

It has to be in the firmware somewhere ... or it somehow re-opens closed burning sessions and rewrites information onto installation disks ...which is virtually impossible.

On the new machine i did not even install an OS ... i just used a Linux disk that runs of the cd. But i have seen the install screen a billion times in the last month or more to know that as soon as i see: installing on shared memory and rpm overides by ACPI warnings that its alive and well. In Linux just open up a console and hit "w" without the quotes and it will tell you how many users are currently on your machine ... I always have 2 users listed ... me and a duplicate of me and under the logged in time it shows a "?" question mark for my duplicate. Nightmare City.

[Misereor]

I have ruled out the mainboard bios because i installed a new board with a clean and higher numbered bios on it, and this board was also brand new in the box ... and the trojan was still there.

What firmware capable hardware and disks were connected when you did this? Did you connect a single piece of hardware at a time, or just plug everything in?

Since I had my sense of humor surgically removed when I was four, I will waste time in pointing out that it does not live in the electricity in the wall. It is in memory somewhere. Isolating it must be the first step.

Normally you would do so by installing one piece of hardware from the infected machine at a time into a brand new, uninfected machine.

Since you do not have the resources to waste on getting a dozen machines to play around with, get help from someone that does.

Call up your local, friendly AV provider, get someone, a software engineer or something, on the phone, and explain your case.
They will have the resources to disassemble this little #¤%&!, and find out how it ticks.

If not, go to their competitor, explain that you have discovered a new type of malware, and make sure to tell them that AV company#1 wasn't interested, but that "this is big".
(Nothing peaks interest like getting an advantage over a sworn enemy...)

[novaflare]

Now that i read everyones ideas and see all the posts i am thinking more and more that it is a firmware trojan ... I find it very hard to believe that one piece of code could work flawlessly on every OS platform.
The common threads are my keyboard, cd-writer, monitor, video card, and the install disks.
I have ruled out the mainboard bios because i installed a new board with a clean and higher numbered bios on it, and this board was also brand new in the box ... and the trojan was still there.

It has to be in the firmware somewhere ... or it somehow re-opens closed burning sessions and rewrites information onto installation disks ...which is virtually impossible.

On the new machine i did not even install an OS ... i just used a Linux disk that runs of the cd. But i have seen the install screen a billion times in the last month or more to know that as soon as i see: installing on shared memory and rpm overides by ACPI warnings that its alive and well. In Linux just open up a console and hit "w" without the quotes and it will tell you how many users are currently on your machine ... I always have 2 users listed ... me and a duplicate of me and under the logged in time it shows a "?" question mark for my duplicate. Nightmare City.

um i hate to say this but you could have infected the new mother board as well. You likly wont be able to track the hard ware down that is infected if it is. You will need to reflash your new mother boards bios then hook up each piece of hardware in turn untill your reinfected go with a raw os install no drivers beyond what it install be that xp 2k or 98. have your anti virus running that detected it and nothing else.

[Swami]

What firmware capable hardware and disks were connected when you did this? Did you connect a single piece of hardware at a time, or just plug everything in?

I had an extra case and i installed a board that i had purchased (a duplicate of the infected board) into it.
I did not install a hard drive at all.

I used from the infected system:

• Sony CDRW
• Keyboard
• 1 Continuity rim (needed for Rdram memory)
• GeForce 2 Card
• Sony Monitor
• Mouse
• IDE Cables/MPC Cables

Everything else was brand new... the board, processor, PS, etc....
It seems most likely the videocard (being flashable) or the continuity rim were the culprits to me ... but it could be the CDRW or other hardware ... who knows.
I ordered new components from newegg.com this week ... I have finally had it with fighting it. They are due to be delivered Thursday.

I know this sounds rediculous but ... do you guys think i can safely use my monitor? if it is a firmware trojan? I think most monitors require some type of driver and contain firmware don't they?

I'm Freaking Out

Edited by Swami, 13 July 2004 - 01:03 PM.

[pillo79]

Hold on a second. I am a super newbie on this forum, but as many others registered just for this to give my $0.02.

There are many things that are wildly unbelievable.
First of all, I am sorry but I do not believe that what you say is true, this is not for flaming but it really seems science fiction to me.
There just can't be a software capable of hiding in the BIOS or firmware of different THINGS. Damn, two revisions of the same BIOS have different structure; making something able to deal with the internal details of both of them is already complicated. How can you even conceive a program that, for DIFFERENT KINDS of device,

Once, it reaches the firmware, it copies the old firmware which usually has space unused and wraps it inside and writes back to flash.

because the number of variables is astounding... and apart from the fact that the free space is in the range of 100's of BYTES! Moreover,

I believe that it is able to live in the memory and/or bios flash memory space of many different types of hardware (ie video cards, sound cards, mainboard CMOS, routers, etc), and that it may be propagated in an encrypted source or pseudo-code format... this would explain the seemingly infinite number of processors and platform OS's it is able to exist on.

(which is absolutely right, if this is true), but please explain me how do you create a trojan with a self-cross-compiler in, say, 4096 BYTES. Also, in case, send me your compression algorithm
Seriously, there is NO WAY that this could exist. The trojan needs, as a minimum, a Windows hook in such a way to allow it to download the rest of its software from the net as soon as the connection is up. How to do this from the BIOS code (which goes unused after Windows boots) is complete mystery to me...


Regarding your original post, Swami, there are points very unclear to me.

I have tried format/MBR and fdisk/MBR to try and clear the rails but its a no go - Just like its a no go trying to kill it in Linux with CF Disk and even the hackers best friend SF Disk and thats while being root (super-user) ... i can see the modules (devices) but when i try to delete them it asks for the password and i don't know any Chinese, nor do i have a keyboard to generate the proper characters. But its not a real disk at all its a RAMDISK Boot Image - but your OS and partition managers see it as a partition and unmountable read only file system.

1. what "modules (devices)" are you talking about? Please install Linux (or use any Linux boot CDs) and post the output of the "dmesg" command. This shows what Linux found out during the kernel initialization. Be specific about what does worry you.

2. "when I try to delete them it asks for a password". Please explain in MUCH more detail this! What are trying to "delete"? Where are you? (BIOS? Linux console? Windows device manager? ...)

3. "your OS ... see it as a partition and unmountable read only file system". The two things are separate. They may see it as a partition, but Linux doesn't mount anything until you say it to!

I think the board must die!!  not only for my suffering but for its own good.
conventional theory says a "Ramdisk" can't survive without power (voltage) until i read about this software from Cenatek i beleived that,  but i still took every single component out of that case including the fans, Power Supply, CPU and disconnected all cables from the board and removed the onboard battery. It still Lives on ... and it's looking like forever at this point.

The software you mentioned works for Windows XP only, and uses standard device drivers to write and read the ramdisk to a temporary drive image, as you said. It NEEDS the disk image *as well as Windows and its setup * to be able to work... nothing comparable to what you are explaining.

Conclusion: either you have a MUCH simpler solution (common trojans that infect windows from the network) or everybody has been already subverted. And in that case, I wonder why the guy that wrote this didn't provide a patch to stop me in writing this forum message.
And rest assured, you can use your monitor (unless THIS is able to infect it via DDC channels which is monitor->PC only... but maybe it is able to ride the cable uphill )

I repeat, no offence to anybody but if this works as described, it is simply too many steps above -any- other kind of spyware. it is not even a virus. it is itself!

Edited by pillo79, 14 July 2004 - 04:17 AM.

[Misereor]

It seems hard to believe for the rest of us too Pillo79, but that does not mean it is impossible.

The first thing Swami did was a reinstall, and the PC was reinfected.
This would normally indicate a bootsector virus, or a memory resident executable (ramdisk), if he tried to do a reinstall without booting from the CD.

When this didn't work, he then booted from a disk, did a format /mbr, and to his surprise discovered that a ramdisk was present.
(Not the usual ramdisk you get with an fdisk boot, gathering from the other information he has given us.)

Now, if he booted from a floppy, where did this ramdisk come from?

Assuming Swami's information is correct (and I *do* assume it, as he is generally quite knowledgeable), the infection has to have been resident in some type of offline memory. That would normally be the harddisk, but since a harddisk was never accessed on reboot, it must have been somewhere else.

That leaves flashable firmware memory.
<edit>The obvious candidates being the bios or any usb device, as these are accessed on boot by most modern computers</edit>

There may well be an important piece of information missing in this equation, but regardless I think the situation needs more investigation.
(And yes, I'm aware of the fact that I sound like Johnny Cochrane.)

The simplest solution would be to take a clean, uninfected machine, add one piece of hardware from the infected machine at a time, complete with reboot, and see exactly when the machine becomes infected.

Regardless of when the machine became infected, you would ofcourse have to test the remaining hardware as well, in uninfected machines, just in case...

... and if it never became infected, Swami would have to buy a truckload of beer for the people in this thread

Anyway, the saga continues.

Edited by Misereor, 14 July 2004 - 07:33 AM.

[awuh0]

Finally I found somewhere on the internet were someone else has this evil virus and realized it.....
I have replaced motherboards, low level formats, other operating systems everything... its still there it even poped up a message telling me I failed to get rid of it ... again
I hate it it wont die..... why
anyone have more success at killing this thing?

from what I know of this virus it spreads threw networks and boot loader the latter is how I got it, cursed usb flash card @ library

I have seen this virus on *alot* of computers I run a computer repair shop and have seen it on almost all coputers sent in. This thing is really scary.

nothing picks it up and it overwrites operating system files as well as some other softwear.

while you are online it downloads 'updates' threw your browser, (It infects any from IE to netscape to mozilla firefox) and also spreads them to any other machines on your network

[pillo79]

It seems hard to believe for the rest of us too Pillo79, but that does not mean it is impossible.

I see you have some experience with computers!

Now, if he booted from a floppy, where did this ramdisk come from?
(Not the usual ramdisk you get with an fdisk boot, gathering from the other information he has given us.)

Good question. In fact, I would really like to see the dmesg output from the Linux kernel, as it shows all kinds of devices being recognized with great detail. But what I don't understand is where the virus stores all its data, as it would need a lot of nonvolatile space... and assuming it is not the harddrive, which was deeply formatted and replaced ... very little remains...
You must also think that there is no way to distinguish used firmware space from free space, from outside it's all ones and zeroes, so it's -very- risky to try to write to these areas, and the ways to write are soo many... and to top it off, most systems have protection against this kind of attack by having checksums computed at boot.

Adding items to an uninfected machine until it gets infected is a sure but costly solution. But could someone detail a bit more what are the symptoms? And also, how to find it out before windows is installed...

<edit>
Sorry Swami, I did not read your posts so carefully.

On the new machine i did not even install an OS ... i just used a Linux disk that runs of the cd. But i have seen the install screen a billion times in the last month or more to know that as soon as i see: installing on shared memory and rpm overides by ACPI warnings that its alive and well. In Linux just open up a console and hit "w" without the quotes and it will tell you how many users are currently on your machine ... I always have 2 users listed ... me and a duplicate of me and under the logged in time it shows a "?" question mark for my duplicate. Nightmare City.

I didn't understand this sentence: "as i see: installing on shared memory and rpm overides by ACPI warnings that its alive and well". Could you please say it again?
As for the "w" thing, I believe it is a quirk of your particular Linux CD. (And BTW, I'm curious to know which one is that ). If your PC was booted from a CD, without any network connection, come on, nobody -could- have logged in except you. No firmware on Earth is able to ask Linux to log on after having stolen your password... of this I am reasonably certain. Which TTY does the "w" command report the logon?
</edit>

... and if it never became infected, Swami would have to buy a truckload of beer for the people in this thread

Yes, definitely; I believe it is written in the forum's agreement !

<edit> Sorry for the multiple edits, we cross-posted in a few minutes...

it even poped up a message telling me I failed to get rid of it ... again

It's nice (in a certain sense) to see that Swami is not the only one to have experienced this. Please explain in much detail this sentence! This is really driving me mad...
</edit>

Edited by pillo79, 14 July 2004 - 09:17 AM.

[n1mr0d]

pleeease tell me you DON'T run a computer repair shop if you can't spell softWARE correctly.

and the thought that every computer that runs through your shop seems to have this virus is a bit disturbing, kind of like a mcdonalds cook that adds his own special sauce.....


swami, why don't you try this?

keep your motherboard, cpu, ram, but ditch your hd and your current os install cds. pull the network card.

go out and buy a hd and windows xp. or at the very least, get a FRESH copy from one of the many sources.

install xp on the new harddrive.

put your favorite AV on a cd with the latest updates, and get a firewall on that cd too.

install the AV/firewall from the cd.

scan your system. lol, good luck findin somethin without a NIC.

now go download SP1 and all the latest updates and put them on a cd, also.

install sp1.

put your NIC back in your new puter.


enjoy being virus free


seriously, this is retarded. want a ramdisk to disappear? pull the plug on your HD before you shut it down, and turn off the computer. then pull the ram out, just to be doublely safe. bye ramdisk.

i'm willing to bet you have infected/tainted os cds.

[Tuxedo Jack]

How about this? Hook it up to a LAN with a Linux proxy, turn it on, then hustle over to the proxy's terminal (NOT ON YOUR MACHINE WITH TERMINAL SERVICES), and use Ethereal to packet-sniff what goes out from it? If there's something transmitting or receiving, Ethereal will pick it up thanks to the proxy.

[j823777]

TROJAN INFO-
It attempts to phone home to 239.255.255.250 (a bogus IP) on port TCP 1900 as an instance of svc.host ...

239.255.255.250 port 1900 is the Simple Service Discovery Protocol (SSDP) using multicast to locate a gateway. Perfectly normal, nothing to worry about.

I need more convincing this is real... What other symptoms of infection are there? How are you determining that you are re-infected once you've reformatted / changed the hard disk / cleaned the motherboard with detergent...?

I'd like to see everyone who claims to be infected reporting the same symptoms otherwise I'm going to have to class this as people blaming undetectable malware for software incompatibilites, misconfigurations and hardware malfunction on their individual systems that they can't trace by any other means.

Either that or its an elaborate wind up.

[New Raider]

hey Swami, i'm new to this site, but not to the tech/security scene, i was wondering if you could perphaps send me a copy of the trojan that you got hit with to examine?
I am curious about it, and if you have anymore insight besides what you have posted, i would be interested in hearing it.
Good luck getting your new computer online.
-[FCT] Herr Floyd

I'm sorry if I am wrong, but by that statement, you sound like you are interested in being a copycat spyware distributer.

[Misereor]

But what I don't understand is where the virus stores all its data, as it would need a lot of nonvolatile space...

Then again, maybe not.
All you would need was a few kilobytes. Just enough for a single executable file.
It wouldn't have to contain anything nasty, just an infection vector, and where to go to get the rest of the files it needed (looped).

And I assume that even firmware memory has some form of memory allocation method that is universal (OS'es have to read it after all), so I doubt that it's just random one's and zero's.

If you knew how such memory is allocated and placed your file at the end of the available memory, I doubt it would ever be overwritten unless you overwrote the entire firmware memory.

Even then it might have to be a cold reset, just in case the little bugger had a checksum of it's own, and reinfected the firmware memory as soon as it didn't detect itself there.

.........

...Ok, that was a stretch of the imagination.

But assuming that such a thing is possible, the next question is how such a file could be accessed.

If bios resident, that would explain alot. It would then be a simple matter of irq redirects. That's how some of the old boot sector viruses worked.
(Original irq: When X do Y.)
(Redirected irq: When X do Z and afterwards do Y, so the victim doesn't suspect anything.)

But Swami said he changed the motherboard.

Ofcourse if the method above is possible, there is a remote possibility that he could have compromised his new bios by putting all the other firmware in the new PC as well, just in case it was infected as well, and was running the checksum I mentioned above.

The reason I mentioned usb devices, is that all the modern bios'es I know of, are capable of booting from them. There are some difficulties with this approach that I'm not sure can be overcome, but there are alot of things I don't know about hardware and coding, so I guess the option should be kept open. It is offline memory after all, and one of the few things we know is that it is spread from offline memory, so it would be foolish to dismiss the notion before having more information.


Anyway, this is all assuming that we have correct information from Swami.

If we do, then it would indicate a level of threat that is as of yet unsurpassed, and definetely something worth further investigation.

If not, then we have lost nothing, except the time used indulge our paranoia.
(Apart from Swami, who will also have lost several nights worth of sleep and next months paycheck which will be used to buy lots of beer...)

[pillo79]

I agree with you on most of your reply. But let me add a few remarks:
(yes, we're reaching real paranoia status! )

even firmware memory has some form of memory allocation method that is universal (OS'es have to read it after all), so I doubt that it's just random one's and zero's.

There's a subtle distinction in what non-volatile memory is used for. BIOS data (such as POST results, timer, and I don't remember anymore what else) is stored in certain predefined positions, which were fixed in the 80's and never touched anymore. OSes go and read these information during the boot sequence; however, this contains only hundreds of bytes (if I remember correctly was <256), and therefore is -so- crowded that storing more than 2 bytes would be tricky.
The bigger part of the non-volatile memory in today's computers comes from the BIOS code itself, which is not put in ROM as in PC-AT's, but in Flash memory. This has a much greater size (I remember some boards having 512kB or more), BUT the contents aren't fixed by any standards (apart from the address space occupied). The code in this memory block is decided by the board vendor/system integrator in full freedom, which means that there's no way to find out which sections of the memory are used and which are not.
Moreover, this memory can be written only in blocks, and also the way to program this memory is unique, board by board -- try using another board's BIOS update software and force it to run on yours, and observe your board turn to ashes.

Old boot sector viruses (--which were not BIOS resident, but hard-disk resident--) worked exactly as you explained. But in current OSes, the BIOS code is executed at system boot and never again, because immediately after boot all IRQ handlers are redirected to internal drivers *which, assuming they are not infected, being a clean install, can't be fooled*.
That technique worked flawlessly with fatally old systems such as DOS or Win95, where the BIOS was ultimately in charge of writing data to disk. Todays operation goes from the OS directly to the IDE device-- bypassing any BIOS out there.

And, going slightly OT, many are proposing to remove the BIOS altogether (as it is now ridiculously outdated) or replacing it with a completely new boot system designed for today's computers, with MUCH more integrated PnP support, boot sequencing and more.

To sum up, I still don't believe it... there are SO MANY easier ways! Heck, I believe it's easier to come in your house at night and your PC!

[Misereor]

The code in this memory block is decided by the board vendor/system integrator in full freedom, which means that there's no way to find out which sections of the memory are used and which are not.

So they are not universal, but specified by the driver?
Ahhhhh... I guess you learn something new every day.

Ok, so if that is the standard for all flash memory, I guess that means that Swami (if he isn't busy talking to some AV vendor like some of us suggested ) starts from step 1 again, and sees if the same results come up this time round...

If they do, we are gonna need step by step documentation.
If they don't... Well, it was an interesting discussion anyway...

[pillo79]

So they are not universal, but specified by the driver?

Yes. Actually it has nothing to do with drivers; the BIOS is code that's completely OS-independent. Its original reason was exactly that: to make different PCs able to use the same OS by doing all the low level work... somebody sooner or later must know which phisical line to raise or lower for the data to be sent. What we call "driver" is the same concept, done in software instead of hard/firmware-- but remember we're talking 80's here

And that is the reason why it is so different... since board makers have reasonable freedom in choosing components, each BIOS has to handle with the phisical ICs on the board in a different way, and set everything up much earlier than Windows could be started.

Anyways, interesting discussion indeed!

[Exasperated in Phoenix]

Howdy, Swami!

I'm a hardware jock, so I have more than a passing familiarity with the guts & bolts of a PC. Some of the comments in this thread are HILARIOUS, some thoughtful, a few right on-target.

When you re-infested your machine, you used: keyboard, cd-writer, monitor, video card, install disks. How about mouse, as well? Do you connect through a router box with a NIC, or use a dial-up modem? A lot of modems have a Flash area for updates of the modem chip, which could theoretically be used to send some errant code up the serial or USB port. A modem is a microcontroller with a DSP chip, and most of 'em I've seen were possible to infect if you were bright enough.

I'd class it as "nearly impossible" for it to come through the monitor or genuine MS install disks, but keyboard, CD-R and video board are all easily possible. Older stupid keyboards used the 8048 micro and weren't infectable, my newer one uses a Microchip part and a little flash to store macros. Dunno about yours, but the firmware on my CD-R is update-able (thus infectable), same for the video board. Both are installed in the BIOS boot process, and could run code snippets.

If you're using an intelligent router and a NIC to connect, it's possible that something hacked the router and it's backing into your PC that route. There's MORE than enough storage in smart routers, and probably enough in the boot ROM area of NICs that allow network-boot for your little piece of grief. It could hijack the DHCP configuration and re-route all of your packets through a third party, if so. Anyone with engineering-level design experience on a particular router could come up with a "back door" to trash that router. Not really likely, but do-able.

Another wonderful place for storage are the PnP "ROM"s and the NIC MAC storage. Some are hard OTP devices, most are Flash or EEPROM. They're usually 2K bytes or smaller, but I've seen viruses written in less than 500 bytes of code.

USB mice shouldn't be a problem as long as they're not using a Flash microcontroller. As another poster noted, USB services are installable from the device under Win2K & WinXP, so it's at least remotely possible that your mouse is the source of the initial loader module. What an ugly thought... mine's a dumb serial mouse with an OTP micro, not infectable.

If the geometry of your harddrive was modified, then SOMETHING is hiding in the excess area that it freed up by reducing the SPT and cylinders. You'd need to do a raw search of the drive to find anything with the appropriate forensic tools. Personally, I'd use the manufacturer's sw tools to reset the geometry (on a clean machine), then do a full low-level format and complete wipe. Depending on what type of drive you have, the manufacturer's tools may be able to do all of this for you. By the way, most IDE drives I've seen recently use Flash for the little micro on the board, and something may be hiding in there, as well. Huge amounts of free space are available in most Flash devices (I'm talking about Flash PROMs, not the thing you borrowed from the library) used to program micros and load FPGAs. I've only rarely done one that had less than 100K free space. Multiply that by the number of Flash chips in the average computer, and it's a sizeable area available to the creative @##h*les that write this junk.

You don't have to worry about cables or power supply, but I'd start off with a virgin system, using NOTHING else from the previous set-up. That includes your router or firewall box, if you're running one now. Your monitor should be safe as it just passes info to the ACPI handlers about scan rates and such, nothing executable. Don't keep anything with ICs in it in the new setup.

ABSOLUTELY DO NOT send copies of this thing around, *particularly* to folks that aren't admins on this forum. Do feel free to mail it to AV vendors, but if it's truly this nasty, you do _not_ want to randomly hand it around to people you don't know. There's probably at least a few idiots here that are lurking for ideas to use in their next exploit. Sounds like you already have a hefty dose of paranoia, so extend it to the folks here. I'd rather not find a variant of it next month out on the 'net.

[Swami]

seriously, this is retarded. want a ramdisk to disappear? pull the plug on your HD before you shut it down, and turn off the computer. then pull the ram out, just to be doublely safe. bye ramdisk.

i'm willing to bet you have infected/tainted os cds.

pleeease tell me you DON'T run a computer repair shop if you can't spell softWARE correctly.

and the thought that every computer that runs through your shop seems to have this virus is a bit disturbing, kind of like a mcdonalds cook that adds his own special sauce.....

I don't need your junior league observations ... I am quite aware of how a ramdisk is supposed to operate and have forgotten more about trojans than you will probably ever know ... if your sick of reading the thread ... then why not stop. And as far as mis-spelling the word software ... that is a very childish and idiotic thing to pull out of a thread and try to use as some sort of ammunition to do what? ... make yourself look smart?

If you could comprehend half of what you read you might be tolerable ... I didn't say i run or work in a computer shop ... I made over 8 DELIBERATE infections to try and study the trojan ... I finally bought a new board ,ram, and cpu and it re-infected it ... So where do you get i am churning out infected computers like an assembly line idiot?

I graduated college 15yrs ago ... let's see if you can make it out of high school junior ... i doubt it.

----------------------------------------------------------------------

To those with useful input (Miseror), (Exasperated in Phoenix) ... I set the hard drive up on another system and made it a slave instead of master and hand modified the geometry by using the size+ command and got rid of the un-touchable partition. But whatever is in the ramdisk area or flash memory of the as yet un-identitified component is still there ... if i had to make a guess i would say its in the Nvidia drivers.

But its over now ... i am taking the PC to its final resting place ... my stinky dumpster.
This thread has obviously reached its full potential of being useful, and has turned into an apparent magnet for the braindead ... so good luck to you all ... especially the idiot "Nimrod" , your going to need all the help you can get my friend.

Edited by Swami, 20 July 2004 - 11:49 PM.

[Misereor]

Whoa, calm down buddy. He was referring to awuh0, not you.
(Not that that makes the personal attacks allright...)

How about making it 9 times, instead of giving up?
Now that you have the capability of removing the ramdisk boot area on your infected harddisk, you have a little more room for manouver.

So start from step one again.
Disassemble the infected PC, and start reassembling it one component at a time. Start with the motherboard, RAM+CR, and harddisk, and see if the disk gets reinfected. Don't add an OS to the HD yet, but boot from a floppy.

If it doesn't get reinfected, start adding one more component at a time. (OS last.)


As someone alluded, it is not impossible that some disaffected Taiwanese software engineer decided to make a little cash on the side by adding a little extra something to one of his projects.

Not impossible at all. Just pretty damn unlikely...


No matter what you decide, don't throw out the PC.
If you don't want to spend any more time on this, send it to a major vendor.

Hell, you can send it to me if you want.
(If you need verification that I'm not some pond scum looking to spread this thing around, I guess Mike can quietly confirm where I work from my e-mail addy. This is not my area of expertise, just a hobby, but if need be, I can get in touch with our security solution provider. They tend to take stuff seriously when it is presented by multimillion dollar customers, and if it should turn out to be nothing, they'll just shrug their shoulders and smile... )

[pillo79]

Swami, would you please be so kind and answer my questions:

1) how do you figure out you are infected. Explain in full detail, especially if the problem can be seen before installing any OS.

2) please post the output of the "dmesg" command from any Linux boot disk. This will clear out all the questions on unknown partitions and boot-time disks.

We're here to help. It's just that this is so wildly ahead that it's almost unbelievable.
Thanks a lot!

[WyoCowboy]

Since i used a new board + memory + hard drive = and it lived ... there isn't really a way to infect a processor (that i know of) it has no bios instructions or changeable drivers like most other hardware ... but a videocard does have updatable drivers that could remain on the videocard forever just waiting to be installed or used ... right?

Plus isn't the video bios the first thing that your sub system loads when you startup your PC? ... maybe we possibly have an Nvidia card trojan? ... or the supernatural is at hand?

Some thoughts that may or may not trigger something that might help...

You could burn it in a pile if you like, but there are a few more things you could try that might shed some light. Sort of like studying a new strain of ebola or such.

AFAIK, there is no non-volatile memory in a cpu that is writable by an external process after the chip leaves the factory. I might be wrong, but I am presuming that the cpu instruction set is hardcoded in silicon.

As far as video BIOS goes, yes, one of the first things that m/b BIOS POST checks for is a video card, so that is likely to be where this thing lives on. This is different than the video driver, which is only loaded when the OS calls for it, although it is likely that video adapter vendors silently include card BIOS updates in at least some of their driver updates.

To test the theory at this point, you would have to start with a fresh hard drive and a fresh video card, and this has to come up clean, unless it also infects the motherboard BIOS while running from the video BIOS, and has already done so.

You can probably/possibly get rid of this possibility by booting with a write-protected floppy containing the m/b BIOS files & updater program, but it isn't a sure thing. Overwriting the BIOS by updating it does not always overwrite the entire memory. When we used Intel boards as the basis of a networking product of our own design, Intel shared with us that there is a reserved area (at the upper end) of the flash chip used to store the BIOS that they were using at the time that does not get overwritten, either by a BIOS update, or by resetting the CMOS to defaults from within the BIOS setup program.

If these guys are really that smart, the only way to get rid of it would be to desolder the flash chip and replace it wth a fresh one from the vendor, if they will send you one, or burn your own on a PROM burner.

I'm not sure about the relative sizes of BIOS on the motherboard vs video card, but most m/b BIOS flash tend to be =< 512k AFAIK. I would expect that the size of the flash on video cards varies more widely. The question is, does the entire body of code for this thing fit into this restricted space, or does it have to download something else.

If it is in fact getting written to the video flash BIOS, the programmer would have had to do some pretty fancy work, as the flash writing routines probably vary with the different vendors/models. If it came from Asia, where many of the video cards are made, it implies that someone has been able to collect source code from a number of vendors, if this is in fact the method, and the author had hopes of it spreading to any great degree. The alternative approach would be to reverse engineer the driver update code that installs new BIOS on the video adapter.

[awatson]

Good question. In fact, I would really like to see the dmesg output from the Linux kernel, as it shows all kinds of devices being recognized with great detail

Ok, you asked for it... This is from a recent version of System Rescue CD, which is a Gentoo-flavor linux-live-on-cd repair disc. The ISO for this disc is freely downloadable on the web. I checked its md5 sum against the one provided before baking it, and then popped it into one of my infected machines that I use typically for lab / testing work (which, by the way, is infected with this thing, along with all other CPUs I own). The hardware is a simple 1GHz Celereon with 128k cache, a 6.8G Quantum Fireball HD, 256M PC133 Ram, and a RealTek 8139 NIC. The mainboard is based on an Intel i810 chipset, and uses Phoenix Bios 4.0 release 6 version 1.05e. It has onboard video (selectable between 512k and 1MB ram shared memory in BIOS) and onboard AC97 sound. I have disabled the onboard sound, serial ports and parallel port. One interesting thing to note is that, on several of my infected machines, you will notice a new entry in the Boot-Order Configuration section, named "Bootable Add-In Cards". Prior to this virus hitting my systems, the only selections that used to be available were the usual run of "CD-ROM", "HD0", "Network", and so on... anyway, here is what dmesg output looks like on this machine:

(I have highlighted certain key sections of note)


771k data, 180k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
initialized device: /dev/synth, node ( MAJOR 10, MINOR 25 )
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Celeron (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20040326
ACPI: Interpreter disabled.
PCI: PCI BIOS revision 2.10 entry at 0xfd9a8, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ACPI tables contain no PCI IRQ routing entries
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801AA PCI Bridge
PCI: Using IRQ router PIIX/ICH [8086/2410] at 00:1f.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
SGI XFS with no debug enabled
SGI XFS Quota Management subsystem
intelfb: Framebuffer driver for Intel® 830M/845G/852GM/855GM/865G chipsets
intelfb: Version 0.7.7, written by David Dawes <dawes@tungstengraphics.com>
Detected PS/2 Mouse Port.
Rocketport device driver module, version 1.14c, 24-Aug-98
No rocketport ports found; unloading driver.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
Computone IntelliPort Plus multiport driver version 1.2.14
Real Time Clock Driver v1.10f
hw_random: RNG not detected
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes (simon@ncm.com)
Linux agpgart interface v0.99 © Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 202M
agpgart: Detected an Intel i810 E Chipset.
agpgart: AGP aperture is 64M @ 0xf8000000
[drm] AGP 0.99 Aperture @ 0xf8000000 64MB
[drm] Initialized gamma 2.0.0 20010624 on minor 0
[drm] AGP 0.99 Aperture @ 0xf8000000 64MB
[drm] Initialized i810 1.2.1 20020211 on minor 1
[drm] AGP 0.99 Aperture @ 0xf8000000 64MB
[drm] Initialized i830 1.3.2 20021108 on minor 2
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH: IDE controller at PCI slot 00:1f.1
ICH: chipset revision 2
ICH: not 100% native mode: will probe irqs later
   ide0: BM-DMA at 0x10a0-0x10a7, BIOS settings: hda:DMA, hdb:pio
   ide1: BM-DMA at 0x10a8-0x10af, BIOS settings: hdc:DMA, hdd:pio
hda: QUANTUM FIREBALL SE6.4A, ATA DISK drive
blk: queue c04c0320, I/O limit 4095Mb (mask 0xffffffff)
hdc: SAMSUNG CD-ROM SC-148, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: 12594960 sectors (6449 MB) w/80KiB Cache, CHS=784/255/63, UDMA(33)
hdc: attached ide-cdrom driver.
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
/dev/ide/host0/bus0/target0/lun0:<7>ldm_validate_partition_table(): Found an MS-DOS partition table, not a dynamic disk.
p1 p2 p3
Promise Fasttrak™ Softwareraid driver 0.03beta: No raid array found
Highpoint HPT370 Softwareraid driver for linux version 0.02
Guestimating sector 12593999 for superblock
driver for Silicon Image™ Medley™ hardware version 0.0.1: No raid array found
SCSI subsystem driver Revision: 1.00
megaraid: v2.10.3 (Release Date: Thu Apr  8 16:16:05 EDT 2004)
libata version 1.02 loaded.
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
mice: PS/2 mouse device common for all mice
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
  8regs     :  1651.200 MB/sec
  32regs    :   994.400 MB/sec
  pIII_sse  :  1996.400 MB/sec
  pII_mmx   :  2273.600 MB/sec
  p5_mmx    :  2374.800 MB/sec
raid5: using function: pIII_sse (1996.400 MB/sec)
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.8(17/11/2003)
device-mapper: 4.1.1-ioctl (2004-04-07) initialised: dm-devel@redhat.com
device-mapper: dm_multipath v0.2.0
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Initializing Cryptographic API
IPv6 v0.8 for NET4.0
IPv6 over IPv4 tunneling driver
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2036 buckets, 16288 max) - 288 bytes per conntrack
ip_tables: © 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
lec.c: May  7 2004 21:04:26 initialized
mpoa: /proc/mpoa initialized
mpc.c: May  7 2004 21:04:27 initialized
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1279k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 180k freed
NCR53c406a: no available ports found
aec671x_detect:
scsi: <fdomain> Detection failed (no card)
GDT: Storage RAID Controller Driver. Version: 2.05
GDT: Found 0 PCI Storage RAID Controllers
megaraid: v1.18k (Release Date: Thu Aug 28 10:05:11 EDT 2003)
megaraid: no BIOS enabled.
DC390: 0 adapters found
Failed initialization of WD-7000 SCSI card!
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
cloop: Initializing cloop v1.02
cloop: /newroot/mnt/cdrom/sysrcd.dat: 1897 blocks, 131072 bytes/block, largest block is 131118 bytes.
cloop: loaded (max 8 devices)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
3c505.c: warning, using default DMA channel,
3c505.c: module autoprobe not recommended, give io=xx.
3c505.c: Failed to register card at 0x0.
3c507: register_netdev() returned non-zero.
3c515.c:v0.99t 17-Nov-2001 becker@scyld.com and others
0 3c515 cards found.
3c523.c: No 3c523 cards found
ac3200.c: No ac3200 card found (i/o = 0x0).
aironet4500_cards.c v0.2  Feb 27, 2000  Elmer Joandi, elmer@ylenurme.ee.

<3>No Aironet 4X00 cards were found. Note that for ISA
cards you should use either automatic PNP mode or
ISA mode with both io and irq param
Aironet is also afraid of: being second PNP controller(by slot), having anything(brandname bios weirdnesses) in range 0x100-0x180 and maybe around  0xd0000
If you PNP type card does not get found, try non-PNP switch before complainig.
aironet4500.c v0.1 1/1/99 Elmer Joandi, elmer@ylenurme.ee.
arlan: no devices found
at1700: register_netdev() returned non-zero.
atp.c:v1.09 8/9/2000 Donald Becker <becker@scyld.com>
 http://www.scyld.com/network/atp.html
cs89x0.c: Module autoprobing not allowed.
cs89x0.c: Append io=0xNNN
eth0: D-Link DE-600 pocket adapter: not at I/O 0x378.
D-Link DE-620 pocket adapter not identified in the printer port
defxx.c:v1.05e 2001/02/03  Lawrence V. Stefani and others
eth0: depca_probe() cannot find device at 0x0200.
dgrs: SW=$Id: dgrs.c,v 1.13 2000/06/06 04:07:00 rick Exp $ FW=Build 550 11/16/96 03:45:15
FW Version=$Version$
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
Intel® PRO/1000 Network Driver - version 5.2.30.1
Copyright © 1999-2004 Intel Corporation.
e2100.c: Presently autoprobing (not recommended) for a single card.
e2100.c: No E2100 card found (i/o = 0x0).
eepro_init_module: Probe is very dangerous in ISA boards!
eepro_init_module: Please add "autodetect=1" to force probe
eexpress.c: Module autoprobe not recommended, give io=xx.
eexpress.c: Failed to register card at 0x0.
eth16i.c: Presently autoprobing (not recommended) for a single card.
eth16i.c No Eth16i card found (i/o = 0x0).
eth0: ewrk3_probe() cannot find device at 0x0300.
hp-plus.c: Presently autoprobing (not recommended) for a single card.
hp-plus.c: No HP-Plus card found (i/o = 0x0).
hp.c: Presently autoprobing (not recommended) for a single card.
hp.c: No HP card found (i/o = 0x0).
lance.c: Module autoprobing not allowed. Append "io=0xNNN" value(s).
eth0: i82596 initialization timed out
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
 originally by Donald Becker <becker@scyld.com>
 http://www.scyld.com/network/natsemi.html
 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
ne2.c: No NE/2 card found.
ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker
 http://www.scyld.com/network/ne2k-pci.html
NI5010: Autoprobing for modules is hazardous, trying anyway..
ni52: Autoprobing not allowed for modules.
ni52: Set symbols 'io' 'irq' 'memstart' and 'memend'
ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
pcnet32.c:v1.28 02.20.2004 tsbogend@alpha.franken.de
sis900.c: v1.08.06 9/24/2002
SLIP: version 0.8.4-NET3.019-NEWTTY-MODULAR (dynamic channels, max=256).
smc-mca.c: No SMC Ultra card found (i/o = 0x0).
SMC9194: You shouldn't use auto-probing with insmod!
starfire.c:v1.03 7/26/2000  Written by Donald Becker <becker@scyld.com>
(unofficial 2.2/2.4 kernel port, version 1.03+LK1.3.9, December 13, 2002)
STRIP: Version 1.3-STUART.CHESHIRE-MODULAR (unlimited channels)
sundance.c:v1.01+LK1.09a 10-Jul-2003  Written by Donald Becker
 http://www.scyld.com/network/sundance.html
ThunderLAN driver v1.15
TLAN: 0 devices installed, PCI: 0  EISA: 0
Universal TUN/TAP device driver 1.5 ©1999-2002 Maxim Krasnyansky
via-rhine.c:v1.10-LK1.1.19  July-12-2003  Written by Donald Becker
 http://www.scyld.com/network/via-rhine.html
WaveLAN init_module(): doing device probing (bad !)
Specify base addresses while loading module to correct the problem
WaveLAN init_module(): no device found
wd.c: Presently autoprobing (not recommended) for a single card.
wd.c: No wd80x3 card found (i/o = 0x0).
winbond-840.c:v1.01-d (2.4 port) Nov-17-2001  Donald Becker <becker@scyld.com>
 http://www.scyld.com/network/drivers.html
yellowfin.c:v1.05  1/09/2001  Written by Donald Becker <becker@scyld.com>
 http://www.scyld.com/network/yellowfin.html
 (unofficial 2.4.x port, 1.05+LK1.1.5, May 10, 2001)
inserting floppy driver for 2.4.26-fd35
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
apm: BIOS not found.
8139too Fast Ethernet driver 0.9.26
PCI: Found IRQ 10 for device 01:0e.0
PCI: Sharing IRQ 10 with 00:01.0
eth0: RealTek RTL8139 at 0xd09a6000, 00:c0:f0:47:1b:f6, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139B'
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
eth0: link down
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:1f.2
PCI: Setting latency timer of device 00:1f.2 to 64
uhci.c: USB UHCI at I/O 0x1080, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
hub.c: new USB device 00:1f.2-2, assigned address 2
hub.c: USB hub found
hub.c: 4 ports detected
i810_rng: RNG not detected
hub.c: new USB device 00:1f.2-2.2, assigned address 3
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
hub.c: USB hub found
hub.c: 4 ports detected
i810_rng: RNG not detected
hub.c: new USB device 00:1f.2-2.2.1, assigned address 4
usb.c: USB device 4 (vend/prod 0x46d/0xc508) is not claimed by any active driver.
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
hub.c: new USB device 00:1f.2-2.2.3, assigned address 5
hub.c: USB hub found
hub.c: 3 ports detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
hub.c: new USB device 00:1f.2-2.2.4, assigned address 6
hub.c: USB hub found
hub.c: 4 ports detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
hub.c: new USB device 00:1f.2-2.2.3.2, assigned address 7
usb.c: USB device 7 (vend/prod 0x5ac/0x307) is not claimed by any active driver.
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
hub.c: new USB device 00:1f.2-2.2.3.3, assigned address 8
usb.c: USB device 8 (vend/prod 0x5ac/0x20b) is not claimed by any active driver.
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
usb.c: registered new driver usbmouse
input0: Logitech USB Receiver on usb1:4.0
input1: Logitech Apple Optical USB Mouse on usb1:7.0
usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
usb.c: registered new driver hid
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb1:8.0
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb1:8.1
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
usbdevfs: USBDEVFS_CONTROL failed dev 8 rqt 128 rq 6 len 9 ret -6
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
usb.c: registered new driver usbkbd
usbkbd.c: :USB HID Boot Protocol keyboard driver
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
eth0: no IPv6 routers present
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
i810_rng: RNG not detected



Please note: the top of the dmesg text, where it looks like I just sloppily cut and pasted at the middle of a line, is exactly the beginning of dmesg output. Whatever comes before that flashes by so fast during startup that I cannot read it, and I believe that the dmesg output gets deliberately munged to hide something important to this virus.

I have more to comment on, but cannot now... will return later to read and post more. Hey, swami... hang in there! I know what you are going through...


A

Edited by awatson, 28 July 2004 - 03:30 AM.

[awatson]

Some notes:

- It has the ability to alter startup sequences and kernel command lines for pretty much any bootable OS that it sees is a threat. I have seen it alter the kernel command-line of my freshly-burned Knoppix CD (another linux live-on-cd distro that I burned offsite, on a seemingly 'clean' computer, in the hopes that it would finally be the tool to help me)... First couple of time I booted, I was able to hit the 'Net again without a problem, and things started looking up... then, third or fourth boot, and the virus had somehow managed to create some sort of change in order to fashion a persitent home directory, including modified startup rc scripts, etc...

- It did the same with the System Rescue CD... so, write-protected medium simply is not as much of a "silver bullet" as one may be used to in battling virus infections.

- There is most certainly a "human aspect" to the way it "learns" to adapt in some cases. I fully believe that some type of rootkit/backdoor code is put in place once the virus establishes itself to some extent on a new installation. Maybe HXDef or FU, or one of the kernel-driver based kits, most likely, since detection is so damn difficult for variants of those already.

- Speaking of FU, I have tried installing and using it on an infected machine, simply because at this point, I try anything remotely possible to aid in a solution. One of this rootkit's features is the ability to list all processes, hidden or not, running on the machine. It actually shows 1 extra process running on all infected machines I have - and the process is named with 4 HTML/Ascii characters: chr(255). As a crude description, the characters look like a y with 2 dots above it. For a more exact example, go to http://www.asciichart.com, and view the HTML chart, and look at character 255. Anyway, the process id of this thing is a negative long integer, something to the tune of -21999876573 - which is something I have never seen before on a windows-based system.... so, I cannot kill the process by name OR number, since I cannot find any tool that will accept high-order ascii or negative long integers as input for a kill process command. If I can find ANY amount of free time at some point soon, I think I will just focus on writing such a tool if it is possible.

- I am convinced that whatever we are dealing with is a kernel-level beast. It's operating BEFORE the OS layers, and hence is not bound by the usual rules of userland viruses.... do a little research on rootkit.com and you will find that the concept of kernel-level code such as this is becoming more and more popular by the day.

- Someone mentioned here that it's impossible to have executable code in BIOS due to the fact that the vendors pick their own arbitrary layouts of entry point address space and so forth... WELL, you may be partly (historically) correct there... but today, there is mostly an unofficial standard layout for BIOS code entry points... at least as far as I can ascertain... and if you think about it - how many BIOS vendors are truly inside the majority of PC mainboards in use today? I can think of only 3 - Award (most popular) AMI, and Phoenix. All are very similar in the way that the code gets compressed (LHA), and all are ALSO very similar in the way that a BIOS writer needs only write a properly-formed extension module in assembly, then upload it to the flash area of a rom at the right location (there are tools such as CBROM to handle this quite easily)... and WHAM, executable code immediately on POST and before an OS is even loaded.

... for more proof of concept, please check out this link:

The RomOS Project - Embedded OS in Rom



...more ramblings later... I have over a year invested in this thing... and can talk about its abilities for hours... but can't friggin' remove it from my hardware - pretty sad, huh?


A

[Misereor]

The plot thickens...
Simply fascinating reading.

<edit>
No reason to post twice in a row, so I'll simply do an edit...

- Someone mentioned here that it's impossible to have executable code in BIOS due to the fact that the vendors pick their own arbitrary layouts of entry point address space and so forth... WELL, you may be partly (historically) correct there... but today, there is mostly an unofficial standard layout for BIOS code entry points... at least as far as I can ascertain... and if you think about it - how many BIOS vendors are truly inside the majority of PC mainboards in use today? I can think of only 3 - Award (most popular) AMI, and Phoenix. All are very similar in the way that the code gets compressed (LHA), and all are ALSO very similar in the way that a BIOS writer needs only write a properly-formed extension module in assembly, then upload it to the flash area of a rom at the right location (there are tools such as CBROM to handle this quite easily)... and WHAM, executable code immediately on POST and before an OS is even loaded.

Ok, so imagine the following scenario.

The badguy reverse engineers a bios update from all three major bios vendors.
He discovers that certain segments of the cmos memory are unallocated for all three major product types.

With this knowledge he then creates an executable. This is the original infection vector, to be downloaded in a driveby install, or if some hapless users accidentally executes it.

This file, when run with admin privileges, camoflages itself as a driver (thereby granting it full rights for everything on the PC, including components below OS level), flashes a file to the unused section of the bios, and finally via the reverse engineered and modified bios update, inserts an interrupt request into the bootstrap sequence, executing the file previously mentioned on every boot, *before* the system starts looking for an OS on other media.

I'm not sure about the relative sizes of BIOS on the motherboard vs video card, but most m/b BIOS flash tend to be =< 512k AFAIK.

512 KB is more than sufficient for an entire operating system, and certainly enough for the contents of a small ramdisk with a couple of modules.


And Voila.
Something that can only be removed with a factory reset of the bios (assuming that a bios update doesn't overwrite the entire bios).

From there the badguy starts adding nasty programs to the ramdisk, amongst others a module that is spread to all available storage devices, which checks the bios and reinfects it if cleaned.

Hell, with 512kb available the thing can even be made to recognize different OS'es running concurrently with the ramdisk, and download/activate additional modules that work on those platforms.

I previously mentioned a disaffected Taiwanese software engineer with insider knowledge, but something like this could be made by anyone with a university degree in computer engineering.

This is ofcourse all assuming I haven't leapt to too many conclusions from the information provided by folks more knowledgeable than myself...

</edit>

Edited by Misereor, 28 July 2004 - 07:23 AM.

[pillo79]

A, I will answer some of your questions, not all of them... if I knew all, well then we wouldn't be here anymore!

First of all, the two lines marked in red are perfectly normal. The ramdisk these lines are talking about is the initrd (INITial RamDrive) which si a compressed disk image that contains the additional modules to be loaded at boot by the Linux kernel. Most Linux boot disks have this modular strategy to be able to run on tons of different hardwares.
Also, the dmesg log has a finite capacity. The network card bugs have overflowed the log size and caused the first lines to disappear, I see that regularly (and most annoyingly!!) and I'm not worried by that.

But this, ...

- Someone mentioned here that it's impossible to have executable code in BIOS ... for more proof of concept, please check out this link:
The RomOS Project - Embedded OS in Rom

... this is not a proof of concept, this is almost what we are talking about! I admit I was completely unaware of this standardization. Well so much better for the virus, adding code to the BIOS gets really easy then...

- It has the ability to alter startup sequences and kernel command lines for pretty much any bootable OS that it sees is a threat.  I have seen it alter the kernel command-line of my freshly-burned Knoppix CD (another linux live-on-cd distro that I burned offsite, on a seemingly 'clean' computer, in the hopes that it would finally be the tool to help me)...  First couple of time I booted, I was able to hit the 'Net again without a problem, and things started looking up...  then, third or fourth boot, and the virus had somehow managed to create some sort of change in order to fashion a persitent home directory, including modified startup rc scripts, etc...

Okay. Now go a little more in detail on this, namely, what went wrong with the 3rd/4th boot? How do you guess the virus modified startup scripts?

- It did the same with the System Rescue CD...  so, write-protected medium simply is not as much of a "silver bullet" as one may be used to in battling virus infections.

Now come on and be serious. If the disk has been written from an ISO image, nothing on Earth can change its contents (other than destroying the CD, of course, but even that would require a great deal of tinkering with the CD recorder-assuming you put the CD in a burner and not in a simple drive...)

What does a virus gain from being able to run at BIOS power on? This is a key question. Of course it can infect anything on the HD, Linux and Windows, and copy an auto-running trojan at least inside Windows (Linuxes are very difficult to infect because they are so different from one to the next).
But this is totally ineffective against CD-ROM boots. The only way to get this right is that the virus applies the changes "on the fly" as THE KERNEL is being read. But this is ridiculously difficult, the kernels are REALLY different one another. (And this time I'm not afraid of being contraddicted )

Now let me introduce a small analogy. Trying to guess what a program is doing is like trying to guess the map of the surroundings from your standpoint. The lower you go the shorter you can see, if you climb over a hill (e.g. from a full-loaded OS) you can see all the lower levels, and very far also.
This is to say that editing the kernel command line is a snap from the console or from GRUB, but from the BIOS standpoint, just knowing that this memory is used for the command line is a total mess

In conclusion, I believe the scenario outlined by Misereor ist true, provided the following problems can be solved (and I keep being skeptic...)
- How to get some bios code to run the injected trojan?
- (also) Why act after two system boots when the user is potentially able to kill the trojan?

"Another brick in the wall"

Edited by pillo79, 29 July 2004 - 10:37 AM.

[Misereor]

How to get some bios code to run the injected trojan?

Assembler code should be quite capable of this AFAIK.
<edit>I assumed you were talking about the injected malware in the bios?</edit>

- (also) Why act after two system boots when the user is potentially able to kill the trojan?

Theoretically it could be because as additional modules are activated, they require a reboot. Normally you get a warning when you install something that requires a reboot, but what does the badguy care if you have to reboot a hundred times before his "product" is fully active?

It did the same with the System Rescue CD...  so, write-protected medium simply is not as much of a "silver bullet" as one may be used to in battling virus infections.

Now come on and be serious. If the disk has been written from an ISO image, nothing on Earth can change its contents<snip>

I don't think he was talking about the CD being changed, but rather the ramdisk.

...And everyone is sceptic, but so long as noone is asking us for money, it doesn't cost a thing to assume that everything has occurred exactly as described. In fact it's rather interesting.

Edited by Misereor, 30 July 2004 - 12:45 AM.

[pillo79]

I think the word "Ramdisk" is misleading. Let's call the space used to store the trojan (all its files needed for Linux and Windows) "flash storage".

Yes, I was talking about the BIOS malware. Let me reword my question:

- How can a POST-run code (code run by the BIOS when the system boots but much before any OS) change a CD-ROM's boot structure such that something contained in the flash storage gets run by the OS at some point?

I agree that at POST-level the trojan can, assuming deep knowledge about the file systems (which is not uncommon-- see the boot loader GRUB), inject code in existing Windows and Linux installations on any hard drive. (And BTW, this would also mean that the virus should be able to run right from the start, because the changes it applies to the OS are committed before it even begins to run, so there's no need to reboot.)

If a CD-ROM is used, well then there is little a virus could do to hack in. The only moment a malicious BIOS can interfere with a bootable CD is while the kernel is loading from the CD; not after, because the BIOS gets tossed away by the direct (and clean) device interface of the disk's OS. And if someone managed to do that, well, he or she would have drilled Microsoft another gazillion times before!

Of course, this is all IMHO!

[Misereor]

I think the word "Ramdisk" is misleading. Let's call the space used to store the trojan (all its files needed for Linux and Windows) "flash storage".

Remember that there is both a ramdisk and a (thus far theoretical) bios infection, and we don't know the nature of their relationship yet.

<tangent>
I guess the ramdisk could be used to retrieve, store, and process information that couldn't fit in the bios. So the contents wouldn't necessarily have to be the same, until the next time the machine was powered on.
</tangent>

How can a POST-run code (code run by the BIOS when the system boots but much before any OS) change a CD-ROM's boot structure such that something contained in the flash storage gets run by the OS at some point?

I'm not quite sure if the 3-4 mentioned reboots were all done from CD, or if a reinstall was done, and 3-4 boots later everything was infected again.
Clarification please?

Anyway, does it necessarily have to be run by the OS?
We have a ramdisk happily running along, even before the OS is loaded. Couldn't a module be activated from there, once a vulnerable OS was recognized?

And BTW, this would also mean that the virus should be able to run right from the start, because the changes it applies to the OS are committed before it even begins to run, so there's no need to reboot.

Maybe. Who knows if all the modifications are done in one go?
(Assuming that it's done on writeable media here.)



On the matter of interfering with the loading process from CD, and interjecting code in the middle of it, that is waaaaay out there.
Quite a stretch even for our paranoid imaginations...

Anyway, still a fascinating discussion