>How Linux boots

>

As it turns out, there isn’t much to the boot process:

   1. A boot loader finds the kernel image on the disk, loads it into memory, and starts it.
   2. The kernel initializes the devices and its drivers.
   3. The kernel mounts the root filesystem.
   4. The kernel starts a program called init.
   5. init sets the rest of the processes in motion.
   6. The last processes that init starts as part of the boot sequence allow you to log in.

Secure Computer: How To Hack Computers

Hard Drive Problem
Identifying each stage of the boot process is invaluable in fixing boot problems and understanding the system as a whole. To start, zero in on the boot loader, which is the initial screen or prompt you get after the computer does its power-on self-test, asking which operating system to run. After you make a choice, the boot loader runs the Linux kernel, handing control of the system to the kernel.

There is a detailed discussion of the kernel elsewhere in this book from which this article is excerpted. This article covers the kernel initialization stage, the stage when the kernel prints a bunch of messages about the hardware present on the system. The kernel starts init just after it displays a message proclaiming that the kernel has mounted the root filesystem:

VFS: Mounted root (ext2 filesystem) readonly.

Soon after, you will see a message about init starting, followed by system service startup messages, and finally you get a login prompt of some sort.

NOTE On Red Hat Linux, the init note is especially obvious, because it “welcomes” you to “Red Hat Linux.” All messages thereafter show success or failure in brackets at the right-hand side of the screen.

Linux Desktop

Most of this chapter deals with init, because it is the part of the boot sequence where you have the most control.
init

There is nothing special about init. It is a program just like any other on the Linux system, and you’ll find it in /sbin along with other system binaries. The main purpose of init is to start and stop other programs in a particular sequence. All you have to know is how this sequence works.

Window to Linux

There are a few different variations, but most Linux distributions use the System V style discussed here. Some distributions use a simpler version that resembles the BSD init, but you are unlikely to encounter this.

Runlevels

At any given time on a Linux system, a certain base set of processes is running. This state of the machine is called its runlevel, and it is denoted with a number from 0 through 6. The system spends most of its time in a single runlevel. However, when you shut the machine down, init switches to a different runlevel in order to terminate the system services in an orderly fashion and to tell the kernel to stop. Yet another runlevel is for single-user mode, discussed later.

The easiest way to get a handle on runlevels is to examine the init configuration file, /etc/inittab. Look for a line like the following:

id:5:initdefault:

This line means that the default runlevel on the system is 5. All lines in the inittab file take this form, with four fields separated by colons occurring in the following order:

# A unique identifier (a short string, such as id in the preceding example)
# The applicable runlevel number(s)
# The action that init should take (in the preceding example, the action is to set the default runlevel to 5)
# A command to execute (optional)

There is no command to execute in the preceding initdefault example because a command doesn’t make sense in the context of setting the default runlevel. Look a little further down in inittab, until you see a line like this:

l5:5:wait:/etc/rc.d/rc 5

This line triggers most of the system configuration and services through the rc*.d and init.d directories. You can see that init is set to execute a command called /etc/rc.d/rc 5 when in runlevel 5. The wait action tells when and how init runs the command: run rc 5 once when entering runlevel 5, and then wait for this command to finish before doing anything else.

There are several different actions in addition to initdefault and wait, especially pertaining to power management, and the inittab(5) manual page tells you all about them. The ones that you’re most likely to encounter are explained in the following sections.

respawn

The respawn action causes init to run the command that follows, and if the command finishes executing, to run it again. You’re likely to see something similar to this line in your inittab file:

1:2345:respawn:/sbin/mingetty tty1

The getty programs provide login prompts. The preceding line is for the first virtual console (/dev/tty1), the one you see when you press ALT-F1 or CONTROL-ALT-F1. The respawn action brings the login prompt back after you log out.

ctrlaltdel

The ctrlaltdel action controls what the system does when you press CONTROL-ALT-DELETE on a virtual console. On most systems, this is some sort of reboot command using the shutdown command.

sysinit

The sysinit action is the very first thing that init should run when it starts up, before entering any runlevels.

How processes in runlevels start

You are now ready to learn how init starts the system services, just before it lets you log in. Recall this inittab line from earlier:

l5:5:wait:/etc/rc.d/rc 5

This small line triggers many other programs. rc stands for run commands, and you will hear people refer to the commands as scripts, programs, or services. So, where are these commands, anyway?

For runlevel 5, in this example, the commands are probably either in /etc/rc.d/rc5.d or /etc/rc5.d. Runlevel 1 uses rc1.d, runlevel 2 uses rc2.d, and so on. You might find the following items in the rc5.d directory:

