Classification of computer viruses in the unix environment

Disk inodes consist of the following fields: 9 File owner identifier 9 File type 9 File access permission 9 File access time 9 Number of link to the file 9 Table of content for the disk

Classification of computer viruses

in the Unix environment

by

Le Tan Phuoc

A thesis submitted in partial fulfillment of requirement

for the degree of Master Engineering

Examination Committee: Prof Phan Minh Dung (Chairman)

Dr Ir Erik L.J Bohez

Dr Ho Dinh Duan

Previous degree B.E in Computer Science

Ho Chi Minh University of Technology

ACKNOWLEDGMENT

I would like to express my deepest of gratitude to my advisor, Prof Phan Minh Dung for his valuable guidance, encouragement, and constant support through out my study Grateful thanks are also conveyed to my examination committee, Dr Ho Dinh Duan and Ir Erik L.J Bohez for their constructive comments and helpful suggestions

I would especially thanks to the Department of Industrial Systems Engineering (HCMC University of Technology) and Dr Ho Thanh Phong for the support, encouragement and so forth, which allowed me to concentrate on this dissertation Special thanks for CSIM staff for support and technical assistance and thanks for all

my friends, for their encouragement and support during my study I am gratly indebted for their help in solving problems during the experimentation

Finally, this thesis is dedicated to my beloved parents and all family members for their moral support and great inspiration which encouraged me to pursue this study tirelessly

ABSTRACT

In just over a decade, most of us have been familiar with the term computer virus Even those of us who don't know how to use a computer have heard about viruses through Hollywood films such as Independence Day or Hackers and some means like that International magazines and newspapers regularly have virus-scares as leading stories There is no doubt that our culture is fascinated by the potential danger of these viruses

Computer virus have become threat to computer users and almost every field in the advance technology industrial nowadays Know about virus and environments that can be infected by virus is very necessary for anti-virus researchers as well as operating systems makers With the development of the open source systems today, computer viruses on these systems should be considered strictly This study is about Unix environment, from the analysis of internal mechanisms of Unix, propose some viruses that can work on this environment and suggest methods to prevent as well as restrain damages of these viruses

6 Conclusion 46

CHAPTER 1 INTRODUCTION

When the possibility of computer virus was first mentioned in scientific papers published by Fred Cohen in 1984, nobody took it seriously It did not take long before the first wide scale computer virus infection swept in 1986 Along the development of internet, there are more opportunities for computer virus to spread Appearance of a virus type using network as transmission medium created a new term of the computer virus called worm In 1999, Melissa is the first worm spreading widely via email All of operating systems are target of computer viruses The first IBM-PC virus, called "Brain", appeared in 1987 After a few years, several viruses of Apple Macintosh, Commodore Amiga, and Atari systems have been detected

The history of computer viruses is still incomplete and continues to pose a major threat to computer users throughout the world Just as computers and computer operating systems have become increasingly complex, computer viruses have also become more complex and harder to detect Although viruses appear in many places

in the world, they always have a common method to spread out and damage, we need

to have a more detail classification about virus to make them to be examined easier In this thesis, I will try to classify virus types, study mechanism, structure and damage levels of computer virus base on mechanism of Unix operating systems as well as its applications These tasks help those who want to study computer virus have a deeper look about it and also very important for anti-virus researchers

1.2 Statement of the Problem

With the development of operating systems as well as applications, viruses are created and increase day by day, the study of virus is really necessary, especially for software developer or persons who are working in information technology fields

Base on different operating systems or different applications, there will have viruses with structures and behaviours respectively To study and classify computer virus, firstly we have to know common structure and behaviours of a virus, and second, the most important, we have to know deeply about environment that virus are working

on Depend on supports of systems, that allow virus exist or not

1.3 Objective of the Study

The primary objectives of the study are:

- To analyze the mechanism of some basic Unix system call functions

