I am on chapter 2 and this chapter is all about TOOLS. Below is a list and a few points on the tools mentioned in this chapter. I learned about a few new tidbits like magic numbers and name mangling and what tools are the best for what situation.
- FILE
- included in all linux like OS's (this includes osx btw, and CYGWIN for Windows)
- tries to guess at the file's type
- uses magic numbers (certain bit patterns that are standard to certain files)
- usage - 'file filename'
- PE Tools
- Windows based
- collection of tools
- can analyze files on disk or running process
- usage - GUI
- Link cited in book is gone, found it available here http://uinc.ru/files/neox/PE_Tools.shtml
- PEiD
- Windows based
- identifies entry point
- Compiler and/or Packers used
- usage - open a binary file in PEiD gui
- http://peid.info
- NM
- available in linux (includes OSX)
- lists symbols from object files
- basically lists function and variable names
- 'man nm' has more
- usage 'nm filename'
- LDD
- linux type operating systems (does NOT include OSX, see next tool)
- stands for list dynamically dependencies
- works on dynamically linked binaries (see below for what this means)
- usage 'ldd filname'
- objdump
- runs on linux and cygwin(not OSX)
- dumps out LDD information and way more
- very flexible, with lots of command line options
- Includes: headers, debugging info, symbol info, disassembly listing (dead listing)
- usage objdump filename
- otool
- runs on OSX
- similar to objdump but for OSX Mach-O binaries
- displays dynamically linked dependencies like ldd with the -L switch
- run otool with no arguments for a list of all switches
- dumpbin
- runs on Windows, is included in Visual Studio
- can extract lots of info from PE files, including: symbols, imported function names, exported function names, and disassembly listing
- output is usually pretty, IMO
- usage dumpbin /dependents filename.exe --lists dependencies similar to ldd.
- c++filt
- runs on linux (was native on OSX too)
- addresses mangled name problem, (see special note below)
- treats input as a mangled name and returns more usefull function information
- usage pipe nm output to c++filt. ie. nm filename | grep functionname | c++filt
- strings
- runs on linux, osx, cygwin (also an .exe windows version out there somewhere too)
- simply returns any string data in any file
- useful for getting a quick idea of a file, but can contain loads of garbage data
- usage strings filename
- to scan the complete binary (not just initialized sections) use the -a switch
- use -t to get the hex offset of the string locations
- use -e for Unicode strings
Special note on magic numbers
- 0xCA FE BA BE is standard for all Java .class files
- 0x4D 5A ascii MZ is standard for all Windows PE Executables
- 0xFF D8 at the beginning, then 0x4A 46 49 46 ascii JFIF is standard in all JPEG files
Special note on Dynamic and Static Linking:
- Static linking puts copies of all the required libraries into the file.
- PRO - functions calls are faster and you don't need the libraries on your system
- CON - binary is larger and difficulty upgrading the software when components change
- Dynamic is the opposite. Library files are specified in the binary and loaded in at run time
- Dynamic linking is the default
- You can specify static linking in gcc with the --static switch
Special note on Function Overloading and Name Mangling:
- When you overload a function, that is, have multiple functions with the same names that perform different tasks based on the number or type of arguments given, the compiler has to handle this in a unique way. It assigns random names to each function in a not that really random way. More on name mangling can be found at wikipedia!
That is it for chapter 2. I should also mention that if you are having trouble getting through a book. Blogging your notes like I am doing right now is an awesome motivator and keeps your mind entertained and engaged. You may cover the material more slowly, but retention is greatly increased.
Best of luck world.
No comments:
Post a Comment