Given the good welcome that found the small article about the viruses matter exposed in this web some days ago, it pleases us recapture the topic again, in a wider way this time, to share with you our own experiences on the behaviour of one of the most harmful viruses that lately have been unleashed, as well as our knowledge over its weak points and the attack methods that we have designed to combat him and to clean our systems.

Everything has come soon after the great world disaster (without exaggerating) that has meant the arrival of the CIH virus, good known for Chernobyl, when coinciding their activation with the date of the sadly famous nuclear disaster in Ukraine.
News are arriving us from all the countries of numerous friends that have suffered the attack of the CIH who are still quarrelling with the "bug". Regrettably, we must say that, according to our experience, it will be very difficult to get rid of that plague.
The following paragraphs go along a narrative line, for such of introducing a temporary perspective in the series of facts that took place, because the wasted time is one of the main harmful effects of the viruses (the other ones are the money invested in repairing the mishaps and the rotten data, being the last ones frequently unrecoverable).
The blissful CIH infiltrated our system through an IRC client program, while we were doing some "chat" with the server where the pages of our domain are located.
We must clarify that both server's computers and staff are completely free of all suspicion, and that the virus very probably entered to the server coming from one of our computers, the people who meet usually, apart from some unknown partner (very suspicious), who we didn't know (and don't); this person entered from time to time, and even we have traced back some stranger from diverse countries, we haven't located no one yet.

The domain server we use is a Linux OS system, and according to the Webmaster, he has had not a problem. Neither have had many other colleagues that habitually work with Linux. Those PC's and servers equipped with Windows NT, OS/2 or Unix OS's, or running under Mac environment, have not reported any vulnerability in front of the CIH.
However, the rest of us, working with systems different from those aforementioned, as well as the PC's and servers which running on Intel, AMD or Cyrix processors, have been targeted by the CIH. Here is the first conclusion:

However, there is another popular statement that points out something like "There is always something good in the harm received", and thanks to the attack of the CIH we suffered, we can share with you this experience of how losing a battle doesn't mean to lose the war. On the contrary, although the first assault left our systems K.O., the rest of the combat was good to overcome the enemy progressively and to end up defeating it completely, eradicating it from our systems and from others affected. At the same time, new variables appeared to be considered in this field of the computer virology (thinking of new, future, more dangerous attacks).

April 26, 1.999. 09:00 am local time.

After switching on the workstations and the rest of the hardware, one of these included in the secondary chain, a Pentium 200MMX system working on Windows 98, made the POST (Previous Operating System Test) with normality and loaded the OS.
Few seconds had passed, and the fatidic blue screen of Windows critical errors appeared, indicating that a "Fatal Error" had taken place. After pressing the "Reset" key, the operator waited that it was one of so many Windows sporadic shortcomings, but this time the machine didn't make absolutely nothing, neither the POST which is controlled by the system BIOS.
Deeply concerned, the operator turned off the machine and asked for Development Head, who started to deal with the situation. He came with a bootable diskette for the system, but the answer was the same one: hung system. It was seemingly clear (some component of the mother board had been ruined), so he ask from the hardware department a mechanical revision of the computer and to repair it with readiness.
As it is known, the motherboards are completely compact, so that they don't accept a replacement of any of its parts. Therefore, and without delay, we proceeded to unpack a brand new motherboard, brought directly from our spare part store, together with their corresponding new memory modules (since the current MB's are not compatible with EDO SIMM, something older).
It seemed that the initial action of the Chernobyl virus was to erase the BIOS, and therefore, to destroy the motherboard, but that could not be possible, since a ROM chip is not rewritable neither for the manufacturer itself.
The explanation is that the manufacturers build the BIOS of the type called FLASH, and not of the ROM type. This way, the chips left as surplus can be used in the assembly line when they stop to manufacture a board model, since they have enough with rewriting the existing chips, which is some cheaper.

April 26, 1.999. 12:00 pm local time.

The replacement of the MB and memory modules already supposes some money invesment, and it's much more expensive if what is affected is a computer net or a "Web-Coffee Shop" with several dozens of machines, so that, among the implied departments, we could ferret out the first solution for one of the reported disasters.
The MB's manufacturers usually have in their webs a downloadable program to update the BIOS of their boards. The emergency procedure is like this:
a) - Access to board manufacturer's main web site (with another computer, of course) and download the BIOS update program, as well as the code of the BIOS pattern that the board carries. Both, programs and code, fit in a diskette.
b) - Locate another computer equipped, precisely, with the same MB and BIOS model.
c) - Load the BIOS update program and stop the system in that exact moment when the program is about to update the BIOS, after recognizing the MB and the BIOS.
d) - In that moment, with the computer switched on, proceed to extract the BIOS chip from its place, and insert the chip from the attacked computer, which has been overwritten by the virus. Now there is no BIOS supporting the interrupt request of the programs, but it is definitely loaded in memory the Shadow Bios with the interrupts of the operating system (SO). In all ways, the BIOS update program is, obviously, built with self-sufficient code and doesn't need to lean on the interrupts of the BIOS.
e) - Once loaded the BIOS with the manufacturer's code, swap again the chips, and the damaged BIOS is already like it came out from the factory.
If you can solve this way the problem, it'll be great. If not, there will not be other way but purchasing a new motherboard.

April 26, 1.999. 14:00 local time.