- To analyze file structure in Unix, analyze characteristics and behaviours of some applications in Unix environment, OpenOffice for instance

- Base on analyses above, give out some specific viruses with their full behaviours such as infect, damage and so forth

- To propose some methods to prevent, detect and recover these kinds of virus

1.4 Scope and limitation of the Study

Viruses exist in almost every operating system that allow to access and modify files in these systems Although the common behaviours of viruses are the same in all systems, base on specific system, the detail mechanisms of computer virus are different

In this study, I only concentrate on Unix operating system and application in Unix (Linux is typically), study viruses and their behaviours that can attack to Linux OS as well as its application Hence, give out some methods prevent computer virus, restrain the damage capability of computer virus

CHAPTER 2 LITERATURE REVIEW

Virus is one of things that are mentioned the most in fields of information technology nowadays There are many seminars and report about virus every year, the suffer damage cause by virus as well as the new antivirus products, or the intelligent method

to detect and clean virus Especially, in autumn of this year, Calgary, a university of Canada, intend to teach a course about virus for the fourth year student with the title

“Computer Viruses and Malware”, however protests were raised against this plan Now we take a look for previous studies about virus In 1985, The Ph.D thesis with title “Computer virus” of Fred Cohen (University of Southern California) is the first formal work in the field of computer viruses He also wrote "Computer Viruses-Theory and Experiments" in 1987, this paper brought the term "computer viruses" to general attention It describes computer viruses and also describes several experiments in each of which all system rights were granted to an attacker in under an hour "Models of Practical Defenses Against Computer Viruses” is written by Cohen

in 1989, this paper models complexity based virus detection mechanisms, that detect modifications and thereby prevent computer viruses from causing secondary infections These models are then used to show how to protect information in both trusted and untrusted computing bases, show the optimality of these mechanisms, and discuss some of their features The models indicate that we can cover changes at all levels of interpretation with a unified mechanism for describing interdependencies of information in a system and discuss the ramifications of this unification in some depth And in 1992, the paper with title "A Formal Definition of Computer Worms and some related Results" of Cohen, a formal definition for computer worms has been presented The definition is based on Turing's model of computation

The doctoral thesis of Vesselin Bontchev at University of Harmbug in 1998 with the title "Methodology of Computer Anti-Virus Research" is a detailed writing on computer viruses It can be treated as a definitive text on understanding and dealing with computer viruses The important topics discussed in this work include classification and analysis of computer viruses, state of art in anti-virus software, possible attacks against anti-virus software, test methods for anti-virus software systems and social aspects of virus problem It also discusses useful applications of self- replicating software In "Future Trends in Virus Writing" (1994), Bontchev summarizes some ideas that are likely be used by virus writers in the future and suggests the kind of measures that could be taken against them And in "Macro Virus Identification Problems" (1997), Vesselin Bontchev discusses some interesting theoretical problems to anti-virus software Two viral sets of macros can have common subsets or one of the sets could be a subset of the other The paper discusses the problems caused by this It emphasizes the difficulties that could be exploited by the virus writers and methods, which could be followed to tackle it

Besides, there are also a lot of study about virus of many other authors such as Brunnstein, David M Chess, Jeffrey O Kephart and so forth And The Virus Test Center has been publishing antivirus product virus detection analyses (1994-2002) Furthermore, several papers concentrating on antivirus product evaluation have been published in EICAR conferences, Virus Bulletin conferences and information security conferences The antivirus product analysis processes described in this dissertation

have been developed without knowing about other implementations and the processes developed are as such novel innovations

There are many books and documents about Virus Classification, but most of them much more concentrate about characteristic of virus rather than environment of virus, they only classify base on virus’s characteristic such as family, damage level, infect ability, etc And in this study, I will classify virus base on mechanisms of a specific environment (Unix) that virus are working on, hence propose some viruses and damages that can be caused by these viruses

CHAPTER 3 INTERNAL REPRESENTATION OF FILES

