FORENSICS ANALYSIS

here we just start we will analyze the file with a name practical.floppy.dd

after that we will start cloning the file with the command below

 we create a directory with the name of evid

 we create a directory with the name of analysa but a different place on the flash

 to see the information we partition type as follows

We can redirect the output of this command to a file for later use by issuing the command

Here we need a flash device / mnt / result / as the input file and write output file (of) called image.disk1 in the current directory (/root/evid/)

to gives all users readonly access you can type the following command

then we make another duplicate with input image.disk1 and output on the flash disk

to see the picture we have to mount using loop interface, and to move the location of where we're going to see us add (/ mnt / analysis) contained on our flash.

below we can see the results of the above mount

after you can see below this type

here to ensure that our analysis files have been changed or not we can be sure with this command.

following command will store the code of what we see above is stored into sha.disk1

to see the picture we have to mount using loop interface, and to move the location of where we're going to see us add (/ mnt / analysis) contained on our flash.

to look for evidence of where all the files that are stored in ~ / evil /sha.filelist

to view the contents of sha.filelist you can type the following command

To verify that nothing has been changed on the original floppy, you can use the c as below

below is the same as above just different file only

to view the contents of the directory analysis with the following command

under the command functions the same as above but this will show all the hidden files (a), give the list in long format to identify permission, date, etc. (l).
You can also use the –R option to list recursively through directories.

dibwah masih sama juga tapi di tambah dengan perintah -i and -u,  –i option to include the inode -u can be used so that the output will include and sort by access time

There is also the tree command, which prints a recursive listing that is
more visual. It indents the entries by directory depth and colorizes the
filenames.

SLACK SPACE

SLACK SPACE

          Slack Space is the space that was used by the file, but the space is used, is not spent entirely for storing data.

Slack space refers to portions of a hard drive that are not fully used by the current allocated file and which may contain data from a previously deleted file.

Illustration of slack space on a hard drive

In the example above, saving a 768 byte file (named User_File.txt) requires only sector 1 and 1/2 of sector 2 in the cluster.  Depending on the operating system, the remaining 256 bytes in sector 2 might be filled with 1′s or 0′s or might simply remain intact.  Both sectors 3 and 4 would not be overwritten and are thus considered slack space.  If the slack space previously contained data from a deleted file, this information could be recovered with forensic tools. Additional Details Operating systems allocate files on a hard drive using clusters, which are a collection of contiguous sectors.  Because a cluster is the smaller allocation unit an operating system can address, if a file does not utilize the full cluster, a portion of the space remaining may not be overwritten and might contain data from a previously deleted file. For forensic analysts, it is important to understand that slace space is considered allocated space since it is part of an allocated cluster.  As such, special tools must be used to extract and analyse slace space.  An analysis of unallocated data will not contain any slack space data.

UNALLOCATED SPACE

          Unallocated space is simply defined as the area or space on the hard drive of the computer that is available to write data to.

Clusters of a media partition not in use for storing any active files. They may contain pieces of files that were deleted from the file partition but not removed from the physical disk

The unallocated space is not viewable to the typical computer user and requires specialized computer forensic software to view and analyze.  Unallocated space can contain deleted files or partially deleted files.  When a file is deleted, the pointers to the file are removed, but the data remains in unallocated space until such time as the operating system stores another file in the same space, thereby over-writing the data. 

Example :

           If the operating system writes a file to a certain space on the hard drive that part of the drive is now “allocated”, as the file is using it the space, and no other files can be written to that section. If that file is deleted then that part of the hard drive is no longer required to be “allocated” it becomes unallocated. This means that  new files can now be re-written to that location.
On a standard, working computer, files can only be written to the unallocated space.
          If a newly formatted  drive is connected to a computer, virtually all of the drive space is unallocated space (a small amount of space will be taken up by files within the file system, e.g $MFT, etc). On a new drive the unallocated space is normally zeros, as files are written to the hard drive the zeros are over written with the file data

MAGIC NUMBER

  Magic numbers are common in programs across many operating systems. Magic numbers implement strongly typed data and are a form of in-band signaling to the controlling program that reads the data type(s) at program run-time. Many files have such constants that identify the contained data. Detecting such constants in files is a simple and effective way of distinguishing between many file formats and can yield further run-time information.