S10sysklogd       S20ppp          S99gpm
S12kerneld        S25netstd_nfs   S99httpd
S15netstd_init    S30netstd_misc  S99rmnologin
S18netbase        S45pcmcia       S99sshd
S20acct           S89atd
S20logoutd        S89cron

The rc 5 command starts programs in this runlevel directory by running the following commands:

S10sysklogd start
S12kerneld start
S15netstd_init start
S18netbase start
…
S99sshd start

Notice the start argument in each command. The S in a command name means that the command should run in start mode, and the number (00 through 99) determines where in the sequence rc starts the command.

The rc*.d commands are usually shell scripts that start programs in /sbin or /usr/sbin. Normally, you can figure out what one of the commands actually does by looking at the script with less or another pager program.

You can start one of these services by hand. For example, if you want to start the httpd Web server program manually, run S99httpd start. Similarly, if you ever need to kill one of the services when the machine is on, you can run the command in the rc*.d directory with the stop argument (S99httpd stop, for instance).

Some rc*.d directories contain commands that start with K (for “kill,” or stop mode). In this case, rc runs the command with the stop argument instead of start. You are most likely to encounter K commands in runlevels that shut the system down.

Adding and removing services

If you want to add, delete, or modify services in the rc*.d directories, you need to take a closer look at the files inside. A long listing reveals a structure like this:

lrwxrwxrwx . . . S10sysklogd -> ../init.d/sysklogd
lrwxrwxrwx . . . S12kerneld -> ../init.d/kerneld
lrwxrwxrwx . . . S15netstd_init -> ../init.d/netstd_init
lrwxrwxrwx . . . S18netbase -> ../init.d/netbase
…

The commands in an rc*.d directory are actually symbolic links to files in an init.d directory, usually in /etc or /etc/rc.d. Linux distributions contain these links so that they can use the same startup scripts for all runlevels. This convention is by no means a requirement, but it often makes organization a little easier.

To prevent one of the commands in the init.d directory from running in a particular runlevel, you might think of removing the symbolic link in the appropriate rc*.d directory. This does work, but if you make a mistake and ever need to put the link back in place, you might have trouble remembering the exact name of the link. Therefore, you shouldn’t remove links in the rc*.d directories, but rather, add an underscore (_) to the beginning of the link name like this:

mv S99httpd _S99httpd

At boot time, rc ignores _S99httpd because it doesn’t start with S or K. Furthermore, the original name is still obvious, and you have quick access to the command if you’re in a pinch and need to start it by hand.

To add a service, you must create a script like the others in the init.d directory and then make a symbolic link in the correct rc*.d directory. The easiest way to write a script is to examine the scripts already in init.d, make a copy of one that you understand, and modify the copy.

When adding a service, make sure that you choose an appropriate place in the boot sequence to start the service. If the service starts too soon, it may not work, due to a dependency on some other service. For non-essential services, most systems administrators prefer numbers in the 90s, after most of the services that came with the system.

Linux distributions usually come with a command to enable and disable services in the rc*.d directories. For example, in Debian, the command is update-rc.d, and in Red Hat Linux, the command is chkconfig. Graphical user interfaces are also available. Using these programs helps keep the startup directories consistent and helps with upgrades.

HINT: One of the most common Linux installation problems is an improperly configured XFree86 server that flicks on and off, making the system unusable on console. To stop this behavior, boot into single-user mode and alter your runlevel or runlevel services. Look for something containing xdm, gdm, or kdm in your rc*.d directories, or your /etc/inittab.

Controlling init

Occasionally, you need to give init a little kick to tell it to switch runlevels, to re-read the inittab file, or just to shut down the system. Because init is always the first process on a system, its process ID is always 1.

You can control init with telinit. For example, if you want to switch to runlevel 3, use this command:

telinit 3

When switching runlevels, init tries to kill off any processes that aren’t in the inittab file for the new runlevel. Therefore, you should be careful about changing runlevels.

When you need to add or remove respawning jobs or make any other change to the inittab file, you must tell init about the change and cause it to re-read the file. Some people use kill -HUP 1 to tell init to do this. This traditional method works on most versions of Unix, as long as you type it correctly. However, you can also run this telinit command:

telinit q

You can also use telinit s to switch to single-user mode.

Shutting down

init also controls how the system shuts down and reboots. The proper way to shut down a Linux machine is to use the shutdown command.

There are two basic ways to use shutdown. If you halt the system, it shuts the machine down and keeps it down. To make the machine halt immediately, use this command:

shutdown -h now

On most modern machines with reasonably recent versions of Linux, a halt cuts the power to the machine. You can also reboot the machine. For a reboot, use -r instead of -h.

The shutdown process takes several seconds. You should never reset or power off a machine during this stage.