A simple description of the Unix system, also applicable to Linux, is this:

"On a Unix system, everything is a file, if something is not a file, it is a process."

This statement is true because there are special files that are more than just files (named pipes and sockets, for instance), but to keep things simple, saying that everything is a file is an acceptable generalization A Linux system, just like Unix, makes no difference between a file and a directory, since a directory is just a file containing names of other files Programs, services, texts, images, and so forth, are all files Input and output devices, and generally all devices, are considered to be files, according to the system

The same as others system, working with Unix, allows us to access and do almost every operation with file such as open, read, modify, delete and so forth User can do something like that with a simple system call supported by the operating system Now

we consider internal structure of file system to see what the Operating system do to access files

Every file on a Unix system has a unique inode The inode contains the information necessary for a process to access a file Processes access files by a defined set of system calls and specify a file by a character string that is the path name Each path name uniquely specify a file, and the kernel converts the path name to the file’s inode

3.1 Inodes

The internal representation of a file is given by an inode, which contains the information necessary for a process to access a file, such as file ownership, access rights, file size and location of the file’s data in the file system

Processes access file by a well defined set of system calls and specify a file by a character string that is the path name Each path name uniquely specifies a file, and the kernel converts the path name to the file’s inode

Here is the structure of the disk inode:

Field Byte Description

Mode 2 File type, protection bits, setuid, setgid bits

Nlinks 2 Number of directory entries pointing to this i-node

Uid 2 User ID of the file owner

Gid 2 Group ID of the file owner

Size 4 File size in bytes

Addr 39 Address of first 10 disk blocks, then 3 indirect blocks

Gen 1 Generation number (Incremented everytime i-node is used) Atime 4 Time the file was last accessed

Mtime 4 Time the file was last modified

Ctime 4 Time the i-node was last changed

Inodes exist in a static form on disk, and the kernel read them into an in-core inode to manipulate them Disk inodes consist of the following fields:

9 File owner identifier

9 File type

9 File access permission

9 File access time

9 Number of link to the file

9 Table of content for the disk addresses of data in a file

9 File size

The in-core copy of the inode contains the following fields in addition to the fields of the disk inode:

9 The status of the in-core inode

9 The logical device number of the file system that contain the file

9 The inode number

9 Pointer to other in-core inodes

An inode is active when a process allocates it, such as opening a file An inode is on the free list only if its reference count is 0, meaning that the kernel can reallocate the in-core inode to another disk inode The free list of inode thus serves as a cache of inactive inodes If a process attempts to access a file whose inode is not currently in the in-score inode pool, the kernel reallocates an in-core inode from the free list for its use

And here is the algorithm used by the operating system for allocation of in-core inodes:

Input: file system inode number

Output : locked inode

continue; /* loop back to while */

}

if (inode on inode free list) remove from free list;

increment inode reference count;

return(inode);

}

/* inode not in inode cache */

if (no inode on free list) return(error);

remove new inode from free list;

reset inode number and file system;

remove inode from old hash queue, place on new one;

read inode from disk;

on the state of the file The kernel unlock the inode before returning from the system call so that other system calls can access the inode if they wish

This is the algorithm to release an inode:

Input: pointer to in-core inode

Output : none

Subroutine iput()