However, we must not rest unaware, because although the BIOS problem has been solved, updating with the emergency procedure described before, or buying a new one,
Don't be happened to switch on the machine. The virus code is still in the hard disk, and if you boot up the system, it will be necessary to begin again.
To understand how our computer came to a stop after the virus attack, we must briefly analyze what happened. When the predetermined day the computer was connected, all the executable programs that the Windows 95 / 98 system needs to become stabilized in memory were executed, like it was and it is habitual.
The virus had been infected all the executable files; the arrival of the waited date, 26th, April, 1.999, drove to the decompression of the virus and the installation of all its code in more than 80 sectors of the C unit, beginning from the first of these. Next, the virus loaded its code in memory and it passed "him" the execution control.
Once executed, the first thing the CIH made was becoming encrypted and to hide in the tracks or reserved cylinders of the hard disk, to begin immediately with their main task: to destroy all the BIOS that can have a computer (main board BIOS, hard disks internal adapter BIOS, CD recorders BIOS, etc.).
The destructive task included the Shadow BIOS copy, which is in fact the one we work with. When the following executable program that Windows needed must load, Windows sent an alert of "Fatal Error "when not finding in the BIOS the interrupts that it needed, and next, it stopped.
The circle became closed when making a reset, because no task was inside the BIOS to be carried out. And a booting attempt with a diskette was also condemned, because it lacked the BIOS instructions from where the orders to read a diskette are given.
The computer was, simply, brainless.

