According to this article http://msdn.microsoft.com/en-us/library/ms809762.aspx?ppud=4
we can name the PE sections with custom names.
So in a PE file which its creator has replaced the sections names with his own names,
now if the ".pdata" section for example isn't called ".pdata" anymore so I can't find it by its name.
how can I find the ".pdata"?
Correct, according to the Windows Portable Executable specification and other source like the ones of Matt Pietrek, sections Names are made for the humans! Typically compilers set "standard" names for specific types of sections content (e.g. ".text" for code, etc..). But, these names are fully ignored by the loader. These sections names can be modified using different methods (using pragma or other tools e.g Peid, etc..). The section of interest (.pdata) is associated the IMAGE_DIRECTORY_ENTRY_EXCEPTION directory.
To find the .pdata section (which is BTW an indicator that the image is 64bit) when it has been renamed, all you need to do is to search for the IMAGE_DIRECTORY_ENTRY_EXCEPTION directory, and based on its content, retrieve the section it is located in (as you can do for all directories).
Related
When looking at PE files in a hex editor, I often encountered some bytes between the section table and the first section, which doesn't really make sense to me. As far as I am concerned, there should be a 00-byte padding in order to fit the alignment. However, here is a screenshot which demonstrates the opposite:
As it turned out the highlighted block is pretty much the Bound Import Table. But I am still confused. Why is this table not located in a section? Is this always the case or is it just the specification of a certain compiler/linker? I did not find any documentation on this specific issue. Everything one can find on this topic basically says:
DOS MZ Header
DOS Stub
PE Header
Section Table
Section 1
Section 2
Section 3
... and so on
Before I encountered this issue I was not even aware of the fact, that there can be things outside of the sections (besides the ones i listed above, of course).
[EDIT]
Proof of concept (Since Mox did not believe me):
Data directories such as the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT can exist outside of sections. Another example of a data directory existing outside of any known section would be the IMAGE_DIRECTORY_ENTRY_CERTIFICATE data directory which is the data directory used to store the certificate information when an executable is signed.
Data directories can point to data outside of a section, with-in a section, or they can point to the entire section. The IMAGE_DIRECTORY_ENTRY_RESOURCE data directory points to the entire ".rsrc" section. Certain data directories point to known sections and these are documented in the PE format specification by Microsoft.
Items like the bound import table can be written wherever the linker wants to put them in the raw image. It just overwrites the zero bytes with the table and makes the pointer correct in the data directory. You could probably even overwrite the middle of the DOS header or stub with the import table and it would work as long as the pointer in the directory was correct.
As far as I can see with LordPe, the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry of iexplore.exe is empty.
both 32bit and 64bit versions of IEXPLORE.EXE don't have IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entries.
Here a snaphot of LordPE, showing the 64bit version of IEXPLORE.EXE on a Windows 7 machine and (in green) the missing IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry:
It looks like you don't look at the right directory entry.
I need to read the ".pdata" section of a x64 PE file.
I've seen that the structures in the ".pdata" section differ from one platform to another
http://msdn.microsoft.com/en-us/library/aa448751.aspx
It also says the same thing in the PE specifications document.
But I dont understand what it is for the regular windows (XP/Vista/Win7 etc.)
Does anybody what it is?
The .pdata section is an array of RUNTIME_FUNCTION. It gives you a code range (first two members) and an RVA to the corresponding UNWIND_INFO.
From there you get info like exception handler RVA, size of prolog, etc.
Products like Picasa build databases that include metadata about files. Captions, keywords locations and the like.
Files have a number of attributes that is dependant on the file type and / or the application that produced the file.
My question is can I programmatically add a tag to a file and then use this tag to search for content.
Eg. Text files include Name, Type, Folder Path, Size, Date Created, Date Modified, Attributes, Owner, Computer. How can I add a "Keywords" attribute?
I am interested in a solution in C# but am primarily asking for help in understanding how this functionality could be implemented in Windows operating systems.
Thank you
You can try to use Extended Attributes, but they don't have a good API in Windows and in general are not widely used. There also exist Alternate Data Streams, but these are ,as the name suggests, data streams, and not attributes.
One of the field of the IMAGE_EXPORT_DIRECTORY structure is 'Name'. According to the COFF spec, this field contains the name of the PE file which exports the symbols. I can programmatically read this field. It does really reference the name of the file which exports the symbols. But, can someone explains the meaning of this field? Why does it actually exist? It looks like it could be used as double-check..
The Name field in IMAGE_EXPORT_DIRECTORY contains the internal name of the module (i.e. original name that was used while building the module). This is useful in the cases where the actual file itself is renamed. For example, NT kernel that supports PAE is named as ntkrnlpa.exe. But, the Name field in its IMAGE_EXPORT_DIRECTORY struct still contains ntoskrnl.exe.
AFAIK, .dll is in PE format, what about .lib?
There is 2 kind of files with .lib extension :
the static library (for static linking)
The import library (for dynamic linking)
Both are an archive of COFF files. The format of this archive is an 'ar archive'.
The unix (cygwin/mingw) command ar can parse this file like the tar command does.
If you want to see the archived file in a .lib, you can do:
ar tv <name>.lib
Generally, if you see .obj file, it means that it is a static library.
If you see .dll then it is an import library.
I always though they were COFF format
See here for more info: http://support.microsoft.com/?id=121460 (archive)
Common Object File Format (COFF)
Article ID: Q121460
Creation Date: 05-OCT-1994
Revision Date: 12-OCT-1994
The information in this article applies to:
Microsoft Windows NT operating system version 3.1
Microsoft Windows NT Advanced Server version 3.1
Microsoft Windows NT Workstation version 3.5
Microsoft Windows NT Server version 3.5
SUMMARY
Windows NT uses a special format for the executable (image) files and object files. The format used in these files are referred to as Portable Executable (PE) or Common Object File Format (COFF) files. The name Portable Executable refers to the fact that executable files can run on more than one platform. This article describes in detail the internal features of PE/COFF file formats and its parameters.
MORE INFORMATION
The PE/COFF file headers consist of a MS-DOS stub, file signature, COFF Header, and Optional Header. An object file contains only the COFF Header, but an image file contains all the headers described above. The most important of these headers is the COFF header. The table below describes the information stored in the COFF header.
Offset Size Field Description
0 2 Machine Number identifying type of target machine.
2 2 Number of Sections Number of sections; indicates size of the
Section Table, which immediately follows
the headers.
4 4 Time/Date Stamp Time and date the file was created.
8 4 Pointer to Symbol Offset, within the COFF file, of the symbol
Table table.
12 4 Number of Symbols Number of entries in the symbol table.
This data can be used in locating the
string table, which immediately follows
the symbol table.
16 2 Optional Header Size of the optional header, which is
Size included for executable files but not
object files. An object file should have a
value of 0 here.
18 2 Characteristics Flags indicating attributes of the file.
Windows NT Software Development Kit (SDK) provides a utility called
DUMPBIN. DUMPBIN is a 32-bit tool that displays information about 32-bit
Common Object File Format (COFF) binary files. DUMPBIN runs only from a
command prompt. You can use DUMPBIN to examine the following kinds of COFF
files: object files, standard libraries of COFF objects, executable files,
and dynamic-link library (DLL) files.
To run DUMPBIN, use the following syntax:
DUMPBIN [options] [files]
The following are options parameters and definitions for DUMPBIN:
/ALL
/ARCHIVEMEMBERS
/DISASM
/EXPORTS
/HEADERS
/IMPORTS
/LINENUMBERS
/LINKERMEMBER[:{1|2}]
/OUT:filename
/PDATA
/RAWDATA[:{NONE|BYTES|SHORTS|LONGS}[,#]]
/RELOCATIONS
/SECTION:name
/SUMMARY
/SYMBOLS
Options Definition
/ALL Setting this option causes DUMPBIN to display all
available information except code disassembly.
/ARCHIVEMEMBERS Setting this option causes DUMPBIN to display minimal
information about member objects in a library.
/DISASM Setting this option causes DUMPBIN to show disassembly
of code sections, using symbols if present in the file.
/EXPORTS This option causes DUMPBIN to list all definitions
exported from an executable file or DLL.
/HEADERS Setting this option causes DUMPBIN to display the file
header and the header for each section. When used with a
library, displays the header for each member object.
/IMPORTS This option causes DUMPBIN to list all definitions
imported to an executable file or DLL.
/LINENUMBERS Setting this option causes DUMPBIN to show COFF line
numbers. Line numbers exist in an object file if it was
compiled with /Zi. An executable file or DLL contains
COFF line numbers if it was linked with /DEBUG and
/DEBUGTYPE:COFF option.
/LINKERMEMBER [[:{1|2}]]
Setting this option causes DUMPBIN to list public symbols
defined in a library. Specify the 1 argument to display
symbols in object order, along with their offsets. Specify
the 2 argument to display offsets and index numbers of
objects, then list the symbols in alphabetical order along
with the object index for each. To get both outputs,
specify /LINKERMEMBER without the number argument.
/OUT:<filename> This option specifies a filename for the output.
/RAWDATA [[:{BYTES|SHORTS|LONGS|NONE}[[,number]]]]
Setting this option causes DUMPBIN to display the raw
contents of each section in the file. The arguments
control the format of the display, as follows:
Argument - Result
BYTES - The default. Contents are displayed in hexadecimal bytes,
and also as ASCII if they have a printed representation.
SHORTS - Contents are displayed in hexadecimal words.
LONGS - Contents are displayed in hexadecimal longwords.
NONE - Raw data is suppressed. This is useful to control the
output of /ALL.
number - Displayed lines are set to a width that holds number
values per line.
/RELOCATIONS Setting this option causes DUMPBIN to display any
relocations in the object or image.
/SECTION: <section>
This option restricts the output to information on the
specified section.
/SUMMARY Setting this option causes DUMPBIN to display minimal
information about sections, including total size. This
option is the default if no other option is specified
in a DUMPBIN command.
/SYMBOLS Setting this option causes DUMPBIN to display the COFF symbol
table. Symbol tables exist in all object files. A COFF symbol
table appears in an image file only if it is linked with
/DEBUG /DEBUGTYPE:COFF
Some compilers (eg. Microsoft) use COFF format and some (eg. Borland/Codegear) use OMF format.
Here's description of microsoft's Lib file (same content, working link) format.
Examining a lib file in a hex editor (Visual Studio 2010), the data seems to be the same as an .a file on unix... an ar archive. It has two special files (with empty names) in the beginning that are some sort of symbol list.
EDIT: found a duplicate question Which format does static library (*.lib) files use? Where can I find "Official" specifications of *.LIB file structure/format? - it has a link that confirms this.
If you're interested in actually viewing the contents:
Wayne J. Radburn's PEView can decode it
and 7-zip can also give limited view of it