{

lock inode if not already locked;

decrement inode reference count;

3.2 Conversion of a path name to an inode

The initial access to a file is by its path name, as in the open, chdir or link system calls Because the kernel works internally with inode rather than with its path names,

it converts the path names to inodes to access files The convert algorithm parses a path name one component at a time, converting each component into an inode based

on its name and the directory being searched, and eventually returns the inode of the input path name

The algorithm uses intermediate inodes as it parses a pathname, call them working inode The inode where the search starts is the first working inode During each iteration of the loop, the kernel make sure that the working inode is indeed that of a directory Otherwise, the system would violate the assertion that non-directory files can onlu be leaf nodes of the file system tree The process must also have permission

to search the directory

Algorithm for conversion of a path name to an inode

Input: path name

Output: locked inode

Subroutine namei()

{

if (path name starts from root)

working inode = root inode else

working inode = current directory inode;

while (there is more path name)

{

read next path name component from input;

verify that working inode is of directory, access permission OK;

if (working node is of root and component is “ ”) continues;

read directory(working inode);

if (component matches an entry in directory(working inode)) {

get inode number for matched component;

release working inode;

working inode = inode of matched component }

else /* component not in directory */

return (no inode);

of the block as a sequence of directory entries If it finds a match, it records the inode number of the matched directory entry, release the block and the old working inode

and allocates the inode of the matched component The new inode becomes the working inode If the kernel doen not match the path name with any name in the block, it releases the block, adjusts he byte offset by the number of bytes in a block, convert the new offset to a disk block number and read the next block The kernel repeats the procedure until it matches the path name component with a directory entry name, or until it reaches the end of the directory

3.3 Inode assignment to a new file

The file system contains a linear list of inodes, an inode is free if its type field is zero When a process need a new inode, the kernel could theoretically search the inode list for a free inode However, such a search would be expensive, requiring at least one read operation for every inode To improve performance, the file system super block contains an array to cache the number of free inodes in the file system

The super block consist of the following fields:

9 The size of the file system

9 The number of free blocks in the file system

9 A list of free blocks available on the file system

9 The index of the next free block in the free block disk

9 The size of the inode list

9 The number of free inodes in the file system

9 A list of free inodes in the file system

9 The index of the next free inode in the free inode lidt

9 Lock fields for the free block and free inode lists

9 A flag indicating that the super block has been modified

Algorithm for assigning new inodes

Input: file system

Output: locked inode

lock super block;

get remembered inode for free inode search;

search disk for free inode until super block full,

or no more free inode;

unlock super block;

wake up (even super block becomes free);

if (no free inodes found on disk) return (no inode);

set remembered inode for the next free inode search;

}

/* there are inodes in super block inode list */

get inode number from super block inode list;

write inode to disk;

decrement file system tree inode count;

A non-zero file type field indicates that the disk inode is assigned If the super block list of free inodes is empty, the kernel searches the disk and places as many free inode number as possible into the super block The kernel read the inode list on disk, block

by block, and fills the super block list of inode number to capacity, remembering the highest-numbered (the last one saved in the super block) inode that it finds, and the next time the kernel searches the disk for free inodes, it uses the remembered inode as its starting point After gathering a fresh set of free inode numbers, it starts the inode assignment algorithm from the beginning Whenever the kernel assign a disk inode, it decrements the free inode count recorded in the super block

The algorithm for freeing an inode is much simpler After incrementing the total number of available inodes in the file system, the kernel checks the lock on the super block If locked, it avoids race conditions by returning immediately The inode number is not put in to the super block , but it can be found on disk and is available for reassignment If the list is not locked, the kernel checks if it has room for more inode numbers and, if it does, places the inode number in the list and returns

Algorithm for freeing inode

Input: file system inode number

Output: none

Subroutine ifree()

{

increment file system free inode count;

if (super block locked)

set remembered inode for search = input inode number; }

else

store inode number in inode list;

return;

}

CHAPTER 4 SYSTEMS CALLS FOR THE FILE SYSTEM

The last chapter described the internal data structures for the file system and the algorithms that manipulate them This chapter deals with system calls for the file system, using the concepts explored in the previous chapter

The open system call is the first step a process must take to access the data in a file The syntax for the open system call is

fd = open(pathname, flags, modes)

where pathname is a file name,

flags indicate the type of open, modes give the file permission

The open system call returns an integer called the user file descriptor, other operations

of file use the file descriptor that the open system call returns

The kernel searches the file system for the file name parameter, it checks permission for opening the file after it finds the in-core inode and allocate an entry in the file table for the open file The file table entry contains a pointer to the inode of the open file and a field that indicates the byte offset in the file where the kernel expects the

next read or write operation to begin The kernel initialize the offset to 0 during the

open call, meaning that the initial read or write starts at the beginning of a file by

default Alternatively, a process can open a file in write-append mode, in which case the kernel initializes the offset to the size of the file

Algorithm for opening a file:

Inputs: file name, type of open, file permissions

Output: file descriptor

Subroutine open()

{

convert file name to inode;

if (file does not exist or not permitted access)

return (error);

allocate file table entry for inode, initialize count, offset;

allocate user file descriptor entry, set pointer to file table entry;

if (type of open specifies truncate file)

free all file blocks (free);

unlock(inode);

return (user file descriptor);

}

Each open returns a file descriptor to the process, and the corresponding entry in the

user file descriptor table point to a unique entry in the kernel file table The file table entries of all in stances of an open file point to one entry in the in-core inode table

4.2 Read

The syntax for the read system call is

n = read(fd, buffer, count)

where fd is the file deiscriptor returned by open,

buffer is the address of a data structure in the user process

count is the number of byte the user wants to read,

n is the number of bytes actually read

• The kernel gets the file table entry that corresponds the user file descriptor

• The kernel sets several I/O parameters in the u area, eliminating the need to pass them as function parameters

– I/O mode to indicate that a read is being done

– a flag to indicate that the I/O will go to user address space

– a count field to indicate the number of bytes to read

– the target address of the user data buffer

– an offset field (from the file table) to indicate the byte offset

into the file where the I/O should begin

• The kernel locks the inode before it reads the file

• The kernel converts the file byte offset into block number by bmap

• After reading the block into a buffer by bread and breada, it copies the data from the block to the target address in the user space

• The kernel updates the I/O parameters in the u area according to the number of bytes

it read

• If the user request is not satisfied, the kernel repeats the entire cycle

• The cycle completes either when the kernel completely satisfies the user request, or

if the kernel encounters an error in reading the data from disk or in copying the data to user space

• The kernel updates the offset in the file table according to the number of bytes it actually read

Algorithm for reading a file:

Input: user file descriptor, address of buffer in user space, number of bytes to read Output: count of bytes copied into user space

Subroutine read()

{

get file table entry from user file descriptor;

check file accessibility;

set parameters in u area for user address, byte count, I/O to user;

get inode from file table;

lock inode;

set byte offset in u area from file table offset;

while (count not satisfied)

{

convert file offset to disk block (bmap);

calculate offset into block, number of bytes to read;

if (number of bytes to read = 0) break; /* trying to read end of file */

read block;

copy data from system buffer to user address;

update u area fields for file byte, offset, read count,

address to write into user space, release buffer;

}

unlock inode;

update file table offset for next read;

return (total number of bytes read);

}

The syntax for the write system call is

n = write(fd, buffer, count);

where the meaning of variables are the same as they are for the read system call The algorithm for writing a file is similar to that for reading a file However, if the file does not contain a block that corresponds to the byte offset to be written, the kernel locates a new block and assign the block number to the correct position in the inode’s table of contents If the byte offset is that of in indirect lock, the kernel may have to allocate several blocks for use as indirect blocks and data blocks The inode is locked for the duration of the write because the kernel may change the inode when allocating new blocks, allowing other processes access to the file could corrupt the inode if several processes allocate block simultaneously for the same byte offsets When the write is complete, the kernel updates the file size entry in the inode if the file has grown larger

The ordinary use of read and write system calls provides sequential access to a file, but process can use the lseek system call to position the I/O and allow random access

to a file

The syntax for the lseeik system call is

position = lseek(df, offset, reference);

• The ordinary use of read and write system calls provides sequential access to a file, but processes can use the lseek system call to position the I/O and allow random access to a file

• The lseek system call has nothing to do with seek operation that positions a disk arm over a particular disk sector

• To implement lseek, the kernel simply adjusts the offset value in the file table; subsequent read or write system calls use the file table offset as their starting byte offset

• If the reference count of the file table entry is greater than 1 because of dup or fork calls, then other user file descriptor reference the file table entry; the kernel decrements the count and the close completes

• If the file table reference count is 1, the kernel frees the entry and releases the core inode originally allocated in the open system call

in-• If other process still reference the inode, the kernel decrements the inode reference count but leaves it allocated; otherwise, the inode is free for reallocation

because its reference count is 0

• When the close system call completes, the user file descriptor table entry is empty

to suitable file access permission

Algorithm for creating a file :

Input: file name, permission settings

Output: file descriptor

Subroutine create()

{

get inode for file name;

if (file already exists)

assign free inode from file system;

create new directory entry in parent directory,

include new file name and newly assigned inode number;

}

allocate file table entry for inode, initiailize count;

if (file did exist at time of creat)

free all file blocks (free);

unlock(inode);

return (user file descriptor);

}

