not

Linux accesses the hard disk directly and does not use the BIOS, so we do not risk getting incorrect data from the BIOS about the size of the disk. That also means that there are not software write blockers for Linux, but you can use a hardware device if you want.

hdparm -I /dev/hda ve fdisk -lu /dev/hda hdparm -ig /dev/hda
sektor sayısı

The ability to obfuscate evidence makes the HPA and DCO a
concern for investigators. When imaging an HDD, the investigator must be aware that
any HDD that supports ATA-6 and above can contain HPA and or DCO. However, if
the HDD supports ATA-4 or 5, it only has the potential to contain HPA. Given that the
majority of current HDDs support ATA-6 and above, it is extremely important for current
forensics practitioners to be aware of the HPA and DCO and use appropriate tools.

http://freenet-homepage.de/moyamu/sw/hpatools/index.html
http://www.thinkwiki.org/wiki/Hidden_Protected_Area


The hard disk is where most of the evidence is found in current investigations, which will likely be the case for many years to come, at least until all hard disks are encrypted

UNIX systems use different partitions for different directories to minimize the impact of file system corruption

Linux uses the standard MS-DOS partitioning scheme

sadece bi tane extended olabilir deniyor bi yerde


An OS can use different strategies for allocating data units. Typically, an OS allocates consecutive data units, but that is not always possible. When a file does not have consecutive data units, it is called fragmented.

Damaged Data Units
Many file systems have the ability to mark a data unit as damaged. This was needed with older hard disks that did not have the capability to handle errors. The operating system would detect that a data unit was bad and mark it as such so that it would not be allocated to a file. Now, modern hard disks can detect a bad sector and replace it with a spare, so the file system functionality is not needed.
It is easy to hide data using the file system functionality, if it exists. Many consistency-checking tools will not verify a data unit that the file system reports as being damaged is actually damaged. Therefore, a user could manually add a data unit to the damaged list and place data in it. Most acquisition tools report bad sectors, so that report can be compared the damaged list to identify sectors that may have been manually added to hide data.

All file systems have slack space because all file systems allocate data in multiple-byte chunks instead of in individual bytes. Slack space is interesting because of the OS and what it writes, not because of the file system. It is important to note that slack space is considered allocated data. It may contain data from a previously deleted file, but it is currently allocated to a file. If you extract the unallocated data from a file system, it should not include the slack space of a file.

Compressed files can present a challenge for an investigation because the investigation tool must support the compression algorithm. Further, some forms of keyword searching and file recovery are ineffective because they examine the compressed data instead of the uncompressed data.

Encrypted data can present a challenge to an investigator because most of the files are inaccessible if she does not know the encryption key or password. It is even worse if the encryption technique is not known. Some tools exist to guess every key or password combination, called a brute force attack, but those are not useful if the algorithm is not known. If only select files and directories were being encrypted, copies of the unencrypted data may be found in temporary files or in unallocated space

You also should verify that entries for special types of files do not have data units allocated to them. For example, some file systems can have special files called sockets that are used by processes to communicate with each other, and they do not allocate data units.

Many file systems do not clear the file name of a deleted file, so deleted file names can also be shown in the listing. In some cases, though, the metadata address is cleared when a file is deleted, and you will not be able to obtain more information.

Note that searching by extension does not necessarily return files of a given type because the extension may have been changed to hide the file. Application-level analysis techniques that rely on the file structure can be used to find all files of a given type

Wiping Techniques
A wiping tool in this category clears the name and metadata address from the structure. One wiping technique might write over the values in the file name structure, so the analysis will show that an entry existed but the data are no longer valid. For example, the file name setuplog.txt could be replaced with abcdefgh.123. With some OSes, this is difficult because the OS will place the new name at the end of a list, using a next available strategy.
Another technique for wiping file names is to reorganize the list of names so that one of the existing file names overwrites the deleted file name. This is much more complex than the first method and much more effective as a hiding technique because the investigator may never know that anything is out of the ordinary in this directory.

http://mirror.href.com/thestarman/asm/mbr/GRUB.htm

http://www.cyberciti.biz/faq/howto-use-tar-command-through-network-over-ssh-session/

