diff --git a/SabreTools.Models/PortableExecutable/Executable.cs b/SabreTools.Models/PortableExecutable/Executable.cs index 297814e..953df28 100644 --- a/SabreTools.Models/PortableExecutable/Executable.cs +++ b/SabreTools.Models/PortableExecutable/Executable.cs @@ -1,3 +1,5 @@ +using System.Collections.Generic; + namespace SabreTools.Models.PortableExecutable { /// @@ -52,15 +54,162 @@ namespace SabreTools.Models.PortableExecutable /// public COFF.StringTable? StringTable { get; set; } + /// + /// Delay-load directory table + /// + public DelayLoad.DirectoryTable? DelayLoadDirectoryTable { get; set; } + + #region Data Directories + + /// + /// The export data section, named .edata, contains information about symbols that other images + /// can access through dynamic linking. Exported symbols are generally found in DLLs, but DLLs + /// can also import symbols. + /// + /// An overview of the general structure of the export section is described below. The tables + /// described are usually contiguous in the file in the order shown (though this is not + /// required). Only the export directory table and export address table are required to export + /// symbols as ordinals. (An ordinal is an export that is accessed directly by its export + /// address table index.) The name pointer table, ordinal table, and export name table all + /// exist to support use of export names. + /// + /// + #region Export Table (.edata) + + // TODO: Look into splitting this up + // Technically speaking, even though all of these should live in the same + // section, there is nothing in the spec that guarantees that they are together + // outside of the obvious logical grouping. The directory table is more obviously + // directly a part of the executable, while the other 4 structures are all based + // on information from that one-row table. + + /// + /// A table with just one row (unlike the debug directory). This table indicates the + /// locations and sizes of the other export tables. + /// + public Export.DirectoryTable? ExportDirectoryTable { get; set; } + + /// + /// An array of RVAs of exported symbols. These are the actual addresses of the exported + /// functions and data within the executable code and data sections. Other image files + /// can import a symbol by using an index to this table (an ordinal) or, optionally, by + /// using the public name that corresponds to the ordinal if a public name is defined. + /// + public Export.AddressTableEntry[]? ExportAddressTable { get; set; } + + /// + /// An array of pointers to the public export names, sorted in ascending order. + /// + public Export.NamePointerTable? NamePointerTable { get; set; } + + /// + /// An array of the ordinals that correspond to members of the name pointer table. The + /// correspondence is by position; therefore, the name pointer table and the ordinal table + /// must have the same number of members. Each ordinal is an index into the export address + /// table. + /// + public Export.OrdinalTable? OrdinalTable { get; set; } + + /// + /// A series of null-terminated ASCII strings. Members of the name pointer table point into + /// this area. These names are the public names through which the symbols are imported and + /// exported; they are not necessarily the same as the private names that are used within + /// the image file. + /// + public Export.NameTable? ExportNameTable { get; set; } + + #endregion + + /// + /// All image files that import symbols, including virtually all executable (EXE) files, + /// have an .idata section. A typical file layout for the import information follows: + /// + /// - Directory Table + /// Null Directory Entry + /// - DLL1 Import Lookup Table + /// Null + /// - DLL2 Import Lookup Table + /// Null + /// - DLL3 Import Lookup Table + /// Null + /// - Hint-Name Table + /// + /// + #region Import Table (.idata) and Import Address Table + + /// + /// The import information begins with the import directory table, which describes the + /// remainder of the import information. + /// + public Import.DirectoryTableEntry[]? ImportDirectoryTable { get; set; } + + /// + /// An import lookup table is an array of 32-bit numbers for PE32 or an array of 64-bit + /// numbers for PE32+. + /// + public Dictionary? ImportLookupTables { get; set; } + + /// + /// These addresses are the actual memory addresses of the symbols, although technically + /// they are still called "virtual addresses". + /// + public Dictionary? ImportAddressTables { get; set; } + + /// + /// One hint/name table suffices for the entire import section. + /// + public Import.HintNameTableEntry[]? HintNameTable { get; set; } + + #endregion + + #region Resource Table (.rsrc) + + /// + /// Resource directory table (.rsrc) + /// + public Resource.DirectoryTable? ResourceDirectoryTable { get; set; } + + #endregion + + // TODO: Handle Exception Table + + #region Certificate Table + /// /// Attribute certificate table /// public AttributeCertificate.Entry[]? AttributeCertificateTable { get; set; } + #endregion + + #region Base Relocation Table (.reloc) + /// - /// Delay-load directory table + /// Base relocation table /// - public DelayLoad.DirectoryTable? DelayLoadDirectoryTable { get; set; } + public BaseRelocation.Block[]? BaseRelocationTable { get; set; } + + #endregion + + #region Debug Data (.debug*) + + /// + /// Debug table + /// + public DebugData.Table? DebugTable { get; set; } + + #endregion + + // TODO: Handle Architecture + // TODO: Handle Global Ptr + // TODO: Thread Local Storage (.tls) + // TODO: Load Configuration Table + // TODO: Bound Import Table + // TODO: Delay Import Descriptor + // TODO: CLR Runtime Header (.cormeta) + // TODO: Reserved + + #endregion #region Named Sections @@ -68,16 +217,6 @@ namespace SabreTools.Models.PortableExecutable // the object file contains managed code. The format of the metadata is not // documented, but can be handed to the CLR interfaces for handling metadata. - /// - /// Base relocation table (.reloc) - /// - public BaseRelocation.Block[]? BaseRelocationTable { get; set; } - - /// - /// Debug table (.debug*) - /// - public DebugData.Table? DebugTable { get; set; } - // .drectve - A section is a directive section if it has the IMAGE_SCN_LNK_INFO // flag set in the section header and has the .drectve section name. The linker // removes a .drectve section after processing the information, so the section @@ -94,20 +233,7 @@ namespace SabreTools.Models.PortableExecutable // // TODO: Can we implement reading/parsing the .drectve section? - /// - /// Export table (.edata) - /// - public Export.Table? ExportTable { get; set; } - - /// - /// Import table (.idata) - /// - public Import.Table? ImportTable { get; set; } - - /// - /// Resource directory table (.rsrc) - /// - public Resource.DirectoryTable? ResourceDirectoryTable { get; set; } + // .pdata Section - Multiple formats per entry // .sxdata - The valid exception handlers of an object are listed in the .sxdata // section of that object. The section is marked IMAGE_SCN_LNK_INFO. It contains @@ -122,18 +248,6 @@ namespace SabreTools.Models.PortableExecutable #endregion - // TODO: Implement and/or document the following non-modeled parts: - // - Delay-Load Import Tables - // - [The Delay-Load Directory Table] - // - Delay Import Address Table - // - Delay Import Name Table - // - Delay Bound Import Address Table - // - Delay Unload Import Address Table - // - The .pdata Section [Multiple formats per entry] - // - The .tls Section - // - TLS Callback Functions - // - [The Load Configuration Structure (Image Only)] - // TODO: Determine if "Archive (Library) File Format" is worth modelling } } diff --git a/SabreTools.Models/PortableExecutable/Export/Table.cs b/SabreTools.Models/PortableExecutable/Export/Table.cs deleted file mode 100644 index 0ccfc3a..0000000 --- a/SabreTools.Models/PortableExecutable/Export/Table.cs +++ /dev/null @@ -1,60 +0,0 @@ -namespace SabreTools.Models.PortableExecutable.Export -{ - /// - /// The export data section, named .edata, contains information about symbols that other images - /// can access through dynamic linking. Exported symbols are generally found in DLLs, but DLLs - /// can also import symbols. - /// - /// An overview of the general structure of the export section is described below. The tables - /// described are usually contiguous in the file in the order shown (though this is not - /// required). Only the export directory table and export address table are required to export - /// symbols as ordinals. (An ordinal is an export that is accessed directly by its export - /// address table index.) The name pointer table, ordinal table, and export name table all - /// exist to support use of export names. - /// - /// - public sealed class Table - { - // TODO: Look into splitting this up - // Technically speaking, even though all of these should live in the same - // section, there is nothing in the spec that guarantees that they are together - // outside of the obvious logical grouping. The directory table is more obviously - // directly a part of the executable, while the other 4 structures are all based - // on information from that one-row table. - - /// - /// A table with just one row (unlike the debug directory). This table indicates the - /// locations and sizes of the other export tables. - /// - public DirectoryTable? ExportDirectoryTable { get; set; } - - /// - /// An array of RVAs of exported symbols. These are the actual addresses of the exported - /// functions and data within the executable code and data sections. Other image files - /// can import a symbol by using an index to this table (an ordinal) or, optionally, by - /// using the public name that corresponds to the ordinal if a public name is defined. - /// - public AddressTableEntry[]? ExportAddressTable { get; set; } - - /// - /// An array of pointers to the public export names, sorted in ascending order. - /// - public NamePointerTable? NamePointerTable { get; set; } - - /// - /// An array of the ordinals that correspond to members of the name pointer table. The - /// correspondence is by position; therefore, the name pointer table and the ordinal table - /// must have the same number of members. Each ordinal is an index into the export address - /// table. - /// - public OrdinalTable? OrdinalTable { get; set; } - - /// - /// A series of null-terminated ASCII strings. Members of the name pointer table point into - /// this area. These names are the public names through which the symbols are imported and - /// exported; they are not necessarily the same as the private names that are used within - /// the image file. - /// - public NameTable? ExportNameTable { get; set; } - } -} diff --git a/SabreTools.Models/PortableExecutable/Import/Table.cs b/SabreTools.Models/PortableExecutable/Import/Table.cs deleted file mode 100644 index 19866d4..0000000 --- a/SabreTools.Models/PortableExecutable/Import/Table.cs +++ /dev/null @@ -1,45 +0,0 @@ -using System.Collections.Generic; - -namespace SabreTools.Models.PortableExecutable.Import -{ - /// - /// All image files that import symbols, including virtually all executable (EXE) files, - /// have an .idata section. A typical file layout for the import information follows: - /// - /// - Directory Table - /// Null Directory Entry - /// - DLL1 Import Lookup Table - /// Null - /// - DLL2 Import Lookup Table - /// Null - /// - DLL3 Import Lookup Table - /// Null - /// - Hint-Name Table - /// - /// - public sealed class Table - { - /// - /// The import information begins with the import directory table, which describes the - /// remainder of the import information. - /// - public DirectoryTableEntry[]? ImportDirectoryTable { get; set; } - - /// - /// An import lookup table is an array of 32-bit numbers for PE32 or an array of 64-bit - /// numbers for PE32+. - /// - public Dictionary? ImportLookupTables { get; set; } - - /// - /// These addresses are the actual memory addresses of the symbols, although technically - /// they are still called "virtual addresses". - /// - public Dictionary? ImportAddressTables { get; set; } - - /// - /// One hint/name table suffices for the entire import section. - /// - public HintNameTableEntry[]? HintNameTable { get; set; } - } -}