The create system call proceeds according to he same algorithm as the open system

call The kernel allocates an entry in the file table for the created file so that the

process can write the file, allocate an entry in the user file descriptor table, and

eventually returns the index to the later entry as the user file descriptor

CHAPTER 5 COMPUTER VIRUSES CLASSIFICATION

5.1 Introduction

There are many definitions of virus, but all of them have the same meaning Computer virus is a program that is designed with a special purpose, it can replicate and copy itself into other programs It often perform these following steps:

Attach to another program, modify data so that virus can get control when ever that program is executed

9 When executed, virus finds other objects and infects into these objects

9 Perform some damage actions such as destroy, spy… etc

9 Return control to that program as normally

In general, virus can infect into objects that can be executed, for example, file that has the extend name is bat, exe, or com … some text documents, even class files written by Java

By anyway, most of virus have the same common structure although that works in many different environment, here is the common structure of virus that is proposed by

then goto loop

else prepend VIRUS to file;

The pseudo code about just showed a very basic characteristics of computer viruses However, with different environment the detail code will be different, for example,

let’s survey simply the subroutine infect-executable in the pseudo code above

For random-executable statement, in single user environment (e.g win9x, ms

dos), virus can file any executable file to infect but in multi-user environment (Unix) virus can only infect to some restrict files, base on user’s right or virus can find files via network (e.g in window, virus can access file in remote computer via some functions in MPR.DLL library such as WNetOpenEnum, WNetEnumResource, WNetCloseEnum etc)