As the experience and our investigations have taught us that all virus that is executed leaves in the hard disk (in very visible form) the entire code, or at least, a part of it, we appeal to our more powerful program, MICROSCOPE-32, and we prepared to face with so unworthy opponent.
MICROSCOPE-32 is our main tool of work when working with hard disks, and a comprehensive description of its features surpasses the limits of this article.
However, we are forced to make a brief review on their operation and main benefits, because otherwise the statements here contained would be simple axioms, only sustained for Quipusoft's opinions.
The reality is totally different. MICROSCOPE-32 is a program that we need to design on our own to cover the hole left in this field by the available software in the market. The disk utilities and antivirus programs don't access to certain areas of the hard disks, for us denominated "Master Sectors", which are in fact those that the viruses designers use to make their misdeeds.
Inside these "Master Sectors" (MS's), we could mention the "Hidden Sectors" (HS's), "Partition Sectors" (PS's), "Boot Partition Sectors" (BPS's), "Overcluster" (OC's), and the "Landing Track or Cylinder (LT or LC).
Without trying to carry out self-publicity, the reader is remitted to the magazine PC WORLD (No. February 1996) and to the magazine ACTUAL PC (No. March 1996), where the critics of the first version of MICROSCOPE are made. The current version, MICROSCOPE-32, is able to analyze FAT-32 hard disks and Windows' long names, all under MS-DOS environment.
The accompanying manual, a 250 pages book, is a technical treatise that begins from the most elementary ideas, to reach an advanced level on the physical composition and magnetic hard disks logic. At the same time, and because we are talking about a topic intimately related with the hard disks themselves, it also covers the problem of the viruses, and it concludes teaching to make a key disk, for all that enough code source is provided in BASIC, C and assembler.

Well, it has been clear which is the basic armament we faced the CIH with, already comfortably installed in one of our systems and without any intention of leaving for own initiative.
We began booting the system with a trustful boot diskette; once loaded the MS-DOS OS, we ran up MICROSCOPE-32, requesting to analyze the hard disk C. MICROSCOPE-32 alerted that it didn't recognize the code of the "Partitions Sector" neither of the "Boot Sectors", and it passed automatically to make a physical scanning of the hard disk to know, at least, the size of the disk that the program had to analyze.
Given the tactical scenario set for the design of the commented program, these adverse conditions were not obstacle for MICROSCOPE-32. We could reach this way to the content of all and each one of the physical sectors of the disk.
We were able to access to the code of the first sector (face 0, track 0, sector 1). In accordance with all the norms of any operating system, this it is the sector of the primary partition of the hard disk. To the first glance we understood that the code that appeared in screen was not but the own virus CIH who contemplated us from its sheltered refuge with a certain cynic superiority.
As a established norm, all the remaining sectors of the face 0 and track 0 are considered reserved and they are not used for anything. In this case, when scrolling down the code of these sectors, which were supposed to be empty, the rest of the code of the virus was parading before us.
Continuing with the standard rules established for the manufacturers, the sector 1 of the face 1, in its track 0, should be containing the code with the OS booting code installed at that time, code that is also quite familiar at first sight. Instead of the mentioned code of the boot sector, what we found there was, obviously, the continuation of the virus code.
Among other characteristics, the FAT-32 has its boot system occupying 16 sectors, with two copies, one behind another. Easily identifiable, it is located, in the hard disk, after the boot sector. After that comes the first sector of the root directory.
The polluted hard disk was (and it is, after have being recovered) 2 Gigabytes in size, and it is formatted in FAT-32, occupying 4025 sectors each one of the FAT copies.
We continued tracing back the code of the sectors, sequentially, until we observe in screen a numeric sequence clearly belonging to FAT-32. As we were on the sequential sector 80 of the disk and the FAT-32 should have begun in the sector 96 (63 sectors of the partitions track plus the 32 sectors of the two copies of the boot sector), we understood that the first copy of the FAT was hopelessly damaged, but that surely, the second copy of the FAT would be intact. We confirmed that fact when requesting to see the code of the sector 4121 (= 96 + 4025), because this is where the mentioned second copy began.
Fortunately, among the many tools MICROSCOPE-32 is equipped with, two of them would be the key in the first counterattack that we were about to carry out:

* MICROSCOPE-32 can make a back up copy of the partitions and boot sectors in a diskette. * MICROSCOPE-32 can overwrite a copy of the FAT with the other one.

We were perfectly sure that it would be enough with restoring the back up copies on the sectors that now had the code of the virus and overwrite the first copy of the FAT with the second one.
We took the diskette where the back up copies stayed, containing a copy of the master sectors, and we made the overwriting process without any problem. Being completed this procedure, we thought that requesting MICROSCOPE-32 to analyze the hard disk C again will be enough so as to take the parameters now available and corresponding with those supposed to be (remember that, at the beginning of this battle, MICROSCOPE-32 didn't recognize the partitions sector code neither of the boot sectors).

You will be able to understand the surprise of the task force gathered around the computer when MICROSCOPE-32 notified again that it ignored the code found in the sectors that we had just restored. Certainly unsettled, we ran the "Sector Editor" utility, in order to check that the code recently installed was there and that it was correct. However, MICROSCOPE-32 refused to recognize it. What was happening really ?.
In the partition and in the boot sector there was an exact, clean code just restored. MICROSCOPE-32 confirmed that the code was located correctly, and showed it in screen when requested. In spite of everything, MICROSCOPE-32 itself didn't recognize that code when trying to analyze. How to explain this contradiction?.

At this moment, we must give some more information about the structure of MICROSCOPE-32, because if we don't, all the statements contained here will seem like taken out from a magic cauldron. MICROSCOPE-32 is more than 75% built with direct interrupts to the BIOS, instead of the interrupts that can be made to the operating system. We found this operating mode more effective; consider, for instance, that we have been able to analyze Unix or Mac diskettes under MS-DOS environment.
In spite of the fact that the MB BIOS was a brand new one (non suspect), it was obvious that MICROSCOPE-32 was showing on screen the content of a sector different to the sector analyzed as the first sector of the disk.
Suddenly, the situation cleared up as the sky after a summer storm: we were before the typical behaviour of the viruses: they take over the control of the BIOS interrupts, deceiving the operator.
However, let us remember that we had booted from a diskette. Therefore, the virus code had not been run to also take the control of this device. Also, the caution had been had of configuring the BIOS with the units A, C as boot sequence, before switching on the computer. It was a new cul-de-sac.
We requested MICROSCOPE-32 to access to the code of the last sectors of the hard disk, and even the content of the sectors of the landing track, usually inaccessible (except for this program), because here is where the viruses usually hide their code. Nothing to do: the area was as clean as it was supposed to be.
As we were in a hurry to get back our damaged system in line to continue working, and with the conviction given by the fact of having back up copies of all our work, it was opted to stop wasting time trying to figure out what was happening. We decided to carry out a low-level format process on the hard disk with MICROSCOPE-32, for soon afterwards installing everything again. Problem solved.

April 26, 1.999. 16:00 local time.

It took some more than one hour to format the hard disk at low level. When we checked it, our surprise was enormous: the standard format process had not worked, because all the sectors continued having the same content and code than before the operation, when they should be set to zero totally.
Again, another of the options of MICROSCOPE-32 would be of great help, as alternative to the standard format process: it allows cleaning the complete disk overwriting the content of all and each one of the sectors with one zero (character). Once more, we invested another working hour, after which we could check with relief that the whole content of the hard disk, both the virus code the virus itself had been destroyed.
The next step was to prepare the hard disk using the programs FDISK and FORMAT (logical format), included in the OS.
Since everything was working without problems, we installed Windows 98, the Internet browsers, the drivers, the compilers, etc., and this way it lapsed a complete working day, fully invested in recovering for work one of our systems.
At each moment, we used MICROSCOPE-32 to verify the perfect state of the hard disk, in order to detect any anomaly and the program that had caused it.

However, and considering that the CIH was the winner for the moment (the only available solution seemed to be the formatting process described until here), when finishing the installation of all that needed, we ran a special antivirus against CIH that had been downloaded from the web through another computer, belonging to a very well known antivirus software firm, put in free download for those days.

April 26, 1.999. 21:00 local time.

When the antivirus began to work, the desperation preyed on our minds, after checking that all and each one of the executable files was infected by the CIH again.
It was very difficult to accept that situation. On one hand, we relied absolutely in the followed scheme to terminate the virus: the BIOS was brand new, MICROSCOPE-32 had guided us in all moment and the hard disk was clean completely (that believed at that time); on the other, both the Windows 98 system and the rest of applications installed were in closed-session CD-ROM's, impossible to be overwritten by any virus.
It is perfectly understandable the frustration of an entire qualified task force, arrived this point: this situation can be possible for non-professional people, but not to those who have long years of training and of investigation as their support.

Without any doubt, the CIH was inside the circuits of the machine, but as the MB was new, it only could be in the hard disks. How to locate it ?. Was MICROSCOPE-32 failing ?.
The small doubt that arose about MICROSCOPE-32 led us to appeal for a conventional antivirus, which made the customary thing, that is, to clean almost all the affected files. As leaving a file damaged by the virus supposed not to have made anything useful, we had to begin cleaning the disk again and to start another time.
It was evident: the virus had been able to establish a stronghold, in some way, inside the hard disk. What element have the HD's in common with the MB's ?. Indeed, the adapter that they equip from factory, which a takes a FLASH BIOS where the manufacturer introduces the parameters of each one of the HD's.
If the CIH had been able to overwrite the motherboard BIOS, was there something to prevent it from overwriting the hard disk internal adapter BIOS ?. It was clear that we faced somebody, the creator of the CIH, who, at least, had identical knowledge about chips engineering than the engineers who designed the circuitry of the MB. No physical device was forbidden to him and his creature.
The two affected hard disks were "Quantum", so we searched in this manufacturer's web page some check-up utility for its own disks. The problem was that the Quantum engineers had limited the possibilities from its check-up program to the verification of the physical state of the disks, which were healthy and sane (MICROSCOPE-32 had already verified it). However, the manufacturer's utility didn't allow us to check the structure of data of the corresponding BIOS.
We opted to install in the infected computer a brand new hard disk as "MASTER", and we place the hard disk theoretically worn-out as second unit (SLAVE). Next, we indicated the BIOS that a hard disk only existed in the system. Again Windows 98 was reinstalled and the whole series of necessary programs for the work, this time running the antivirus to each given step. Everything worked perfectly.
In this point it was necessary to stake our all in order to have the complete confirmation that the CIH virus was no longer inside the system parts declared to the BIOS. The key test consisted in setting the system date to "April 26, 1.999", and to switch on as if anything has happened. We were dicing with our system's death: everything or anything, because if the CIH didn't exploit again, that was meaning it had been eliminated totally (except of that second hard disk that we had whisked away to the BIOS, and that we had reserved ourselves to analyze more peacefully).
The computer rebooted normally and it ran all programs without problem, being the date April 26, 1.999. The CIH was no longer in the system.

April 26, 1.999. 23:30 local time.

On one hand, we felt calm, knowing that we could continue with our work, after almost one whole day of fight with the virus.
On the other hand, we were disappointed, because we haven't been able to find where the virus was hidden, and which undoubtedly continued inside the hard disk now set as secondary unit. The firm trust in our best, more brilliant tool, MICROSCOPE-32, had begun to crack. Soon we would see that there were no reasons for it.

April 27, 1.999. 08:00 local time.

We allow spending some hours in order to relax the state of spirit, returning soon over the second hard disk.
As it is already known by some (and like it is explained in the MICROSCOPE-32 manual), the users of Microsoft systems are accessing to the disks by means of the wonderful Pentiums processors, which really use the 8086 code.
That is, we are employing 16 bits code for calling to the interrupt 13H, the one in charge of handling the diskettes and the hard disks of the system. That conditions us to not being able to use, in any way, hard disks that have more than 1024 tracks (numbered from the 0 to 1023).
To palliate this defect, the manufacturers of the most modern motherboards designed a procedure, called LBA (Large Block Assignment) that consists in indicating the BIOS to decompose virtually the hard disk larger than 1024 tracks or cylinders that it is managing, in 2, 4 or 8 parts, producing 2, 4 or 8 virtual heads instead of the physical ones, and 2, 4 or 8 times less virtual tracks than the physical ones. The BIOS, through the LBA mode, makes the corresponding adjustments when the user requests it to access some face beyond those that physically the hard disk has.
This presents a possible small rounding problem when facing with a disk whose total number of tracks or cylinders are not exactly divisible for a binary multiple, because it would be always a rest of the last cylinder that only would be accessible in a part of the available virtual faces in LBA mode.
Usually, this rest of physical track is invisible to the LBA logic, and it is not at disposal to of any conventional program. The creators of the viruses know this, and they take advantage of these track pieces to locate a part or the entire code of their own. However, MICROSCOPE-32 can also pass over the barrier which closes the step to these tracks that we call "landing tracks", for being the track where the physical heads of the hard disk withdraw, once concluded their access to disk itself (would we say "landing runway" instead ?).
Anyway, if the virus had tampered the hard disk internal adapter BIOS, it had been very careful in order to respect the virtual size of the landing track in the LBA mode, since in some way it was deceiving us: the virus had been able to reserve a cylinder exclusively for its code, but at the same time, it was deceiving the BIOS, which showed the correct figure of cylinders.
How could we reprogram a hard disk BIOS and to whisk away a cylinder?. Very simple: implementing in the BIOS an instruction like this (let us remember that it is also a FLASH BIOS):

Increase the requested track in 1.

This way, when being the BIOS requested access to the authentic track zero, this would never be shown, because it would be controlled by the virus code. There would not be problems in showing the last track of the disk (the 1023 in the LBA mode), since the manufacturers include one more physical cylinder in their disks, which is the authentic landing track.

Well aware of the littleness, effectiveness of the code before we were, we understood that nothing could be done without reprogramming the hard disk internal adapter BIOS. This is not of common access for everybody, because it is necessary to have the manufacturer's data to know the exact port through we can reprogram the BIOS and what parameters it accepts.

However, after so many hours invested in understanding the virus performance logic, the detective's task we were carrying out would give their results through another detail, seemingly without importance, which has already been stated at the beginning of the article:

The CIH virus code is optimized for the Windows 95/98 systems.

This detail would reveal its transcendence now, since the non-Windows systems use the 32 bits access to hard disks, and they don't need the LBA mode.
This way, we could install in our computer an operating system working on a 32 bits real access basis, that is, a system that use the EAX registers and similar instead of the AX registers and similar, which run on 16 bits. However, our key program, MICROSCOPE-32, is designed for the system MS-DOS (16 bits)...
It was necessary to confuse the hard disk internal adapter BIOS. But how?. The human stubbornness is a powerful tool, just in case, and our staff demonstrated to possess this feature at a remarkable level.
We booted the system and entered the BIOS configuration program. We ran "Hard Disk Auto detect" utility to indicate the BIOS to manage the second hard disk in "Normal" mode, instead of "LBA."
This way, the system could see the hard disk like it is configured physically, that is, with 4096 tracks or cylinders. The BIOS cannot object any problem at all, because it doesn't know what OS will be installed in the computer.
Once instructed the BIOS to manage the hard disk in "Normal" mode, we enter to the first options screen that all configuration programs have, where we select to manage the hard disks in "predetermined mode" or in "USER mode". If we arrive here from the hard disk auto-detection utility, having left the "LBA" mode, in this screen we won't be able to introduce manually the number of tracks, faces and sectors. However, if we have set the hard disk in "Normal" mode, in this screen we can change on our own, in "USER" mode, the number of tracks, faces and sectors.
It was to modify the information of hard disk parameters, to confuse the motherboard BIOS, trying to access beyond the real tracks the disk had.
We only changed the number of tracks, indicating the BIOS the disk had 4097 instead of the 4096. In fact, like it has already been mentioned, the disk have 4097 tracks when coming out of the assembly line, but the last one is always reserved as landing track or cylinder.
Once the motherboard BIOS allowed us to vary the number of tracks that the hard disk had, in the same line, at the end, we could change from "Normal" mode to "LBA" mode, which is the only way we had to analyze the disk with our MS-DOS program, MICROSCOPE-32.
It did work. We could configure a hard disk in "LBA" mode with 1025 tracks, thing that is seemingly impossible from any point of view.
Immediately, we saved the changes in the Shadow BIOS and we booted the system with a diskette. The second attack scheme this time was more likely to be victorious, because everything worked and the second hard disk was managed "LBA" mode, with a lightly higher capacity to that the disk had in fact.
Before forging the BIOS parameters, we had cleaned totally the second disk, denominated D in this current system configuration, using the already commented option of MICROSCOPE-32 as an alternative to the usual formatting DOS process: that one which writes the content of all and each one of the sectors with characters zero.
Now that the landscape was no longer sewed with mines, we prepare MICROSCOPE-32 to enter in action, analysing the second disk. MICROSCOPE-32, obviously, protested when finding some parameters of the partition sector and of the boot sector, which didn't keep the prospective norms, and it passed to make a physical scanning of the disk. It only found the 1024 LBA tracks the disk had, but according to the operating mode of MICROSCOPE-32, it will not carry out any change without warning or a confirmation request. So, it's very illustrative to contemplate the sequence of performances literally:

MICROSCOPE: Heads: 64. Tracks: 1024. Sectors on each track: 63. Do you agree?. USER: N.

After pressing the "N" key, MICROSCOPE-32 offered us its second alternative, which were the default hard disk data stored in the motherboard BIOS:

MICROSCOPE: Heads: 64. Tracks: 1025. Sectors on each track: 63. Do you agree? USER: Y.

This time we press the "Y" key, and after that, we called for the "Sector Editor" utility, looking for some code leftovers in some place. As the D disk had been cleaned completely previously, the content of all its sectors should be full with characters zero.
The first sector of the disk and the following ones were completely clean, without any code; the same was for the content of the last logical sector (Head: 63. Track: 1023. Sector: 63), also verified immediately. This way, when confirming the clean status of the disk, we understood that the only slot that was still hidden to our exploration was the landing track: through MICROSCOPE-32, we asked the BIOS to go further one track beyond those allowed by the "LBA" mode.

MICROSCOPE: [Overtrack Authorized]

When obtaining this answer of the program, we did ask it immediately to show the content of the sector 1, face 0, track 1024 (the impossible track).
At last, we had opened the Pandora's box: the virus code was there.
We begin to rake the following sectors with the same result: that cylinder was replete of a code that should not exist, considering that the disk had been formatted and cleaned in a thousand different ways.
But what track or cylinder was the program reading ?. It was not enough with having located the hidden virus code, we did need to know exactly what physical track the virus was inside. How did it arrive until there ?. To unveil this mystery, it did become indispensable for the team the use the binary numeration system in the subsequent calculations.
The interrupt 13H of the BIOS for the handling of disks use the register CL (of 16 bits) so that we indicate track and sector to which want to access, according to the following rule:
"Given 16 bits for the register, the first ten places are to calculate the track number in binary base, and the six remaining are for the number of the requested sector".
Here is one of the reasons for the traditional limitations of the 1024 tracks system (numbered from 0 to 1023), since in 10 bits, the maximum number that we can write is 1111111111 (= 1023 in decimal). In similar way, the sectors are also limited, because in 6 bits we can only write 111111 (= 63 in decimal), with the only exception of not using the zero for the sectors numeration.
What had it happened ?. When forcing the number 1024 inside 10 bits, we had been able to set the cluster of 10 bits to zero and to force a 1 to their left, which went to no place in this case. This way, what we had achieved was to request the BIOS to show the authentic track zero.
In some way, this procedure had made the motherboard BIOS and the hard disk internal adapter BIOS to reorganize their parameters. From that moment ahead, we could access to the track zero of the disk that before was always hidden because that order of "Increase the requested track in 1", already imagined for our team and obviously included inside the virus code.
When reaching this conclusion, it was demanded directly of MICROSCOPE-32 to show the content of the track zero: there was the damned code. From now on, if we asked MICROSCOPE-32 to show us the track 1024, the program protested and notified that it didn't find it, since the disk parameters had returned to the normality and the track 1024 it was the impossible track, binary speaking.
Now the behaviour of MICROSCOPE-32 was clearly explained. When trying to analyze the sector zero of the partitions table, it protested again. This way, with the hidden track zero, the whole content of the hard disk was displaced a track forward, and when the program was requested to show the track zero, in fact it showed the track one. MICROSCOPE-32 was not failing, and it was our duty to apologize before so faithful friend for having doubted of its skilfulness. At the same time, we gave him the last task: to clean the whole code that was inside that cylinder.

Already more relaxed we think the final victory well deserved some vacations. However, the problems continued.
Concluded our actions over the primitive C hard disk, now configured as D to proceed to its analysis and reparation, we turned back on the initial D disk, to which we practiced the same operation, with identical results. This entire task, added to the fact of having brand new motherboards and BIOS, allowed us to continue with our habitual work.
But another awful experience was waiting for us up ahead inside our CD writer Philips 3610, also located in the system attacked by the Chernobyl: in desperation, we noticed that some of the back up copies we had in a rewritable CD had disappeared.
We take the rewritable CD to check it in the CD writers of the remaining computers; they came from other manufacturers, for further guarantee. There was not way: we had lost a complete directory, one of the most important, because it could not be recovered with money, since it was the outcome of several months programming activities.
Investigating the rewritable CD with all the programs at our disposal, we observed that a CD of this type, of 650 Megabytes, once formatted, leaves available a size of 531 Megabytes, but this one containing the data announced that its maximum size was 529 Megabytes.
Obviously, the CIH had been able to tamper with the CD writer BIOS, and like it made with the hard disks, the virus had been able to falsify the TOC and it had been reserved 2 Megabytes for its use, overwriting the data of the lacking directory.
We visited Philips Europe's main web site, where we get the program and the necessary data to update the BIOS of the CD writer. The problem is that Philips only offers this technical assistant for the individual bought devices, separated from a computer, and the updating program doesn't work with the OEM units assembled in several of our machines.
We contact by phone with the Philips Europe customer service and they informed us that they could not give us any help in this respect, since the" Firmware" of the OEM devices differs of that included in the retail devices. There was no more solution than to change the CD writer and purchasing a new one, according to Philips Europe.
As failure is not an option at Quipusoft's, we rake all Phillips main webs sites, and finally we found a really professional person at Philips USA customer service who knew and wanted to inform us about we could update the CD writer BIOS. At least, the Philips Europe customer service's attitude is surprising.
From that moment ahead, the system works perfectly, and setting as working date April 26 1999 doesn't suppose any problem.

April 30, 1.999. 09:00 local time.

Four days had passed from the CIH attack, we had invested several hundred dollars in new spare parts, and we had wasted near 100 working hours in getting back in line one of our computers. Anyway, we had conquered the virus when being able to understand how it worked and which had been its tactics to infiltrate, dominate and be perpetuated in our system's interior, far beyond the reach of any antivirus conventional program.
However, we could not ignore the situation in which many colleagues (users) and Quipusoft's customers were (as technical assistance is one of our main goals).
One of our colleagues was lucky enough to learn of the Chernobyl's explosion before switching on his system, when the adjoining fellow was already infected. This way, he contacted Quipusoft before turning on the computer.

USER 1: What am I supposed to do ? I'm even scared of looking at the keyboard!.
QUIPUSOFT: Settle down, we are still on time. Follow to the letter the following steps:
1) Introduce in the floppy disk drive the Windows 95/98 boot diskette, write protected.
2) Boot up the machine, and press on the keyboard the corresponding key sequence to access at the BIOS configuration program.
3) Once in BIOS configuration program, change the date, so that the virus cannot identify the date April 26 1999.
4) Save the changes and restart the system from a diskette.
.....
USER 1: Right now (some minutes pass).
QUIPUSOFT: Well, does it start up t?.
USER 1: No, a message appears in screen requesting me to unprotect the diskette.
QUIPUSOFT: Warning. No boot diskette will ever produce such a message: that BIOS has been affected and may explode at any moment. Turn the computer off and, when rebooting, enter in the BIOS configuration utility, and check if boot sequence is A, C.
USER 1: OK, boot checked as A, C. The system is hung and doesn't respond.

