let's pretend you need a serial number for windows xp pro.
in the search bar type in just like this - "Windows XP Professional" 94FBR
the key is the 94FBR code.. it was included with many MS Office registration codes so this will help you dramatically reduce the amount of 'fake' porn sites that trick you.
or if you want to find the serial for winzip 8.1 - "Winzip 8.1" 94FBR
just try it out, it's very quick and it works nicely..
-----------------------------------------------------------
here is another trick that works fairly decent for finding mp3's on the web (which is hard to do normally, to say the least)
say you want to get, for example, a Garth Brooks song. type this in the search bar - "index of/" "garth brooks" .mp3 the ones you want to check out first are the ones that say "Index of/" in the title of the search result. this technique allows you to easily pull up web folders with direct downloads. it will look the same as if you were logging into a ftp url.. i'm sure you can be pretty flexible on how you type that in, so long as you include "index of/"
i'm sure you can use this for more than just mp3's (it's not perfect but it has worked for me on a few occasions)
always make sure to use the quotations where i placed them. they help pinpoint the correct search results more accurately. just try it out, also if you want to learn how to do more with google look up "google hacks"
Showing posts with label Hacks. Show all posts
Showing posts with label Hacks. Show all posts
Monday, October 13, 2008
Thursday, September 18, 2008
How to find Security Holes
Security holes manifest themselves in (broadly) four ways:
1) Physical Security Holes.
- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.
A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.
Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.
2) Software Security Holes
- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.
The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.
(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine. The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)
New holes like this appear all the time, and your best hopes are to:
a: try to structure your system so that as little software as possible
runs with root/daemon/bin privileges, and that which does is known to
be robust.
b: subscribe to a mailing list which can get details of problems
and/or fixes out to you as quickly as possible, and then ACT when you
receive information.
>From: Wes Morgan
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need. Many packages include daemons or utilities which can reveal
> information to outsiders. For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user. Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
> tftpd, all of which can present security problems.
>
> Careful system administration is the solution. Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution. You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities
> tend to install/run everything in the package without asking you. Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.
3) Incompatible Usage Security Holes
- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.
Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind. It's
never too late to have a rethink, though.
Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.
4) Choosing a suitable security philosophy and maintaining it.
>From: Gene Spafford
>The fourth kind of security problem is one of perception and
>understanding. Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it. Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.
---
From: Hacking
Subject: Hacking Ideas
Date: 11/10/93
( Please contribute by sending E-Mail to ... )
[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]
NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations
The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories
(Suggested splitting of above into main and sub-catagories)
I: Suid binaries and scripts
unexpected user interactions
flawed liberary calls
implicit assumptions of external conditions (sym links, loc. paths)
race conditions
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
Kernel race conditions
device driver code
The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated. Doing a comprehensive search for operating system flaws
requires four steps:
Step 1) Knowledge of system control structure.
===============================================
To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects : objects in both classes. ie: the password file
With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.
Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
Code history:
What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
A solid cross reference:
Who checked which bug in what OS and what version prevents us from
duplicating work.
A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
rcp is suid root because it must use a privilaged port to do user
name authentication.
Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
Any sugestions on how to implement such a DB?
Step 3) Confirm hypotheses. (test and exploit flaws)
====================================================
Step 4) Make generalizations of the underlying system weaknesses, for
which the flaw represents a specific instance.
=====================================================================
Tool Box:
=========
AGREP: I suggest everyone obtain, and install agrep from:
ftp cs.arizona.edu /agrep/agrep.tar.Z
Agrep supports "windowing" so it can look for routines, and subroutines.
It also supports logical operators and is thus ideally suited to automating
the search for many of the following flaws. i.e.
agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
OR execvp()]} /usr/local/src/*.c
PERMUTATION PROGRAM: Another tool worth producing is a program to generate
all possible permutations of command line flags/arguments in order to uncover
undocumented features, and try to produce errors.
TCOV:
CRASH: Posted to USENET (what FTP archive?) (descrip?)
PAPERS: There are several papers that discuss methods of finding flaws, and
present test suites.
1) An Emphirical Study of the reliability of UNIX Utilities, by Barton P.
Miller, Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,
Dec '90. Describes a test suite for testing random input strings.
Results indicated that 25% of the programs hung, crashed, or misbehaved.
In one case the OS crashed. An understanding of buffer and register
layout on the environment in question, and the expected input is likely
to produce the desired results.
2) The Mothra tools set, in Proceedings of the 22nd Hawaii International
Conference on Systems and Software, pages 275-284, Kona, HI, January '89
3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.
Spafford, Software Practice and Experience, 20(2):181-189, Feb '90
4) A paper by IBM was mentioned that was submitted to USENIX a few years
ago. (Anyone have a citation?).
Specific Flaws to Check For:
============================
1) Look for routines that don't do boundary checking, or verify input.
ie: the gets() family of routines, where it is possible to overwrite
buffer boundaries. ( sprintf()?, gets(), etc. )
also: strcpy() which is why most src has:
#define SCYPYN((a)(b)) strcpy(a, b, sizeof(a))
2) SUID/SGID routines written in one of the shells, instead of C or
PERL.
3) SUID/SGID routines written in PERL that don't use the "taintperl"
program.)
4) SUID/SGID routines that use the system(), popen(), execlp(), or
execvp() calls to run something else.
5) Any program that uses relative path names inside the program.
6) The use of relative path names to specify dynamically linked libraries.
(look in Makefile).
7) Routines that don't check error return codes from system calls. (ie:
fork(2), suid(2), etc), setuid() rather, as in the famous rcp bug
8) Holes can often be found in code that:
A) is ported to a new environment.
B) receives unexpected input.
C) interacts with other local software.
D) accesses system files like passwd, L.sys, etc.
E) reads input from a publicly writable file/directory.
F) diagnostic programs which are typically not user-proofed.
9) Test code for unexpected input. Coverage, data flow, and mutation
testing tools are available.
10) Look in man pages, and users guides for warnings against doing X, and
try variations of X. Ditto for "bugs" section.
11) Look for seldom used, or unusual functions or commands - read backwards.
In particular looking for undocumented flags/arguments may prove useful.
Check flags that were in prior releases, or in other OS versions. Check
for options that other programs might use. For instance telnet uses -h
option to login ...
right, as most login.c's I've seen have:
if((getuid()) && hflag){
syslog()
exit()
}
12) Look for race conditions.
13) Failure of software to authenticate that it is really communicating
with the desired software or hardware module it wants to be accessing.
14) Lack or error detection to reset protection mechanisms following an
error.
15) Poor implementation resulting in, for example, condition codes being
improperly tested.
16) Implicit trust: Routine B assumes routine A's parameters are correct
because routine A is a system process.
17) System stores it's data or references user parameters in the users
address space.
18) Inter process communication: return conditions (passwd OK, illegal
parameter, segment error, etc) can provide a significant wedge, esp.
when combined with (17).
19) User parameters may not be adequately checked.
20) Addresses that overlap or refer to system areas.
21) Condition code checks may be omitted.
22) Failure to anticipate unusual or extraordinary parameters.
23) Look for system levels where the modules involved were written by
different programmers, or groups of programmers - holes are likely
to be found.
24) Registers that point to the location of a parameters value instead
of passing the value itself.
25) Any program running with system privileges. (too many progs are given
uid 0, to facilitate access to certain tables, etc.)
26) Group or world readable temporary files, buffers, etc.
27) Lack of threshold values, and lack of logging/notification once these
have been triggered.
28) Changing parameters of critical system areas prior to their execution
by a concurrent process. (race conditions)
29) Inadequate boundary checking at compile time, for example, a user
may be able to execute machine code disguised as data in a data area.
(if text and data areas are shared)
30) Improperly handling user generated asynchronous interrupts. Users
interrupting a process, performing an operation, and either returning
to continue the process or begin another will frequently leave the
system in an unprotected state. Partially written files are left open,
improper writing of protection infraction messages, improper setting
of protection bits, etc often occur.
31) Code that uses fopen(3) without setting the umask. ( eg: at(1), etc. )
In general, code that does not reset the real and effective uid before
forking.
32) Trace is your friend (or truss in SVR4) for helping figure out what
system calls a program is using.
33) Scan /usr/local fs's closely. Many admins will install software from
the net. Often you'll find tcpdump, top, nfswatch, ... suid'd root for
their ease of use.
34) Check suid programs to see if they are the ones originally put on the
system. Admins will sometimes put in a passwd replacement which is less
secure than the distributed version.
35) Look for programs that were there to install software or loadable
kernel modules.
36) Dynamically linked programs in general. Remember LD_PRELOAD, I think
that was the variable.
37) I/O channel programming is a prime target. Look for logical errors,
inconsistencies, and omissions.
38) See if it's possible for a I/O channel program to modify itself, loop
back, and then execute the newly modified code. (instruction pre-load
may screw this up)
39) If I/O channels act as independent processors they may have unlimited
access to memory, thus system code may be modified in memory prior to
execution.
40) Look for bugs requiring flaws in multiple pieces of software, i.e. say
program a can be used to change config file /etc/a now program b assumes
the information in a to be correct and this leads to unexpected results
(just look at how many programs trust /etc/utmp)
41) Any program, especially those suid/sgid, that allow shell escapes.
1) Physical Security Holes.
- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.
A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.
Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.
2) Software Security Holes
- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.
The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.
(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine. The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)
New holes like this appear all the time, and your best hopes are to:
a: try to structure your system so that as little software as possible
runs with root/daemon/bin privileges, and that which does is known to
be robust.
b: subscribe to a mailing list which can get details of problems
and/or fixes out to you as quickly as possible, and then ACT when you
receive information.
>From: Wes Morgan
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need. Many packages include daemons or utilities which can reveal
> information to outsiders. For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user. Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
>
>
> Careful system administration is the solution. Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution. You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities
> tend to install/run everything in the package without asking you. Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.
3) Incompatible Usage Security Holes
- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.
Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind. It's
never too late to have a rethink, though.
Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.
4) Choosing a suitable security philosophy and maintaining it.
>From: Gene Spafford
>The fourth kind of security problem is one of perception and
>understanding. Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it. Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.
---
From: Hacking
Subject: Hacking Ideas
Date: 11/10/93
( Please contribute by sending E-Mail to
[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]
NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations
The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories
(Suggested splitting of above into main and sub-catagories)
I: Suid binaries and scripts
unexpected user interactions
flawed liberary calls
implicit assumptions of external conditions (sym links, loc. paths)
race conditions
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
Kernel race conditions
device driver code
The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated. Doing a comprehensive search for operating system flaws
requires four steps:
Step 1) Knowledge of system control structure.
===============================================
To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects : objects in both classes. ie: the password file
With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.
Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
Code history:
What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
A solid cross reference:
Who checked which bug in what OS and what version prevents us from
duplicating work.
A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
rcp is suid root because it must use a privilaged port to do user
name authentication.
Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
Any sugestions on how to implement such a DB?
Step 3) Confirm hypotheses. (test and exploit flaws)
====================================================
Step 4) Make generalizations of the underlying system weaknesses, for
which the flaw represents a specific instance.
=====================================================================
Tool Box:
=========
AGREP: I suggest everyone obtain, and install agrep from:
ftp cs.arizona.edu /agrep/agrep.tar.Z
Agrep supports "windowing" so it can look for routines, and subroutines.
It also supports logical operators and is thus ideally suited to automating
the search for many of the following flaws. i.e.
agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
OR execvp()]} /usr/local/src/*.c
PERMUTATION PROGRAM: Another tool worth producing is a program to generate
all possible permutations of command line flags/arguments in order to uncover
undocumented features, and try to produce errors.
TCOV:
CRASH: Posted to USENET (what FTP archive?) (descrip?)
PAPERS: There are several papers that discuss methods of finding flaws, and
present test suites.
1) An Emphirical Study of the reliability of UNIX Utilities, by Barton P.
Miller, Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,
Dec '90. Describes a test suite for testing random input strings.
Results indicated that 25% of the programs hung, crashed, or misbehaved.
In one case the OS crashed. An understanding of buffer and register
layout on the environment in question, and the expected input is likely
to produce the desired results.
2) The Mothra tools set, in Proceedings of the 22nd Hawaii International
Conference on Systems and Software, pages 275-284, Kona, HI, January '89
3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.
Spafford, Software Practice and Experience, 20(2):181-189, Feb '90
4) A paper by IBM was mentioned that was submitted to USENIX a few years
ago. (Anyone have a citation?).
Specific Flaws to Check For:
============================
1) Look for routines that don't do boundary checking, or verify input.
ie: the gets() family of routines, where it is possible to overwrite
buffer boundaries. ( sprintf()?, gets(), etc. )
also: strcpy() which is why most src has:
#define SCYPYN((a)(b)) strcpy(a, b, sizeof(a))
2) SUID/SGID routines written in one of the shells, instead of C or
PERL.
3) SUID/SGID routines written in PERL that don't use the "taintperl"
program.)
4) SUID/SGID routines that use the system(), popen(), execlp(), or
execvp() calls to run something else.
5) Any program that uses relative path names inside the program.
6) The use of relative path names to specify dynamically linked libraries.
(look in Makefile).
7) Routines that don't check error return codes from system calls. (ie:
fork(2), suid(2), etc), setuid() rather, as in the famous rcp bug
8) Holes can often be found in code that:
A) is ported to a new environment.
B) receives unexpected input.
C) interacts with other local software.
D) accesses system files like passwd, L.sys, etc.
E) reads input from a publicly writable file/directory.
F) diagnostic programs which are typically not user-proofed.
9) Test code for unexpected input. Coverage, data flow, and mutation
testing tools are available.
10) Look in man pages, and users guides for warnings against doing X, and
try variations of X. Ditto for "bugs" section.
11) Look for seldom used, or unusual functions or commands - read backwards.
In particular looking for undocumented flags/arguments may prove useful.
Check flags that were in prior releases, or in other OS versions. Check
for options that other programs might use. For instance telnet uses -h
option to login ...
right, as most login.c's I've seen have:
if((getuid()) && hflag){
syslog()
exit()
}
12) Look for race conditions.
13) Failure of software to authenticate that it is really communicating
with the desired software or hardware module it wants to be accessing.
14) Lack or error detection to reset protection mechanisms following an
error.
15) Poor implementation resulting in, for example, condition codes being
improperly tested.
16) Implicit trust: Routine B assumes routine A's parameters are correct
because routine A is a system process.
17) System stores it's data or references user parameters in the users
address space.
18) Inter process communication: return conditions (passwd OK, illegal
parameter, segment error, etc) can provide a significant wedge, esp.
when combined with (17).
19) User parameters may not be adequately checked.
20) Addresses that overlap or refer to system areas.
21) Condition code checks may be omitted.
22) Failure to anticipate unusual or extraordinary parameters.
23) Look for system levels where the modules involved were written by
different programmers, or groups of programmers - holes are likely
to be found.
24) Registers that point to the location of a parameters value instead
of passing the value itself.
25) Any program running with system privileges. (too many progs are given
uid 0, to facilitate access to certain tables, etc.)
26) Group or world readable temporary files, buffers, etc.
27) Lack of threshold values, and lack of logging/notification once these
have been triggered.
28) Changing parameters of critical system areas prior to their execution
by a concurrent process. (race conditions)
29) Inadequate boundary checking at compile time, for example, a user
may be able to execute machine code disguised as data in a data area.
(if text and data areas are shared)
30) Improperly handling user generated asynchronous interrupts. Users
interrupting a process, performing an operation, and either returning
to continue the process or begin another will frequently leave the
system in an unprotected state. Partially written files are left open,
improper writing of protection infraction messages, improper setting
of protection bits, etc often occur.
31) Code that uses fopen(3) without setting the umask. ( eg: at(1), etc. )
In general, code that does not reset the real and effective uid before
forking.
32) Trace is your friend (or truss in SVR4) for helping figure out what
system calls a program is using.
33) Scan /usr/local fs's closely. Many admins will install software from
the net. Often you'll find tcpdump, top, nfswatch, ... suid'd root for
their ease of use.
34) Check suid programs to see if they are the ones originally put on the
system. Admins will sometimes put in a passwd replacement which is less
secure than the distributed version.
35) Look for programs that were there to install software or loadable
kernel modules.
36) Dynamically linked programs in general. Remember LD_PRELOAD, I think
that was the variable.
37) I/O channel programming is a prime target. Look for logical errors,
inconsistencies, and omissions.
38) See if it's possible for a I/O channel program to modify itself, loop
back, and then execute the newly modified code. (instruction pre-load
may screw this up)
39) If I/O channels act as independent processors they may have unlimited
access to memory, thus system code may be modified in memory prior to
execution.
40) Look for bugs requiring flaws in multiple pieces of software, i.e. say
program a can be used to change config file /etc/a now program b assumes
the information in a to be correct and this leads to unexpected results
(just look at how many programs trust /etc/utmp)
41) Any program, especially those suid/sgid, that allow shell escapes.
Monday, September 15, 2008
Change Your Ip In Less Then 1 Minute
How To: Change Your Ip In Less Then 1 Minute
1. Click on "Start" in the bottom left hand corner of screen
2. Click on "Run"
3. Type in "command" and hit ok
You should now be at an MSDOS prompt screen.
4. Type "ipconfig /release" just like that, and hit "enter"
5. Type "exit" and leave the prompt
6. Right-click on "Network Places" or "My Network Places" on your desktop.
7. Click on "properties"
You should now be on a screen with something titled "Local Area Connection", or something close to that, and, if you have a network hooked up, all of your other networks.
8. Right click on "Local Area Connection" and click "properties"
9. Double-click on the "Internet Protocol (TCP/IP)" from the list under the "General" tab
10. Click on "Use the following IP address" under the "General" tab
11. Create an IP address (It doesn't matter what it is. I just type 1 and 2 until i fill the area up).
12. Press "Tab" and it should automatically fill in the "Subnet Mask" section with default numbers.
13. Hit the "Ok" button here
14. Hit the "Ok" button again
You should now be back to the "Local Area Connection" screen.
15. Right-click back on "Local Area Connection" and go to properties again.
16. Go back to the "TCP/IP" settings
17. This time, select "Obtain an IP address automatically"
tongue.gif 18. Hit "Ok"
19. Hit "Ok" again
20. You now have a new IP address
With a little practice, you can easily get this process down to 15 seconds.
P.S:
This only changes your dynamic IP address, not your ISP/IP address. If you plan on hacking a website with this trick be extremely careful, because if they try a little, they can trace it back
1. Click on "Start" in the bottom left hand corner of screen
2. Click on "Run"
3. Type in "command" and hit ok
You should now be at an MSDOS prompt screen.
4. Type "ipconfig /release" just like that, and hit "enter"
5. Type "exit" and leave the prompt
6. Right-click on "Network Places" or "My Network Places" on your desktop.
7. Click on "properties"
You should now be on a screen with something titled "Local Area Connection", or something close to that, and, if you have a network hooked up, all of your other networks.
8. Right click on "Local Area Connection" and click "properties"
9. Double-click on the "Internet Protocol (TCP/IP)" from the list under the "General" tab
10. Click on "Use the following IP address" under the "General" tab
11. Create an IP address (It doesn't matter what it is. I just type 1 and 2 until i fill the area up).
12. Press "Tab" and it should automatically fill in the "Subnet Mask" section with default numbers.
13. Hit the "Ok" button here
14. Hit the "Ok" button again
You should now be back to the "Local Area Connection" screen.
15. Right-click back on "Local Area Connection" and go to properties again.
16. Go back to the "TCP/IP" settings
17. This time, select "Obtain an IP address automatically"
tongue.gif 18. Hit "Ok"
19. Hit "Ok" again
20. You now have a new IP address
With a little practice, you can easily get this process down to 15 seconds.
P.S:
This only changes your dynamic IP address, not your ISP/IP address. If you plan on hacking a website with this trick be extremely careful, because if they try a little, they can trace it back
Change Text on XP Start Button
Step 1 - Modify Explorer.exe File
In order to make the changes, the file explorer.exe located at C:\Windows needs to be edited. Since explorer.exe is a binary file it requires a special editor. For purposes of this article I have used Resource Hacker. Resource HackerTM is a freeware utility to view, modify, rename, add, delete and extract resources in 32bit Windows executables and resource files (*.res). It incorporates an internal resource script compiler and decompiler and works on Microsoft Windows 95/98/ME, Windows NT, Windows 2000 and Windows XP operating systems.
get this from h**p://delphi.icm.edu.pl/ftp/tools/ResHack.zip
The first step is to make a backup copy of the file explorer.exe located at C:\Windows\explorer. Place it in a folder somewhere on your hard drive where it will be safe. Start Resource Hacker and open explorer.exe located at C:\Windows\explorer.exe.
The category we are going to be using is "String Table". Expand it by clicking the plus sign then navigate down to and expand string 37 followed by highlighting 1033. If you are using the Classic Layout rather than the XP Layout, use number 38. The right hand pane will display the stringtable. We’re going to modify item 578, currently showing the word “start” just as it displays on the current Start button.
There is no magic here. Just double click on the word “start” so that it’s highlighted, making sure the quotation marks are not part of the highlight. They need to remain in place, surrounding the new text that you’ll type. Go ahead and type your new entry. In my case I used Click Me!
You’ll notice that after the new text string has been entered the Compile Script button that was grayed out is now active. I won’t get into what’s involved in compiling a script, but suffice it to say it’s going to make this exercise worthwhile. Click Compile Script and then save the altered file using the Save As command on the File Menu. Do not use the Save command – Make sure to use the Save As command and choose a name for the file. Save the newly named file to C:\Windows.
Step 2 – Modify the Registry
!!!make a backup of your registry before making changes!!!
Now that the modified explorer.exe has been created it’s necessary to modify the registry so the file will be recognized when the user logs on to the system. If you don’t know how to access the registry I’m not sure this article is for you, but just in case it’s a temporary memory lapse, go to Start (soon to be something else) Run and type regedit in the Open field. Navigate to:
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon
In the right pane, double click the "Shell" entry to open the Edit String dialog box. In Value data: line, enter the name that was used to save the modified explorer.exe file. Click OK.
Close Registry Editor and either log off the system and log back in, or reboot the entire system if that’s your preference. If all went as planned you should see your new Start button with the revised text.[/b]
In order to make the changes, the file explorer.exe located at C:\Windows needs to be edited. Since explorer.exe is a binary file it requires a special editor. For purposes of this article I have used Resource Hacker. Resource HackerTM is a freeware utility to view, modify, rename, add, delete and extract resources in 32bit Windows executables and resource files (*.res). It incorporates an internal resource script compiler and decompiler and works on Microsoft Windows 95/98/ME, Windows NT, Windows 2000 and Windows XP operating systems.
get this from h**p://delphi.icm.edu.pl/ftp/tools/ResHack.zip
The first step is to make a backup copy of the file explorer.exe located at C:\Windows\explorer. Place it in a folder somewhere on your hard drive where it will be safe. Start Resource Hacker and open explorer.exe located at C:\Windows\explorer.exe.
The category we are going to be using is "String Table". Expand it by clicking the plus sign then navigate down to and expand string 37 followed by highlighting 1033. If you are using the Classic Layout rather than the XP Layout, use number 38. The right hand pane will display the stringtable. We’re going to modify item 578, currently showing the word “start” just as it displays on the current Start button.
There is no magic here. Just double click on the word “start” so that it’s highlighted, making sure the quotation marks are not part of the highlight. They need to remain in place, surrounding the new text that you’ll type. Go ahead and type your new entry. In my case I used Click Me!
You’ll notice that after the new text string has been entered the Compile Script button that was grayed out is now active. I won’t get into what’s involved in compiling a script, but suffice it to say it’s going to make this exercise worthwhile. Click Compile Script and then save the altered file using the Save As command on the File Menu. Do not use the Save command – Make sure to use the Save As command and choose a name for the file. Save the newly named file to C:\Windows.
Step 2 – Modify the Registry
!!!make a backup of your registry before making changes!!!
Now that the modified explorer.exe has been created it’s necessary to modify the registry so the file will be recognized when the user logs on to the system. If you don’t know how to access the registry I’m not sure this article is for you, but just in case it’s a temporary memory lapse, go to Start (soon to be something else) Run and type regedit in the Open field. Navigate to:
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon
In the right pane, double click the "Shell" entry to open the Edit String dialog box. In Value data: line, enter the name that was used to save the modified explorer.exe file. Click OK.
Close Registry Editor and either log off the system and log back in, or reboot the entire system if that’s your preference. If all went as planned you should see your new Start button with the revised text.[/b]
Cant See Secure Sites
Cant See Secure Sites
Fix the problem with seeing them secrue sites (banks or online stores) i found this very usefull to me at my work (isp backbone support lol, at the time i was regular support )
Any way... what u need to do is make a new notepad file and write in it the followng DLL's.. just copy-paste these
regsvr32 SOFTPUB.DLL
regsvr32 WINTRUST.DLL
regsvr32 INITPKI.DLL
regsvr32 dssenh.dll
regsvr32 Rsaenh.dll
regsvr32 gpkcsp.dll
regsvr32 sccbase.dll
regsvr32 slbcsp.dll
regsvr32 Cryptdlg.dll
and save it as > all file types, and make it something like securefix.bat.
then just run the file and ur problem shuld be gone.
Fix the problem with seeing them secrue sites (banks or online stores) i found this very usefull to me at my work (isp backbone support lol, at the time i was regular support )
Any way... what u need to do is make a new notepad file and write in it the followng DLL's.. just copy-paste these
regsvr32 SOFTPUB.DLL
regsvr32 WINTRUST.DLL
regsvr32 INITPKI.DLL
regsvr32 dssenh.dll
regsvr32 Rsaenh.dll
regsvr32 gpkcsp.dll
regsvr32 sccbase.dll
regsvr32 slbcsp.dll
regsvr32 Cryptdlg.dll
and save it as > all file types, and make it something like securefix.bat.
then just run the file and ur problem shuld be gone.
cannot use my password to get back into Windows XP
Because of the security features built into Windows XP, it is virtually impossible to get back into the system without the password.
You have several options to try and get around this problem.
If you have access to another user account with administrator rights, you can use that account to change the password
of the account that is locked out. You can also use the default Administrator account that is built into Windows XP.
First you need to boot the system into Safe Mode.
1.Restart your system.
2.When you see the blue Dell globe or screen, press the ( F8 ) key about 3 times a second.
3.You should get the Windows startup menu. Use the (Up or Down) arrow keys to highlight (SafeMode)
4.Press (Enter) on (Safe Mode), then press (Enter) on (Windows XP).
5.The system should boot to Safe Mode.
Once you are at the Account Log on Screen, click on the icon
for the user account with administrator rights, or click on the icon
for the administrators account.
Note: For Home the Administrator account isn't normally shown & in Safe Mode you have to press Ctrl+Alt+Delete keys twice to show.
For PRO you can do this in normal mode
When the system has booted to the desktop, use the following steps to change the accounts password.
1.Click Start, Control Panel, Administrative Tools.
2.Click Computer Management.
3.Double click Local Users and Groups, double click the folder Users.
4.Right click on the account name that is locked out, and click on Set Password.
5.You may get a warning message about changing the password, simply click proceed.
6.Leave the New Password box blank, also leave the Confirm Password box blank.
7.Click OK, and OK again.
8.Then close all Windows, reboot the system and try to log in.
There are also applications that can recover the password for you.
The following companies provide these applications at a cost.
iOpus® Password Recovery XP here.
LostPassword.com, here.
Asterisk Password Recovery XP v1.89 here.
Windows XP / 2000 / NT Key here.
If the above information does not help in recovering the password, the only option left is to
format the hard drive then reinstall Windows and the system software.
You have several options to try and get around this problem.
If you have access to another user account with administrator rights, you can use that account to change the password
of the account that is locked out. You can also use the default Administrator account that is built into Windows XP.
First you need to boot the system into Safe Mode.
1.Restart your system.
2.When you see the blue Dell globe or screen, press the ( F8 ) key about 3 times a second.
3.You should get the Windows startup menu. Use the (Up or Down) arrow keys to highlight (SafeMode)
4.Press (Enter) on (Safe Mode), then press (Enter) on (Windows XP).
5.The system should boot to Safe Mode.
Once you are at the Account Log on Screen, click on the icon
for the user account with administrator rights, or click on the icon
for the administrators account.
Note: For Home the Administrator account isn't normally shown & in Safe Mode you have to press Ctrl+Alt+Delete keys twice to show.
For PRO you can do this in normal mode
When the system has booted to the desktop, use the following steps to change the accounts password.
1.Click Start, Control Panel, Administrative Tools.
2.Click Computer Management.
3.Double click Local Users and Groups, double click the folder Users.
4.Right click on the account name that is locked out, and click on Set Password.
5.You may get a warning message about changing the password, simply click proceed.
6.Leave the New Password box blank, also leave the Confirm Password box blank.
7.Click OK, and OK again.
8.Then close all Windows, reboot the system and try to log in.
There are also applications that can recover the password for you.
The following companies provide these applications at a cost.
iOpus® Password Recovery XP here.
LostPassword.com, here.
Asterisk Password Recovery XP v1.89 here.
Windows XP / 2000 / NT Key here.
If the above information does not help in recovering the password, the only option left is to
format the hard drive then reinstall Windows and the system software.
Boot Block Recovery For Free
You don't need to pay a measly sum of dollars just to recover from a boot block mode. Here it is folks:
AWARD Bootblock recovery:
That shorting trick should work if the boot block code is not corrupted, and it should not be if /sb switch is used when flashing the bios (instead of /wb switch).
The 2 pins to short to force a checksum error varies from chip to chip. But these are usually the highest-numbered address pins (A10 and above).
These are the pins used by the system to read the System BIOS (original.bin for award v6), calculate the ROM checksum and see if it's valid before decompressing it into memory, and subsequently allow Bootblock POST to pass control over to the System BIOS.
You just have to fool the system into believing that the System BIOS is corrupt. This you do by giving your system a hard time reading the System BIOS by shorting the 2 high address pins. And when it could not read the System BIOS properly, ROM Checksum Error is detected "so to speak" and Bootblock recovery is activated.
Sometimes, any combination of the high address pins won't work to force a checksum error in some chips, like my Winbond W49F002U. But shorting the #WE pin with the highest-numbered address pin (A17) worked for this chip. You just have to be experimentative if you're not comfortable with "hot flashing" or "replacement BIOS".
But to avoid further damage to your chip if you're not sure which are the correct pins to short, measure the potential between the 2 pins by a voltmeter while the system is on. If the voltage reading is zero (or no potential at all), it is safe to short these pins.
But do not short the pins while the system is on. Instead, power down then do the short, then power up while still shorting. And as soon as you hear 3 beeps (1 long, 2 short), remove the short at once so that automatic reflashing from Drive A can proceed without errors (assuming you had autoexec.bat in it).
About how to do the shorting, the tip of a screwdriver would do. But with such minute pins on the PLCC chip, I'm pretty comfortable doing it with the tip of my multi-tester or voltmeter probe. Short the pins at the point where they come out of the chip.
AMIBIOS Recovery bootblock:
1. Copy a known working BIOS image for your board to a floppy and rename it to AMIBOOT.ROM.
2. Insert the floppy in your system's floppydrive.
3. Power on the system while holding CTRL+Home keys. Release the keys when you hear a beep and/or see the floppy light coming on.
4 . Just wait until you hear 4 beeps. When 4 beeps are heard the reprogramming of the System Block BIOS went succesfull, so then you may restart your system.
Some alternative keys that can be used to force BIOS update (only the System Block will be updated so it's quite safe):
CTRL+Home= restore missing code into system block and clear CMOS when programming went ok.
CTRL+Page Up= restore missing code into system block and clear CMOS or DMI when programming went ok.
CTRL+Page Down= restore missing code into system block and do not clear CMOS and DMI area when programming went ok
Btw: the alternative keys work only with AMIBIOS 7 or higher (so for example an AMI 6.26 BIOS can be only recovered by using CTRL+Home keys).
Boot Block Recovery for FREE
************************************************
BLACKOUT Flashing
*************************************************
Recovering a Corrupt AMI BIOS chip
With motherboards that use BOOT BLOCK BIOS it is possible to recover a corrupted BIOS because the BOOT BLOCK section of the BIOS, which is responsible for booting the computer remains unmodified. When an AMI BIOS becomes corrupt the system will appear to start, but nothing will appear on the screen, the floppy drive light will come on and the system will access the floppy drive repeatedly. If your motherboard has an ISA slot and you have an old ISA video card lying around, put the ISA video card in your system and connect the monitor. The BOOT BLOCK section of the BIOS only supports ISA video cards, so if you do not have an ISA video card or your motherboard does not have ISA slots, you will have to restore your BIOS blind, with no monitor to show you what’s going on.
AMI has integrated a recovery routine into the BOOT BLOCK of the BIOS, which in the event the BIOS becomes corrupt can be used to restore the BIOS to a working state. The routine is called when the SYSTEM BLOCK of the BIOS is empty. The restore routine will access the floppy drive looking for a BIOS file names AMIBOOT.ROM, this is why the floppy drive light comes on and the drive spins. If the file is found it is loaded into the SYSTEM BLOCK of the BIOS to replace the missing information. To restore your BIOS simply copy a working BIOS file to a floppy diskette and rename it AMIBOOT.ROM, then insert it into the computer while the power is on. The diskette does not need to be bootable or contain a flash utility. After about four minutes the system will beep four times. Remove the floppy diskette from the drive and reboot the computer. The BIOS should now be restored.
Recovering a Corrupt AWARD BIOS
With AWARD BIOS the process is similar but still a bit different. To recover an AWARD BIOS you will need to create a floppy diskette with a working BIOS file in .BIN format, an AWARD flash utility and an AUTOEXEC.BAT file. AWARD BIOS will not automatically restore the BIOS information to the SYSTEM BLOCK for this reason you will need to add the commands necessary to flash the BIOS in the AUTOEXEC.BAT file. The system will run the AUTOEXE.BAT file, which will in turn flash the BIOS. This is fairly easy. Here are the steps you need to take.
· Create a bootable floppy diskette
· Copy the BIOS file and flash utility to the diskette
· Create an text file with any standard text editor and add the following lines
@ECHO OFF
FLASH763 BIOSFILE.BIN /py
In the above example I am assuming that you are using the FLASH763.EXE flash utility. You will need to replace the FLASH763 with the name of whatever flash utility you are using, and replace the BIOSFILE.BIN with the name of the BIOS file you are using. You will also need to change the ‘/py’ to whatever the command is for your flash utility to automatically program the BIOS without user intervention. If you do not know the command to automatically flash your BIOS type the name of the flash utility with a space and then /? to display the utility’s help screen. The help screen should pecify the command switch to automatically flash your BIOS. If you are using the FLASH763.EXE utility then the switch to automatically flash your BIOS is ‘/py’.
AWARD Bootblock recovery:
That shorting trick should work if the boot block code is not corrupted, and it should not be if /sb switch is used when flashing the bios (instead of /wb switch).
The 2 pins to short to force a checksum error varies from chip to chip. But these are usually the highest-numbered address pins (A10 and above).
These are the pins used by the system to read the System BIOS (original.bin for award v6), calculate the ROM checksum and see if it's valid before decompressing it into memory, and subsequently allow Bootblock POST to pass control over to the System BIOS.
You just have to fool the system into believing that the System BIOS is corrupt. This you do by giving your system a hard time reading the System BIOS by shorting the 2 high address pins. And when it could not read the System BIOS properly, ROM Checksum Error is detected "so to speak" and Bootblock recovery is activated.
Sometimes, any combination of the high address pins won't work to force a checksum error in some chips, like my Winbond W49F002U. But shorting the #WE pin with the highest-numbered address pin (A17) worked for this chip. You just have to be experimentative if you're not comfortable with "hot flashing" or "replacement BIOS".
But to avoid further damage to your chip if you're not sure which are the correct pins to short, measure the potential between the 2 pins by a voltmeter while the system is on. If the voltage reading is zero (or no potential at all), it is safe to short these pins.
But do not short the pins while the system is on. Instead, power down then do the short, then power up while still shorting. And as soon as you hear 3 beeps (1 long, 2 short), remove the short at once so that automatic reflashing from Drive A can proceed without errors (assuming you had autoexec.bat in it).
About how to do the shorting, the tip of a screwdriver would do. But with such minute pins on the PLCC chip, I'm pretty comfortable doing it with the tip of my multi-tester or voltmeter probe. Short the pins at the point where they come out of the chip.
AMIBIOS Recovery bootblock:
1. Copy a known working BIOS image for your board to a floppy and rename it to AMIBOOT.ROM.
2. Insert the floppy in your system's floppydrive.
3. Power on the system while holding CTRL+Home keys. Release the keys when you hear a beep and/or see the floppy light coming on.
4 . Just wait until you hear 4 beeps. When 4 beeps are heard the reprogramming of the System Block BIOS went succesfull, so then you may restart your system.
Some alternative keys that can be used to force BIOS update (only the System Block will be updated so it's quite safe):
CTRL+Home= restore missing code into system block and clear CMOS when programming went ok.
CTRL+Page Up= restore missing code into system block and clear CMOS or DMI when programming went ok.
CTRL+Page Down= restore missing code into system block and do not clear CMOS and DMI area when programming went ok
Btw: the alternative keys work only with AMIBIOS 7 or higher (so for example an AMI 6.26 BIOS can be only recovered by using CTRL+Home keys).
Boot Block Recovery for FREE
************************************************
BLACKOUT Flashing
*************************************************
Recovering a Corrupt AMI BIOS chip
With motherboards that use BOOT BLOCK BIOS it is possible to recover a corrupted BIOS because the BOOT BLOCK section of the BIOS, which is responsible for booting the computer remains unmodified. When an AMI BIOS becomes corrupt the system will appear to start, but nothing will appear on the screen, the floppy drive light will come on and the system will access the floppy drive repeatedly. If your motherboard has an ISA slot and you have an old ISA video card lying around, put the ISA video card in your system and connect the monitor. The BOOT BLOCK section of the BIOS only supports ISA video cards, so if you do not have an ISA video card or your motherboard does not have ISA slots, you will have to restore your BIOS blind, with no monitor to show you what’s going on.
AMI has integrated a recovery routine into the BOOT BLOCK of the BIOS, which in the event the BIOS becomes corrupt can be used to restore the BIOS to a working state. The routine is called when the SYSTEM BLOCK of the BIOS is empty. The restore routine will access the floppy drive looking for a BIOS file names AMIBOOT.ROM, this is why the floppy drive light comes on and the drive spins. If the file is found it is loaded into the SYSTEM BLOCK of the BIOS to replace the missing information. To restore your BIOS simply copy a working BIOS file to a floppy diskette and rename it AMIBOOT.ROM, then insert it into the computer while the power is on. The diskette does not need to be bootable or contain a flash utility. After about four minutes the system will beep four times. Remove the floppy diskette from the drive and reboot the computer. The BIOS should now be restored.
Recovering a Corrupt AWARD BIOS
With AWARD BIOS the process is similar but still a bit different. To recover an AWARD BIOS you will need to create a floppy diskette with a working BIOS file in .BIN format, an AWARD flash utility and an AUTOEXEC.BAT file. AWARD BIOS will not automatically restore the BIOS information to the SYSTEM BLOCK for this reason you will need to add the commands necessary to flash the BIOS in the AUTOEXEC.BAT file. The system will run the AUTOEXE.BAT file, which will in turn flash the BIOS. This is fairly easy. Here are the steps you need to take.
· Create a bootable floppy diskette
· Copy the BIOS file and flash utility to the diskette
· Create an text file with any standard text editor and add the following lines
@ECHO OFF
FLASH763 BIOSFILE.BIN /py
In the above example I am assuming that you are using the FLASH763.EXE flash utility. You will need to replace the FLASH763 with the name of whatever flash utility you are using, and replace the BIOSFILE.BIN with the name of the BIOS file you are using. You will also need to change the ‘/py’ to whatever the command is for your flash utility to automatically program the BIOS without user intervention. If you do not know the command to automatically flash your BIOS type the name of the flash utility with a space and then /? to display the utility’s help screen. The help screen should pecify the command switch to automatically flash your BIOS. If you are using the FLASH763.EXE utility then the switch to automatically flash your BIOS is ‘/py’.
10 Security Enhancements
Before you spend a dime on security, there are many precautions you can take that will protect you against the most common threats.
1. Check Windows Update and Office Update regularly (_http://office.microsoft.com/productupdates); have your Office CD ready. Windows Me, 2000, and XP users can configure automatic updates. Click on the Automatic Updates tab in the System control panel and choose the appropriate options.
2. Install a personal firewall. Both SyGate (_www.sygate.com) and ZoneAlarm (_www.zonelabs.com) offer free versions.
3. Install a free spyware blocker. Our Editors' Choice ("Spyware," April 22) was SpyBot Search & Destroy (_http://security.kolla.de). SpyBot is also paranoid and ruthless in hunting out tracking cookies.
4. Block pop-up spam messages in Windows NT, 2000, or XP by disabling the Windows Messenger service (this is unrelated to the instant messaging program). Open Control Panel | Administrative Tools | Services and you'll see Messenger. Right-click and go to Properties. Set Start-up Type to Disabled and press the Stop button. Bye-bye, spam pop-ups! Any good firewall will also stop them.
5. Use strong passwords and change them periodically. Passwords should have at least seven characters; use letters and numbers and have at least one symbol. A decent example would be f8izKro@l. This will make it much harder for anyone to gain access to your accounts.
6. If you're using Outlook or Outlook Express, use the current version or one with the Outlook Security Update installed. The update and current versions patch numerous vulnerabilities.
7. Buy antivirus software and keep it up to date. If you're not willing to pay, try Grisoft AVG Free Edition (Grisoft Inc., w*w.grisoft.com). And doublecheck your AV with the free, online-only scanners available at w*w.pandasoftware.com/activescan and _http://housecall.trendmicro.com.
8. If you have a wireless network, turn on the security features: Use MAC filtering, turn off SSID broadcast, and even use WEP with the biggest key you can get. For more, check out our wireless section or see the expanded coverage in Your Unwired World in our next issue.
9. Join a respectable e-mail security list, such as the one found at our own Security Supersite at _http://security.ziffdavis.com, so that you learn about emerging threats quickly and can take proper precautions.
10. Be skeptical of things on the Internet. Don't assume that e-mail "From:" a particular person is actually from that person until you have further reason to believe it's that person. Don't assume that an attachment is what it says it is. Don't give out your password to anyone, even if that person claims to be from "support."
1. Check Windows Update and Office Update regularly (_http://office.microsoft.com/productupdates); have your Office CD ready. Windows Me, 2000, and XP users can configure automatic updates. Click on the Automatic Updates tab in the System control panel and choose the appropriate options.
2. Install a personal firewall. Both SyGate (_www.sygate.com) and ZoneAlarm (_www.zonelabs.com) offer free versions.
3. Install a free spyware blocker. Our Editors' Choice ("Spyware," April 22) was SpyBot Search & Destroy (_http://security.kolla.de). SpyBot is also paranoid and ruthless in hunting out tracking cookies.
4. Block pop-up spam messages in Windows NT, 2000, or XP by disabling the Windows Messenger service (this is unrelated to the instant messaging program). Open Control Panel | Administrative Tools | Services and you'll see Messenger. Right-click and go to Properties. Set Start-up Type to Disabled and press the Stop button. Bye-bye, spam pop-ups! Any good firewall will also stop them.
5. Use strong passwords and change them periodically. Passwords should have at least seven characters; use letters and numbers and have at least one symbol. A decent example would be f8izKro@l. This will make it much harder for anyone to gain access to your accounts.
6. If you're using Outlook or Outlook Express, use the current version or one with the Outlook Security Update installed. The update and current versions patch numerous vulnerabilities.
7. Buy antivirus software and keep it up to date. If you're not willing to pay, try Grisoft AVG Free Edition (Grisoft Inc., w*w.grisoft.com). And doublecheck your AV with the free, online-only scanners available at w*w.pandasoftware.com/activescan and _http://housecall.trendmicro.com.
8. If you have a wireless network, turn on the security features: Use MAC filtering, turn off SSID broadcast, and even use WEP with the biggest key you can get. For more, check out our wireless section or see the expanded coverage in Your Unwired World in our next issue.
9. Join a respectable e-mail security list, such as the one found at our own Security Supersite at _http://security.ziffdavis.com, so that you learn about emerging threats quickly and can take proper precautions.
10. Be skeptical of things on the Internet. Don't assume that e-mail "From:" a particular person is actually from that person until you have further reason to believe it's that person. Don't assume that an attachment is what it says it is. Don't give out your password to anyone, even if that person claims to be from "support."
Subscribe to:
Posts (Atom)
