1 / 16

F13 Forensic tool analysis

F13 Forensic tool analysis. Dr. John P. Abraham Professor UTPA. Write a Hello world program in c. This chapter is running redhat Linux. Create c program on page 303 inside Linux. Enter command mode by pressing: and typing wq! To write the data to file and quit.

rinah-hicks
Download Presentation

F13 Forensic tool analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. F13 Forensic tool analysis Dr. John P. Abraham Professor UTPA

  2. Write a Hello world program in c • This chapter is running redhat Linux. • Create c program on page 303 inside Linux. • Enter command mode by pressing: and typing wq! To write the data to file and quit. • To compile this source in Linux: • Gcc –o hello hello.c • Gcc is the compiler, -o is the name of the compiled file, hello.c is the source code. • While we’re here, we’ll compile a debug version of hello. The –g option indicates that we want to include debugging information, which embeds additional information. • Gcc –g –o hello_debug hello.c

  3. More about the hello world program • The executable code we have compiled so far will include variable and function names which are called symbols. Removing the symbols is a common action taken to reduce the size of the binary. • The versions of hello we have created so far are dynamically linked meaning they rely on shared librariesand this is the default mode for the gcc compiler. • The final version of hello we will create a statically compiled version meaning that we will embed those shared libraries directly into our compiled executable, which will dramatically increase the overall size. • Static executables are self-contained and do not require external code, whereas dynamic executables use external code at runtime. • Gcc –static -0 hello_static hello.c

  4. Examining files created • To examine the file sizes of the various versions we have created, run the ls command: • Ls –alh (see explanation on p 305) • Static Analysis of Hello • There are two general approaches to examining an unknown executable binary: static and dynamic analysis. • Static – involves various forms of examination that do not actually involve executing or running the binary, which is dynamic analysis. By executing the binary during dynamic analysis, with specialized monitoring utilities such as debuggers, you can trace or alter program flow and execution. Static analysis can eventually enable us to “know all” about the tool, whereas dynamic analysis may be limited simply by the virtue of how the programmer allows the user to interact with the application.

  5. Generate an md5sum • We’ll generate an MD5 message digest hash value on all the files in our working directory and save the output to a file. MD5sum is a 128-bit mathematically generated value from the contents of a file, and it effectively acts as a digital fingerprint. • Md5sum hello* >mdsum_hello_files.txt • Cat md5sum_hello_files.txt (will diplay file we created) • When you have completed your analysis, or at various points along the way, you should always go back and check the md5sum to ensure that the values have not changed. If they have changed, either you unintentionally modified the binary during your examination, or the binary may have intentionally modified itself. To avoid altering or destroying the original evidence, as a general forensic analysis and evidence processing guideline, you should work on a copy of the evidence whenever possible. • To check these values at a later time to confirm that you haven’t modified the files during your analysis, simply run the md5sum command with the –c option in the same directory as the files. If a changes is detected you will se FAILED instead of OK.

  6. The file command • Now that we have fingerprinted the files to be examined, we can use the file command to determine the file type. • This command uses the /usr/share/magic file, a text database of file signatures, to identify the file type. • By executing the file command, we can get general information about the binary. • File hello hello_debug hello_stripped hello_static • See results on p.307 – reveals that these are 32-bit executables stored in little endian order for i8036

  7. The strings command • Strings command is a convenient way to take a quick look at the binary for ASCII text information that may be viewable. • These text strings may give you some insight as to the function of the binary, but such information must still be confirmed through further analysis. • Strings-a hello |more • We produced the strings command output from the two files and compared them with the diff command. • May be able to find a binary with debug information in it, pointing you to the source code.

  8. Using a Hexadecimal Viewer • Difficult to show here. Go to pages 311,312 and 313

  9. Using the nm command to view symbol information. • nm hello • All symbols used for variables and functions can be viewed here. • See p.314 symbol explanation is given on p. 315

  10. Using ldd to List Shared Objects • All Linux dynamically compiled programs are incomplete and require additional linking at runtime to execute. This is accomplished by the execution of a dynamic linker, information about which is stored in the .interp section of the binary. • The ldd command lists the shared objects and the memory address at which the library will be available. • Ldd hello

  11. Examining the ELF Structure with readelf • ELF (executable and linking format) structure actually provides two parallel representations of the file content: a linking view documented in the section headers, and an execution view in the program header table. • Readelf—file-header (pg 319) • Readelf—section-headers (pg320) • Readelf—program-headers (pg 323) • Readelf—symbols (page 324) • Readelf—debug-dump (page 326) • Readelf—hex-dump (pg 327)

  12. Using objdump to Display Object File Information • The objdump command enables us to further probe the contents of an ELF executable binary. • Some of the options provide information that parallels the readelf command. • Objdump will enable us to disassemble executable portions of the code. • Objdump command is designed to display information from object files. To display the file header information, we execute the following command, which tells us that the hello binary is an Intel i386 ELF executable with a program entry point or starting address of 0x08048278 • Objdump –file-header ./hello

  13. Using objdump to disassemble • The objdump command includes the capability to disassemble the executable object code, converting it from machine code to assembly language. • The translation that occurs during a disassembly is not always correct, especially in simple sequential processing disassemblers such as objdump. Interactive dissassemblers such as IDA Pro, which utilize multiple passes and follow execution paths to resolve information, generate much more accurate dead listings • Using a disassemler, you can generate a dead listing, or a text file with the assembly language representation of the interpreted executable machine code contained within the object file under examination. • Objdump –l –source .hello_debug • Assembly language depicted on page 332. • Anyone with assembly language background can now figure out the program.

  14. Dynamic Analysis of Hello • You must prepare a contained testing environment before starting any type of dynamic forensic tool analysis of an unknown binary. • Ensure that your designated testing systems are completely isolated from your network and the Internet—you do not want malicious code propagating through your own network, or even worse, attacking others.

  15. System Call Trace (strace) • A system call is a routine executed by the operating system that performs a low-level operation. • When a program is executing in user space, these operations are requested via a system call. • System calls can provide information on activity such as file, network, and memory access. • Signals are used for interprocess communication. • Strace executes the binary executable you want to examine, intercepting and recording any system calls and signals. • Strace ./hello

  16. The GNU Debugger (gdb) • The GNU debugger (gdb) enables us to peer inside the binary under investigation as it runs. We can stop execution at various points to examine data structures, and we can even control program flow to access and examine functions that may normally be accessed during execution. • Gdb ./hello_debug • This starts gdb and tells us that it is Red Hat Linux, version 5.2.1-4. The debug information included provides references to the lines of source code, but the C source code is not actually included in the binary. • For gdb to make use of it, we also have to make sure that hello.c is in the same directory. • The info functions command will provide the addresses of functions contained within the binary. If you examine non-debug version of hello, you will see that the main function is listed in the non-debugging symbols section with an address of 0x8048328. • The main function is the heart of the program. We really need a starting point, so we’re going to tell the debugger that we want to stop execution of the program so that we can take a look around. • Break main • Run

More Related