The conclusion was obvious: the virus code was already decrypted in the hard disk before the date April 26, 1.999, and had been tampering with the BIOS, controlling it for itself and for the great explosion.
This case ended as described in the following second one. The difference between these two example is that the first one concluded without damage at all for the BIOS. Regrettably, the second user was not so fortunate.

There was a second case, also enough illustrative to be described here. Another fellow was able to boot the system up with the boot diskette. Immediately, we took again MICROSCOPE-32 and prepared the hunt for the spectrum that dominated the damaged system (Chernobyl, we go for you).

QUIPUSOFT: Boot up the machine under MS-DOS, insert MICROSCOPE-32 disk and run the program.
USER 2: Already done. MICROSCOPE-32 is working perfectly.
QUIPUSOFT: Ask it to analyze your C drive.
USER 2: OK. Analysis is running, without problems.
QUIPUSOFT: Using the "Sector Editor" utility, tell us what you see in the content MICROSCOPE-32 shows you in screen. It should be the partitions sector.
USER 2: There is a great quantity of code and weird characters I don't understand.
QUIPUSOFT: Well. Ask MICROSCOPE-32 to print out the content of that sector in hexadecimal base and send it to us by fax.


Five minutes later we could analyze the content of that sector, almost 600 miles away from where these colleagues were.