The statement first-line-of-file=1234567 help virus to verify a file has been

infected by itself or not, some virus can verify by checking a file in a special directory or check a key in registry etc

The statement prepend VIRUS to file is a step to infect virus to file, base on mechanism of different files that virus has many different mechanism to infect And the other subroutines also have some characteristics somehow like the subroutine described above

A program infected with a virus and loaded and executing in the main memory of a computer can infect another executable program in the computer’s disk storage system by requesting the computer’s operating system to append a copy of the virus code to the object program, usually at the start The infection makes the object program slightly longer

When the newly infected program is itself loaded into memory and invoked, the virus

in it takes control and performs hidden functions, such as infecting other object programs The virus may also perform destructive functions before transferring control to the original entry point The virus code contains a marker so that the virus will not attempt to infect a program already infected by its own kind (multiple infection would cause an object file to grow ever larger, leading to easy detection)

5.2 Shell script virus

The shell is a command interpreter; it takes each command and passes it to the operating system kernel to be acted upon It then displays the results of this operation

on the screen In Unix there are several shells that can be used, the most commonly available shells are:

• Bourne shell (sh)

The Bourne shell is usually installed as /bin/sh on most versions of Unix For this reason, it is the shell of choice for writing scripts to use on several different versions of UNIX In addition to being a command interpreter, the Bourne shell is