In the preceding example, now is the time to shut down. This argument is mandatory, but there are many ways of specifying it. If you want the machine to go down sometime in the future, one way is to use +n, where n is the number of minutes shutdown should wait before doing its work. For other options, look at the shutdown(8) manual page.

To make the system reboot in 10 minutes, run this command:

shutdown -r +10

On Linux, shutdown notifies anyone logged on that the machine is going down, but it does little real work. If you specify a time other than now, shutdown creates a file called /etc/nologin. When this file is present, the system prohibits logins by anyone except the superuser.

When system shutdown time finally arrives, shutdown tells init to switch to runlevel 0 for a halt and runlevel 6 for a reboot. When init enters runlevel 0 or 6, all of the following takes place, which you can verify by looking at the scripts inside rc0.d and rc6.d:

   1. init kills every process that it can (as it would when switching to any other runlevel).

# The initial rc0.d/rc6.d commands run, locking system files into place and making other preparations for shutdown.
# The next rc0.d/rc6.d commands unmount all filesystems other than the root.
# Further rc0.d/rc6.d commands remount the root filesystem read-only.
# Still more rc0.d/rc6.d commands write all buffered data out to the filesystem with the sync program.
# The final rc0.d/rc6.d commands tell the kernel to reboot or stop with the reboot, halt, or poweroff program.

The reboot and halt programs behave differently for each runlevel, potentially causing confusion. By default, these programs call shutdown with the -r or -h options, but if the system is already at the halt or reboot runlevel, the programs tell the kernel to shut itself off immediately. If you really want to shut your machine down in a hurry (disregarding any possible damage from a disorderly shutdown), use the -f option.

>Install Xp From Dos

>

If XP will not install from the CD or if you have a new drive with no operating system on
it yet try these:

Install Windows XP from the hard drive with Windows 98 already installed:

Boot Windows 98
Insert the XP CD into your CD reader
Explore Windows XP through My Computer
Copy i386 folder to C:\windows xp
Go into C:\i386 folder and double click on winnt32.exe to launch the setup from the hard drive

Install Windows XP from DOS (ie. no OS on a new hard drive):

Boot with a Windows 98 Start Up disk
Insert the Windows 98 CD into the CD reader
Run smartdrv.exe from the Win98 directory on the windows 98 CD (file caching)
Type cd.. to back up to the root directory
Insert Windows XP CD into the CD reader
Copy the i386 folder to C:\
Go into C:\i386 folder on C: and type winnt.exe to launch the setup from the hard drive.

Windows 7 home premium 64

Install Xp From Dos

>How To Hack Computers

>

The First Step of Hacking 

The key to doing amazing things with XP is as simple as D O S. Yes, that’s right, DOS as in MS-DOS, as in MicroSoft Disk Operating System. Windows XP (as well as NT and 2000) comes with two versions of DOS. Command.com is an old DOS version. Various versions of command.com come with Windows 95, 98, SE, ME, Window 3, and DOS only operating systems.

The other DOS, which comes only with the XP, 2000 and NT operating systems, is cmd.exe. Usually cmd.exe is better than command.com because it is easier to use, has more commands, and in some ways resembles the bash shell in Linux and other Unix-type operating systems. For example, you can repeat a command by using the up arrow until you back up to the desired command. Unlike bash, however, your DOS command history is erased whenever you shut down cmd.exe. The reason XP has both versions of DOS is that sometimes a program that won?t run right in cmd.exe will work in command.com.

Hacking guide

Hacking E book

Hacking turorials

DOS is your number one Windows gateway to the Internet, and the open sesame to local area networks. From DOS, without needing to download a single hacker program, you can do amazingly sophisticated explorations and even break into poorly defended computers.

Lots more Soon 

>DVD Copying And Ripping

>

Dvd Copying/ripping Definitions

Rip
To take off the audio or video from a CD or DVD. Often CD Audio is “ripped” to MP3 files or DVD video ripped to VOB files.

Compression
The process of removing redundancies in digital data to reduce the amount that must be stored or transmitted. Lossless compression removes only enough redundancy so that the original data can be recreated exactly as it was. Lossy compression sacrifices additional data to achieve greater compression.

Encoding
Encoding is the process of changing data from one form into another according to a set of rules specifiec by a codec. The data is usually a file containing audio, video or still image. Often the encoding is done to make a file compatible with specific hardware (such as a DVD Player) or to compress or reduce the space the data occupies.

Common video encoding methods are DivX, MPEG-1, MPEG-2 and MPEG-4. A common audio encoding method is MP3 although many others exist including MPEG1 audio, DTS, and Dolby Digital.

Transcoding
On this site generally another name for encoding.

A more technical term would be “The reformatting of content, without changing the source, to another type of content – most often of a different format than the original (but does not have to be)”