chattr

 
*  allow setting the flag and honor its value
i  allow setting the flag but ignore its value
-  ignore the flag altogether

1.0     1.2     2.0     2.2     2.4
A       -       -       *       *       *
S       *       *       *       *       *
a       -       *       *       *       *
i       -       *       *       *       *
d       -       *       *       *       *
c       i       i       i       i       i
s       *       *       i       i       i
u       i       i       i       i       i
 

Although earlier kernels honored the 'secure deletion' flag, during the development of the 1.3 series the developers dropped the implementation of this property since it seemed to provide at best only a trivial amount of additional security and at worst a false sense of real security to users unfamiliar with the inherent problems of any 'secure deletion' scheme.

[1] Tyler Hudak GCFA assignment



[2] 

[3] 

[4] linux source code 

[5] The Art of Defiling



[6] Defeating Forensic Analysis on Unix

http://www.phrack.org/issues.html?issue=59&id=6#article
http://www.nsfocus.net/index.php?act=magazine&do=view&mid=2586

DOS Partition tables exist in the MBR and in the first sector of each extended
partition. Conveniently, they all use the same 512-byte structure. The first 446
bytes are reserved for assembly boot code. Code needs to exist in the MBR
because it is used when the computer is started, but the extended partitions do
not need it and could contain hidden data.

her extended partition inin ilk sektorunde de partition table var ama bu ilk sektorun
ilk 446 byte ında asm kodunun olamsına ihtiyaç yok , bu gölgeye veri saklanabilir.

This section includes a few characteristics that can be taken into consideration when analyzing a DOS-based disk. The partition table and boot code require only one sector, yet 63 are typically allocated for both the MBR and extended partitions because the partitions start on a cylinder boundary. Therefore, sector 0 of the extended partition or MBR is used for code and the partition table, but sectors 1-62 may not be used. The unused area can be used by additional boot code, but it also may contain data from a previous installation, zeros, or hidden data. Windows XP does not wipe the data in the unused sectors when it partitions a disk.

http://groups.google.com.by/group/comp.unix.programmer/browse_thread/thread/51e4201501fd4b26/1c9eedf187381c61

aşağıdaki linkte triple indirect block pointer animasyonu var.
http://www.linux-tutorial.info/modules.php?name=MContent&pageid=96

It could be possible for data to be hidden in directory entry structures. The space between the last directory entry and the end of the block is unused and could contain data. This is especially true when the hash trees are used because the first block contains a small amount of administrative data, and the rest is unused. This is a dangerous hiding technique, though, because the OS could overwrite it when a new file name is created.

http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

http://www.mountimage.com/vmware-forensics-vfc.php
http://liveview.sourceforge.net/

Are you already try the good tool "procget" on Linux box?
procget can save contents for fornsic use.

http://www.packetstormsecurity.org/crypt/ssh/openssh/openssh-logging.patch

http://www.shrew.net/?page=software

UNIX ctime is not equivalent to NTFS creation time (NTFS record modified time is closer). File modifications do not change the ctime. The difference between a change (ctime) and a modification (mtime) in UNIX is the difference between altering the label of a package and altering its contents (Peek et al. 1997). A change alters a file's inode whereas a modification alters the contents of the file. For instance, when someone changes permissions on a file it is a change, whereas when someone adds to the contents of a file it is a modification

The ext3 Linux file system is similar to ext2 but adds journaling capabilities to facilitate file system recovery and repair after a system crash. As with NTFS, there are currently no tools available for interpreting the journal file on ext3 to determine what changes were made. This is a potential rich source of information from a forensic standpoint that will certainly be exploited in the future.

The root directory is always associated with inode number 2 and is denoted by a "/". The first inode is generally used to keep track of bad blocks.

md5sum.exe disk.dd
dd if=/dev/sda conv=noerror,syc | md5sum

dd if=/dev/sda conv=noerror,syc | netcat -l -p 2000
netcat hedefip 2000 > disk.dd

http://www.porcupine.org/forensics/forensic-discovery/

silinen dosyayı bulma örneği

/root/sil.txt içine bulsana beni yazdık.
rm /root/sil.txt yaptık
hemen ardından yukardaki komutlarla diskin image ini aldık

live cd ile disk partition a ulaşıyoruz
lde /dev/sda1
buradan dosyanın klasörünün inodunu (burada /root) buluyoruz
bulduğumuz inode 1845

yada

fls -f linux-ext3 /dev/hda1 2
inode 2(/ ) yazılmazsa default ile / içindeki klasör ve dosyaların inodelarına
ve dosya isimlerine ulaşıyoruz(rm edilmiş dosyalar dahil) burdanda /root un inode numarasını
bulabiliriz.

istat -f linux-ext3 /dev/sda1 18435
inode: 18435
Allocated
Group: 9
uid / gid: 0 / 0
mode: drwxr-xr-x
size: 1024
num of links: 2

yukarda görüldüğü gibi /root klasörü allocated(silinmemiş)

fls -f linux-ext3 -a /dev/sda1 18435
root@0[knoppix]# fls -f linux-ext3 -a /dev/sda1 18435
d/d 18435: .
d/d 2: ..
r/r 18448: .profile
r/r 18449: .bashrc
r/r 74726: metallica.jpg
r/r 74732: .viminfo
r/r 74727: .bash_history
r/r 74729: hack.txt
r/r 74730: crack.txt
r/r * 74731: sil.txt
r/r * 74732(realloc): .viminfo.tmp
yukarda görüldüğü gibi sil.txt silinmiş olarak işretli(* işareti)


istat -f linux-ext3 /dev/sda1 74731
root@0[knoppix]# istat -f linux-ext3 /dev/sda1 74731
inode: 74731
Not Allocated
Group: 36
uid / gid: 0 / 0
mode: -rw-r--r--
size: 0
num of links: 0
sil.txt nin inoduna yapısında bu inode not allocated(yani her an başka bir dosya tarafından kullanılabilir durumda) ve 36 nolu blok grubuna ait

fsstat -f linux-ext3 /dev/sda1 | less
Group: 36:
Inode Range: 73729 - 75776
Block Range: 294913 - 303104
Data bitmap: 294913 - 294913
Inode bitmap: 294914 - 294914
Inode Table: 294915 - 295170
Data Blocks: 294915 - 294914, 295171 - 303104

