How to install chrome is very simple, just follow the following :
root@bt:~# apt-get install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
chromium-browser-inspector chromium-browser-l10n chromium-codecs-ffmpeg libvpx0
root@bt:~# apt-get install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
chromium-browser-inspector chromium-browser-l10n chromium-codecs-ffmpeg libvpx0
The following NEW packages will be installed:
chromium-browser chromium-browser-inspector chromium-browser-l10n chromium-codecs-ffmpeg libvpx0
root@bt:~# apt-get install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
chromium-browser-inspector chromium-browser-l10n chromium-codecs-ffmpeg libvpx0
The following NEW packages will be installed:
chromium-browser chromium-browser-inspector chromium-browser-l10n chromium-codecs-ffmpeg libvpx0
root@bt:~# cd /usr/lib/chromium-browser
root@bt:/usr/lib/chromium-browser# ls
chrome.pak chromium-browser-sandbox libppGoogleNaClPluginChrome.so plugins resources.pak xdg-settings
chromium-browser libffmpegsumo.so locales resources xdg-mime
root@bt:/usr/lib/chromium-browser# hexedit chromium-browser
root@bt:/usr/lib/chromium-browser# tar -zxvf /root/Desktop/
.directory install_flash_player_11_linux_i386.tar.gz
root@bt:/usr/lib/chromium-browser# tar -zxvf /root/Desktop/install_flash_player_11_linux_i386.tar.gz
libflashplayer.so
readme.txt
usr/
usr/bin/
usr/bin/flash-player-properties
usr/share/
usr/share/kde4/
usr/share/kde4/services/
usr/share/kde4/services/kcm_adobe_flash_player.desktop
usr/share/applications/
root@bt:/usr/lib/chromium-browser# cp libflashplayer.so /usr/lib/chromium-browser/plugins/
root@bt:/usr/lib/chromium-browser# launch chrome
Friday, November 9, 2012
Thursday, November 1, 2012
Tools in Forensic
1. Antiword
Antiword is an application used to display text and a picture of a Microsoft Word document. Antiword only supports documents created by MS Word version 2 and version 6 or newer.
2. Autopsy
The Autopsy Forensic Browser is a graphical interface for investigative analysis tool command line diginal The Sleuth Kit. Together, they can analyze the disks and Windows and UNIX filesystems (NTFS, FAT, Ext2, UFS1/2/3).
3. Binhash
Binhash is a simple program to perform the hashing of the various sections of the files ELF and PE for comparison. Currently she performs a hash on the segment header from the header segment of an object segment header parts elves and obyekPE.
4. Sigtool
Sigtcol is a tool for the management of database and ClamAV signatures. sigtool
can be used to rnenghasilkan the MD5 checksum, data conversion into
hexadecimal format, display a list of virus signatures and
build/unpack/test/verify a database update script and CVD.
5. ChaosReader
ChaosReader is a freeware tool to track the session TCP/UDP/... and pick up application data from log tcpdump. la
would take a telnet session, file transfer FTP, HTTP (HTML, GIF, JPEG,
...), email SMTP, and so on, from the data captured by a log of network
traffic. An html index file will be created
containing a link to the rest of the session details, including the
program replay realtime for a telnet session, rlogin, IRC, or X 11 VNC; and create reports such as the report image and report the contents of the HTTP GET/POST.data
6. Chkrootkit
Chkrootkit is a tool to check for signs of a rootkit. la will examine the main whether utilities are infected, and is currently examining approximately 60 rootkit and its variations.
7. dcfldd
This Tool was originally developed at the Department of Defense Computer Forensics Lab (DCFL). Although Nick Harbour is no longer affiliated with the DCFL he maintains this tool.
8. ddrescue
GNU
ddrescue is a data recovery tool, la menyalinkan data from one file or
block device (hard disc, cdrom, etc) to another, trying hard to save
data in case of failure of the reading. Ddrescue does not truncate the output file if not asked. So each time you run it kefile the same output, he attempted to fill the void.
9. the foremost
Foremost is a tool that can be used to recover files based on the header, footer, or data structure of the file. la
was initially developed by Jesse Kornblum and Kris Kendall of the
United States Air Force Office of Special Investigations and The Center
for Information Systems Security Studies and Research. Foremost
is currently maintained by Nick Mikus a researcher at the Naval
Postgraduate School Center for Information Systems Security Studies and
Research.
10. Gqview
Gqview is an image viewing program for GTK la supports image formats, zooming, panning, thumbnails, and sorting of images.
11. Galleta
Galleta is a tool written by Keith j. Jones to perform forensic analysis of cookies Internet Explorer.
12. Ishw
Ishw
(Hardware Lister) is a small tool that provides detailed information
about the configuration of the hardware in the machine. la
may report memory configuration, firmware version, mainboard
configuration, version and CPU speed, bus speed, cache configuration,
etc. on the system of t > MI-capable x 86 or EFI System.
13. pasco
A lot of computer crime investigations require reconstruction of the Internet activities of the suspects. Because
this analysis technique is done regularly, Keith investigates the
structure of the data found in the activity file Internet Explorer
(index.dat files). Pasco, which comes from Latin and means "browse", was developed to test the contents of the Internet Explorer cache files. Pasco
will check the information in the index.dat files and issue results in
delimited fields so it can be imported into your favorite spreadsheet
program.
14. the Scalpel
Scalpel
is a forensic tool that is designed to identify, isolate and recover
data from media computer forensic investigations throughout the process.
Scalpel seeks hard drive, bit-stream image,
unallocated file space, or any computer files for characteristics,
content or a particular attribute, and generates reports on the location
and content of the artifacts that were found during the search process.
Scalpel also produce (carves) artifacts that are found as individual files.
Forensic Analysis,NTFS Examination: ADS,NTFS Examination: Sorting Files,Signature Search in Unallocated Space.
File System Forensic Analysis :
Let's create a directory in our /root (the root user's home) directory
called /root/ntfs_pract/ and place the file in there. First, we will decompress the
gzipped file using the gzip command we learned earlier and check its SHA1
hash:
root@bt:~# cd /root/forensic/
root@bt:~/forensic# ls
ntfs_pract.dd
root@bt:~/forensic# sha1sum ntfs_pract.dd
0cbce7666c8db70377cb5fc2abf9268821b6dafe ntfs_pract.dd
Now we will run through a series of basic Sleuthkit commands as we
would in any analysis. The structure of the forensic image is viewed using
mmls:
root@bt:~/forensic# mmls ntfs_pract.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000058 0000000059 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated
The output shows that an NTFS partition (and most likely the file
system) begins at sector offset 59. This is the offset we will use in all our
Sleuthkit commands. We now use fsstat to have a look at the file system
statistics inside that partition:
root@bt:~/forensic# fsstat -o 59 -f ntfs ntfs_pract.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: E4D06402D063D8F6
OEM Name: NTFS
Volume Name: NEW VOLUME
Version: Windows XP
METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 42625
First Cluster of MFT Mirror: 63937
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 144
Root Directory: 5
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 127874
Total Sector Range: 0 - 1022999
Looking at the fsstat output on our NTFS file system, we see it differs
greatly from the output we saw running on a Linux EXT file system. The tool is
designed to provide pertinent information based on the file system being
targeted. Notice that when run on an NTFS file system, fsstat provides us with
information specific to NTFS, including data about the Master File Table (MFT)
and specific attribute values.
We will now have a look at how the Sleuthkit interacts with active and
deleted files on an NTFS file system, given the structure of MFT entries.
Let's begin this exercise with the output of fls. We can specify that fls
only show us only “deleted” content on the command line with the d
option.
We will use F
(only file entries) and r
(recursive) as well:
root@bt:~/forensic# fls -Frd -o 59 ntfs_pract.dd
r/r * 42-128-1: Cookies/buckyball@revsci[2].txt
r/r * 43-128-1: Cookies/buckyball@search.msn[1].txt
r/r * 44-128-1: Cookies/buckyball@slashdot[1].txt
r/r * 45-128-1: Cookies/buckyball@sony.aol[2].txt
-/r * 112-128-4: My Documents/My Pictures/bandit-streetortrack2005056.jpg
-/r * 116-128-4: My Documents/My Pictures/fighterama2005-ban4.jpg
-/r * 81-128-4: My Documents/direct_attacks.doc
As of Sleuthkit version 3, the output of fls now shows content that
includes NTFS “orphan” files.20 Previous versions required the user to run an
additional command, ifind, on parent directories in order to recover orphan
files. The article in the footnote explains how this works.
The output above shows that our NTFS example file system holds 7
deleted files. Let's have a closer look at some NTFS specific information that
can be parsed with the Sleuthkit.
Have a look a the deleted file at MFT entry 112. The file is ./ My
Documents/My Pictures/banditstreetortrack2005056.
jpg . We can have a closer
look at the file's attributes by examining its MFT entry directly. We do this
through the istat tool. Recall that when we were working on an EXT file system
previously, the output of istat gave us information directly from the inode of
the specified file (see Sleuthkit Exercise #1). As we mentioned earlier, the
output of the Sleuthkit tools is specific to the file system being examined. So
let's run the command on MFT entry 112 in our current exercise:
root@bt:~/forensic# istat -o 59 ntfs_pract.dd 112
MFT Entry Header Values:
Entry: 112 Sequence: 2
$LogFile Sequence Number: 4201668
Not Allocated File
Links: 2
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 259 ()
Created: Sat Apr 7 11:52:53 2007
File Modified: Sat Oct 14 21:37:13 2006
MFT Modified: Sat Apr 7 11:52:53 2007
Accessed: Sun Apr 8 07:00:04 2007
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-3) Name: N/A Resident size: 90
Type: $FILE_NAME (48-2) Name: N/A Resident size: 128
Type: $DATA (128-4) Name: N/A Non-Resident size: 112063 init_size: 112063
60533 60534 60535 60536 60537 60538 60539 60540
60541 60542 60543 60544 60545 60546 60547 60548
60549 60550 60551 60552 60553 60554 60555 60556
60557 60558 60559 60560
The information istat provides us from the MFT shows values directly
from the $STANDARD_INFORMATION attribute (which contains the basic
meta data for a file), the $FILE_NAME attribute and basic information for other
attributes that are part of an MFT entry. The data blocks that contain the
actual file content are listed at the bottom of the output (for NonResident
data).
Take note of the fact that there are two separate attribute identifiers for
the $FILE_NAME attribute, 483
and 482.
It is interesting to note we can
access the contents of each attribute separately using the icat command.
The two attributes store the DOS (8.3) filename and the Win32 (long) file
name. By piping the output of icat to xxd we can see the difference. By itself,
this may not be of much investigative interest, but again we are illustrating the
capabilities of the Sleuthkit tools.
Note the difference in output between the attribute identifiers 112-48-3
and 112-48-2:
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112-48-3 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 0c02 4200 4100 4e00 4400 4900 5400 7e00 ..B.A.N.D.I.T.~.
0000050: 3100 2e00 4a00 5000 4700 1...J.P.G.
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112-48-2 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 1f01 6200 6100 6e00 6400 6900 7400 2d00 ..b.a.n.d.i.t.-.
0000050: 7300 7400 7200 6500 6500 7400 6f00 7200 s.t.r.e.e.t.o.r.
0000060: 7400 7200 6100 6300 6b00 3200 3000 3000 t.r.a.c.k.2.0.0.
0000070: 3500 3000 3500 3600 2e00 6a00 7000 6700 5.0.5.6...j.p.g.
The same idea is extended to other attributes of a file, most notably the
“Alternate Data Streams” or ADS. By showing us the existence of multiple
attribute identifiers for a given file, the Sleuthkit gives us a way of detecting
potentially hidden data. We cover this in our next exercise.
NTFS Examination: ADS
First, to see what we are discussing here, in case the reader is not
familiar with alternate data streams, we should compare the output of a normal
file listing with that obtained through a forensic utility.
Obviously, when examining a system, it may be useful to get a look at all
of the files contained in an image. We can do this two ways. The first way
would be to simply mount our image with the loop back device and get a file
listing. We will do this to compare a method using standard command line
utilities that we used in the past with a method using the Sleuthkit tools.
Remember that the mount command works on file systems, not disks.
The file system in this image starts 59 sectors into the image, so we mount
using an offset. We can then obtain a simple list of files using the find
command:
root@bt:~/forensic# mount -t ntfs -o ro,loop,offset=30208 ntfs_pract.dd /mnt/analysis/
root@bt:~/forensic# cd /mnt/analysis/
root@bt:/mnt/analysis# find . -type f
./Cookies/buckyball@ad.yieldmanager[1].txt
./Cookies/buckyball@adopt.specificclick[2].txt
./Cookies/buckyball@ads.as4x.tmcs[1].txt
./Cookies/index.dat
./Desktop/dtrsetup.exe
./Favorites/MSN.com.url
./Favorites/StreetFighter Accessories - StreetFighter and Sportbike accessories. One stop shopping for StreetFighters.url
./Favorites/Two Brothers Racing.url
./My Documents/amstra~1
./My Documents/My Pictures/b45ac806a965017dd71e3382581c47f3_refined.jpg
./My Documents/My Pictures/bankor1.jpg
./NTUSER.DAT
./SVstunts.avi
root@bt:/mnt/analysis# file /mnt/analysis/SVstunts.avi
/mnt/analysis/SVstunts.avi: RIFF (little-endian) data, AVI, 160 x 120, 15.00 fps, video: Cinepak
root@bt:/mnt/analysis# cd
root@bt:~# cd /root/forensic/
root@bt:~/forensic# file /m
media/ mnt/
root@bt:~/forensic# file /mnt/analysis/SVstunts.avi
/mnt/analysis/SVstunts.avi: RIFF (little-endian) data, AVI, 160 x 120, 15.00 fps, video: Cinepak
root@bt:~/forensic# fls -Fr -o 59 -f ntfs_pract.dd
Unsupported file system type: ntfs_pract.dd
usage: fls [-adDFlpruvV] [-f fstype] [-i imgtype] [-b dev_sector_size] [-m dir/] [-o imgoffset] [-z ZONE] [-s seconds] image [images] [inode]
If [inode] is not given, the root directory is used
-a: Display "." and ".." entries
-d: Display deleted entries only
-D: Display only directories
-F: Display only files
-l: Display long version (like ls -l)
-i imgtype: Format of image file (use '-i list' for supported types)
-b dev_sector_size: The size (in bytes) of the device sectors
-f fstype: File system type (use '-f list' for supported types)
-m: Display output in mactime input format with
dir/ as the actual mount point of the image
-o imgoffset: Offset into image file (in sectors)
-p: Display full path for each file
-r: Recurse on directory entries
-u: Display undeleted entries only
-v: verbose output to stderr
-V: Print version
-z: Time zone of original machine (i.e. EST5EDT or GMT) (only useful with -l)
-s seconds: Time skew of original machine (in seconds) (only useful with -l & -m)
Now let's try another method of obtaining a file list. Since this is a
forensic examination, let's use a forensic tool to give us a list of files. We will
use the fls command with the -F option to show only files, and the -r
option to recurse through directories (starting from the root directory, by default). The “...” signifies removed output for brevity :
root@bt:~/forensic# fls -Fr -o 59 -f ntfs ntfs_pract.dd
r/r 4-128-4: $AttrDef
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-11: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
r/r 36-128-1: Cookies/buckyball@as-eu.falkag[2].txt
r/r 30-128-1: Cookies/buckyball@2o7[1].txt
r/r 31-128-1: Cookies/buckyball@ad.yieldmanager[1].txt
r/r 32-128-4: Cookies/buckyball@adopt.specificclick[2].txt
r/r 28-128-3: Desktop/dtrsetup.exe
r/r 74-128-4: My Documents/anon-mail.txt
Both entries have the same MFT record number and are identified as file
data (137128) but the attribute identifier increments by one (1371283
and 1371284) 22. This is an example of an “Alternate Data Stream” (ADS).
Accessing the standard contents (1371283)
of SVstunts.avi is easy, since it is
an allocated file. However, we can access either data stream, the normal data or the ADS, by using the Sleuthkit command icat, much as we did with the two file name types in our previous exercise. We simply call icat with the complete MFT record entry, to include the alternate attribute identifier. To view the contents of the ADS (1371284):
root@bt:~/forensic# icat -o 59 -f ntfs ntfs_pract.dd 137-128-4
<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>
/|| ||\
\|| P R O F E S S O R F A L K E N ' S ||/
/|| ||\
\|| GUIDE TO ||/
/|| ||\
\|| ***** ***** **** ***** ||/
/|| * * * * * * * ||\
\|| * * * * * ***** ||/
/|| * * * * * * * ||\
\|| ***** ***** **** ***** ||/
/|| P { ||\
\|| ||/
/|| HACKING SECURITY ||\
\|| (C)1988||/
<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>
First I'd like to thank the following people for thier contributions to this
file and to my knowledge about this fucking world--=-> Frye Guy, Laser,
David Lightman, HackerSoft in it's entirety, The Rebel, Digital Logic,
L.E. Pirate, Brain Tumor, Boris Crack, Mad Max, Sike III, The Blade,
Spartacus, Baby Eagle, Iceman/TOPGUN, Spam Master, & Codebuster.
This file is meant for the beginner/novice/amateur code hacker. Anyone
have been hacking for over 2 years you probably don't need to read.
The first thing I would like to point out is the major LD companies security
systems. A couple years ago MCI and SPRINT installed a NEW type of ESS
which makes it easier to catch code hacks. This system is able to detect
patterns on it's ports, such as one target number being repeated many times or
invalid codes repeating every x number of minutes. They thought they were
smart, but we just have to be a step smarter.
MULTIPLE PORTS-->
By having a code hacker that uses multiple port hacking ( that is one that
can hack many ports in one session ) you can lower the odds of being caught
tremendously. By entering many ports into the hackers database and being able
to access them all in one session reduces the LD Co's ability to catch a
pattern on one of their port/s. With this feature you are able to throw the LD
company off WHERE and WHEN you will strike next. ALSO SEE TIMING PATTERNS.
MULTIPLE TARGETS-->
The first of the (IBM) programs to have multiple targets was Terminus's
Codebuster, it was then implemented into The Brew Associate's Code Thief. By
utilizing a program's multiple target option, the chances you being caught by
their system's pattern detection is almost NIL. Code Thief's multiple target
file contains 369 targets. If you cannot get this target list I suggest you
compile a list of TELENET,COMPUSERVE, etc. dial ups and use them for targets.
At least you'll have a better chance...
PORT PATTERNS & TIMING PATTERNS-->
Long distance companies like SPRINT/MCI usually have more than 1 port in
large cities/areacodes, thus you can hack on many of their ports. Increasing
the number of ports you hack on gives you an edge. The LD's system will get
suspicious if it finds many invalid codes attempts on one of its port. Each
port is allotted a certain amount of invalid codes attempts. If this number is
exceeded an error flag will go on and the security division will be alerted to
the port. So in other words by increasing the ports you can decrease your odds
of being alerted to and ANI'ed.
As mentioned before the LD companies also have timing pattern recognition.
This means they can tell if they are getting an invalid code attempt every
x minutes. This really is the most deadly features of their system ( next to
ANI of course ) because almost every hacker I know of runs on a set amount of
time for each thing to happen. Carrier timeout,seconds to wait till code &
target are entered, all of these are on a fixed amount of time. Every so many
number of seconds the hacker repeats its invalid code timeout & retry time
almost exactly. To get rid of this deadly feature is QUITE simple.
What I suggest is to add another port or two to your list. However, this port
is special because its not a port at all. It's a friend you hate or a
disconnected number or some business. That way your timing for the LD's ports
will not stay predictable. Also vary the carrier timeout value ( a.k.a.
timeout value ) for the fake port numbers. Doing this will make you about as
unpredictable as nitroglycerine made from a T-File.
TIMES TO HACK-->
When I first started code hacking 84' I thought the best time to hack was
at 2 a.m. because there wouldn't be anybody at the L.D. company then. Well
maybe back then there wasn't because there wasn't any customer service after
6pm. But the times have changed. There is security and customer service and
maintenance there 24 hours a day 7 days a week- Even Holidays. So the best
time to hack would be when normal customers are using it. Most customers are
either business's or households. So your best bet would be hacking when they
would use it- M-F 8am to 7pm. This is when most people accidently fuck-up on
their code and thus it is the best time to hack. I would suggest hacking in
the morning since the LD's system is counting the number of invalid attempts
if you do a lot in the morning then the subscribers in the afternoon will get
get evil eye, not you. Usually the LD companies system RESETS its value at
12:00 midnight so that the invalid attempt numbers don't keep adding on the
the previous days. Also hacking on holidays such as Christmas is excellent
because the amount of people calling everyone all over the fucking place is
magnanimous.
IBM HACK PROGRAMS-->
I have an IBM and I use Code Thief Version 2.2 which can be found on almost
any good phreak/pirate BBS around. Most of the code hacker's I have run into
either didn't work on my system because 1> The programmer didn't BETA test the
program totally. 2> The programmer didn't know what the fuck he was doing.
3> The program had so little features that you're bound to be caught using it.
The best program I've found was Code Thief Version 2.2 I have looked over:
Fuckin Hacker 2.0- It didn't work properly on IBM PC (Possibly fucked ARC)
All-In-One Hacker- Not enough features/Parts of program fucked up.
Codebuster- Couldn't get it to work with my modem ( HAYES 1200B )
AutoHack- Not enough features.
NEW PRODUCTS-->
Be on the look out for INTEL-Hack. This hacker is somewhat secret right now,
but I'll tell you it will have all the features of Code Thief but it will take
advantage of the 80386's multitasking capabilities. Lookout it should be
killer, release date: Not yet planned, 89' sometime.
Later, and I hope this shed some insight on how to keep yourself safe...- Professor Falken
root@bt:~/forensic# mkdir sort_out
root@bt:~/forensic# sorter -d ./sort_out -md5 -h -s -o 59 -f ntfs ntfs_pract.dd
Analyzing "ntfs_pract.dd"
Loading Allocated File Listing
Processing 133 Allocated Files and Directories
100%
All files have been saved to: ./sort_out
root@bt:~/forensic# ls sort_out/
archive audio.html disk documents.html images mismatch.html text
archive.html data disk.html exec images.html system text.html
audio data.html documents exec.html index.html system.html unknown.html
Look in the file :
Signature Search in Unallocated Space
Now let's do the same sort of unallocated analysis we did in Exercise #3,
but this time instead of searching for text data, we will look for file signatures.
This will give us an opportunity to introduce another useful Sleuthkit tool,
sigfind.
For this particular exercise, we'll use the NTFS image we used
previously, ntfs_pract.dd. Change to the directory containing that image and
let's begin.
As always, we start with mmls to help us identify the offset of the file
system within the image that we are interested in :
root@bt:~# cd /root/forensic/
root@bt:~/forensic# ls
evid ntfs_pract.dd Rby sort_out
root@bt:~/forensic# mmls ntfs_pract.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000058 0000000059 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated
Here we want to study the unallocated data from the NTFS file system at
sector offset 59. So we issue our blkls command and redirect the output to
another file:
root@bt:~/forensic# blk
blkcalc blkcat blkid blkls blkstat
root@bt:~/forensic# blkls -o 59 ntfs_pract.dd > ntfs_pract.blkls
root@bt:~/forensic# ls -lh
total 978M
drwxr-xr-x 2 root root 4.0K 2012-10-31 00:07 evid
-rw-r--r-- 1 root root 478M 2012-11-01 23:52 ntfs_pract.blkls
-rwxr-xr-x 1 root root 500M 2007-10-23 01:28 ntfs_pract.dd
drwxr-xr-x 2 root root 4.0K 2012-10-31 17:16 Rby
drwxr-xr-x 11 root root 4.0K 2012-11-01 21:39 sort_out
Once again, the output file is arbitrarily named. I give it a .blkls
extension for the sake of simplicity. Now, let's go ahead and search the
unallocated image we created for JPEG images. We use these JPEG picture files
for our example because most experienced forensic examiners are familiar with
the signatures.
For example, the man page for sigfind gives the example of searching for
a boot sector signature with the command:
root@bt:~/forensic# sigfind -o 510 -l AA55 ntfs_pract.dd
Block size: 512 Offset: 510 Signature: 55AA
Block: 0 (-)
Block: 59 (+59)
Block: 492076 (+492017)
Block: 1023059 (+530983)
error reading bytes 1024000
In this case, the block size is the default 512 (no -b
option is given). The -o 510 tells sigfind to look for the signature 510 bytes into every sector it searches.
The loption refers to the endian ordering of the signature.
Back to our exercise at hand...We must also keep in mind that sigfind
takes hex as it's signature string, so unlike grep, we cannot simply search for
“JFIF”. We need to convert the ASCII string to hex. This is easily done by
echoing the string to xxd with the p
option (continuous or “plain” dump):
root@bt:~/forensic# echo -n JFIF | xxd -p
4a464946
Also note in the above command, we use the n
option to echo to
prevent a newline character from being passed to xxd as well. The hex
signature we are going to search for is 4A464946 (“JFIF”).
We can now do our sigfind command.
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.dd
Block size: 4096 Offset: 6 Signature: 4A464946
error reading bytes 128000
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.blkls
Block size: 4096 Offset: 6 Signature: 4A464946
Block: 57539 (-)
Block: 57582 (+43)
error reading bytes 122238
The command above sows us running sigfind with a block size (-b)
of 4096 (from fsstat output), an offset (-o)
of 6, and a signature of 4A464946 on the extracted unallocated space ntfs_pract.blkls.
As you can see, we come up with two hits. Now we use the blkcalc
command to determine the block address of the unallocated block in the
original image:
root@bt:~/forensic# blkcalc -o 59 -u 57539 ntfs_pract.dd
60533
Above, we called blkcalc with u
57539 to indicate that we are passing an address from an unallocated image provided by blkls. The file system this unallocated block was extracted from is in our ntfs_pract.dd image at sector offset 59. The result shows us that unallocated block 57539 in our blkls image maps to data block 60533 in the original file system.
Now that we have the data block (60533) in the original file system, we
can use ifind to identify the meta data structure that is assigned to that data
block. In this case the meta data structure is an MFT entry, since we are
working with an NTFS file system:
root@bt:~/forensic# ifind -o 59 -d 60533 ntfs_pract.dd
112-128-4
The MFT entry is 1121284 or simply 112 (The 1284 portion denotes
the $DATA attribute identifier). We can use ffind to determine the file name
that holds (or held) that particular MFT entry. Be very careful of interpretation here. As always, you need to have a firm grip on how the file system works before deciding that the information being presented is accurate, depending on the file system being examined.
root@bt:~/forensic# ffind -o 59 ntfs_pract.dd 112
* /My Documents/My Pictures/bandit-streetortrack2005056.jpg
Recovering the deleted file using icat and piping the results to the file
command indicates that we have found a JPEG image, which the previous ffind command indicated may have been called banditstreetortrack2005056.
jpg.
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112 | file-
No command 'file-' found, did you mean:
Command 'file2' from package 'file-kanji' (universe)
Command 'filep' from package 'mp' (universe)
Command 'file' from package 'file' (main)
file-: command not found
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112 | file -
/dev/stdin: JPEG image data, JFIF standard 1.02
Recall now our original sigfind output:
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.blkls
Block size: 4096 Offset: 6 Signature: 4A464946
Block: 57539 (-)
Block: 57582 (+43)
root@bt:~/forensic# blkcalc -u 57582 -o 59 ntfs_pract.dd
60662
root@bt:~/forensic# ifind -o 59 -d 60662 ntfs_pract.dd
116-128-4
root@bt:~/forensic# ffind -o 59 ntfs_pract.dd 116
* /My Documents/My Pictures/fighterama2005-ban4.jpg
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 116 | file -
/dev/stdin: JPEG image data, JFIF standard 1.01
We have another JPEG, this one at MFT entry 116, and named
fighterama2005ban4.jpg.
We can actually recover both files by using icat and redirecting to new
files. I've named the files by their MFT entry and the .jpg extension, since the file command confirmed that's what they are :
root@bt:~/forensic# icat -o ntfs_pract.dd 112 > 112.jpg
Invalid image offset (tsk_parse: invalid image offset: ntfs_pract.dd)
root@bt:~/forensic# icat -o ntfs_pract.dd 116 > 116.jpg
Invalid image offset (tsk_parse: invalid image offset: ntfs_pract.dd)
You can now view the files with any graphics viewer you might have
available. For example, you can use the display command
root@bt:~/forensic# display 112.jpg
display: Empty input file `112.jpg' @ jpeg.c/EmitMessage/232.
called /root/ntfs_pract/ and place the file in there. First, we will decompress the
gzipped file using the gzip command we learned earlier and check its SHA1
hash:
root@bt:~# cd /root/forensic/
root@bt:~/forensic# ls
ntfs_pract.dd
root@bt:~/forensic# sha1sum ntfs_pract.dd
0cbce7666c8db70377cb5fc2abf9268821b6dafe ntfs_pract.dd
Now we will run through a series of basic Sleuthkit commands as we
would in any analysis. The structure of the forensic image is viewed using
mmls:
root@bt:~/forensic# mmls ntfs_pract.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000058 0000000059 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated
The output shows that an NTFS partition (and most likely the file
system) begins at sector offset 59. This is the offset we will use in all our
Sleuthkit commands. We now use fsstat to have a look at the file system
statistics inside that partition:
root@bt:~/forensic# fsstat -o 59 -f ntfs ntfs_pract.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: E4D06402D063D8F6
OEM Name: NTFS
Volume Name: NEW VOLUME
Version: Windows XP
METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 42625
First Cluster of MFT Mirror: 63937
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 144
Root Directory: 5
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 127874
Total Sector Range: 0 - 1022999
Looking at the fsstat output on our NTFS file system, we see it differs
greatly from the output we saw running on a Linux EXT file system. The tool is
designed to provide pertinent information based on the file system being
targeted. Notice that when run on an NTFS file system, fsstat provides us with
information specific to NTFS, including data about the Master File Table (MFT)
and specific attribute values.
We will now have a look at how the Sleuthkit interacts with active and
deleted files on an NTFS file system, given the structure of MFT entries.
Let's begin this exercise with the output of fls. We can specify that fls
only show us only “deleted” content on the command line with the d
option.
We will use F
(only file entries) and r
(recursive) as well:
root@bt:~/forensic# fls -Frd -o 59 ntfs_pract.dd
r/r * 42-128-1: Cookies/buckyball@revsci[2].txt
r/r * 43-128-1: Cookies/buckyball@search.msn[1].txt
r/r * 44-128-1: Cookies/buckyball@slashdot[1].txt
r/r * 45-128-1: Cookies/buckyball@sony.aol[2].txt
-/r * 112-128-4: My Documents/My Pictures/bandit-streetortrack2005056.jpg
-/r * 116-128-4: My Documents/My Pictures/fighterama2005-ban4.jpg
-/r * 81-128-4: My Documents/direct_attacks.doc
As of Sleuthkit version 3, the output of fls now shows content that
includes NTFS “orphan” files.20 Previous versions required the user to run an
additional command, ifind, on parent directories in order to recover orphan
files. The article in the footnote explains how this works.
The output above shows that our NTFS example file system holds 7
deleted files. Let's have a closer look at some NTFS specific information that
can be parsed with the Sleuthkit.
Have a look a the deleted file at MFT entry 112. The file is ./ My
Documents/My Pictures/banditstreetortrack2005056.
jpg . We can have a closer
look at the file's attributes by examining its MFT entry directly. We do this
through the istat tool. Recall that when we were working on an EXT file system
previously, the output of istat gave us information directly from the inode of
the specified file (see Sleuthkit Exercise #1). As we mentioned earlier, the
output of the Sleuthkit tools is specific to the file system being examined. So
let's run the command on MFT entry 112 in our current exercise:
root@bt:~/forensic# istat -o 59 ntfs_pract.dd 112
MFT Entry Header Values:
Entry: 112 Sequence: 2
$LogFile Sequence Number: 4201668
Not Allocated File
Links: 2
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 259 ()
Created: Sat Apr 7 11:52:53 2007
File Modified: Sat Oct 14 21:37:13 2006
MFT Modified: Sat Apr 7 11:52:53 2007
Accessed: Sun Apr 8 07:00:04 2007
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-3) Name: N/A Resident size: 90
Type: $FILE_NAME (48-2) Name: N/A Resident size: 128
Type: $DATA (128-4) Name: N/A Non-Resident size: 112063 init_size: 112063
60533 60534 60535 60536 60537 60538 60539 60540
60541 60542 60543 60544 60545 60546 60547 60548
60549 60550 60551 60552 60553 60554 60555 60556
60557 60558 60559 60560
The information istat provides us from the MFT shows values directly
from the $STANDARD_INFORMATION attribute (which contains the basic
meta data for a file), the $FILE_NAME attribute and basic information for other
attributes that are part of an MFT entry. The data blocks that contain the
actual file content are listed at the bottom of the output (for NonResident
data).
Take note of the fact that there are two separate attribute identifiers for
the $FILE_NAME attribute, 483
and 482.
It is interesting to note we can
access the contents of each attribute separately using the icat command.
The two attributes store the DOS (8.3) filename and the Win32 (long) file
name. By piping the output of icat to xxd we can see the difference. By itself,
this may not be of much investigative interest, but again we are illustrating the
capabilities of the Sleuthkit tools.
Note the difference in output between the attribute identifiers 112-48-3
and 112-48-2:
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112-48-3 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 0c02 4200 4100 4e00 4400 4900 5400 7e00 ..B.A.N.D.I.T.~.
0000050: 3100 2e00 4a00 5000 4700 1...J.P.G.
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112-48-2 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 1f01 6200 6100 6e00 6400 6900 7400 2d00 ..b.a.n.d.i.t.-.
0000050: 7300 7400 7200 6500 6500 7400 6f00 7200 s.t.r.e.e.t.o.r.
0000060: 7400 7200 6100 6300 6b00 3200 3000 3000 t.r.a.c.k.2.0.0.
0000070: 3500 3000 3500 3600 2e00 6a00 7000 6700 5.0.5.6...j.p.g.
The same idea is extended to other attributes of a file, most notably the
“Alternate Data Streams” or ADS. By showing us the existence of multiple
attribute identifiers for a given file, the Sleuthkit gives us a way of detecting
potentially hidden data. We cover this in our next exercise.
NTFS Examination: ADS
First, to see what we are discussing here, in case the reader is not
familiar with alternate data streams, we should compare the output of a normal
file listing with that obtained through a forensic utility.
Obviously, when examining a system, it may be useful to get a look at all
of the files contained in an image. We can do this two ways. The first way
would be to simply mount our image with the loop back device and get a file
listing. We will do this to compare a method using standard command line
utilities that we used in the past with a method using the Sleuthkit tools.
Remember that the mount command works on file systems, not disks.
The file system in this image starts 59 sectors into the image, so we mount
using an offset. We can then obtain a simple list of files using the find
command:
root@bt:~/forensic# mount -t ntfs -o ro,loop,offset=30208 ntfs_pract.dd /mnt/analysis/
root@bt:~/forensic# cd /mnt/analysis/
root@bt:/mnt/analysis# find . -type f
./Cookies/buckyball@ad.yieldmanager[1].txt
./Cookies/buckyball@adopt.specificclick[2].txt
./Cookies/buckyball@ads.as4x.tmcs[1].txt
./Cookies/index.dat
./Desktop/dtrsetup.exe
./Favorites/MSN.com.url
./Favorites/StreetFighter Accessories - StreetFighter and Sportbike accessories. One stop shopping for StreetFighters.url
./Favorites/Two Brothers Racing.url
./My Documents/amstra~1
./My Documents/My Pictures/b45ac806a965017dd71e3382581c47f3_refined.jpg
./My Documents/My Pictures/bankor1.jpg
./NTUSER.DAT
./SVstunts.avi
root@bt:/mnt/analysis# file /mnt/analysis/SVstunts.avi
/mnt/analysis/SVstunts.avi: RIFF (little-endian) data, AVI, 160 x 120, 15.00 fps, video: Cinepak
root@bt:/mnt/analysis# cd
root@bt:~# cd /root/forensic/
root@bt:~/forensic# file /m
media/ mnt/
root@bt:~/forensic# file /mnt/analysis/SVstunts.avi
/mnt/analysis/SVstunts.avi: RIFF (little-endian) data, AVI, 160 x 120, 15.00 fps, video: Cinepak
root@bt:~/forensic# fls -Fr -o 59 -f ntfs_pract.dd
Unsupported file system type: ntfs_pract.dd
usage: fls [-adDFlpruvV] [-f fstype] [-i imgtype] [-b dev_sector_size] [-m dir/] [-o imgoffset] [-z ZONE] [-s seconds] image [images] [inode]
If [inode] is not given, the root directory is used
-a: Display "." and ".." entries
-d: Display deleted entries only
-D: Display only directories
-F: Display only files
-l: Display long version (like ls -l)
-i imgtype: Format of image file (use '-i list' for supported types)
-b dev_sector_size: The size (in bytes) of the device sectors
-f fstype: File system type (use '-f list' for supported types)
-m: Display output in mactime input format with
dir/ as the actual mount point of the image
-o imgoffset: Offset into image file (in sectors)
-p: Display full path for each file
-r: Recurse on directory entries
-u: Display undeleted entries only
-v: verbose output to stderr
-V: Print version
-z: Time zone of original machine (i.e. EST5EDT or GMT) (only useful with -l)
-s seconds: Time skew of original machine (in seconds) (only useful with -l & -m)
Now let's try another method of obtaining a file list. Since this is a
forensic examination, let's use a forensic tool to give us a list of files. We will
use the fls command with the -F option to show only files, and the -r
option to recurse through directories (starting from the root directory, by default). The “...” signifies removed output for brevity :
root@bt:~/forensic# fls -Fr -o 59 -f ntfs ntfs_pract.dd
r/r 4-128-4: $AttrDef
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-11: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
r/r 36-128-1: Cookies/buckyball@as-eu.falkag[2].txt
r/r 30-128-1: Cookies/buckyball@2o7[1].txt
r/r 31-128-1: Cookies/buckyball@ad.yieldmanager[1].txt
r/r 32-128-4: Cookies/buckyball@adopt.specificclick[2].txt
r/r 28-128-3: Desktop/dtrsetup.exe
r/r 74-128-4: My Documents/anon-mail.txt
Both entries have the same MFT record number and are identified as file
data (137128) but the attribute identifier increments by one (1371283
and 1371284) 22. This is an example of an “Alternate Data Stream” (ADS).
Accessing the standard contents (1371283)
of SVstunts.avi is easy, since it is
an allocated file. However, we can access either data stream, the normal data or the ADS, by using the Sleuthkit command icat, much as we did with the two file name types in our previous exercise. We simply call icat with the complete MFT record entry, to include the alternate attribute identifier. To view the contents of the ADS (1371284):
root@bt:~/forensic# icat -o 59 -f ntfs ntfs_pract.dd 137-128-4
<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>
/|| ||\
\|| P R O F E S S O R F A L K E N ' S ||/
/|| ||\
\|| GUIDE TO ||/
/|| ||\
\|| ***** ***** **** ***** ||/
/|| * * * * * * * ||\
\|| * * * * * ***** ||/
/|| * * * * * * * ||\
\|| ***** ***** **** ***** ||/
/|| P { ||\
\|| ||/
/|| HACKING SECURITY ||\
\|| (C)1988||/
<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>-<()>
First I'd like to thank the following people for thier contributions to this
file and to my knowledge about this fucking world--=-> Frye Guy, Laser,
David Lightman, HackerSoft in it's entirety, The Rebel, Digital Logic,
L.E. Pirate, Brain Tumor, Boris Crack, Mad Max, Sike III, The Blade,
Spartacus, Baby Eagle, Iceman/TOPGUN, Spam Master, & Codebuster.
This file is meant for the beginner/novice/amateur code hacker. Anyone
have been hacking for over 2 years you probably don't need to read.
The first thing I would like to point out is the major LD companies security
systems. A couple years ago MCI and SPRINT installed a NEW type of ESS
which makes it easier to catch code hacks. This system is able to detect
patterns on it's ports, such as one target number being repeated many times or
invalid codes repeating every x number of minutes. They thought they were
smart, but we just have to be a step smarter.
MULTIPLE PORTS-->
By having a code hacker that uses multiple port hacking ( that is one that
can hack many ports in one session ) you can lower the odds of being caught
tremendously. By entering many ports into the hackers database and being able
to access them all in one session reduces the LD Co's ability to catch a
pattern on one of their port/s. With this feature you are able to throw the LD
company off WHERE and WHEN you will strike next. ALSO SEE TIMING PATTERNS.
MULTIPLE TARGETS-->
The first of the (IBM) programs to have multiple targets was Terminus's
Codebuster, it was then implemented into The Brew Associate's Code Thief. By
utilizing a program's multiple target option, the chances you being caught by
their system's pattern detection is almost NIL. Code Thief's multiple target
file contains 369 targets. If you cannot get this target list I suggest you
compile a list of TELENET,COMPUSERVE, etc. dial ups and use them for targets.
At least you'll have a better chance...
PORT PATTERNS & TIMING PATTERNS-->
Long distance companies like SPRINT/MCI usually have more than 1 port in
large cities/areacodes, thus you can hack on many of their ports. Increasing
the number of ports you hack on gives you an edge. The LD's system will get
suspicious if it finds many invalid codes attempts on one of its port. Each
port is allotted a certain amount of invalid codes attempts. If this number is
exceeded an error flag will go on and the security division will be alerted to
the port. So in other words by increasing the ports you can decrease your odds
of being alerted to and ANI'ed.
As mentioned before the LD companies also have timing pattern recognition.
This means they can tell if they are getting an invalid code attempt every
x minutes. This really is the most deadly features of their system ( next to
ANI of course ) because almost every hacker I know of runs on a set amount of
time for each thing to happen. Carrier timeout,seconds to wait till code &
target are entered, all of these are on a fixed amount of time. Every so many
number of seconds the hacker repeats its invalid code timeout & retry time
almost exactly. To get rid of this deadly feature is QUITE simple.
What I suggest is to add another port or two to your list. However, this port
is special because its not a port at all. It's a friend you hate or a
disconnected number or some business. That way your timing for the LD's ports
will not stay predictable. Also vary the carrier timeout value ( a.k.a.
timeout value ) for the fake port numbers. Doing this will make you about as
unpredictable as nitroglycerine made from a T-File.
TIMES TO HACK-->
When I first started code hacking 84' I thought the best time to hack was
at 2 a.m. because there wouldn't be anybody at the L.D. company then. Well
maybe back then there wasn't because there wasn't any customer service after
6pm. But the times have changed. There is security and customer service and
maintenance there 24 hours a day 7 days a week- Even Holidays. So the best
time to hack would be when normal customers are using it. Most customers are
either business's or households. So your best bet would be hacking when they
would use it- M-F 8am to 7pm. This is when most people accidently fuck-up on
their code and thus it is the best time to hack. I would suggest hacking in
the morning since the LD's system is counting the number of invalid attempts
if you do a lot in the morning then the subscribers in the afternoon will get
get evil eye, not you. Usually the LD companies system RESETS its value at
12:00 midnight so that the invalid attempt numbers don't keep adding on the
the previous days. Also hacking on holidays such as Christmas is excellent
because the amount of people calling everyone all over the fucking place is
magnanimous.
IBM HACK PROGRAMS-->
I have an IBM and I use Code Thief Version 2.2 which can be found on almost
any good phreak/pirate BBS around. Most of the code hacker's I have run into
either didn't work on my system because 1> The programmer didn't BETA test the
program totally. 2> The programmer didn't know what the fuck he was doing.
3> The program had so little features that you're bound to be caught using it.
The best program I've found was Code Thief Version 2.2 I have looked over:
Fuckin Hacker 2.0- It didn't work properly on IBM PC (Possibly fucked ARC)
All-In-One Hacker- Not enough features/Parts of program fucked up.
Codebuster- Couldn't get it to work with my modem ( HAYES 1200B )
AutoHack- Not enough features.
NEW PRODUCTS-->
Be on the look out for INTEL-Hack. This hacker is somewhat secret right now,
but I'll tell you it will have all the features of Code Thief but it will take
advantage of the 80386's multitasking capabilities. Lookout it should be
killer, release date: Not yet planned, 89' sometime.
Later, and I hope this shed some insight on how to keep yourself safe...- Professor Falken
root@bt:~/forensic# mkdir sort_out
root@bt:~/forensic# sorter -d ./sort_out -md5 -h -s -o 59 -f ntfs ntfs_pract.dd
Analyzing "ntfs_pract.dd"
Loading Allocated File Listing
Processing 133 Allocated Files and Directories
100%
All files have been saved to: ./sort_out
root@bt:~/forensic# ls sort_out/
archive audio.html disk documents.html images mismatch.html text
archive.html data disk.html exec images.html system text.html
audio data.html documents exec.html index.html system.html unknown.html
Look in the file :
Signature Search in Unallocated Space
Now let's do the same sort of unallocated analysis we did in Exercise #3,
but this time instead of searching for text data, we will look for file signatures.
This will give us an opportunity to introduce another useful Sleuthkit tool,
sigfind.
For this particular exercise, we'll use the NTFS image we used
previously, ntfs_pract.dd. Change to the directory containing that image and
let's begin.
As always, we start with mmls to help us identify the offset of the file
system within the image that we are interested in :
root@bt:~# cd /root/forensic/
root@bt:~/forensic# ls
evid ntfs_pract.dd Rby sort_out
root@bt:~/forensic# mmls ntfs_pract.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000058 0000000059 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated
Here we want to study the unallocated data from the NTFS file system at
sector offset 59. So we issue our blkls command and redirect the output to
another file:
root@bt:~/forensic# blk
blkcalc blkcat blkid blkls blkstat
root@bt:~/forensic# blkls -o 59 ntfs_pract.dd > ntfs_pract.blkls
root@bt:~/forensic# ls -lh
total 978M
drwxr-xr-x 2 root root 4.0K 2012-10-31 00:07 evid
-rw-r--r-- 1 root root 478M 2012-11-01 23:52 ntfs_pract.blkls
-rwxr-xr-x 1 root root 500M 2007-10-23 01:28 ntfs_pract.dd
drwxr-xr-x 2 root root 4.0K 2012-10-31 17:16 Rby
drwxr-xr-x 11 root root 4.0K 2012-11-01 21:39 sort_out
Once again, the output file is arbitrarily named. I give it a .blkls
extension for the sake of simplicity. Now, let's go ahead and search the
unallocated image we created for JPEG images. We use these JPEG picture files
for our example because most experienced forensic examiners are familiar with
the signatures.
For example, the man page for sigfind gives the example of searching for
a boot sector signature with the command:
root@bt:~/forensic# sigfind -o 510 -l AA55 ntfs_pract.dd
Block size: 512 Offset: 510 Signature: 55AA
Block: 0 (-)
Block: 59 (+59)
Block: 492076 (+492017)
Block: 1023059 (+530983)
error reading bytes 1024000
In this case, the block size is the default 512 (no -b
option is given). The -o 510 tells sigfind to look for the signature 510 bytes into every sector it searches.
The loption refers to the endian ordering of the signature.
Back to our exercise at hand...We must also keep in mind that sigfind
takes hex as it's signature string, so unlike grep, we cannot simply search for
“JFIF”. We need to convert the ASCII string to hex. This is easily done by
echoing the string to xxd with the p
option (continuous or “plain” dump):
root@bt:~/forensic# echo -n JFIF | xxd -p
4a464946
Also note in the above command, we use the n
option to echo to
prevent a newline character from being passed to xxd as well. The hex
signature we are going to search for is 4A464946 (“JFIF”).
We can now do our sigfind command.
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.dd
Block size: 4096 Offset: 6 Signature: 4A464946
error reading bytes 128000
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.blkls
Block size: 4096 Offset: 6 Signature: 4A464946
Block: 57539 (-)
Block: 57582 (+43)
error reading bytes 122238
The command above sows us running sigfind with a block size (-b)
of 4096 (from fsstat output), an offset (-o)
of 6, and a signature of 4A464946 on the extracted unallocated space ntfs_pract.blkls.
As you can see, we come up with two hits. Now we use the blkcalc
command to determine the block address of the unallocated block in the
original image:
root@bt:~/forensic# blkcalc -o 59 -u 57539 ntfs_pract.dd
60533
Above, we called blkcalc with u
57539 to indicate that we are passing an address from an unallocated image provided by blkls. The file system this unallocated block was extracted from is in our ntfs_pract.dd image at sector offset 59. The result shows us that unallocated block 57539 in our blkls image maps to data block 60533 in the original file system.
Now that we have the data block (60533) in the original file system, we
can use ifind to identify the meta data structure that is assigned to that data
block. In this case the meta data structure is an MFT entry, since we are
working with an NTFS file system:
root@bt:~/forensic# ifind -o 59 -d 60533 ntfs_pract.dd
112-128-4
The MFT entry is 1121284 or simply 112 (The 1284 portion denotes
the $DATA attribute identifier). We can use ffind to determine the file name
that holds (or held) that particular MFT entry. Be very careful of interpretation here. As always, you need to have a firm grip on how the file system works before deciding that the information being presented is accurate, depending on the file system being examined.
root@bt:~/forensic# ffind -o 59 ntfs_pract.dd 112
* /My Documents/My Pictures/bandit-streetortrack2005056.jpg
Recovering the deleted file using icat and piping the results to the file
command indicates that we have found a JPEG image, which the previous ffind command indicated may have been called banditstreetortrack2005056.
jpg.
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112 | file-
No command 'file-' found, did you mean:
Command 'file2' from package 'file-kanji' (universe)
Command 'filep' from package 'mp' (universe)
Command 'file' from package 'file' (main)
file-: command not found
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 112 | file -
/dev/stdin: JPEG image data, JFIF standard 1.02
Recall now our original sigfind output:
root@bt:~/forensic# sigfind -b 4096 -o 6 4A464946 ntfs_pract.blkls
Block size: 4096 Offset: 6 Signature: 4A464946
Block: 57539 (-)
Block: 57582 (+43)
root@bt:~/forensic# blkcalc -u 57582 -o 59 ntfs_pract.dd
60662
root@bt:~/forensic# ifind -o 59 -d 60662 ntfs_pract.dd
116-128-4
root@bt:~/forensic# ffind -o 59 ntfs_pract.dd 116
* /My Documents/My Pictures/fighterama2005-ban4.jpg
root@bt:~/forensic# icat -o 59 ntfs_pract.dd 116 | file -
/dev/stdin: JPEG image data, JFIF standard 1.01
We have another JPEG, this one at MFT entry 116, and named
fighterama2005ban4.jpg.
We can actually recover both files by using icat and redirecting to new
files. I've named the files by their MFT entry and the .jpg extension, since the file command confirmed that's what they are :
root@bt:~/forensic# icat -o ntfs_pract.dd 112 > 112.jpg
Invalid image offset (tsk_parse: invalid image offset: ntfs_pract.dd)
root@bt:~/forensic# icat -o ntfs_pract.dd 116 > 116.jpg
Invalid image offset (tsk_parse: invalid image offset: ntfs_pract.dd)
You can now view the files with any graphics viewer you might have
available. For example, you can use the display command
root@bt:~/forensic# display 112.jpg
display: Empty input file `112.jpg' @ jpeg.c/EmitMessage/232.
Wednesday, October 31, 2012
Sleuthkit Exercise
As the size of media being examined continues go grow, it is becoming
apparent to many investigators that data reduction techniques are more
important than ever. These techniques take on several forms, including hash
analysis (removing known"good' files from a data set, for example) and
separating allocated space in an image from unallocated space, allowing them
to be searched separately with specialized tools. we will be doing the latter
in this exercise.
The Sleuthkit comes with a set of tools for handling information at the
"block" layer of the analysis model. The block layer consists of the actual file
system block that hold the information we are seeking.
They are not specific to unallocate data only, but are especially useful for
working on unallocated blocks that have been exstracted from an image.
the tools that manipulate this layer, as you would expect, start with blk and include:
blkls
blkcalc
blkstat
blkcat
We will be focusing on blkls, blkcalc and blkstat for the nexs couple of exercise.
The tool that starts us off here is blkls. This command “lists all the data
blocks”. If you were to use the “-e” option, the output would be the same as
the output of dd for that volume, since -e tells blkls to copy “every block”.
However, by default, blkls will only copy out the unallocated blocks of an
image.
This allows us to separate allocated and unallocated blocks in our file
system. We can use logical tools (find, ls, etc.) on the “live” files in a mounted
file system, and concentrate data recovery efforts on only those blocks that
may contain deleted or otherwise unallocated data. Conversely, when we do a
physical search of the output of blkls, we can be sure that artifacts found are
from unallocated content.
To illustrate what we are talking about here, we'll run the same exercise
we did in Sleuthkit Exercise #2, this time extracting the unallocated data from
our volume of interest and comparing the output from the whole volume
analysis vs. unallocated analysis. So, we'll be working on the able2.dd image
from earlier. We expect to get the same results we did in Exercise #2, but this
time by analyzing only the unallocated space, and then associating the
recovered data with its original location in the full disk image.
First we'll need to change into the directory containing our able2.dd
image. Then we check the partition table and decide which volume we'll be
examining. Recall that this is where we get our -o (offset) value from for our
Sleuthkit commands. To do this, we run the mmls command :
example file the wish to identify :
root@bt:~# mkdir ~/Rby
mkdir: cannot create directory `/root/Rby': File exists
root@bt:~# cd ~/Rby
root@bt:~/Rby# mmls able2.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000056 0000000057 Unallocated
02: 00:00 0000000057 0000010259 0000010203 Linux (0x83)
03: 00:01 0000010260 0000112859 0000102600 Linux (0x83)
04: 00:02 0000112860 0000178694 0000065835 Linux Swap / Solaris x86 (0x82)
05: 00:03 0000178695 0000675449 0000496755 Linux (0x83)
As with Exercise #2, we've decided to search the unallocated space in the
second Linux partition (at offset 10260, in bold above).
We run the blkls command using the offset option (-o) which indicates
what partition's file system we are analyzing. We then redirect the output to a
new file that will contain only the unallocated blocks of that particular volume.
root@bt:~/Rby# blkls -o 10260 able2.dd > able2.blkls
root@bt:~/Rby# ls -lh
total 340M
-rw-r--r-- 1 root root 9.3M 2012-10-31 16:53 able2.blkls
-rwxrwxrwx 1 root root 330M 2012-10-23 18:38 able2.dd
In the above command, we are using blkls on the second partition (-o
10260) within the able2.dd image, and redirecting the output to a file called
able2.blkls. The file able2.blkls will contain only the unallocated blocks from
the target file system.
Now, as we did in our previous analysis of this file system (Exercise #2)
we will use grep, this time on the extracted unallocated space, our able2.blkls
file, to search for our text string of interest. Read back through Exercise #2 if
you need a refresher on these commands.
root@bt:~/Rby# grep -abi cybernetik able2.blkls
1631299: * updated by Cybernetik for linux rootkit
9317041:Cybernetik proudly presents...
9323055:Email: cybernetik@nym.alias.net
9323087:Finger: cybernetik@nym.alias.net
The grep command above now tells us that we have found the string
“cybernetik” at four different offsets in the extracted unallocated space. We
will concentrate on the first hit here. Of course these are different from the
offsets we found in Exercise #2 because we are no longer searching the entire
original dd image.
So the next obvious question is “so what?”. We found potential evidence
in our extracted unallocated space. But how does it relate to the original
image? As forensic examiners, merely finding potential evidence is not good
enough. We also need to know where it came from (physical location in the
original image), what file it belongs or (possibly) belonged to, meta data
associated with the file, and context. Finding potential evidence in a big block
of aggregate unallocated space is of little use to us if we cannot at least make
some effort at attribution in the original file system.
That's where the other block layer tools come in. We can use blkcalc to
calculate the location (by data block or fragment) in our original image. Once
we've done that, we simply use the meta data layer tools to identify and
potentially recover the original file, as we did in our previous effort.
First we need to gather a bit of data about the original file system. We
run the fsstat command to determine the size of the data blocks we are
working with.
root@bt:~/Rby# fsstat -o 10260 able2.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext2
Volume Name:
Volume ID: 906e777080e09488d0116064da18c0c4
Last Written at: Mon Aug 11 01:50:03 2003
Last Checked at: Tue Feb 11 12:20:09 1997
Last Mounted at: Thu Feb 13 14:33:02 1997
Unmounted Improperly
Last mounted on:
Source OS: Linux
Dynamic Structure
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super,
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 12881
Root Directory: 2
Free Inodes: 5807
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 51299
Block Size: 1024
Reserved Blocks Before Block Groups: 1
Free Blocks: 9512
BLOCK GROUP INFORMATION
--------------------------------------------
Number of Block Groups: 7
Inodes per group: 1840
Blocks per group: 8192
Group: 0:
Inode Range: 1 - 1840
Block Range: 1 - 8192
Layout:
Super Block: 1 - 1
Group Descriptor Table: 2 - 2
Data bitmap: 3 - 3
Inode bitmap: 4 - 4
Inode Table: 5 - 234
Data Blocks: 235 - 8192
Free Inodes: 789 (42%)
Free Blocks: 4601 (56%)
Total Directories: 16
Group: 1:
Inode Range: 1841 - 3680
Block Range: 8193 - 16384
Layout:
Super Block: 8193 - 8193
Group Descriptor Table: 8194 - 8194
Data bitmap: 8195 - 8195
Inode bitmap: 8196 - 8196
Inode Table: 8197 - 8426
Data Blocks: 8427 - 16384
Free Inodes: 1542 (83%)
Free Blocks: 33 (0%)
Total Directories: 13
Group: 2:
Inode Range: 3681 - 5520
Block Range: 16385 - 24576
Layout:
Data bitmap: 16385 - 16385
Inode bitmap: 16386 - 16386
Inode Table: 16389 - 16618
Data Blocks: 16387 - 16388, 16619 - 24576
Free Inodes: 0 (0%)
Free Blocks: 1813 (22%)
Total Directories: 12
Group: 3:
Inode Range: 5521 - 7360
Block Range: 24577 - 32768
Layout:
Super Block: 24577 - 24577
Group Descriptor Table: 24578 - 24578
Data bitmap: 24579 - 24579
Inode bitmap: 24580 - 24580
Inode Table: 24581 - 24810
Data Blocks: 24811 - 32768
Free Inodes: 746 (40%)
Free Blocks: 2379 (29%)
Total Directories: 76
Group: 4:
Inode Range: 7361 - 9200
Block Range: 32769 - 40960
Layout:
Data bitmap: 32769 - 32769
Inode bitmap: 32770 - 32770
Inode Table: 32773 - 33002
Data Blocks: 32771 - 32772, 33003 - 40960
Free Inodes: 0 (0%)
Free Blocks: 0 (0%)
Total Directories: 10
Group: 5:
Inode Range: 9201 - 11040
Block Range: 40961 - 49152
Layout:
Super Block: 40961 - 40961
Group Descriptor Table: 40962 - 40962
Data bitmap: 40963 - 40963
Inode bitmap: 40964 - 40964
Inode Table: 40965 - 41194
Data Blocks: 41195 - 49152
Free Inodes: 969 (52%)
Free Blocks: 545 (6%)
Total Directories: 4
Group: 6:
Inode Range: 11041 - 12880
Block Range: 49153 - 51299
Layout:
Data bitmap: 49153 - 49153
Inode bitmap: 49154 - 49154
Inode Table: 49157 - 49386
Data Blocks: 49155 - 49156, 49387 - 51299
Free Inodes: 1761 (176100%)
Free Blocks: 141 (6%)
Total Directories: 18
In the fsstat command above, we see that the block size (in bold) is 1024.
We take the offset from our grep output on the able2.blkls image and divide
that by 1024. This tells us how many unallocated data blocks into the
unallocated image we found our string of interest. We use the echo command
to pass the math expression to the command line calculator, bc:
root@bt:~/Rby# echo "1631299/1024" | bc
1593
We now know, from the above output, that the string “cybernetik” is in
data block 1593 of our extracted unallocated file, able2.blkls.
This is where our handy blkcalc command comes in. We use blkcalc
with the -u option to specify that we want to calculate the block address from
an extracted unallocated image (from blkls output). We run the command on
the original dd image because we are calculating the orginal data block in that
image.
root@bt:~/Rby# blkcalc -o 10260 -u 1593 able2.dd
5184
The command above is running blkcalc on the file system at offset
10260 (-o 10260) in the original able2.dd, passing the data block we calculated
from the blkls image able2.blkls (-u 1593). The result is a familiar block 5184
(see Exercise #2 again). The illustration below gives a visual representation of a
simple example:
caIn the illustrated example above, the data in block #3 of the blkls image
would map to block #49 in the original file system. We would find this with the
blkcalc command as shown (this is just an illustration, and does not apply to
the current exercise):
root@bt:~/example# blkcalc -o $fs_offset -u 3 original.dd
49
So, in simple terms, we have extracted the unallocated space, found a
string of interest in a data block in the unallocated image, and then found the
corresponding data block in the original image.
If we look at the blkstat (data block statistics) output for block 5184 in
the 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.
root@bt:~/Rby# blkstat -o 10260 able2.dd 5184
Fragment: 5184
Not Allocated
Group: 0
Using the command blkcat we can look at the raw contents of the data
block (using xxd and less as a viewer). If we want to, we can even use blkcat to
extract the block, redirecting the contents to another file:
root@bt:~/Rby# blkcat -o 10260 able2.dd 5184 | xxd | less
0000000: 2f2a 0a20 2a09 6669 7865 722e 630a 202a /*. *.fixer.c. *
0000010: 0962 7920 4964 6566 6978 200a 202a 0969 .by Idefix . *.i
0000020: 6e73 7069 7265 6420 6f6e 2073 756d 2e63 nspired on sum.c
0000030: 2061 6e64 2053 6169 6e74 5374 6174 2032 and SaintStat 2
0000040: 2e30 0a20 2a09 7570 6461 7465 6420 6279 .0. *.updated by
0000050: 2043 7962 6572 6e65 7469 6b20 666f 7220 Cybernetik for
Note the size of the file resulting from the blkcat output (5184.blkcat) is
1.0k (1024 bytes – the file system block size), just as expected.
root@bt:~/Rby# blkcat -o 10260 able2.dd 5184 > 5184.blkcat
root@bt:~/Rby# ls -lh
total 340M
-rw-r--r-- 1 root root 1.0K 2012-10-31 17:16 5184.blkcat
-rw-r--r-- 1 root root 9.3M 2012-10-31 16:53 able2.blkls
-rwxrwxrwx 1 root root 330M 2012-10-23 18:38 able2.dd
Note the size of the file resulting from the blkcat output (5184.blkcat) is
1.0k (1024 bytes – the file system block size), just as expected.
If we want to recover the actual file and meta data associated with the
identified data block, we use ifind to determine which meta data structure (in
this case inode since we are working on an EXT file system) holds the data in
block 5184. Then istat shows us the meta data for the inode:
root@bt:~/Rby# ifind -o 10260 -d 5184 able2.dd
10090
root@bt:~/Rby# istat -o 10260 able2.dd 10090
inode: 10090
Not Allocated
Group: 5
Generation Id: 3534950782
uid / gid: 4 / 7
mode: rrw-r--r--
size: 3591
num of links: 0
Inode Times:
Accessed: Sun Aug 10 11:18:36 2003
File Modified: Thu Dec 26 04:27:43 1996
Inode Modified: Sun Aug 10 11:29:58 2003
Deleted: Sun Aug 10 11:29:58 2003
Direct Blocks:
5184 5185 5186 5187
Again, as we saw previously, the istat command, which shows us the
meta data for inode 10090, indicates that the file with this inode is Not
Allocated, and its first direct block is 5184. Just as we expected.
We then use icat to recover the file. In this case, we just pipe the first few
lines out to see our string of interest, “cybernetik”.
root@bt:~/Rby# icat -o 10260 able2.dd 10090 | head -n 10
/*
* fixer.c
* by Idefix
* inspired on sum.c and SaintStat 2.0
* updated by Cybernetik for linux rootkit
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
Tuesday, October 30, 2012
Linux and Forensic Tools
Included Forensic Tools
Linux comes with a number of simple utilities that make imaging and basic analysis of suspect disk and drives
comparatively easy, These Tools include:
*dd -command used to copy from an input file or device to an output file or device. simple bitstream imaging.
*sfdisk and fdisk -used to determine the disk structure.
*gref -search files (or multiple files)for intances of an expression or patten.
*The loop device -allows you to associate regular files with device nodes, This will then allow you to mount
a bitstream image without having to rewrite the image to a disk.
*md5sum and sha1sum -create and store an MD5 or SHA hast of a file or list of files (including devices)
*file-reads a file's header information in an attempt to ascretain its type, regardless of name or extension.
*xxd -command line hexdump tool, For viewing a file in hex mode.
Following is a a very simple series of steps to allow you to perform easy practice analysis
using the simple Linux tools mentioned above.All of the commands can be further explored with
"man command". For simplicity we are going to use a floppy with a FAT file system. Again,
this is just an introduction to the basic commands. These steps can be far powerful with some
command line tweaking.
example file the wish to identify :
Once you download the floppy image, put a blank floppy disk in your drive and create the practice
floppy with the following command(covered in detail later):
root@bt:~# dd if=practical.floppy.dd of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 0.337022 s, 4.4 MB/s
root@bt:~# md5sum /dev/fd0
2f4791784e2af37cf196e6a72cc79d99 /dev/fd0
One way organizing your data would be to create a directory in your "home" directory for evidence
and then a subdirectory for different cases. since we will be executing these commands as root,
the home directory is /root:
root@bt:~# mkdir ~/evid/
mkdir: cannot create directory `/root/evid/': File exists
An additonal step you might want to take is to create a special mount poin for all subject file
system analysis. this is a another way of separating common system use with evidence processing:
root@bt:~# mkdir /mnt/analysis/
mkdir: cannot create directory `/mnt/analysis/': File exists
There are two simple tools available for determining the structure of a disk attached to your system.
The first,fdisk, we discussed earlier using the -l option. Replace the "x" with the letter of the drive
that corresponds to the subject drive. For example, if our subject disk is attached on the secondary IDE
channel as the master disk, it will be seen as /dev/hdc. A serial ATA (SATA) disk will be /dev/sda(or sdb,etc.)
We can get the partition information on that disk with:
root@bt:~# fdisk -l /dev/hdc
root@bt:~# fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe23b2a65
Device Boot Start End Blocks Id System
/dev/sda3 1 10707 86003946 7 HPFS/NTFS
/dev/sda4 19467 60802 332018689 f W95 Ext'd (LBA)
/dev/sda5 19467 25841 51200984+ 7 HPFS/NTFS
/dev/sda6 25880 34293 67585423+ 7 HPFS/NTFS
/dev/sda7 34294 40004 45873576 7 HPFS/NTFS
/dev/sda8 40005 40251 1983996 82 Linux swap / Solaris
/dev/sda9 40252 60801 165067843+ 83 Linux
root@bt:~# fdisk -l /dev/sda3
Disk /dev/sda3: 88.1 GB, 88068040704 bytes
255 heads, 63 sectors/track, 10706 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6e697373
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sda3p1 ? 120528 234814 918008208 4f QNX4.x 3rd part
Partition 1 does not end on cylinder boundary.
/dev/sda3p2 ? 119381 153271 272218546+ 73 Unknown
Partition 2 does not end on cylinder boundary.
/dev/sda3p3 ? 113202 147075 272087568 2b Unknown
Partition 3 does not end on cylinder boundary.
/dev/sda3p4 ? 177064 177067 27487 61 SpeedStor
Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
We can redirect the output of this command to a file for later use by issuing the command as:
root@bt:~# fdisk -l /dev/sda3 > ~/evid/fdisk.disk1
A couple of things to note here: The name of the output file (fdisk.disk1) is completely arbitrary.
root@bt:~# fdisk -l /dev/sda3 > ~/evid/fdisk.disk1
root@bt:~# fdisk -l /dev/sda3 > ~/evid/fdisk.disk1
Make an image of the practice disk using basic dd. this is your standard forensic image of a suspect disk.
Change to and execute the command from within the /root/evid/ directory:
root@bt:~# cd ~/evid/
root@bt:~/evid# dd if=/dev/sda3 of=image.disk1 bs=512
^C24834529+0 records in
24834529+0 records out
12715278848 bytes (13 GB) copied, 557.744 s, 22.8 MB/s
root@bt:~/evid# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe23b2a65
Device Boot Start End Blocks Id System
/dev/sda3 1 10707 86003946 7 HPFS/NTFS
/dev/sda4 19467 60802 332018689 f W95 Ext'd (LBA)
/dev/sda5 19467 25841 51200984+ 7 HPFS/NTFS
/dev/sda6 25880 34293 67585423+ 7 HPFS/NTFS
/dev/sda7 34294 40004 45873576 7 HPFS/NTFS
/dev/sda8 40005 40251 1983996 82 Linux swap / Solaris
/dev/sda9 40252 60801 165067843+ 83 Linux
Note: sector size is 2048 (not 512)
Disk /dev/sdb: 1047 MB, 1047263232 bytes
33 heads, 61 sectors/track, 254 cylinders
Units = cylinders of 2013 * 2048 = 4122624 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disk identifier: 0x6f20736b
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdb1 ? 386556 953625 2283019262 72 Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(357, 116, 40) logical=(386555, 11, 23)
Partition 1 has different physical/logical endings:
phys=(357, 32, 45) logical=(953624, 6, 61)
Partition 1 does not end on cylinder boundary.
/dev/sdb2 ? 83801 1045563 3872056480 65 Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(288, 115, 43) logical=(83800, 2, 1)
Partition 2 has different physical/logical endings:
phys=(367, 114, 50) logical=(1045562, 23, 53)
Partition 2 does not end on cylinder boundary.
Partition 2 does not start on physical sector boundary.
/dev/sdb3 ? 928903 1890666 3872056384 79 Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(366, 32, 33) logical=(928902, 28, 32)
Partition 3 has different physical/logical endings:
phys=(357, 32, 43) logical=(1890665, 16, 36)
Partition 3 does not end on cylinder boundary.
Partition 3 does not start on physical sector boundary.
/dev/sdb4 ? 1433523 1433551 110998 d Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(372, 97, 50) logical=(1433522, 22, 25)
Partition 4 has different physical/logical endings:
phys=(0, 10, 0) logical=(1433550, 8, 13)
Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
root@bt:~/evid# fdisk -l /dev/sdb
Note: sector size is 2048 (not 512)
Disk /dev/sdb: 1047 MB, 1047263232 bytes
33 heads, 61 sectors/track, 254 cylinders
Units = cylinders of 2013 * 2048 = 4122624 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disk identifier: 0x6f20736b
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdb1 ? 386556 953625 2283019262 72 Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(357, 116, 40) logical=(386555, 11, 23)
Partition 1 has different physical/logical endings:
phys=(357, 32, 45) logical=(953624, 6, 61)
Partition 1 does not end on cylinder boundary.
/dev/sdb2 ? 83801 1045563 3872056480 65 Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(288, 115, 43) logical=(83800, 2, 1)
Partition 2 has different physical/logical endings:
phys=(367, 114, 50) logical=(1045562, 23, 53)
Partition 2 does not end on cylinder boundary.
Partition 2 does not start on physical sector boundary.
/dev/sdb3 ? 928903 1890666 3872056384 79 Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(366, 32, 33) logical=(928902, 28, 32)
Partition 3 has different physical/logical endings:
phys=(357, 32, 43) logical=(1890665, 16, 36)
Partition 3 does not end on cylinder boundary.
Partition 3 does not start on physical sector boundary.
/dev/sdb4 ? 1433523 1433551 110998 d Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(372, 97, 50) logical=(1433522, 22, 25)
Partition 4 has different physical/logical endings:
phys=(0, 10, 0) logical=(1433550, 8, 13)
Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
root@bt:~/evid# dd if=/dev/sdb of=image.disk1 bs=512
2045436+0 records in
2045436+0 records out
1047263232 bytes (1.0 GB) copied, 103.362 s, 10.1 MB/s
root@bt:~/evid# md5sum /dev/sdb
044144780d449a3af7cd3a01b84c5099 /dev/sdb
root@bt:~/evid# dd if=/dev/sdb of=image.disk2 bs=512
2045436+0 records in
2045436+0 records out
1047263232 bytes (1.0 GB) copied, 103.264 s, 10.1 MB/s
root@bt:~/evid# md5sum /dev/sdb
044144780d449a3af7cd3a01b84c5099 /dev/sdb
root@bt:~/evid# md5sum image.disk2
044144780d449a3af7cd3a01b84c5099 image.disk2
root@bt:~/evid# mount -t vfat -o ro,noexec,loop image.disk2 /mnt/analysis
root@bt:~/evid# umount /mnt/analysis
root@bt:~/evid# sha1sum /dev/fd0
f5ee9cf56f23e5f5773e2a4854360404a62015cf /dev/fd0
root@bt:~/evid# sha1sum /dev/sdb
a00f3b85b348befb2e4876135b2b4449476b4e0f /dev/sdb
root@bt:~/evid# sha1sum /dev/sdb > sha.disk1
root@bt:~/evid# mount -t vfat -o ro,noexec,loop image.disk1 /mnt/analysis
root@bt:~/evid# cd /mnt/analysis/
root@bt:/mnt/analysis# find . -type f -exec sha1sum {} \; > ~/evid/sha.filelist
root@bt:/mnt/analysis# cat /root/evid/sha.filelist
86082e288fea4a0f5c5ed3c7c40b3e7947afec11 ./Docs/Benchmarks.xls
81e62f9f73633e85b91e7064655b0ed190228108 ./Docs/Computer_Build.xml
0950fb83dd03714d0c15622fa4c5efe719869e48 ./Docs/Law.doc
7a1d5170911a87a74ffff8569f85861bc2d2462d ./Docs/whyhack
63ddc7bca46f08caa51e1d64a12885e1b4c33cc9 ./Pics/C800x600.jpg
8844614b5c2f90fd9df6f8c8766109573ae1b923 ./Pics/bike2.jpg
4cf18c44023c05fad0de98ed6b669dc4645f130b ./Pics/bike3.jpg
aeb0151e67ff4dd5c00a19ee351801b5a6f11438 ./Pics/matrixs3.jpg
d252ac06995c1a6215ca5e7df7c3e02c79c24488 ./Pics/mulewheelie.gif
f6f8586eefb5f163eac2bd8ec09053d70cae000e ./Pics/Stoppie.gif
49f0405267a653bac165795ee2f8d934fb1650a9 ./ARP.EXE
9a886c8e8ad376fc53d6398cdcf8aab9e93eda27 ./FTP.EXE
4c703ee9802aa110b0673d7ae80468e6418bf74c ./loveletter.virus
7191c24f0f15cca6a5ef9a4db0aee7b40789d6c0 ./ouchy.dat
6666d9b50508360f4a2362e7fd74c91fcb68d2e8 ./snoof.gz
root@bt:/mnt/analysis# sha1sum -c /root/evid/sha.disk1
/dev/sdb: OK
root@bt:/mnt/analysis# sha1sum -c /root/evid/sha.filelist
./Docs/Benchmarks.xls: OK
./Docs/Computer_Build.xml: OK
./Docs/Law.doc: OK
./Docs/whyhack: OK
./Pics/C800x600.jpg: OK
./Pics/bike2.jpg: OK
./Pics/bike3.jpg: OK
./Pics/matrixs3.jpg: OK
./Pics/mulewheelie.gif: OK
./Pics/Stoppie.gif: OK
./ARP.EXE: OK
./FTP.EXE: OK
./loveletter.virus: OK
./ouchy.dat: OK
./snoof.gz: OK
root@bt:/mnt/analysis# ls -al
.:
total 118
drwxr-xr-x 4 root root 7168 1970-01-01 07:00 .
drwxr-xr-x 3 root root 4096 2012-10-29 19:10 ..
-rwxr-xr-x 1 root root 19536 1996-08-24 11:11 ARP.EXE
drwxr-xr-x 3 root root 512 2000-09-23 15:21 Docs
-rwxr-xr-x 1 root root 37520 1996-08-24 11:11 FTP.EXE
-r-xr-xr-x 1 root root 16161 2000-09-21 07:46 loveletter.virus
-rwxr-xr-x 1 root root 21271 2000-03-19 19:00 ouchy.dat
drwxr-xr-x 2 root root 512 2000-09-23 15:21 Pics
-rwxr-xr-x 1 root root 12384 2000-08-02 07:43 snoof.gz
root@bt:ls -alR | less
drwxr-xr-x 2 root root 512 2000-09-23 15:21 Private
-rwxr-xr-x 1 root root 3928 2000-09-21 07:45 whyhack
./Docs/Private:
total 1
drwxr-xr-x 2 root root 512 2000-09-23 15:21 .
drwxr-xr-x 3 root root 512 2000-09-23 15:21 ..
./Pics:
total 1138
drwxr-xr-x 2 root root 512 2000-09-23 15:21 .
drwxr-xr-x 4 root root 7168 1970-01-01 07:00 ..
-rwxr-xr-x 1 root root 183654 2000-09-21 07:45 bike2.jpg
-rwxr-xr-x 1 root root 187598 2000-09-21 07:45 bike3.jpg
-rwxr-xr-x 1 root root 94426 2000-03-19 19:00 C800x600.jpg
-rwxr-xr-x 1 root root 27990 2000-09-21 07:45 matrixs3.jpg
-rwxr-xr-x 1 root root 418582 2000-09-21 07:45 mulewheelie.gif
-rwxr-xr-x 1 root root 243245 2000-09-21 07:45 Stoppie.gif
root@bt:/mnt/analysis# ls -laiRtu > ~/evid/access_file.list
root@bt:/mnt/analysis# find . -type f > ~/evid/file.list.2
root@bt:/mnt/analysis# tree
.
├── ARP.EXE
├── Docs
│ ├── Benchmarks.xls
│ ├── Computer_Build.xml
│ ├── Law.doc
│ ├── Private
│ └── whyhack
├── FTP.EXE
├── loveletter.virus
├── ouchy.dat
├── Pics
│ ├── bike2.jpg
│ ├── bike3.jpg
│ ├── C800x600.jpg
│ ├── matrixs3.jpg
│ ├── mulewheelie.gif
│ └── Stoppie.gif
└── snoof.gz
3 directories, 15 files
root@bt:/mnt/analysis# grep -i jpg ~/evid/file.list.2
./Pics/C800x600.jpg
./Pics/bike2.jpg
./Pics/bike3.jpg
./Pics/matrixs3.jpg
root@bt:/mnt/analysis# find . -type f -exec file {} \; > ~/evid/filetype.list
root@bt:/mnt/analysis# cat ~/evid/filetype.list
./Docs/Benchmarks.xls: CDF V2 Document, Little Endian, Os: Windows, Version 4.10, Code page: 1252, Author: Barry J. Grundy, Last Saved By: Barry J. Grundy, Name of Creating Application: Microsoft Excel, Create Time/Date: Fri Jan 8 19:53:35 1999, Security: 0
./Docs/Computer_Build.xml: gzip compressed data, from Unix
./Docs/Law.doc: CDF V2 Document, Little Endian, Os: Windows, Version 4.0, Code page: 1252, Title: The Long Arm of the Law, Author: OAG, Template: Normal.dot, Last Saved By: OAG, Revision Number: 2, Name of Creating Application: Microsoft Word 8.0, Total Editing Time: 01:00, Create Time/Date: Wed Sep 20 12:16:00 2000, Last Saved Time/Date: Wed Sep 20 12:16:00 2000, Number of Pages: 1, Number of Words: 1335, Number of Characters: 7610, Security: 0
./Docs/whyhack: ASCII English text, with very long lines, with CRLF, LF line terminators
./Pics/C800x600.jpg: JPEG image data, JFIF standard 1.02
./Pics/bike2.jpg: PC bitmap, Windows 3.x format, 300 x 204 x 24
./Pics/bike3.jpg: PC bitmap, Windows 3.x format, 317 x 197 x 24
./Pics/matrixs3.jpg: JPEG image data, JFIF standard 1.01
./Pics/mulewheelie.gif: PC bitmap, Windows 3.x format, 425 x 328 x 24
./Pics/Stoppie.gif: GIF image data, version 87a, 1024 x 693
./ARP.EXE: PE32 executable for MS Windows (console) Intel 80386 32-bit
./FTP.EXE: PE32 executable for MS Windows (console) Intel 80386 32-bit
./loveletter.virus: ASCII English text
./ouchy.dat: JPEG image data, JFIF standard 1.02
./snoof.gz: gzip compressed data, from Unix, last modified: Thu Feb 11 03:04:46 1999
root@bt:/mnt/analysis# grep image ~/evid/filetype.list
./Pics/C800x600.jpg: JPEG image data, JFIF standard 1.02
./Pics/matrixs3.jpg: JPEG image data, JFIF standard 1.01
./Pics/Stoppie.gif: GIF image data, version 87a, 1024 x 693
./ouchy.dat: JPEG image data, JFIF standard 1.02
root@bt:strings arp.exe | less
l|}
<-t8</t4
t]Ph
t2Ph '
Ph!'
@SVW
wR9U
wM9U
wH9U
SVWj
)h|I
L$ 3
L$ 3
u!Wj
L$ 3
\VSW
KERNEL32.dll
CharToOemA
USER32.dll
%u.%u.%u.%u
-%02x
%02x
%2x-%2x-%2x-%2x-%2x-%2x
SnmpExtensionQuery
SnmpExtensionInit
inetmib1.dll
%1: bad IP address: %2
%1: bad argument: %2
Interface: %1
Internet Address Physical Address Type
%1: not enough memory
other%0
invalid%0
dynamic%0
static%0
%1: Windows Sockets initialization failed: %2!d!
%1: can't load DLL: %2, error = %3!d!
%1: DLL error %3!d! in %2
The specified entry was not found
%1!-20s! %2!-20s! %3!-10s!
The interface failed to initialize: %1!u!
Unable to retrieve ARP information: %1!u!
The ARP entry addition failed: %1!u!
The ARP entry deletion failed: %1!u!
No ARP Entries Found
151J1Q1v3
7+8}8
>B>`>w>
#0a0
0d1w1
2*222L2
3r3y3
4(4.4
5$5+52595@5G5N5U5\5
6&8-8B8I8[8b8q8u8y8}8
:#:':+:/:3:7:;:?:C:G:K:O:S:W:[:_:c:g:k:o:
<e=i=m=q=u=y=}=
0f2/33373;3?3C3G3K3O3S3\7a7g7t7
7 8&8,82888>8D8J8P8V8\8b8h8D9J9P9V9
root@bt:~# umount /mnt/analysis
umount: /mnt/analysis: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
root@bt:~/evid# nano /root/evid/searchlist.txt/hits.txt
root@bt:~/evid# ls -l
total 1024192
-rw-r--r-- 1 root root 1630 2012-10-30 21:51 access_file.list
-rw-r--r-- 1 root root 927 2012-10-30 20:28 fdisk.disk1
-rw-r--r-- 1 root root 256 2012-10-30 21:52 file.list.2
-rw-r--r-- 1 root root 1544 2012-10-30 21:57 filetype.list
-r--r--r-- 1 root root 1474560 2012-10-30 21:06 image.disk1
-rw-r--r-- 1 root root 1047263232 2012-10-30 21:15 image.disk2
drwxr-xr-x 2 root root 4096 2012-10-30 20:00 searchlist.txt
-rw-r--r-- 1 root root 51 2012-10-30 21:32 sha.disk1
-rw-r--r-- 1 root root 886 2012-10-30 21:35 sha.filelist
root@bt:~/evid# nano searchlist
root@bt:~/evid# grep -abif searchlist.txt image.disk1 > hits.txt
root@bt:~/evid# cat hits.txt
8983:�*�J�j��������ADocs`����������������DOCS ��z7)7)�z7)APics`����������������PICS ��z7)7)�z7)vARP EXE ��z7)7)eY▒!K PLFTP EXE $�z7)7)eY▒!r ��Brus�������������������lovel�etter.viLOVELE~1VIR��z7)7)�=5)� !?Aouchy�.dat������OUCHY DAT ��z7)7)▒�s(� SAsnoof�.gz��������SNOOF GZ ��z7)7)s=)
39284:Ninth Circuit Strikes Federal �Virtual� Child Pornography Law on First Amendment Grounds
INCLUDEPICTURE \d "/images/design/5x5.gif"
INCLUDEPICTURE \d "/images/design/5x5.gif"
INCLUDEPICTURE \d "/images/design/5x5.gif"
INCLUDEPICTURE \d "/images/design/5x5.gif"
HYPERLINK "mailto:info@lawnewsnetwork.com"mailto:info@lawnewsnetwork.com
HYPERLINK "http://www.almdc.com/"Criminal Justice Weekly
December 21, 1999
INCLUDEPICTURE \d "/images/design/5x5.gif"
INCLUDEPICTURE \d "/images/design/line2.gif"
INCLUDEPIThe First Amendment prohibits Congress from enacting a statute criminalizing the generation of computer images of fictitious children engaged in imaginary but explicit sexual conduct, the U.S. Court of Appeals for the Ninth Circuit held Dec. 17, widening a split in the circuits. Specifically, the court struck certain language in the Child Pornography Prevention Act of 1996, 18 U.S.C. �2256, prohibiting a "visual depiction" that "is, or appears to be, of a minor engaging in sexually explicit conduct," and advertising or promotion of such images, as unconstitutionally vague and overbroad, language which was found last month to be constitutional by the Eleventh Circuit in U.S. v. Acheson, 11th Cir., No. 98-3559, Story, J., 11/12/99 (Free Speech Coalition v. Reno, 9th Cir., No. 97-1653Section 2256(8) defines child pornography as "any visual depiction, including any photograph, film, video, picture, or computer or computer-generated image or picture, whether made or produced by electronic, mechanical, or other means, of sexually explicit conduct[.]" At issue in the appeal were the definitions contained in subsections (B) and (D). Section 2256(8)(B) bans sexually explicit depictions that appear to be minors. Section 2256(8)(D) bans visual depictions that are "advertised, promoted, presented, described or distributed in such a manner that conveys the imThe plaintiffs were a group of adult-oriented businesses and erotic artists who withheld or stopped distributing certain artistic works out of fear of prosecution under the 1996 amendments. The district court found that the plaintiffs had standing to bring their First Amendment challenge, and the government did not contest that finding on appeal. The district court granted summary judgment in favor of the government on the First Amendment issues, however. On appeal, the plaintiffs argue that where the statute fails to define "appears to be" and "conveys the impression," it is so vague a person of ordinary intelligence cannot understand whatThe Ninth Circuit, in an opinion by U.S. District Judge Donald W. Molloy (D. Mont.), sitting by designation, agreed on that point, while holding most of the statute still passes constitutional muster. However, it did not hold, as the dissent claimed, that the First Amendment protects all computer-generated imaginary images of child pornography. "Because the statute is severable, our holding demonstrates that if morphed computer images are of an identifiable child, the statute is enforceable because there is then the potential harm to a real child."
CONTENT DISCRIMINATION
844548426: <dc:format>image/jpeg</dc:format>
845713864: <dc:format>image/jpeg</dc:format>
846648084: <dc:format>image/jpeg</dc:format>
Project managers may still need to break the rules to meet project goals, and senior managers must support those actions�T�
853499180:��▒�Rectangle 3������
Business Service Management (BSM) tools track the execution of business process flows�ZRd information
853567991:Concourse
1_Concourse
2_Concourse
3_Concourse
4_Concourse
5_Concourse
6_Concourse
7_Concourse
8_Concourse
9_Concourse*Chapter 4: Project Integration ManagementLearning Objectives Learning Objectives (continued) Learning Objectives (continued)HThe Key to Overall Project Success: Good Project Integration Management)Project Integration Management Processes5Project Integration Management Processes (continued)3Figure 4-1. Project Integration Management SummaryWhat Went Wrong?)Strategic Planning and Project SelectionLFigure 4-2. Mind Map of a SWOT Analysis to Help Identify Potential Projects4Figure 4-3. Information Technology Planning ProcessBest PracticeMethods for Selecting Projects'Focusing on Broad Organizational NeedsCategorizing IT ProjectsFinancial Analysis of Projectset Present Value Analysis&Figure 4-4. Net Present Value Example'Figure 4-5. JWD Consulting NPV ExampleNPV CalculationsReturn on InvestmentPayback Analysis(Figure 4-6. Charting the Payback PeriodWeighted Scoring Model@Figure 4-7. Sample Weighted Scoring Model for Project Selection"Implementing a Balanced Scorecard'Figure 4-8. Balanced Scorecard ExampleProject ChartersXTable 4-1. Contoh Project Charter for the DNA-Sequencing Instrument Completion Project Table 4-1. Charter (continued)Project Management Plans-Common Elements of a Project Management PlanITable 4-2. Sample Contents for a Software Project Management Plan (SPMP)What the Winners DoProject Execution$Coordinating Planning and Execution.Providing Leadership and a Supportive Culture'Important Skills for Project Execution'Project Execution Tools and Techniques(Monitoring and Controlling Project WorkMedia Snapshot▒Integrated Change Control2Change Control on Information Technology ProjectsChange Control Systemhange Control Board (CCB)Making Timely ChangesConfiguration Management@Table 4-3. Suggestions for Performing Integrated Change ControlClosing Projects and Phases;Using Software to Assist in Project Integration ManagementChapter Summary
Fonts UseTheme
root@bt: ~/evid: xxd -s 75441 image.disk1 | less
00126b1: 796f 7520 616e 6420 796f 7572 2065 6e74 you and your ent
00126c1: 6972 6520 6275 7369 6e65 7373 2072 616e ire business ran
00126d1: 736f 6d2e 0a0a 5468 6973 2069 7320 6e6f som...This is no
00126e1: 7420 6120 6a6f 6b65 2e0a 0a49 2068 6176 t a joke...I hav
00126f1: 6520 6861 6420 656e 6f75 6768 206f 6620 e had enough of
0012701: 796f 7572 206d 696e 646c 6573 7320 636f your mindless co
0012711: 7270 6f72 6174 6520 7069 7261 6379 2061 rporate piracy a
0012721: 6e64 2077 696c 6c20 6e6f 206c 6f6e 6765 nd will no longe
0012731: 7220 7374 616e 6420 666f 7220 6974 2e20 r stand for it.
0012741: 596f 7520 7769 6c6c 2072 6563 6965 7665 You will recieve
0012751: 2061 6e6f 7468 6572 206c 6574 7465 7220 another letter
0012761: 6e65 7874 2077 6565 6b2e 2020 4974 2077 next week. It w
0012771: 696c 6c20 6861 7665 2061 2073 696e 676c ill have a singl
0012781: 6520 6261 6e6b 2061 6363 6f75 6e74 206e e bank account n
0012791: 756d 6265 7220 616e 6420 6261 6e6b 206e umber and bank n
00127a1: 616d 652e 2020 4920 7761 6e74 2079 6f75 ame. I want you
00127b1: 2074 6f20 6465 706f 7369 7420 2435 302c to deposit $50,
00127c1: 3030 3020 696e 2074 6865 2061 6363 6f75 000 in the accou
00127d1: 6e74 2074 6865 2064 6179 2079 6f75 2072 nt the day you r
00127e1: 6563 6569 7665 2074 6865 206c 6574 7465 eceive the lette
00127f1: 722e 2020 0a0a 446f 6e27 7420 7472 7920 r. ..Don't try
0012801: 616e 7974 6869 6e67 2c20 616e 6420 646f anything, and do
0012811: 6e74 2063 6f6e 7461 6374 2074 6865 2063 nt contact the c
0012821: 6f70 732e 2020 4966 2079 6f75 2064 6f2c ops. If you do,
0012831: 2049 2077 696c 6c20 756e 6c65 6173 6820 I will unleash
0012841: 6120 7669 7275 7320 7468 6174 2077 696c a virus that wil
0012851: 6c20 6272 696e 6720 646f 776e 2079 6f75 l bring down you
0012861: 7220 7768 6f6c 6520 6e65 7477 6f72 6b20 r whole network
:continues....
Subscribe to:
Posts (Atom)