QUIPUSOFT: This code seems correct. However, we will verify the remaining sectors of the track, simply pressing the "right bound" cursor key. All sectors must be absolutely empty. If you see some code in some of them, you will be looking at the virus.
USER 2: every sector is plagued of non repetitive code.
QUIPUSOFT: Check you are in face 0 and track 0.
USER 2: Checked: face 0 and track 0, and all the sectors occupied by code.
QUIPUSOFT: We will clean it. In each one of the sectors to be cleaned, press down "Alt-E" to enter in editing mode; next, key "Alt-L" in, so as to erase (clean) the content of the sector completely (the effect will be visible in screen). Once cleaning process completed in screen, press "Enter" or "Esc" and a dialog window will prompt your agreement to save in the disk the changes made. Press "Yes", and repeat the operation with the other sectors included in face 0 and track 0.
USER 2: (one minute later) The track is clean. And now?.
QUIPUSOFT: Press "End "and it will take you directly to the last sector of the disk. Once there, verify that we are in that part of the hard disk named by Quipusoft "Overcluster", not in "Data "or "Free."
USER 2: Checked: MICROSCOPE-32 informs in screen that we are in the "Overcluster" area. There is no code.
QUIPUSOFT: Verify all the sectors backwards, sequentially, without missing a single none, with the "left bound" cursor key, while MICROSCOPE-32 keep on reporting that we are inside the "Overcluster" area. All sectors must be empty (clean).
USER 2: Checked: I have gone 20 sectors backwards. All of them are empty, but now I have encountered a sector with some code.
QUIPUSOFT: Are you inside the "Overcluster" area ?.
USER 2: No. MICROSCOPE-32 informs "Free Area", but there is some code.
QUIPUSOFT: It doesn't matter; maybe, they are leftovers (garbage) of some erased file. It is normal. We will see now if we can enter in the landing track. For this purpose, press the "End" key again, go to the last sector of the disk and, once there, key "Alt-F" in to force one track further. MICROSCOPE-32 must answer back "Overtrack authorized".
USER 2: OK. "Overtrack authorized".
QUIPUSOFT: Now try to continue reading sectors ahead, pressing the "right bound" cursor key.
USER 2: The program message has changed from "Overcluster" to "Landing"; I can see very much code.
QUIPUSOFT: We got it: that is the virus. We will clean it the same way we did with the sectors of the track zero.
USER 2: Will I be able to write in the landing track ?.
QUIPUSOFT: Why not?. If the virus can write there, MICROSCOPE-32 is also endowed with that feature.
USER 2: It works !. Do I keep going on ?.
QUIPUSOFT: Of course you do. Do the same operation of cleaning all and each one of the sectors included in the landing track containing code, and when you finish call us again.