yukarıda 36 nolu block grubu için Block Range: 294913 - 303104 (bu range içindeki herhangi bir blok içinde silinmiş dosyamızın içeriği bulunabilir.

windowsta accessdata ftk ile bulsana beni yi arattırdığımda 299632 verdi ve bu değer range in içinde.doğru bilgilere sahibiz.

root@0[knoppix]# dstat -f linux-ext3 /dev/sda1 299632
Fragment: 299632
Not Allocated
Group: 36

yukarda görüldüğü bu blokta heran başka bir dosyaya tahsis edilebilir.

root@0[knoppix]# dcat -f linux-ext3 /dev/sda1 299632
bulsana beniroot@0[knoppix]#

yukarıdaki komut ile 299632 nolu bloğun içeriğini görüntüledik

In this example, let’s assume cluster 383624-383635 are marked as bad cluster
and suspected to contain hidden data.
dcat /case1/image1 –f ntfs 383624 12
For further analysis, extract the clusters and use data craving tools such as foremost and comeforth to
recover data.
dd if=/case1/image1 bs=4096 skip=383624 count=12 of=/case1/badclusters
foremost –c /etc/foremost.conf –v –o /forensic/recover /case1/badclusters
http://www.forensicfocus.com/downloads/ntfs-hidden-data-analysis.pdf


ctime linux inode yapısı değerlerinde değişklik
mtime linux dosya içeriğinde değişiklik

http://www.users.bigpond.net.au/hermanzone/p21.html
http://gnurbs.blogsome.com/steph-studies-grub/


mactime komutu için body dosyası oluşturma
fls -f linux-ext3 -m / -r /dev/hda1 > body
kok dizinden recursive olarak tüm dosyaları listeler.
directory entry structure inda silinmiş olan dosyalarıda içerir.ama bunlara denk gelen inode başka bir dosyaya tahsis(allocated) edilmiş olabilir
örnek:
Thu Dec 15 2005 16:57:14 4096 m.c d/drwxr-xr-x 0 0 5586945 /boot Sat Sep 16 2006 04:32:51 608008192 ma. -/-rw-r--r-- 0 0 22 /EMP.rar(deleted-realloc) 608008192 ma. -/-rw-r--r-- 0 0 22 /CentOS-4.4.ServerCD-i386.iso
Tue Oct 24 2006 19:20:25 4096 m.c d/drwxr-xr-x 0 0 8634369 /6500
Thu Oct 26 2006 06:37:31 608008192 ..c -/-rw-r--r-- 0 0 22/EMP.rar(deleted-realloc) 608008192 ..c -/-rw-r--r-- 0 0 22 /CentOS-4.4.ServerCD-i386.iso Mon Apr 09 2007 03:01:19 4096 m.c d/drwxr-xr-x 0 0 6356993 /usr

yukarıda silinik görünen EMP.rar dosyasına ait inode centos a tahsis edildiği için ikiside aynı size
a sahip normalde emp dosya centos dosyadan daha küçük boyuta sahip

ils -f linux-ext3 -m sda1.dd >> body
By default, ils lists only the inodes of removed files.

mactime -b body -i hour/day saat/günindex-p /etc/passwd "Thu Jan 03 2008 15:03:14"-"Thu Jan 03 2008 15:03:37"

cat saat veya gün index

http://www.netmon.ch/forensic/forensic.html
http://odessa.sourceforge.net/
http://www.agilerm.net/linux4.html wmware ile canlı calisma
nigilant32.exe

converters : nomysohttp://www.usinglinux.org/converters/

Convert MASM/TASM files to NASM compatible sources

http://utilsmultiboot.blogeasy.com/

http://www.forensics-intl.com/nta.html

So why do we use hexadecimal to represent digital information?
We do so simply because it takes less space to represent a single character, number,
or symbol. Each hexadecimal value represents four binary values.

http://hermann-uwe.de/
http://www.metropipe.net/ProductsPVPM.shtml
http://www.ericsgrumbles.net/2006/01/28/puppy-linux-vm/
It requires examiners to think “outside-the-box” when dealing with cases known to
involve encryption. Basic encryption schemes need to be understood by examiners.
This understanding will allow them to make sound decisions when seizing digital
evidence. During the execution of a search warrant, just walking into a residence
or business and “pulling-the-plug” on a computer is no longer a viable option.
Seizing agents must be more mindful of encryption programs and must understand
how to best deal with the technology in an already highly stressful situation. If
left unchecked, valuable data could be lost forever. Remember, the main purpose
of encryption is to conceal or secure data from unauthorized access. If the suspect
is using encryption, you can bet that the critical data is secured. However, as
encryption schemes become more secure, so does the technology used to circumvent the
process. Code-breaking software is an indispensable tool to digital evidence examiners.
A weak password or pass phrase coupled with the strongest encryption scheme is
meaningless. “The chain is only as strong as its weakest link” is an effective principle
to apply when using passwords. Code-breaking tools use this fact to exploit the
entire process in order to recover the password and, ultimately, to read the decrypted
file.
Encryption is a two-edged sword. Cryptographers are constantly striving to
develop the world’s perfect encryption algorithm. If such an algorithm exists or is even
possible, the direct effect on our society could be detrimental. A “would-be” terrorist
could use this “perfect” encryption algorithm to conceal their radical views and plans
to commit terrorist acts against any person or country. For this reason, the computer
industry, law enforcement, and intelligence agencies should strive to work together in
an effort to improve software products and digital devices without tying the hands of
law enforcement.

http://thid.thesa.com/thid-0698-8201-th-1220-3575

http://www.cs.auckland.ac.nz/%7Epgut001/pubs/secure_del.html

When all the above factors are combined it turns out that each track contains an image of everything ever written to it, but that the contribution from each "layer" gets progressively smaller the further back it was made. Intelligence organisations have a lot of expertise in recovering these palimpsestuous images.