Magic Number Chart 

Here are a few magic numbers, These are of image files.

File type	Typical extension	Hex digits xx = variable	Ascii digits . = not an ascii char
Bitmap format	.bmp	42 4d	BM
Office2007 Documents	.xlsx	50 4B 03 04 14 00 06 00	PK
GIF Format	.gif	47 49 46 38	GIF8
MP3	.mp3	49 44 33	ID3
PDF	.PDF	25 50 44 46	%PDF
JPEG File Interchange Format	.jpg	ff d8 ff e0	....
NIFF (Navy TIFF)	.nif	49 49 4e 31	IIN1
PM format	.pm	56 49 45 57	VIEW
PNG format	.png	89 50 4e 47	.PNG
Postscript format	.[e]ps	25 21	%!
Sun Rasterfile	.ras	59 a6 6a 95	Y.j.
Targa format	.tga	xx xx xx	...
TIFF format (Motorola - big endian)	.tif	4d 4d 00 2a	MM.*
TIFF format (Intel - little endian)	.tif	49 49 2a 00	II*.
X11 Bitmap format	.xbm	xx xx
XCF Gimp file structure	.xcf	67 69 6d 70 20 78 63 66 20 76	gimp xcf
Xfig format	.fig	23 46 49 47	#FIG

SWF FILE STRUCTURE 

Introduction

When saying Flash, we can mean absolutely different things even within the bounds of web-technology terms. Not to get confused, I'll use the following terms:

Flash – the technology of web-animation on the whole;

Flash player – program, ActiveX library which displays flash;

Standalone Flash player – application (exe file) displaying flash;

Flash IDE, Adobe Flash, Flash Professional – development environment provided by Adobe Systems (former Macromedia);

FLA – project (source) animation file for Flash IDE;

Movie – an integral web-animation at the development stage;

SWF – result animation file.

So, when loading a web page with flash animation, the following processes take place: web-browser detects an embedded flash animation in an HTML markup, creates and object of flash-player and indicate what file needs to be displayed. Flash player loads SWF file and begins to display it if possible. Due to this principle of work, flash player can display so called preloaders, reproduce streaming audio and video (for example, YouTube) without loading SWF fully.

SWF structure

File format is described in "SWF file format specification" document, which can be downloaded at Adobe.com. Documentation is usually issued some months after the release of a new version of flash player. At the moment, flash player v.10 is already released, but specification document is not renewed and contains specification of version 9. One can find specifications about almost everything I explain here, but the matter is that "almost", but not everything :)

Basic structure of SWF doesn't depend on version, that's why SWF always has Header+Body structure. Body consists of records which are called tags in specification.

To describe data structure, I'll use Object Pascal syntax.

Header

Header contains main information about SWF. It can be described in this way:

TSWFHeader = packed record
SIGN: array [0..2] of AnsiChar;
Version: byte;
FileSize: LongWord;
MovieRect: TRect;
FPS: word;
FramesCount: word;
end;

The first parameter is SIGN. CWS value means that this file is packed using ZLib compression method, not an FWS.

Version – version of file format.

FileSize – size of UNPACKED file in bytes.

MovieRect – size of displayed image in twips (1px = 20twips). I should note that in fact SWF and graphic objects can't be larger than $ffff/ 20 = 3276 px. I haven't seen swf with top-left value less or more than 0. Nevertheless, having set these values in my tests, I made sure that these values are really taken into account. It's worth noting that the specified rectangle is a place given by browser. When opening SWF in a standalone player, sometimes one can see "decorations behind the scenes".

FPS (frames per second) – value in format 8.8 fixed, i.e. for human perception this value is Result := FPS shr 8 + (FPS and $FF) / ($FF+1);

FramesCount– frames number. As a rule, SWF always has at least one frame, but it's possible to create SWF without frames if this file is used as a library for other SWFs.

SWF compression

