Your Ad Here

We have moved to http://access-xperia.blogspot.com

ATX If you are this blogs reader, I encourage you to visit and join ATX. This blog will not be discontinued but all the recent updates will be on ATX. ATX brings you a more exciting look, more premium software for free and ofcourse a chance to win invitations of some selected sites.

Visit and readACCESS THE XPERIA

Resource site of Computer software, Phone application, E-books, Programming codes, yahoo tools, tutorials, hacking tools, keylogger, trojan, hacking, MP3 and much more. ::CORE™::

Monday, August 24, 2009

Winrar + Tutorial

    Download WINRAR

WinRar Tutorial: Compression profiles, passwords and more

 FIRST - Set Yer options correctly
Open WInRar

OPTIONS | SETTINGS | COMPRESSSION | CREATE DEFAULT

GENERAL | (ok now that we're there, here's what U do next)
But 1st -> realize that everything U set on the default profile will occur everytime U rar files. So if U only need a password occasionally, or other special settings, then create another profile for those purposes. U can change which profile U need to use when WinRar is open. The Default profile is used otherwise, such as when using WinRar from the context menus in explorer.

General tab:

Archive format RAR

Compression method BEST

size (enter in BYTES the size you want as the max single Rar file). I use 51,200,000 (50,000 KB x 1024). But chose yer max size as U wish.

Update method ADD AND REPLACE FILES

Archiving options: check > PUT RECOVERY RECORD

Archiving options: check > TEST ARCHIVED FILES.

Archiving options: check > DELETE FILES AFTER ARCHIVING ( unless U want yer HDD to fill up with the rars & the original files for some reason)

Archiving options: do NOT check > Put authenticy verification, as this can be a source of Error Messages being generated upon extraction.

Archiving options: check > Create SFX ONLY if U don't expect the person getting the filez to have WinRar. Otherwise leave it UNCHECKED.

Archiving options: do NOT check > Create Solid Archive. This can cause problems in certain cases.

Archiving options: do NOT check > Lock Arhive. This has NOTHING to do with a password.

Advanced tab:

Recovery Record -> U can leave it at 1%. Only set it higher if U expect the rar files to have a high risk of corruption. (very bad internet connections, or use on floppy disks, etc)

All else can be left alone. Don't bother with the Compression button.

Files Tab


File Paths -> STORE RELATIVE PATHS. (unless U have a specific folder U want the files to be extracted to. Such as c:\program files\No Name Appz\link catcher).

The rest leave alone

Backup Tab

No need to change anything.

Time Tab

Files to Process -> OF ANY TIME

Comment Tab

Whatever comment U enter there will be shown on the right hand pane when WinRar opens yer Rar files. Think of something fun, catchy,interesting. I always mention that the files have recovery record set, so if they are corrupted in transfer, the person knows to use REPAIR function.

Click OK, U have now created yer default profile.

==============================================

HOW TO CREATE a PASSWORDED PROFILE, which will NOT be the default:

open WInRar

Click the ADD Icon

ADVANCED | Push the SET PASSWORD Button

Check the SHOW PASSWORD box, so U can see what U typed and also copy/paste it to wherever U need it, such as on yer post. Now only one box will be open to enter the password. COPY/PASTE it to a txt file. I call mine WinRAR_Password.txt. Do this IMMEDIATELY afer entering it, before closing that window, or U may be very sorry later.

Enter the password. It is CASE SENSITIVE. If the password is 8 or more alpha-numeric characters, no one will be able to hack it. Unless they own a super-computer. Avoid using words that are found in dictionaries.

Check the encrypt file names box. That way, even if some nasty person obtains yer Rar file, they won't know what is in it, especially if the name U give the rar file is "Grandma_pix.rar" or whatever.

Back to GENERAL tab | PROFILES button | Save Current Settings to a New Profile

Enter the name of this profile. For example if the passwd is ht*p://www.superforum.com, U might name the profile Superforum. Only U will see this profile name. It does not go into the rar files made from it.

Do NOTHING more, do NOT set this as default profile.

Click OK | Click OK again.

Now U have a Passworded Profile.

================================================

HOW TO USE the PASSWORD PROFILE
Note -> Everything U set on the default profile will occur everytime U rar files. So when U need the password profile, follow these instructions. The Default profile is used otherwise, such as when using WinRar from the contest menus in explorer.

Open WinRar

Browse to the filez/folderz U want to Rar with Password.

Highlight all filez/folderz to be included.

Press the ADD button.

GENERAL tab | PROFILES button

Scoll down to the profile whcih has the password set. In my example Superforum

Click OK

The filez are Rar'd. U can check if U did all correctly by opening the rar filez, and seeing if a password is required.

Until U change back to DEFAULT profile in this same method, or close WinRar, all Rar'z U create after this will have a password.

================================================

HOW TO REPAIR A CORRUPTED RAR FILE:

With Win Explorer create a sub folder REPAIRED

Open WinRar, browse to the folder with the damaged Rar file(z). U can find which one is bad by selecting the 1st RAR file and using TEST button.

Select the damaged file, press REPAIR button.

In dialogue box, enter the path to the REPAIR subfolder, or browse to it.

As long as there is a RECOVERY record in that Rar, it will be repaired.

Copy all the NON-DAMAGED rars to your repair folder and rename the REPAIRED file back to it's original name.

Proceed with extraction in the REPAIR folder as normal.

===============================================

MISC TIPS:

If U select a folder to Rar, later when U extract it inside that folder, U end up with nested folders of same name. (We've all seen this often when extracting rars.

So Instead, go inside the folder, select all the filez & sub-folderz. Now U have a rar inside just one folder.

Note to w***z Groups, how about using WinRar Recovery option finally, and avoiding problems with corrupt DL's ?

Winrar + Tutorial

    Download WINRAR

WinRar Tutorial: Compression profiles, passwords and more

 FIRST - Set Yer options correctly
Open WInRar

OPTIONS | SETTINGS | COMPRESSSION | CREATE DEFAULT

GENERAL | (ok now that we're there, here's what U do next)
But 1st -> realize that everything U set on the default profile will occur everytime U rar files. So if U only need a password occasionally, or other special settings, then create another profile for those purposes. U can change which profile U need to use when WinRar is open. The Default profile is used otherwise, such as when using WinRar from the context menus in explorer.

General tab:

Archive format RAR

Compression method BEST

size (enter in BYTES the size you want as the max single Rar file). I use 51,200,000 (50,000 KB x 1024). But chose yer max size as U wish.

Update method ADD AND REPLACE FILES

Archiving options: check > PUT RECOVERY RECORD

Archiving options: check > TEST ARCHIVED FILES.

Archiving options: check > DELETE FILES AFTER ARCHIVING ( unless U want yer HDD to fill up with the rars & the original files for some reason)

Archiving options: do NOT check > Put authenticy verification, as this can be a source of Error Messages being generated upon extraction.

Archiving options: check > Create SFX ONLY if U don't expect the person getting the filez to have WinRar. Otherwise leave it UNCHECKED.

Archiving options: do NOT check > Create Solid Archive. This can cause problems in certain cases.

Archiving options: do NOT check > Lock Arhive. This has NOTHING to do with a password.

Advanced tab:

Recovery Record -> U can leave it at 1%. Only set it higher if U expect the rar files to have a high risk of corruption. (very bad internet connections, or use on floppy disks, etc)

All else can be left alone. Don't bother with the Compression button.

Files Tab


File Paths -> STORE RELATIVE PATHS. (unless U have a specific folder U want the files to be extracted to. Such as c:\program files\No Name Appz\link catcher).

The rest leave alone

Backup Tab

No need to change anything.

Time Tab

Files to Process -> OF ANY TIME

Comment Tab

Whatever comment U enter there will be shown on the right hand pane when WinRar opens yer Rar files. Think of something fun, catchy,interesting. I always mention that the files have recovery record set, so if they are corrupted in transfer, the person knows to use REPAIR function.

Click OK, U have now created yer default profile.

==============================================

HOW TO CREATE a PASSWORDED PROFILE, which will NOT be the default:

open WInRar

Click the ADD Icon

ADVANCED | Push the SET PASSWORD Button

Check the SHOW PASSWORD box, so U can see what U typed and also copy/paste it to wherever U need it, such as on yer post. Now only one box will be open to enter the password. COPY/PASTE it to a txt file. I call mine WinRAR_Password.txt. Do this IMMEDIATELY afer entering it, before closing that window, or U may be very sorry later.

Enter the password. It is CASE SENSITIVE. If the password is 8 or more alpha-numeric characters, no one will be able to hack it. Unless they own a super-computer. Avoid using words that are found in dictionaries.

Check the encrypt file names box. That way, even if some nasty person obtains yer Rar file, they won't know what is in it, especially if the name U give the rar file is "Grandma_pix.rar" or whatever.

Back to GENERAL tab | PROFILES button | Save Current Settings to a New Profile

Enter the name of this profile. For example if the passwd is ht*p://www.superforum.com, U might name the profile Superforum. Only U will see this profile name. It does not go into the rar files made from it.

Do NOTHING more, do NOT set this as default profile.

Click OK | Click OK again.

Now U have a Passworded Profile.

================================================

HOW TO USE the PASSWORD PROFILE
Note -> Everything U set on the default profile will occur everytime U rar files. So when U need the password profile, follow these instructions. The Default profile is used otherwise, such as when using WinRar from the contest menus in explorer.

Open WinRar

Browse to the filez/folderz U want to Rar with Password.

Highlight all filez/folderz to be included.

Press the ADD button.

GENERAL tab | PROFILES button

Scoll down to the profile whcih has the password set. In my example Superforum

Click OK

The filez are Rar'd. U can check if U did all correctly by opening the rar filez, and seeing if a password is required.

Until U change back to DEFAULT profile in this same method, or close WinRar, all Rar'z U create after this will have a password.

================================================

HOW TO REPAIR A CORRUPTED RAR FILE:

With Win Explorer create a sub folder REPAIRED

Open WinRar, browse to the folder with the damaged Rar file(z). U can find which one is bad by selecting the 1st RAR file and using TEST button.

Select the damaged file, press REPAIR button.

In dialogue box, enter the path to the REPAIR subfolder, or browse to it.

As long as there is a RECOVERY record in that Rar, it will be repaired.

Copy all the NON-DAMAGED rars to your repair folder and rename the REPAIRED file back to it's original name.

Proceed with extraction in the REPAIR folder as normal.

===============================================

MISC TIPS:

If U select a folder to Rar, later when U extract it inside that folder, U end up with nested folders of same name. (We've all seen this often when extracting rars.

So Instead, go inside the folder, select all the filez & sub-folderz. Now U have a rar inside just one folder.

Note to w***z Groups, how about using WinRar Recovery option finally, and avoiding problems with corrupt DL's ?

Tuesday, November 11, 2008

Dark Angel's Virus Writing

Virii are wondrous creations written for the sole purpose of spreading and
destroying the systems of unsuspecting fools. This eliminates the systems
of simpletons who can't tell that there is a problem when a 100 byte file
suddenly blossoms into a 1,000 byte file. Duh. These low-lifes do not
deserve to exist, so it is our sacred duty to wipe their hard drives off
the face of the Earth. It is a simple matter of speeding along survival of
the fittest.

Why did I create this guide? After writing several virii, I have noticed
that virus writers generally learn how to write virii either on their own
or by examining the disassembled code of other virii. There is an
incredible lack of information on the subject. Even books published by
morons such as Burger are, at best, sketchy on how to create a virus. This
guide will show you what it takes to write a virus and also will give you a
plethora of source code to include in your own virii.

Virus writing is not as hard as you might first imagine. To write an
effective virus, however, you *must* know assembly language. Short,
compact code are hallmarks of assembly language and these are desirable
characteristics of virii. However, it is *not* necessary to write in pure
assembly. C may also be used, as it allows almost total control of the
system while generating relatively compact code (if you stay away from the
library functions). However, you still must access the interrupts, so
assembly knowledge is still required. However, it is still best to stick
with pure assembly, since most operations are more easily coded in
assembly. If you do not know assembly, I would recommend picking up a copy
of The Microsoft Macro Assembler Bible (Nabajyoti Barkakati, ISBN #: 0-672-
22659-6). It is an easy-to-follow book covering assembly in great detail.
Also get yourself a copy of Undocumented DOS (Schulman, et al, ISBN #0-201-
57064-5), as it is very helpful.

The question of which compiler to use arises often. I suggest using
Borland Turbo Assembler and/or Borland C++. I do not have a copy of
Zortech C (it was too large to download), but I would suspect that it is
also a good choice. Stay away from Microsoft compilers, as they are not as
flexible nor as efficient as those of other vendors.

A few more items round out the list of tools helpful in constructing virii.
The latest version of Norton Utilities is one of the most powerful programs
available, and is immeasurably helpful. MAKE SURE YOU HAVE A COPY! You
can find it on any decent board. It can be used during every step of the
process, from the writing to the testing. A good debugger helps. Memory
management utilities such as MAPMEM, PMAP, and MARK/RELEASE, are
invaluable, especially when coding TSR virii. Sourcer, the commenting
disassembler, is useful when you wish to examine the code of other virii
(this is a good place to get ideas/techniques for your virus).

Now that you have your tools, you are ready to create a work of art
designed to smash the systems of cretins. There are three types of virii:

1) Tiny virii (under 500 bytes) which are designed to be undetectable
due to their small size. TINY is one such virus. They are
generally very simple because their code length is so limited.
2) Large virii (over 1,500 bytes) which are designed to be
undetectable because they cover their tracks very well (all that
code DOES have a use!). The best example of this is the Whale
virus, which is perhaps the best 'Stealth' virus in existence.
3) Other virii which are not designed to be hidden at all (the writers
don't give a shit). The common virus is like this. All
overwriting virii are in this category.

You must decide which kind of virus you wish to write. I will mostly be
discussing the second type (Stealth virii). However, many of the
techniques discribed may be easily applied to the first type (tiny virii).
However, tiny virii generally do not have many of the "features" of larger
virii, such as directory traversal. The third type is more of a
replicating trojan-type, and will warrant a brief (very, very brief!)
discussion later.

A virus may be divided into three parts: the replicator, the concealer, and
the bomb. The replicator part controls the spread of the virus to other
files, the concealer keeps the virus from being detected, and the bomb only
executes when the activation conditions of the virus (more on that later)
are satisfied.

-=-=-=-=-=-=-=-
THE REPLICATOR
-=-=-=-=-=-=-=-
The job of the replicator is to spread the virus throughout the system of
the clod who has caught the virus. How does it do this without destroying
the file it infects? The easiest type of replicator infects COM files. It
first saves the first few bytes of the infected file. It then copies a
small portion of its code to the beginning of the file, and the rest to the
end.

+----------------+ +------------+
| P1 | P2 | | V1 | V2 |
+----------------+ +------------+
The uninfected file The virus code

In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1
and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be
the same as the size of V1, but the size of P2 doesn't necessarily have to
be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's
assume it copies the code to the end of the file. The file now looks like:

+---------------------+
| P1 | P2 | P1 |
+---------------------+

Then, the virus copies the first part of itself to the beginning of the
file.

+---------------------+
| V1 | P2 | P1 |
+---------------------+

Finally, the virus copies the second part of itself to the end of the file.
The final, infected file looks like this:

+-----------------------------+
| V1 | P2 | P1 | V2 |
+-----------------------------+

The question is: What the **** do V1 and V2 do? V1 transfers control of
the program to V2. The code to do this is simple.

JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes

Duh is a far pointer (Segment:Offset) pointing to the first instruction of
V2. Note that the value of Duh must be changed to reflect the length of
the file that is infected. For example, if the original size of the
program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length
of V1, the original size of the infected file, and 256 (to account for the
PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal
(155 hex).

An alternate, albeit more difficult to understand, method follows:

DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement

This inserts the jump offset directly into the code following the jump
instruction. You could also replace the second line with

DW V2_Start - $

which accomplishes the same task.

V2 contains the rest of the code, i.e. the stuff that does everything else.
The last part of V2 copies P1 over V1 (in memory, not on disk) and then
transfers control to the beginning of the file (in memory). The original
program will then run happily as if nothing happened. The code to do this
is also very simple.

MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]

MOV DI, 0100h
JMP DI

This code assumes that P1 is located just before V2, as in:

P1_Stored_Here:
.
.
.
V2_Start:

It also assumes ES equals CS. If these assumptions are false, change the
code accordingly. Here is an example:

PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB

MOV DI, 0100h
JMP DI

This code first moves CS into ES and then sets the source pointer of MOVSB
to where P1 is located. Remember that this is all taking place in memory,
so you need the OFFSET of P1, not just the physical location in the file.
The offset of P1 is 100h higher than the physical file location, as COM
files are loaded starting from CS:[100h].

So here's a summary of the parts of the virus and location labels:

V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:

P2_Start:
P2_End:

P1_Start:
; First part of the program stored here for future use
P1_End:

V2_Start:
; Real Stuff
V2_End:

V1_Length EQU V1_End - V1_Start

Alternatively, you could store P1 in V2 as follows:

V2_Start:

P1_Start:
P1_End:

V2_End:

That's all there is to infecting a COM file without destroying it! Simple,
no? EXE files, however, are a little tougher to infect without rendering
them inexecutable - I will cover this topic in a later file.

Now let us turn our attention back to the replicator portion of the virus.
The steps are outlined below:

1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1

Finding a file to infect is a simple matter of writing a directory
traversal procedure and issuing FINDFIRST and FINDNEXT calls to find
possible files to infect. Once you find the file, open it and read the
first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to
your virus, change it so that they are. It is *extremely* important that
your virus doesn't reinfect the same files, since that was how Jerusalem
was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:

1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.

You should keep a counter of the number of files infected during this run.
If the number exceeds, say three, then stop. It is better to infect slowly
then to give yourself away by infecting the entire drive at once.

You must be sure to cover your tracks when you infect a file. Save the
file's original date/time/attributes and restore them when you are
finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code,
probably less, to do these few simple things which can do wonders for the
concealment of your program.

I will include code for the directory traversal function, as well as other
parts of the replicator in the next installment of my phunky guide.

-=-=-=-=-
CONCEALER
-=-=-=-=-
This is the part which conceals the program from notice by the everyday
user and virus scanner. The simplest form of concealment is the encryptor.
The code for a simple XOR encryption system follows:

encrypt_val db ?

decrypt:
encrypt:
mov ah, encrypt_val

mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si

xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret

Note the encryption and decryption procedures are the same. This is due to
the weird nature of XOR. You can CALL these procedures from anywhere in
the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set
the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end
sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning
of V2 to unencrypt the file so your program can run. When infecting a
file, first change the encrypt_val, then CALL encrypt, then write V2 to the
end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE
AREA TO BE ENCRYPTED!!!

This is how V2 would look with the concealer:

V2_Start:

Concealer_Start:
.
.
.
Concealer_End:

Replicator_Start:
.
.
.
Replicator_End:

Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:

Alternatively, you could move parts of the unencrypted stuff between
Part_To_Encrypt_End and V2_End.

The value of encryption is readily apparent. Encryption makes it harder
for virus scanners to locate your virus. It also hides some text strings
located in your program. It is the easiest and shortest way to hide your
virus.

Encryption is only one form of concealment. At least one other virus hooks
into the DOS interrupts and alters the output of DIR so the file sizes
appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain
parts of memory allow it to survive warm reboots. There are many stealth
techniques, limited only by the virus writer's imagination.

-=-=-=-=-
THE BOMB
-=-=-=-=-
So now all the boring stuff is over. The nastiness is contained here. The
bomb part of the virus does all the deletion/slowdown/etc which make virii
so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has
infected 100 files. When these conditions are met, then your virus does
the good stuff. Some suggestions of possible bombs:

1) System slowdown - easily handled by trapping an interrupt and
causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the
effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard
drive - This is very nasty, as most dimwits cannot fix this.