In that computer we find the virus code decrypted and extended by the hidden parts of the hard disk, parts normally non-accesible to the conventional antivirus. To be honest, we must clarify we were lucky enough so as to find it before its execution: this way, the cleaning process was complete. That machine is currently working without any problem (related to the Chernobyl).

This case lead to state that anyone not being yet attacked by the virus may have it latent in the hidden parts of the hard disk. We even recommend caution to those that have been able to clean all the files with a conventional antivirus.

"We have received the material that you sent us by fax, and here you have our impressions on what is happening in your hard disk:
MICROSCOPE-32 receives from the motherboard BIOS the following parameters:
Disk: C.
Faces: 255 (0 at 254)
Tracks: 1023 (0 at 1022), with 63 sectors in each track.
This produces a total number of 16.434.495 sectors. We must leave reserved the 63rd first ones for the partitions table, giving us 16.434.432 useful sectors for the primary partition.
This number, 16.434.432, in hexadecimal format is 00 FA C5 00, and it should be located in the hard disk in two different places:
* In the partition sector in the place (offset) 01CA.
* In the boot sector, in the place 0020.
As you already know, the numbers in the disk are written from right to left, and in those two places it should be the number 00 C5 FA 00.
However, in those places we find the hexadecimal number C1 03 FB 00, which we should interpret from right to left as 00 FB 03 C1; its decimal counterpart is the number 16.450.497.
The available number for the partition is higher than the one supposed to be, surprisingly, in 16.065 sectors, that is, a complete track of 63 sectors in each one of the 255 faces. Therefore, when the disk format process was performed, there was an extra track or cylinder more than these 1023 being indicated now for the BIOS.
This statement can be corroborated otherwise. According the sent data, the content of the last sector of the disk (face 254, track 1023, sector 63) was completely set to zero, except the first four bytes.
If we make the opportune calculation, this is the disk physical sector 255 x 1023 x 63 = 16.434.495, since the face 254 is the 255 one (when beginning the count in face 0). This number, in hexadecimal base, is 00 FA C5 3F.
Some hard disks manufacturers, when performing the format process at the factory, number the sectors of the disk sequentially. In this case, they have not used the norm of writing bytes from right to left; they consider that it is a 32 bits disk, and the numeration from right to left is made by groups of two-in-two bytes, instead of making it of one-in-one. Let us see an example.
The hexadecimal number AA-BB - CC-DD, rotated of byte in byte, would be as DD-CC - BB-AA, but rotated of two in two bytes (which are also rotated), will be as BB-AA - DD-CC.

According this system, the first four bytes of this sector, attending to the manufacturer's numeration, should be 3F-C5 - FA-00. However, the first four bytes marked here by the manufacturer in this sector contains FB- 00 - FF-03, which properly rotated gives us the number 00 FB 03 FF; converting into decimal, 16.450.559. As the manufacturer begins with the sector 0, this it is the sector 16.450.560 of the disk (starting on 1).
There is the same difference of 16.065 sectors (1 complete cylinder) between the manufacturer's sector 16.450.560 and the sector 16.434.495 we have obtained through calculation starting from the BIOS information.
MICROSCOPE-32 detects the number of sectors currently written in the partitions table (C1 03 FB 00), and this is reason why it informs in the parameters table that the disk has 1024 tracks.

All these data mean that some virus has been able to change the pertaining BIOS data related to the hard disks.
These data are taken by the BIOS when, in the BIOS configuration program, we run the "Hard Disk Auto detect" utility. The hard disks give to the computer BIOS the data they store in their own BIOS's, and if the virus has been capable, like we have checked for ourselves, of changing the manufacturer's data in the hard disks internal adapter BIOS, there's no solution for the problem, since the manufacturers don't provide us any utility to reprogram the hard disks internal adapter BIOS.
Just in case the only BIOS happened to be reprogrammed were the motherboard BIOS, we can try to run again the "Hard Disk Auto detect" utility, to see if the current hard disks parameters change or they are left invariable. This utility could not change the data; in this case the hard disk BIOS has been clearly damaged by the virus.
With this manoeuvre, the virus deceives the whole system, making the hard disk appear with a cylinder less than those that the device has in fact. In order to avoid any unwanted access to that reserved cylinder for its own data, every time that such event is requested, the virus increases the demanded track number in one unit.
This way, nobody can reach to the authentic zero track. When an access to the last track is sent, the virus makes the system to show the 1023rd track as if was the 1022. We will not suspect of the information given, because we believe to have 1022 tracks.
Exception made of MICROSCOPE-32, no antivirus program will request an extra track further than the supposed to be correct number. This program utility has given us the chance to locate the virus with accuracy, accessing to the track 0.
However, the content of the sectors you printed out (belonging to the track 1024, the impossible track) is not an executable code. In fact, it is a copy of some FAT-32 sectors. This makes us suspect that, when the virus is active in memory, readdresses some data demand or of some executable program toward another place of the hard disk, which is where a virus of the Trojan Horse type could be located, being undetectable for the conventional antivirus software.
In this case, the virus has failed by leaving a hint of its action behind: it has not modified the total number of sectors indicated in the partitions table and in the boot sector. This clue, together with the sectors numeration established by the manufacturer of the disk, allows us to identify the virus CIH.
The counterattack scheme that we would apply here to eliminate the virus of your system would be:

1) - Make a back up copy of your data.
2) - Enter in BIOS configuration program and run the "Hard Disk Auto detect" utility.
3) - Selects the hard disk in "LBA" mode.
4) - Run MICROSCOPE-32 and enter again in the track 1024; delete manually the whole content of these sectors (Alt-E to edit and Alt-L to clean).
5) - Run the MICROSCOPE-32 menu "Tools", "Search for lost sectors sectors" utility. This option cleans the disk completely and numbers the sectors sequentially, like the manufacturer did but in decimal, so that it is easier to identify them.
6) - Boot up the system with a reliable Windows boot diskette and run FDISK. Make a single partition.
7) - Format the hard disk with FORMAT C: /u
8) - Run again MICROSCOPE-32. Choose "Sector Editor" and randomly snoop through the disk to see if the number marked in each sector coincides with the number marked for that sector by MICROSCOPE-32.
9) - If everything goes OK, install Windows and your applications again.
10) - If the numbers written in the sectors don't coincide with those that MICROSCOPE-32 indicates in the head of the screen of Sector Edition" menu, the situation looks quite ugly. If the hard disk manufacturer doesn't provide you a reprogramming BIOS utility, get rid of the disk (proper disposal), because there is no way: damage non-repairable.
11) - It would be also interesting to look for in Internet the main web site of your motherboard manufacturer. These hardware firms usually have programs and data to update their motherboard Flash Bios, available in free download mode.

We hope to have helped you to get a better understanding of the hard disks logical configuration, as well as the procedures and tricky things the viruses do to drive crazy the system and, of course, those people trying to detect, target and destroy these insane computer bugs.

Best regards,

Angel Moreno.
Development Head.
QUIPUSOFT LC.