To reduce file size, Macromedia has used two approaches.
The first one consists of that bit-by-bit compression method is used for saving numbers. It looks like this. Let's presume we need to save a size of rectangle, i.e. four numbers of integer type. At a simple record it will be 4 * 4 bytes = 16 bytes. At recording to SWF, the number of bits needed for coding the largest value is recorded to the first 5 bit, and then these 4 values in bit representation with a specified bit length. For example, it's necessary to save coordinates (0,0 – 100, 100) or in twips (0,0 – 2000,2000). In bit representation number 2000 = 11111010000 (11 bit + 1 for a sign). We have (5 + 4 * 12) / 8 = 7 byte (almost 2 times less). This approach leads to the fact that some identical tags can have different size. It also applies to Header.
The second approach is using ZLib compression method both for the whole SWF and for separate tags.
When a file is compressed, first three parameters of a Header (8 bytes) are not compressed, but the rest are compressed. This explains why it's impossible to read an SWF header only with one read method.

 LOG FILE STRUCTURE

Definition

The log file template contains information about which text files are to be analyzed in which form.

Structure

General Settings for the Monitored Log Files

The following parameters of the log file template apply to all log files that fulfill the conditions for DIRECTORY and FILENAME:

LOGFILE_TEMPLATE

Key word for the agent; opens a search area

DIRECTORY="<directory>"                                          (required parameter)

Directory that contains the log file

FILENAME="<file name>"                                           (required parameter)

Name of the log file; wildcards are permissible

MONITOR_CONTEXT="<context name>"

Name of the monitoring context to which the log file agent writes the results of the monitoring; by default, this is the context Files_of_<Hostname>. Regardless of whether or not you set this parameter, the MTE class of the monitoring context is always CcmsFileMonitoring. By specifying this MTE class, you can define a rule-based monitor that contains the subtrees for all monitored log files. In this way you can, for example, store different components in different contexts to further group the results. Like the PREFIX parameter (see below), this function allows you to differentiate between the different monitored log files, but provides, unlike PREFIX, an additional hierarchical level to group the monitored files. Use this parameter only if you require this additional hierarchical level.

IGNORE_CASE=[0,1]                                                 (Default = 0)

By default, all search patterns are case sensitive (0). If upper and lower case are to be disregarded, set IGNORE_CASE=1.

MONITOR_NEWEST_FILES=<number>                       (Default = 20)

Maximum number of files that is to be monitored; if the number of files whose names fulfill the search criteria exceeds this number, exactly <number> files with the newest change time are monitored. This means that different files are monitored over time. If a file is removed from monitoring because other files have a newer change date, its monitoring tree is deleted, and its alerts are reset. The maximum value for number is also 20, to avoid storing an unnecessarily large quantity of data in the monitoring architecture.

RESCANFROMBEGIN=[0,1]                                       (Default = 0)

Specifies whether each new read operation reads the log file from the start (1) or only the lines that have been added since the log file agent last read the file (0)

MONITOR_FILESIZE_KB=<file size[KB]>           (Default: FileSize is not created)

Value < 0: FileSize is not created. Value = 0: Size of the log file in KB is monitored in the node FileSize Value > 0: The size of the log file in KB is monitored; if the file size exceeds the value, an alert is generated

PREFIX="<character string>"

Appears before the MTE nodes; allows you to differentiate between different log files with different paths, but the same name

SHOWNEWLINES=[0,1]                                             (Default = 0)

Value=1: The Alert Monitor creates the subnode Newlines; that is, the number of lines created  per minute is reported Value=0: Newlines is not created

ANALYZEMETHOD="<method name>"                       (Default: no method)

Analysis method that is assigned to the alert

MONITOR_LAST_FILE_MODIF=[0,1]                       (Default = 0)

Specifies whether a separate performance node File Time Stamp is to be created, which then monitors the last change time point of the log files (1), or whether the last change time point is not to be monitored (0)

MTE_CLASS="<MTE class>"                                   (Default: CcmsFile<file name>)

MTE class of the monitoring object that contains the attributes specified above; the MTE class of the monitoring objects therefore depends on the name of the monitored log file

CHECK_EXISTENCE_ONLY=[0,1]                             (Default = 0)

Specifies whether the system is to check only for the existence of the log files (1). In this case, all parameters for monitoring and for search patterns (see below) are ignored.

Monitored Search Pattern in the Monitored Log Files

You can specify multiple search patterns to be monitored for each of the log files that fulfils the conditions for DIRECTORY and FILENAME. When doing this, enter a number <x> for each search pattern in the parameter suffix of the following parameters. Begin with the number 0.

PATTERN_<x>="<character string>"                 (PATTERN_0 is required)

Search pattern in the log file (case sensitive; wildcards are not allowed)

MESSAGEID_<x>="<message ID>"                         (MESSAGEID_0 is required)

Message number that is assigned to the alert

VALUE_<x>=[RED,YELLOW,GREEN]            Default = YELLOW

Color of the alert in the monitoring architecture

SEVERITY_<x>=[0...255]                 Default = 0

Severity of the alert

MESSAGECLASS_<x>="<message class>"      Default = SAP-T100

Message class

CMP_FROM_BEGIN_<x>=[0,1]                Default = 0

Value=1: The line must begin with the search pattern (better performance) Value=0: The search pattern can be in any position in the line

Search Pattern to be Output in the Monitored Log Files

You can use the parameters explained above to monitor log files for search patterns to which an alert is to be assigned (such as the search pattern Error). This function is not ideal for displaying search patterns to which no alert is to be assigned (such as version or date information). Only one log attribute is available in the Alert Monitor for all monitored search patterns, meaning that only one line is displayed even in the case of multiple search patterns.

There is therefore a second way in which you can monitor log files for search patterns. If a search pattern of this type is found, the Alert Monitor displays the corresponding line as the content of a separate text attribute. You can define the name of the text attribute yourself. If the search pattern exists at several places in the log file, the system displays the last position in which it is found.

APPL_INFO_<x>="<character string>"

Search pattern in the log file (case sensitive; wildcards are not allowed); if the search pattern is found, the system displays the line of the log file in which the search pattern was found in the Alert Monitor

APPL_INFO_MTE_NAME_<x>="<MTE_Name>"

Name of the text attribute in which the line is displayed; the complete node name is INFO[<MTE name>]

·         Note that you must end the file with a period (.).

·         If parameters are required, this is highlighted. All other parameters are optional.

MBR (Master Boot Record)

The Master Boot Record (MBR) is the information in the first sector of any hard disk or diskette that identifies how and where an operating system is located so that it can be boot (loaded) into the computer's main storage or random access memory. The Master Boot Record is also sometimes called the "partition sector" or the "master partition table" because it includes a table that locates each partition that the hard disk has been formatted into. In addition to this table, the MBR also includes a program that reads the boot sector record of the partition containing the operating system to be booted into RAM. In turn, that record contains a program that loads the rest of the operating system into RAM.

Master Boot Record (skema partisi)

 

In this partitioning scheme, the partition is divided into three types, namely :

~ Primary Partition or the primary partition, the partition that can be used to perform the operating system boot process and store user data. There were only four pieces only in a single hard disk. If there is an additional partition, then the amount will be reduced to three primary partitions.

~ Extended Partition or additional partitions, the partitions that can accommodate multiple logical partitions. This partition is actually one kind of primary partition. The numbers should only be one piece only.

~ Logical Partition or logical partition, that partition can not be used to make the process of booting the operating system, and can only store user data. Amount is not restricted, meaning that in a single hard disk may have a lot to have its main office logical partition to a single additional partition.

STRUCTURE FILE SYSTEM

The file system structure is the most basic level of organization in an operating system. Almost all of the ways an operating system interacts with its users, applications, and security model are dependent upon the way it organizes files on storage devices. Providing a common file system structure ensures users and programs are able to access and write files.

FAT16
This is the 16-bit version of the FAT file system. The 16-bit part describes the way units are allocated on the drive. The FAT16 file system uses a 16-bit number to identify each allocation unit (called cluster), and this gives it a total of 65.536 clusters. The size of each cluster is defined in the boot sector of the volume (volume = partition). The File System ID number usually associated with FAT16 volumes are 04h and 06h. The first is used on volumes with less than 65536 sectors (typical this is on drives less than 32 Mb in size), and the latter one is used on volumes with more than 65536 sectors.

The first sector (boot sector) contain information which is used to calculate the sizes and locations of the other regions. The boot sector also contain code to boot the operating system installed on the volume. The data region is split up into logical blocks called clusters. Each of these clusters has an accompanying entry in the FAT region. The cluster specific entry can either contain a value of the next cluster which contain data from the file, or a so called End-of-file value which means that there are no more clusters which contain data from the file. The root directory and its sub-directories contain filename, dates, attribute flags and starting cluster information about the filesystem objects.

FAT32

The first step to reading the FAT32 filesystem is the read its first sector, called the Volume ID. The Volume ID is read using the LBA Begin address found from the partition table. From this sector, you will extract information that tells you everything you need to know about the physical layout of the FAT32 filesystem.

Microsoft's specification lists many variables, and the FAT32 Volume ID is slightly different than the older ones used for FAT16 and FAT12. Fortunately, most of the information is not needed for simple code. Only four variables are required, and three others should be checked to make sure they have the expected values.

After checking the three fields to make sure the filesystem is using 512 byte sectors, 2 FATs, and has a correct signature, you may want to "boil down" these variables read from the MBR and Volume ID into just four simple numbers that are needed for accessing the FAT32 filesystem. Here are simple formulas in C syntax:

(unsigned long)fat_begin_lba = Partition_LBA_Begin + Number_of_Reserved_Sectors;

(unsigned long)cluster_begin_lba = Partition_LBA_Begin + Number_of_Reserved_Sectors + (Number_of_FATs * Sectors_Per_FAT);

(unsigned char)sectors_per_cluster = BPB_SecPerClus;

(unsigned long)root_dir_first_cluster = BPB_RootClus;

As you can see, most of the information is needed only to learn the location of the first cluster and the FAT. You will need to remember the size of the clusters and where the root directory is located, but the other information is usually not needed (at least for simply reading files).

If you compare these formulas to the ones in Microsoft's specification, you should notice two differences. They lack "Root Dir Sectors", because FAT32 stores the root directory the same way as files and subdirectories, so RootDirSectors is always zero with FAT32. For FAT16 and FAT12, this extra step is needed to compute the special space allocated for the root directory.

Microsoft's formulas do not show the "Partition_LBA_Begin" term. Their formulas are all relative to the beginning of the filesystem, which they don't explicitly state very well. You must add the "Partition_LBA_Begin" term found from the MBR to compute correct LBA addresses for the IDE interface, because to the drive the MBR is at zero, not the Volume ID. Not adding Partition_LBA_Begin is one of the most common errors most developers make, so especially if you are using Microsoft's spec, do not forget to add this for correct LBA addressing.

The rest of this page will usually refer to "fat_begin_lba", "cluster_begin_lba", "sectors_per_cluster", and "root_dir_first_cluster", rather than the individual fields from the MBR and Volume ID, because it is easiest to compute these numbers when starting up and then you no longer need all the details from the MBR and Volume ID. 

NTFS

Let's start with the common facts. The NTFS partition theoretically can be almost of any size. The limit certainly exists but I shall not point at it as it will be more than enough for the next hundreds of years of computer technology development at any growth rates. What about practice? Almost the same way. The maximum size of the partition NTFS at the moment is limited only by the hard disks sizes. NT4 probably will have some problems at the attempt of installation on the partition if any of its parts steps back more than on 8 GBytes from the disk physical beginning but this problem concerns only the load partition.

The way of NT4.0 installation on the empty disk is rather original and can lead to incorrect thoughts about NTFS possibilities. If you point the installation program that you wish to format disk in NTFS, maximum size which it will offer you will be only 4 GBytes. Why it is so little if NTFS partition size actually is unlimited? The answer is that installation section simply does not know this file system. The installation program formats this disk in usual FAT which maximum size in NT is 4 GByte (with usage of not absolutely standard huge cluster 64 KByte) NT is installed on this FAT. And during the first operating system load (in the installation phase) the fast partition conversion to NTFS is effected so that user notice nothing except the strange "limiting" on the NTFS size at the installation time.