This is, of course, the fun part of writing a virus, so be original!

-=-=-=-=-=-=-=-
OFFSET PROBLEMS
-=-=-=-=-=-=-=-
There is one caveat regarding calculation of offsets. After you infect a
file, the locations of variables change. You MUST account for this. All
relative offsets can stay the same, but you must add the file size to the
absolute offsets or your program will not work. This is the most tricky
part of writing virii and taking these into account can often greatly
increase the size of a virus. THIS IS VERY IMPORTANT AND YOU SHOULD BE
SURE TO UNDERSTAND THIS BEFORE ATTEMPTING TO WRITE A NONOVERWRITING VIRUS!
If you don't, you'll get fucked over and your virus WILL NOT WORK! One
entire part of the guide will be devoted to this subject.

-=-=-=-
TESTING
-=-=-=-
Testing virii is a dangerous yet essential part of the virus creation
process. This is to make certain that people *will* be hit by the virus
and, hopefully, wiped out. Test thoroughly and make sure it activates
under the conditions. It would be great if everyone had a second computer
to test their virii out, but, of course, this is not the case. So it is
ESSENTIAL that you keep BACKUPS of your files, partition, boot record, and
FAT. Norton is handy in this doing this. Do NOT disregard this advice
(even though I know that you will anyway) because you WILL be hit by your
own virii. When I wrote my first virus, my system was taken down for two
days because I didn't have good backups. Luckily, the virus was not overly
destructive. BACKUPS MAKE SENSE! LEECH A BACKUP PROGRAM FROM YOUR LOCAL
PIRATE BOARD! I find a RamDrive is often helpful in testing virii, as the
damage is not permanent. RamDrives are also useful for testing trojans,
but that is the topic of another file...