a powerful language with a programming syntax similar to that of the ALGOL language It contains the following features:

9 Process control

9 Variables

9 Regular expressions

9 No file name completion

9 No command history or command editing

9 Difficulty in executing multiple background processes or jobs

• C shell (csh)

The C shell was designed to make interactive use of the shell easier for users Another design goal was to change the syntax of the shell from the Bourne shell's older Algol style to the newer C style The C language style of the C shell was intended as an improvement because the C language was familiar to the programmers working on Unix at Berkeley The idea was that a shell that used C language style syntax would be easier to write scripts in than a shell that used the Algol style syntax

As it turned out, the C shell could not be used for much more than the most trivial scripts Some of the major drawbacks are :

9 Weak input and output controls

9 Lack of functions

9 Confusing syntax due to a "lazy" command interpreter

Although the C shell did not catch on for scripts, it has become extremely popular for interactive use Some of the key improvements responsible for this popularity follow:

9 Command history and history substitution

9 Command aliases and functions

9 File name completion

9 Arrays

9 Built-in integer arithmetic

• Bourne Again Shell (bash)

The Bourne Again shell, bash, was developed as part of the GNU project and has replaced the Bourne shell (sh), for GNU-based systems like Linux All major Linux distributions, including Red Hat, Slackware, and Caldera, ship with bash as their sh replacement Although it includes C shell (csh and tcsh) and Korn shell ( ksh) features, bash retains syntax compatibility with the Bourne shell, enabling it

to run almost all Bourne shell scripts

Some features that bash includes in addition to those of the Korn shell are :

9 Name completion for variable names, usernames, host names, commands, and filenames

9 Spelling correction for pathnames in the cd command

9 Arrays of unlimited size

9 Integer arithmetic in any base between 2 and 64

Each shell also includes its own programming language Command files, called "shell scripts" are used to accomplish a series of tasks Because shells are really just interpreted languages, any sequence of commands we wish to run can be placed in a file and run regularly This is a shell program Most Unix programmers write their shell programs for the Bourne shell (/bin/sh) because that shell is standard on every Unix platform

Shell scripts are useful for tasks that are more complicated than executing a sequence

of Unix commands Unix shell script language can match some of the advanced features of high-level programming languages We can also define shell variables or use the predefined shell variables (e.g., $PATH, $HOME) within scripts Scripts can accept command-line arguments or strings from standard input

Some commands and statements that are the most often used in shell scripts to create shell script virus :

o The cut command

The "cut" command is used for getting different fields from the lines of a file The most usual way of using it is defining a character as a field separator and a field number, for example:

/etc/passwd file:

user:x:1001:100::/home/user:/bin/bash

with

$> cat /etc/passwd | cut -d":" -f3

In the example above, we will get the UID of "user" (1001) because we are defining ":" as a field separator (-d":") and we are requesting the third field (-f3)

o The find command

This command is used to search files in the directory tree We can specify many file properties as name, permissions, date, owner, etc

Its use is very easy: we decide where we want to start the search and what properties do our objectives have, for example:

$> find /etc/ -perm +111

will show us every file with any permission enabled starting from the "/etc/" directory

o The head command

With the "head" command we request the first part of a file We can request a specific number of characters or even a specific number of lines, for example:

$> head -5 /etc/passwd

gives us the first 5 lines of the file "/etc/passwd"

Or another use, with:

$> head -c512 /etc/passwd

we get the first 512 characters of the file "/etc/passwd"

o The tail command

The use of tail command is similar to the use of head command, but it returns the

end part of file instead

First of all the first "list" of commands is executed If the final result is TRUE

then the "then" list will be executed, otherwise the "elif" lists will be executed

and if the final result is TRUE their "then" list is also executed In the end, if there was no list with the final result set to TRUE the "else" list is executed

So, "if" does not need an expression, it can be a list of commands or any of the conditions that gives for file, string or numeric argument handling: