Many forensic analysis starts with a button click, but validated by looking at recoded data structures on storage devices in its native format. Non-programmers have a hard time learning and understanding what we mean by stored data. In this post, I wanted to show a code that can be compiled and run to see exactly how data is stored based on the given data type.
#include <iostream>
#include<string>
#include<fstream>
using namespace std;
typedef struct zoltan{
int age;
string fName;
string lName;
float earnings;
bool isGraduated;
}me_t;
int main(){
me_t student;
student.age=34; //change the RED values and experiment
student.earnings=34.45;
student.fName="Zoltan";
student.lName="Szabo";
student.isGraduated=true;
ofstream output_file("students.data", ios::binary); //change the output file name if needed
output_file.write((char*)&student, sizeof(student));
output_file.close();
return 0;
}
As we can see, age is an integer data type with a value of 34 hat was saved as hex value 22 00 00 00 since it is a 32 bit value stored in little endian format. Reading it as hex value 00000022 will give us 32 decimal. The string values for the first and last name are structures with default of 15 character array storage ( 0f000000 ) and a value that stores the current size of the used characters as an integer right before the size value. The floating point and boolean values are stored next. Unused available bytes are filled with a so called "garbage value", in this case, cc. There are 4 bytes before the string values that current state of this paper did not explore further at this time.
Sunday, February 9, 2014
Back to basics - Signed integers
In this post, I wanted to visit the concept of signed vs. unsigned integers from a forensic point-of-view. Many investigators are trained to use tools to view cases from the software vendor point-of-view without understanding basic computer science concepts.
I wanted to look at symbolic links, look at the MFT record for the created hard link, and examine what happens when a long filename link with a hard link created that also have a long filename. These steps were repeated at least three times using Microsoft Windows [Version 6.1.7601], NTFS version 3.1.
1. Created test file with a long file name since hard links do not work on folders.
2. Created a hard link to the test file and named the link also a long file name.
C:\temp>copy con testingLongFilename.txt
hello again
^Z
1 file(s) copied.
C:\temp>mklink /h hardlinktolongfile.txt testingLongFilename.txt
Hardlink created for hardlinktolongfile.txt <<===>> testingLongFilename.txt
C:\temp>dir
02/09/2014 07:51 PM 13 hardlinktolongfile.txt
02/09/2014 06:24 PM <SYMLINK> hello [c:\temp]
02/09/2014 06:25 PM <SYMLINKD> hello2 [c:\temp]
02/09/2014 06:26 PM <JUNCTION> hello3 [c:\temp]
02/09/2014 06:44 PM 7 testfile.txt
02/09/2014 07:51 PM 13 testingLongFilename.txt
3. The resulting MFT record was examined and noticed the MFT record reflects the long and short file names noted by the first two $30 FileName attributes, but the hard link only had a single $30 attribute. The file names of the source and target resides in the same resident MFT record where the length of the NTFS name record shows 0x88.
Note: Microsoft documentation lists flags 0x01 for NTFS and 0x02 for DOS file name flags,
but did not list the 0x00 for hard link filename flag ( red circles ) .
So, in interpreting 0x88, it can be read as 136 or -120 depending on the data type.
Recipe - Two's complement to find the signed decimal value of a Base-16 ( Hex ) value
1. Convert to binary
2. Add -1
a. If the result starts with a one, the result is negative
3. Flip the result bits
128 64 32 16 8 4 2 1
128 64 32 16 8 4 2 1
1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0x88 |
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | +(-1) |
1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | result |
0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | flip bits |
-120 |
Thus, the hex value 0x88 can be interpreted 136 as unsigned integer and -120 as signed integer. Signed integers are used in the MFT table entries for the cluster runs, so be careful with interpretation. In this case, the attribute length is 136 bytes.
Friday, January 10, 2014
Easy Documentation
Is your documentation look like this?
Step 1: (1/10/2014 12:49:40 PM) User left click on "Start (list item)" in "Start"
It is important to document problems precisely and record error messages exactly how they appear for technical support to help troubleshoot system errors. Recording the precise steps that a user took in order to reproduce the exact error is even more useful in troubleshooting technical issues when the client is not technical at all. This is especially important if we need to troubleshoot technical problems remotely.
The word I’ve mentioned above was “reproduce”. It is very important in forensics to reproduce the exact steps an investigator performs on a live system in order to create repeatable and verifiable steps for volatile or sparse data acquisition. We can provide hand written documentation or record steps on the system itself. We can use third party tools for this purpose, but Windows includes a very useful utility that not many people talks about even though it’s been available since Windows 7.
It is nice to know that we have this utility available that we will not have to take with us or install on the suspect drive. It is less than 600KB in size and does a great job recording precise steps using official Microsoft terminology and includes time tamps as well. It creates screenshots with auto highlight of focus area. It creates the report as a flat report in MHTML format that can be viewed as a slide show as well. It also allows the saving of the report and it does it automatically as a compressed ZIP archive to save space.
One of the drawbacks I can see is that it does not record actual characters typed in Command Line Interface ( CLI ). I guess, it was not meant to be a keylogger, just a Graphical User Interface ( GUI ) action recorder. For any typed keywords or commands, the user can add comments to the specific step to make it clear if the user finds it necessary. This can be a useful feature as well since no password will be recorded by mistake and shared with unintended parties.
You can start the Steps Recorder from the Run dialogue or directly from C:\Windows \System32. The executable is called psr.exe. Give it a try and see if you can utilize its capabilities in your environment. I would be curious if anyone is using this tool already or if you can see its benefits in some cases.
Subscribe to:
Posts (Atom)