>Shellcoding Techniques

>

  Introduction

This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper.  I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes.  I do not claim to have invented any of these techniques, except for the one that uses the div instruction.

The multiplicity of mul

This technique was originally developed by Sorbo of darkircop.net.  The mul instruction may, on the surface, seem mundane, and it’s purpose obvious.  However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful.  First some background information on the mul instruction itself.

mul performs an unsigned multiply of two integers.  It takes only one operand, the other is implicitly specified by the %eax register.  So, a  common mul instruction might look something like this:

movl $0x0a,%eax
mul $0x0a

This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10.  The result is then implicitly stored in EDX:EAX.  The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).

So, now comes the ever-important question.  How can we use these attributes to our advantage when writing shellcode?  Well, let’s think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode.  It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication.  Let’s put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0?  The answer, as you may have guessed, is 0.  I think it’s about time for some example code, so here it is:

xorl %ecx,%ecx
mul %ecx

What is this shellcode doing?  Well, it 0’s out the %ecx register using the xor instruction, so we now know that %ecx is 0.  Then it does a mul %ecx, which as we just learned, multiplies it’s operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX.  So, regardless of %eax’s previous contents, %eax must now be 0.  However that’s not all, %edx is 0’d now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax.  Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.

The div instruction

Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax.  Also like, mul it stores the result of the divide in %eax.  Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction.  But first, let’s think about what is normally stored in the %eax register.  The %eax register holds the return value of functions and/or syscalls.  Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur).  So, if we know that after a syscall is performed, %eax will have a non-zero value, and that  the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax.  So…how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80.  It just so happens that the syscall that corresponds to the value 1 is exit().  Now for an example:

      
xorl %ebx,%ebx
mul %ebx
push %edx
pushl   $0x3268732f
pushl   $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al  #execve() syscall, doesn’t return at all unless it fails, in which case it returns -1
int $0x80

divl %eax  # -1 / -1 = 1
int $0x80

Now, we have a 3 byte exit function, where as before it was 5 bytes.  However, there is a catch, what if a syscall does return 0?  Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero.  Some people say that exit’s are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly.  They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn’t worth keeping.  However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system.  So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can’t wipe all the logs, at least this part of your presence will be clear.

Unlocking the power of leal

The leal instruction is an often neglected instruction in shellcode, even though it is quite useful.  Consider this short piece of shellcode.

xorl %ecx,%ecx
leal 0x10(%ecx),%eax

This will load the value 17 into eax, and clear all of the extraneous bits of eax.  This occurs because the leal instruction loads a variable of the type long into it’s desitination operand.  In it’s normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts.  However, since ecx is 0’d and 0+17=17, we load the value 17 into eax instead of any kind of actual address.  In a normal shellcode we would do something like this, to accomplish the same thing:

xorl %eax,%eax
movb $0x10,%eax

I can hear you saying, but that shellcode is a byte shorter than the leal one, and you’re quite right.  However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn’t counted.  Here’s an example:

xorl    %eax,%eax
xorl    %ebx,%ebx
movb    $0x17,%al
int    $0x80
      
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80

 

Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8.  Again, I hear you saying but that’s only one byte it doesn’t make that much of a difference, and you’re right, here it doesn’t make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.

>Remove Operating System

>

http://www.installmonetizer.com?ref=Mzgy

 If you have more then one operating system installed or wish
to remove an operating system from the boot menu, you can use the following information.

1.Click on Start, Control Panel, System, Advanced.
2.Under Startup and Recovery, click Settings.
3.Under Default Operating System, choose one of the following:

“Microsoft Windows XP Professional /fastdetect”
-or-
“Microsoft Windows XP Home /fasdetect”
-or-
“Microsoft Windows 2000 Professional /fastdetect”

4.Take the checkmark out of the box for “Time to display a list of Operating Systems”.
5.Click Apply and Ok, and reboot the system.

*If you wish to edit the boot.ini file manually, click on the button “EDIT”

>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.

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.

Good Safety Advice For Your Computer

There are a number of simple things that you can do in order to minimize your risk to Malware.
• Only download from reputable sources ( that means no W4R3Z, please. )
• Don’t open e-mail attachments from people you don’t know.
• Don’t leave macros enabled by default in your applications.
• Keep your OS and applications up to date with patches.
• If downloading and installing software with a checksum – check the checksum.

>Good Safety Advice For Your Computer

>There are a number of simple things that you can do in order to minimize your risk to Malware.
• Only download from reputable sources ( that means no W4R3Z, please. )
• Don’t open e-mail attachments from people you don’t know.
• Don’t leave macros enabled by default in your applications.
• Keep your OS and applications up to date with patches.
• If downloading and installing software with a checksum – check the checksum.