-=-=-=-=-=-=-
DISTRIBUTION
-=-=-=-=-=-=-
This is another fun part of virus writing. It involves sending your
brilliantly-written program through the phone lines to your local,
unsuspecting bulletin boards. What you should do is infect a file that
actually does something (leech a useful utility from another board), infect
it, and upload it to a place where it will be downloaded by users all over.
The best thing is that it won't be detected by puny scanner-wanna-bes by
McAffee, since it is new! Oh yeah, make sure you are using a false account
(duh). Better yet, make a false account with the name/phone number of
someone you don't like and upload the infected file under the his name.
You can call back from time to time and use a door such as ZDoor to check
the spread of the virus. The more who download, the more who share in the
experience of your virus!

I promised a brief section on overwriting virii, so here it is...
-=-=-=-=-=-=-=-=-
OVERWRITING VIRII
-=-=-=-=-=-=-=-=-
All these virii do is spread throughout the system. They render the
infected files inexecutable, so they are easily detected. It is simple to
write one:

+-------------+ +-----+ +-------------+
| Program | + |Virus| = |Virus|am |
+-------------+ +-----+ +-------------+

These virii are simple little hacks, but pretty worthless because of their
easy detectability. Enuff said!

-=-=-=-=-=-=-=-=-=-=-=-=-
WELL, THAT JUST ABOUT...
-=-=-=-=-=-=-=-=-=-=-=-=-
wraps it up for this installment of Dark Angel's Phunky virus writing
guide. There will (hopefully) be future issues where I discuss more about
virii and include much more source code (mo' source!). Till then, happy
coding!

Dark Angel's Virus Writing

Virii are wondrous creations written for the sole purpose of spreading and
destroying the systems of unsuspecting fools. This eliminates the systems
of simpletons who can't tell that there is a problem when a 100 byte file
suddenly blossoms into a 1,000 byte file. Duh. These low-lifes do not
deserve to exist, so it is our sacred duty to wipe their hard drives off
the face of the Earth. It is a simple matter of speeding along survival of
the fittest.

Why did I create this guide? After writing several virii, I have noticed
that virus writers generally learn how to write virii either on their own
or by examining the disassembled code of other virii. There is an
incredible lack of information on the subject. Even books published by
morons such as Burger are, at best, sketchy on how to create a virus. This
guide will show you what it takes to write a virus and also will give you a
plethora of source code to include in your own virii.

Virus writing is not as hard as you might first imagine. To write an
effective virus, however, you *must* know assembly language. Short,
compact code are hallmarks of assembly language and these are desirable
characteristics of virii. However, it is *not* necessary to write in pure
assembly. C may also be used, as it allows almost total control of the
system while generating relatively compact code (if you stay away from the
library functions). However, you still must access the interrupts, so
assembly knowledge is still required. However, it is still best to stick
with pure assembly, since most operations are more easily coded in
assembly. If you do not know assembly, I would recommend picking up a copy
of The Microsoft Macro Assembler Bible (Nabajyoti Barkakati, ISBN #: 0-672-
22659-6). It is an easy-to-follow book covering assembly in great detail.
Also get yourself a copy of Undocumented DOS (Schulman, et al, ISBN #0-201-
57064-5), as it is very helpful.

The question of which compiler to use arises often. I suggest using
Borland Turbo Assembler and/or Borland C++. I do not have a copy of
Zortech C (it was too large to download), but I would suspect that it is
also a good choice. Stay away from Microsoft compilers, as they are not as
flexible nor as efficient as those of other vendors.

A few more items round out the list of tools helpful in constructing virii.
The latest version of Norton Utilities is one of the most powerful programs
available, and is immeasurably helpful. MAKE SURE YOU HAVE A COPY! You
can find it on any decent board. It can be used during every step of the
process, from the writing to the testing. A good debugger helps. Memory
management utilities such as MAPMEM, PMAP, and MARK/RELEASE, are
invaluable, especially when coding TSR virii. Sourcer, the commenting
disassembler, is useful when you wish to examine the code of other virii
(this is a good place to get ideas/techniques for your virus).

Now that you have your tools, you are ready to create a work of art
designed to smash the systems of cretins. There are three types of virii:

1) Tiny virii (under 500 bytes) which are designed to be undetectable
due to their small size. TINY is one such virus. They are
generally very simple because their code length is so limited.
2) Large virii (over 1,500 bytes) which are designed to be
undetectable because they cover their tracks very well (all that
code DOES have a use!). The best example of this is the Whale
virus, which is perhaps the best 'Stealth' virus in existence.
3) Other virii which are not designed to be hidden at all (the writers
don't give a shit). The common virus is like this. All
overwriting virii are in this category.

You must decide which kind of virus you wish to write. I will mostly be
discussing the second type (Stealth virii). However, many of the
techniques discribed may be easily applied to the first type (tiny virii).
However, tiny virii generally do not have many of the "features" of larger
virii, such as directory traversal. The third type is more of a
replicating trojan-type, and will warrant a brief (very, very brief!)
discussion later.

A virus may be divided into three parts: the replicator, the concealer, and
the bomb. The replicator part controls the spread of the virus to other
files, the concealer keeps the virus from being detected, and the bomb only
executes when the activation conditions of the virus (more on that later)
are satisfied.

-=-=-=-=-=-=-=-
THE REPLICATOR
-=-=-=-=-=-=-=-
The job of the replicator is to spread the virus throughout the system of
the clod who has caught the virus. How does it do this without destroying
the file it infects? The easiest type of replicator infects COM files. It
first saves the first few bytes of the infected file. It then copies a
small portion of its code to the beginning of the file, and the rest to the
end.

+----------------+ +------------+
| P1 | P2 | | V1 | V2 |
+----------------+ +------------+
The uninfected file The virus code

In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1
and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be
the same as the size of V1, but the size of P2 doesn't necessarily have to
be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's
assume it copies the code to the end of the file. The file now looks like:

+---------------------+
| P1 | P2 | P1 |
+---------------------+

Then, the virus copies the first part of itself to the beginning of the
file.

+---------------------+
| V1 | P2 | P1 |
+---------------------+

Finally, the virus copies the second part of itself to the end of the file.
The final, infected file looks like this:

+-----------------------------+
| V1 | P2 | P1 | V2 |
+-----------------------------+

The question is: What the **** do V1 and V2 do? V1 transfers control of
the program to V2. The code to do this is simple.

JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes

Duh is a far pointer (Segment:Offset) pointing to the first instruction of
V2. Note that the value of Duh must be changed to reflect the length of
the file that is infected. For example, if the original size of the
program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length
of V1, the original size of the infected file, and 256 (to account for the
PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal
(155 hex).

An alternate, albeit more difficult to understand, method follows:

DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement

This inserts the jump offset directly into the code following the jump
instruction. You could also replace the second line with

DW V2_Start - $

which accomplishes the same task.

V2 contains the rest of the code, i.e. the stuff that does everything else.
The last part of V2 copies P1 over V1 (in memory, not on disk) and then
transfers control to the beginning of the file (in memory). The original
program will then run happily as if nothing happened. The code to do this
is also very simple.

MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]

MOV DI, 0100h
JMP DI

This code assumes that P1 is located just before V2, as in:

P1_Stored_Here:
.
.
.
V2_Start:

It also assumes ES equals CS. If these assumptions are false, change the
code accordingly. Here is an example:

PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB

MOV DI, 0100h
JMP DI

This code first moves CS into ES and then sets the source pointer of MOVSB
to where P1 is located. Remember that this is all taking place in memory,
so you need the OFFSET of P1, not just the physical location in the file.
The offset of P1 is 100h higher than the physical file location, as COM
files are loaded starting from CS:[100h].

So here's a summary of the parts of the virus and location labels:

V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:

P2_Start:
P2_End:

P1_Start:
; First part of the program stored here for future use
P1_End:

V2_Start:
; Real Stuff
V2_End:

V1_Length EQU V1_End - V1_Start

Alternatively, you could store P1 in V2 as follows:

V2_Start:

P1_Start:
P1_End:

V2_End:

That's all there is to infecting a COM file without destroying it! Simple,
no? EXE files, however, are a little tougher to infect without rendering
them inexecutable - I will cover this topic in a later file.

Now let us turn our attention back to the replicator portion of the virus.
The steps are outlined below:

1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1

Finding a file to infect is a simple matter of writing a directory
traversal procedure and issuing FINDFIRST and FINDNEXT calls to find
possible files to infect. Once you find the file, open it and read the
first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to
your virus, change it so that they are. It is *extremely* important that
your virus doesn't reinfect the same files, since that was how Jerusalem
was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:

1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.

You should keep a counter of the number of files infected during this run.
If the number exceeds, say three, then stop. It is better to infect slowly
then to give yourself away by infecting the entire drive at once.

You must be sure to cover your tracks when you infect a file. Save the
file's original date/time/attributes and restore them when you are
finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code,
probably less, to do these few simple things which can do wonders for the
concealment of your program.

I will include code for the directory traversal function, as well as other
parts of the replicator in the next installment of my phunky guide.

-=-=-=-=-
CONCEALER
-=-=-=-=-
This is the part which conceals the program from notice by the everyday
user and virus scanner. The simplest form of concealment is the encryptor.
The code for a simple XOR encryption system follows:

encrypt_val db ?

decrypt:
encrypt:
mov ah, encrypt_val

mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si

xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret

Note the encryption and decryption procedures are the same. This is due to
the weird nature of XOR. You can CALL these procedures from anywhere in
the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set
the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end
sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning
of V2 to unencrypt the file so your program can run. When infecting a
file, first change the encrypt_val, then CALL encrypt, then write V2 to the
end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE
AREA TO BE ENCRYPTED!!!

This is how V2 would look with the concealer:

V2_Start:

Concealer_Start:
.
.
.
Concealer_End:

Replicator_Start:
.
.
.
Replicator_End:

Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:

Alternatively, you could move parts of the unencrypted stuff between
Part_To_Encrypt_End and V2_End.

The value of encryption is readily apparent. Encryption makes it harder
for virus scanners to locate your virus. It also hides some text strings
located in your program. It is the easiest and shortest way to hide your
virus.

Encryption is only one form of concealment. At least one other virus hooks
into the DOS interrupts and alters the output of DIR so the file sizes
appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain
parts of memory allow it to survive warm reboots. There are many stealth
techniques, limited only by the virus writer's imagination.

-=-=-=-=-
THE BOMB
-=-=-=-=-
So now all the boring stuff is over. The nastiness is contained here. The
bomb part of the virus does all the deletion/slowdown/etc which make virii
so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has
infected 100 files. When these conditions are met, then your virus does
the good stuff. Some suggestions of possible bombs:

1) System slowdown - easily handled by trapping an interrupt and
causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the
effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard
drive - This is very nasty, as most dimwits cannot fix this.

This is, of course, the fun part of writing a virus, so be original!

-=-=-=-=-=-=-=-
OFFSET PROBLEMS
-=-=-=-=-=-=-=-
There is one caveat regarding calculation of offsets. After you infect a
file, the locations of variables change. You MUST account for this. All
relative offsets can stay the same, but you must add the file size to the
absolute offsets or your program will not work. This is the most tricky
part of writing virii and taking these into account can often greatly
increase the size of a virus. THIS IS VERY IMPORTANT AND YOU SHOULD BE
SURE TO UNDERSTAND THIS BEFORE ATTEMPTING TO WRITE A NONOVERWRITING VIRUS!
If you don't, you'll get fucked over and your virus WILL NOT WORK! One
entire part of the guide will be devoted to this subject.

-=-=-=-
TESTING
-=-=-=-
Testing virii is a dangerous yet essential part of the virus creation
process. This is to make certain that people *will* be hit by the virus
and, hopefully, wiped out. Test thoroughly and make sure it activates
under the conditions. It would be great if everyone had a second computer
to test their virii out, but, of course, this is not the case. So it is
ESSENTIAL that you keep BACKUPS of your files, partition, boot record, and
FAT. Norton is handy in this doing this. Do NOT disregard this advice
(even though I know that you will anyway) because you WILL be hit by your
own virii. When I wrote my first virus, my system was taken down for two
days because I didn't have good backups. Luckily, the virus was not overly
destructive. BACKUPS MAKE SENSE! LEECH A BACKUP PROGRAM FROM YOUR LOCAL
PIRATE BOARD! I find a RamDrive is often helpful in testing virii, as the
damage is not permanent. RamDrives are also useful for testing trojans,
but that is the topic of another file...

-=-=-=-=-=-=-
DISTRIBUTION
-=-=-=-=-=-=-
This is another fun part of virus writing. It involves sending your
brilliantly-written program through the phone lines to your local,
unsuspecting bulletin boards. What you should do is infect a file that
actually does something (leech a useful utility from another board), infect
it, and upload it to a place where it will be downloaded by users all over.
The best thing is that it won't be detected by puny scanner-wanna-bes by
McAffee, since it is new! Oh yeah, make sure you are using a false account
(duh). Better yet, make a false account with the name/phone number of
someone you don't like and upload the infected file under the his name.
You can call back from time to time and use a door such as ZDoor to check
the spread of the virus. The more who download, the more who share in the
experience of your virus!

I promised a brief section on overwriting virii, so here it is...
-=-=-=-=-=-=-=-=-
OVERWRITING VIRII
-=-=-=-=-=-=-=-=-
All these virii do is spread throughout the system. They render the
infected files inexecutable, so they are easily detected. It is simple to
write one:

+-------------+ +-----+ +-------------+
| Program | + |Virus| = |Virus|am |
+-------------+ +-----+ +-------------+

These virii are simple little hacks, but pretty worthless because of their
easy detectability. Enuff said!

-=-=-=-=-=-=-=-=-=-=-=-=-
WELL, THAT JUST ABOUT...
-=-=-=-=-=-=-=-=-=-=-=-=-
wraps it up for this installment of Dark Angel's Phunky virus writing
guide. There will (hopefully) be future issues where I discuss more about
virii and include much more source code (mo' source!). Till then, happy
coding!

Saturday, November 8, 2008

10 Good Reasons Why PC Shows Errors

Fatal error: the system has become unstable or is busy," it says. "Enter to return to Windows or press Control-Alt-Delete to restart your computer. If you do this you will lose any unsaved information in all open applications."

You have just been struck by the Blue Screen of Death. Anyone who uses Microsoft Windows will be familiar with this. What can you do? More importantly, how can you prevent it happening?

1 Hardware conflict

The number one reason why Windows crashes is hardware conflict. Each hardware device communicates to other devices through an interrupt request channel (IRQ). These are supposed to be unique for each device.

For example, a printer usually connects internally on IRQ 7. The keyboard usually uses IRQ 1 and the floppy disk drive IRQ 6. Each device will try to hog a single IRQ for itself.

If there are a lot of devices, or if they are not installed properly, two of them may end up sharing the same IRQ number. When the user tries to use both devices at the same time, a crash can happen. The way to check if your computer has a hardware conflict is through the following route:

* Start-Settings-Control Panel-System-Device Manager.

Often if a device has a problem a yellow '!' appears next to its description in the Device Manager. Highlight Computer (in the Device Manager) and press Properties to see the IRQ numbers used by your computer. If the IRQ number appears twice, two devices may be using it.

Sometimes a device might share an IRQ with something described as 'IRQ holder for PCI steering'. This can be ignored. The best way to fix this problem is to remove the problem device and reinstall it.

Sometimes you may have to find more recent drivers on the internet to make the device function properly. A good resource is www.driverguide.com. If the device is a soundcard, or a modem, it can often be fixed by moving it to a different slot on the motherboard (be careful about opening your computer, as you may void the warranty).

When working inside a computer you should switch it off, unplug the mains lead and touch an unpainted metal surface to discharge any static electricity.

To be fair to Mcft, the problem with IRQ numbers is not of its making. It is a legacy problem going back to the first PC designs using the IBM 8086 chip. Initially there were only eight IRQs. Today there are 16 IRQs in a PC. It is easy to run out of them. There are plans to increase the number of IRQs in future designs.

2 Bad Ram

Ram (random-access memory) problems might bring on the blue screen of death with a message saying Fatal Exception Error. A fatal error indicates a serious hardware problem. Sometimes it may mean a part is damaged and will need replacing.

But a fatal error caused by Ram might be caused by a mismatch of chips. For example, mixing 70-nanosecond (70ns) Ram with 60ns Ram will usually force the computer to run all the Ram at the slower speed. This will often crash the machine if the Ram is overworked.

One way around this problem is to enter the BIOS settings and increase the wait state of the Ram. This can make it more stable. Another way to troubleshoot a suspected Ram problem is to rearrange the Ram chips on the motherboard, or take some of them out. Then try to repeat the circumstances that caused the crash. When handling Ram try not to touch the gold connections, as they can be easily damaged.

Parity error messages also refer to Ram. Modern Ram chips are either parity (ECC) or non parity (non-ECC). It is best not to mix the two types, as this can be a cause of trouble.

EMM386 error messages refer to memory problems but may not be connected to bad Ram. This may be due to free memory problems often linked to old Dos-based programmes.

3 BIOS settings

Every motherboard is supplied with a range of chipset settings that are decided in the factory. A common way to access these settings is to press the F2 or delete button during the first few seconds of a boot-up.

Once inside the BIOS, great care should be taken. It is a good idea to write down on a piece of paper all the settings that appear on the screen. That way, if you change something and the computer becomes more unstable, you will know what settings to revert to.

A common BIOS error concerns the CAS latency. This refers to the Ram. Older EDO (extended data out) Ram has a CAS latency of 3. Newer SDRam has a CAS latency of 2. Setting the wrong figure can cause the Ram to lock up and freeze the computer's display.

Mcft Windows is better at allocating IRQ numbers than any BIOS. If possible set the IRQ numbers to Auto in the BIOS. This will allow Windows to allocate the IRQ numbers (make sure the BIOS setting for Plug and Play OS is switched to 'yes' to allow Windows to do this.).

4 Hard disk drives

After a few weeks, the information on a hard disk drive starts to become piecemeal or fragmented. It is a good idea to defragment the hard disk every week or so, to prevent the disk from causing a screen freeze. Go to

* Start-Programs-Accessories-System Tools-Disk Defragmenter

This will start the procedure. You will be unable to write data to the hard drive (to save it) while the disk is defragmenting, so it is a good idea to schedule the procedure for a period of inactivity using the Task Scheduler.

The Task Scheduler should be one of the small icons on the bottom right of the Windows opening page (the desktop).

Some lockups and screen freezes caused by hard disk problems can be solved by reducing the read-ahead optimisation. This can be adjusted by going to

* Start-Settings-Control Panel-System Icon-Performance-File System-Hard Disk.

Hard disks will slow down and crash if they are too full. Do some housekeeping on your hard drive every few months and free some space on it. Open the Windows folder on the C drive and find the Temporary Internet Files folder. Deleting the contents (not the folder) can free a lot of space.

Empty the Recycle Bin every week to free more space. Hard disk drives should be scanned every week for errors or bad sectors. Go to

* Start-Programs-Accessories-System Tools-ScanDisk

Otherwise assign the Task Scheduler to perform this operation at night when the computer is not in use.

5 Fatal OE exceptions and VXD errors

Fatal OE exception errors and VXD errors are often caused by video card problems.

These can often be resolved easily by reducing the resolution of the video display. Go to

* Start-Settings-Control Panel-Display-Settings

Here you should slide the screen area bar to the left. Take a look at the colour settings on the left of that window. For most desktops, high colour 16-bit depth is adequate.

If the screen freezes or you experience system lockups it might be due to the video card. Make sure it does not have a hardware conflict. Go to

* Start-Settings-Control Panel-System-Device Manager

Here, select the + beside Display Adapter. A line of text describing your video card should appear. Select it (make it blue) and press properties. Then select Resources and select each line in the window. Look for a message that says No Conflicts.

If you have video card hardware conflict, you will see it here. Be careful at this point and make a note of everything you do in case you make things worse.

The way to resolve a hardware conflict is to uncheck the Use Automatic Settings box and hit the Change Settings button. You are searching for a setting that will display a No Conflicts message.

Another useful way to resolve video problems is to go to

* Start-Settings-Control Panel-System-Performance-Graphics

Here you should move the Hardware Acceleration slider to the left. As ever, the most common cause of problems relating to graphics cards is old or faulty drivers (a driver is a small piece of software used by a computer to communicate with a device).

Look up your video card's manufacturer on the internet and search for the most recent drivers for it.

6 Viruses

Often the first sign of a virus infection is instability. Some viruses erase the boot sector of a hard drive, making it impossible to start. This is why it is a good idea to create a Windows start-up disk. Go to

* Start-Settings-Control Panel-Add/Remove Programs

Here, look for the Start Up Disk tab. Virus protection requires constant vigilance.

A virus scanner requires a list of virus signatures in order to be able to identify viruses. These signatures are stored in a DAT file. DAT files should be updated weekly from the website of your antivirus software manufacturer.

An excellent antivirus programme is McAfee VirusScan by Network Associates ( www.nai.com). Another is Norton AntiVirus 2000, made by Symantec ( www.symantec.com).

7 Printers

The action of sending a document to print creates a bigger file, often called a postscript file.

Printers have only a small amount of memory, called a buffer. This can be easily overloaded. Printing a document also uses a considerable amount of CPU power. This will also slow down the computer's performance.

If the printer is trying to print unusual characters, these might not be recognised, and can crash the computer. Sometimes printers will not recover from a crash because of confusion in the buffer. A good way to clear the buffer is to unplug the printer for ten seconds. Booting up from a powerless state, also called a cold boot, will restore the printer's default settings and you may be able to carry on.

8 Software

A common cause of computer crash is faulty or badly-installed software. Often the problem can be cured by uninstalling the software and then reinstalling it. Use Norton Uninstall or Uninstall Shield to remove an application from your system properly. This will also remove references to the programme in the System Registry and leaves the way clear for a completely fresh copy.

The System Registry can be corrupted by old references to obsolete software that you thought was uninstalled. Use Reg Cleaner by Jouni Vuorio to clean up the System Registry and remove obsolete entries. It works on Windows 95, Windows 98, Windows 98 SE (Second Edition), Windows Millennium Edition (ME), NT4 and Windows 2000.

Read the instructions and use it carefully so you don't do permanent damage to the Registry. If the Registry is damaged you will have to reinstall your operating system. Reg Cleaner can be obtained from www.jv16.org

Often a Windows problem can be resolved by entering Safe Mode. This can be done during start-up. When you see the message "Starting Windows" press F4. This should take you into Safe Mode.

Safe Mode loads a minimum of drivers. It allows you to find and fix problems that prevent Windows from loading properly.

Sometimes installing Windows is difficult because of unsuitable BIOS settings. If you keep getting SUWIN error messages (Windows setup) during the Windows installation, then try entering the BIOS and disabling the CPU internal cache. Try to disable the Level 2 (L2) cache if that doesn't work.

Remember to restore all the BIOS settings back to their former settings following installation.

9 Overheating

Central processing units (CPUs) are usually equipped with fans to keep them cool. If the fan fails or if the CPU gets old it may start to overheat and generate a particular kind of error called a kernel error. This is a common problem in chips that have been overclocked to operate at higher speeds than they are supposed to.

One remedy is to get a bigger better fan and install it on top of the CPU. Specialist cooling fans/heatsinks are available from www.computernerd.com or www.coolit.com

CPU problems can often be fixed by disabling the CPU internal cache in the BIOS. This will make the machine run more slowly, but it should also be more stable.

10 Power supply problems

With all the new construction going on around the country the steady supply of electricity has become disrupted. A power surge or spike can crash a computer as easily as a power cut.

If this has become a nuisance for you then consider buying a uninterrupted power supply (UPS). This will give you a clean power supply when there is electricity, and it will give you a few minutes to perform a controlled shutdown in case of a power cut.

It is a good investment if your data are critical, because a power cut will cause any unsaved data to be lost.


Related Posts with Thumbnails
 

Featured

Widget by Blog Godown

Popular

Center of Reverse Engineering™ Copyright © 2009 Premium Blogger Dashboard Designed by SAER

ss_blog_claim=982832c1e8ace00c1392e8b9a7a4bbfd ss_blog_claim=982832c1e8ace00c1392e8b9a7a4bbfd