// Foreplay
---------------------------------------------------------------------
Computer forensics is a method to identify, extract and
find information from digital media such as computers and "hard drives".
Computer forensics in the narrow sense, is only applied to the process
computer evaluation, "data storage" and "processing devices" [1]. Computer
forensic usually associated with the law and used the trial.

Then, what is meant by "Anti Computer Forensics" is a method
to make the "computer forensics investigators' difficulties in
his duties.

//Forensic
---------------------------------------------------------------------
Before starting the discussion on Anti-forensics, it is useful first
I invite us all to become a Computer Forensic Expert. Yes, we will
be a forensic computer expert, to be able to know how it works and
how to "counter" it for anti-forensic purposes later. in the case of
This, I deliberately took the samples to recover a file that has been
deleted by the attacker (us?: lol:)

As an example of a deleted file is the log files (syslog, httpd logs,
firewall logs) which is a vital resource for computer forensic experts,
As for the second reason is more to this article, namely the possibility that we can / must
perform recovery when the engine is still burning / process has not been in the "kill".

Note: In this article I use the root user, either in the process
Anti-computer forensics or forensic

// Recovery file was deleted
-----------------------------------------------------------------
Now, we will try to delete syslog file and then to recover his back,
before that, to make sure the file is still in the access / open by the system,
then it helps us see its contents, as well as a method of verification
after the recovery process later.

// for recovery and verify

root@ngelux~# tailf syslog
Aug 15 02:21:47 ngelux NetworkManager: <debug> [1235028047.728549] nm_hal_device\
Aug 15 02:21:47 ngelux NetworkManager: <debug> [1235028047.959516] nm_hal_device\
Aug 15 02:21:47 ngelux NetworkManager: <debug> [1235028047.982317] nm_hal_device\
Aug 15 02:21:47 ngelux sendmail[5406]: unable to qualify my own domain name (ngelux)
Aug 15 02:21:47 ngelux dhclient: bound to 192.168.16.14 -- renewal in 984139
Aug 15 02:21:47 ngelux sendmail[6860]: My unqualified host name (ngelux) unknown;
Aug 15 02:21:47 ngelux ntpdate[6782]: step time server 91.189.94.4 offset -207.\
Aug 15 02:21:47 ngelux sendmail[6860]: unable to qualify my own domain name (ngelux)
Aug 15 02:21:47 ngelux anacron[6522]: Job `cron.daily' started
Aug 15 02:21:47 ngelux anacron[7003]: Updated timestamp for job `cron.daily' to\

**** The contents of my syslog mutilation with a "\", and later removed, to reduce "junk" and follow the provisions of length <80. : lol: ****

Before starting the removal process, we should note the inode number of syslog file, to facilitate us in sorting using "lsof" eventually

/var/log/syslog has inode"99810"

// For recovery & verification

We will use the remove command "rm" with option "rf" to the syslog file.
look at the pict
[spoiler]
http://pppa.or.id/cakill/1.png[/spoiler]
and
[spoiler]http://pppa.or.id/cakill/2.png[/spoiler]
Up here successfully implemented the removal process.

// Lsof; file recovery process

Now, we will try to restore the log files we have deleted,
in this case we will use lsof to get the info file and
merecovernya, follow the "culture" operating system and filesystem used.

Lsof is a utility that serves to display all the information
comprehensively from a file / directory, special file, network file
(Internet socket, NFS, Unix domain sockets), and so on. Information we need
is the PID (process id), and the file descriptor. The whole process will have
a special directory in the directory "/ proc" with a PID number as the name suggests,
and before the parent process is in "kill", then even though the data was deleted
with "rm", copies of the data is going to be here. (got the point?)

The mapping of the full path will be like the following,

/proc/processid/fd/file descriptor

// Forensic recovery in the beginning

Now, we need to get the syslog file information, using
lsof and do the "sorting" utilizing its inode number,

root@ngelux:~# lsof | grep 99785

syslogd 5484 syslog 2w REG 8,1 91967 99785 /var/log/syslog (deleted)

So, get PID = 5484 and the file descriptor = 2 (from 2w), and if we
adjust the mapping to pseudo-filesystem path is :
root@ngelux:~# ls -l /proc/5484/fd/2
l-wx------ 1 root root 64 [X] 14:27 /proc/5484/fd/2 ->/var/log/syslog (deleted)
root@ngelux:~#
**** X= containts the date, 2011-07-10 ****

It will show a single block of red, indicating a link
/proc/5484/fd/2 been deleted.



For verily "rm" just delete the link to an inode, and attributes, information and data blocks of the file is not touched, then the easiest way to to his recovery is by mengkopikan file back. For example used the name "syslog" again.

root@ngelux:~# cp /proc/5484/fd/2 syslog

then, check the results to see the contents
[spoiler]http://pppa.or.id/cakill/3.png[/spoiler]

and we are as a forensic computer expert will be able to re-read the log files that are (considered) erased by the attacker. ** We Are doomed **

// Anti forensic

After the above we prove that the use of 'rm' is deleted a link to
inode or better known as the index node, which stores the attributes of a
file, and inodes in identification with a unique number for each inode. Attribute
of a file is like: the type of file, "permission", and owner info
groups, file size, number of links (soft / hard), its address in the block of data, etc..

I have not attempted to review and tell more about the files in unix /
linux.
The use of "rm" in doing the deletion of files from the target machine is not
efissien, because forensic computer experts can easily re-
to recover the data, well logs, etc., that I have proved above.
The use of "lsof" is just one way,
a lot of applications / utilities / tools
which can be used to recover files, even entire data in the media,
either when the computer is on or after the restart, the "single mode" or "network mode".

// Secure Data Deletion

Secure Data Deletion is one of the oldest techniques / traditional anti-forensics, a method which is very easy, efficient and "simple" thing to do,compared with various other techniques such as encryption, "steganography",
modification of data, hiding data, etc.. Despite the known risks to be
relatively easy, but for rforensic computer activities, if the data
needed is not found then it would complicate / slow down its activities.

Some applications that can be utilized are: SRM, wipe, shred, etc.,
but in this demo I use shred on the operating system GNU / Linux
ext3 filesystem.

Since 2008 shred into the essential package from the GNU
(GNU coreutils) and will
make default installed, so you do not need to install
Secure Data Deletion other applications.

// Shred

What this does is to rewrite shred files are repeatedly
with the objective complicates the possibility to recover deleted data.
Shred, like a double-edged sword. But it also has a range of shred
limitations on certain types of file systems, compressed and have yag
snapshot support, and for details please consult the shred.

For more details, we will use and trying to shred data recovery
returns as we have done above.

// Shred in Action

Now, we'll go back to delete syslog file, before that, to ensure
This file is still in the access / open by the system, so it's good we see, as well
as a method of verification after the recovery process (as above).

[spoiler]http://pppa.or.id/cakill/4.png[/spoiler]

Record the inode of the syslog file, it will be useful during the process to recovery.

root@ngelux:~# stat /var/log/syslog
File: `/var/log/syslog'
Size: 2400 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 99810 Links: 1
Access: (0640/-rw-r-----) Uid: ( 102/ syslog) Gid: ( 4/ adm)
Access: 2009-02-10 15:41:19.000000000 +0700
Modify: 2009-02-10 15:41:01.000000000 +0700
Change: 2009-02-10 15:41:01.000000000 +0700
root@ngelux:~#

next we will remove the file by using shred,
to understand the use of options given, please check the manuals of the shred

shred proved to have successfully deleted the file /var/log/syslog

root@ngelux:~# ls -la /var/log/syslog
ls: cannot access /var/log/syslog: No such file or directory
root@ngelux:~# stat syslog
stat: cannot stat `syslog': No such file or directory

next is a listing of the files are still open, and as before,
because syslog will write on continuously in the system, then automatically file shall be deemed to still exist

root@ngelux:~# lsof | grep 99810
syslogd 5484 syslog 3w REG 8,1 0 99810 /var/log/0 (deleted)

See and match the inode number of the syslog file, and we find that the current recorded file is "0", in contrast to when we remove the use "rm".

Furthermore, like when we had "recovery" earlier syslog file is
with only copying back from the directory where the pseudo-filesystem.



And then after we check it the file does not contain
any data a.k.a empty.

Yup, "we are done now homey", could sleep soundly, because the recovery process becomes it is relatively difficult for experts forensic.