As well as any other system NTFS divides all useful place into clusters -- data blocks used at a time. NTFS supports almost all sizes of clusters -- from 512 bytes up to 64 KBytes. The 4 KBytes cluster is considered to be some standard. NTFS doesn't have any anomalies of cluster structure and I have nothing to say about it.

NTFS disk is symbolically divided into two parts. The first 12% of the disk are assigned to so-called MFT area -- the space which MFT metafile grows into. Any data recording into this area is impossible. The MFT-area is always kept empty not to let the most important service file (MFT) be fragmented at growth. The rest 88% of the disks represent usual space for files storage.

Disk free space however includes all physically free space -- free pieces of MFT-area are included there too. The mechanism of MFT-area usage is like this: when files already cannot be recorded in usual space, MFT-area is simply reduced (in operating systems current versions -twice) clearing the space for recording files. At clearing the usual area, MFT can be extended again. Thus it is possible for usual files to remain in this area and it is normal. The system tried to keep it free but failed. The metafile MFT all the same can be fragmented though it would be undesirable.

EXT2

The physical structure of Ext2 filesystems has been strongly influenced by the layout of the BSD filesystem. A filesystem is made up of block groups. Block groups are analogous to BSD FFS's cylinder groups. However, block groups are not tied to the physical layout of the blocks on the disk, since modern drives tend to be optimized for sequential access and hide their physical geometry to the operating system.

,---------+---------+---------+---------+---------,
| Boot    | Block   | Block   |   ...   | Block   |
| sector  | group 1 | group 2 |         | group n |
`---------+---------+---------+---------+---------'

Each block group contains a redundant copy of crucial filesystem control informations (superblock and the filesystem descriptors) and also contains a part of the filesystem (a block bitmap, an inode bitmap, a piece of the inode table, and data blocks). The structure of a block group is represented in this table:

,---------+---------+---------+---------+---------+---------,
| Super   | FS      | Block   | Inode   | Inode   | Data    |
| block   | desc.   | bitmap  | bitmap  | table   | blocks  |
`---------+---------+---------+---------+---------+---------'

Using block groups is a big win in terms of reliability: since the control structures are replicated in each block group, it is easy to recover from a filesystem where the superblock has been corrupted. This structure also helps to get good performances: by reducing the distance between the inode table and the data blocks, it is possible to reduce the disk head seeks during I/O on files.
In Ext2fs, directories are managed as linked lists of variable length entries. Each entry contains the inode number, the entry length, the file name and its length. By using variable length entries, it is possible to implement long file names without wasting disk space in directories.

 

EXT3

Ext3 file system is the development of the earlier ext2 file system,
by adding journaling feature. Ext3 became the most popular file system in Linux, and usually the default choice for a new installation.
Such as ReiserFS, Ext3 also uses block structure. Block size the same throughout the file system, depending on the size of the file system, however,
The default rates are among the 1024 or 4096 bytes. 1024 The first byte of the ext3 file system is always in use. If there is in the file system boot kernel, then bytes will contain the boot information.
Superblock on ext3 file system stores general information such as name, size, and the data is used when the last time. Ext3 file system has only one primary superblock, although it could be his backup copy can also be stored along the file system.

 

Ext3 file system to put metadata file in a data structure called inodes. Inodes are stored in special blocks called inode tables. Standard length of an inode is 256 bytes. Each inode structure can accommodate up to twelve direct pointers, which are associated with the addresses of the block file system where the first twelve blocks of a file is placed. If the file is too large to be put on the first twelve blocks (usually 12 KB or 48 KB), then the pointer will be used to single, double, and triple indirect pointer blocks. A single indirect block pointer is the address of the file system that consists of all direct pointer. Next, double and triple indirect block pointer points to the file system that contains single and double pointer iDirect.

 

The blocks on ext3 compiled into block groups. Block groups are described in a block or block group named "the group descriptor table", which always follows the superblock or a copy of the superblock.
Each block group contains two bitmap blocks, one for blocks and the other for the inode. Each bit in the bitmap block indicates the status of one of the blocks or inodes in the group is whether allocated or unallocated. Block and the inode associated in older version of a content file or a file is deleted. Blocks that have not been allocated is represented by "0", while containing the content of a file or metadata, and are used by the file system is represented by "1".