misc idea: PE/COFF data embedding...
in [ASM]
|
Prev: overflow of stack for recursive functions
Next: getting keyboard keys strokes via VMware Fusion on Apple MAC
From: BGB / cr88192 on 7 Mar 2010 23:47 the text below is from a misc email. it is an idea I had considered recently, but as of yet have not done much. I am not sure if anything similar is already in common use. some later variants on the idea had considered: really, I don't strictly need a special section, as using pretty much any section would work (assuming that a scan is done over the entire mapped image). other thoughts had considered the possibility of doing something along the lines of WAD or WAD2 (itself embedded into the EXE with a similar mechanism, or possibly based on the same mechanism). ---- as for another idle thought, I have another thought WRT adding custom metadata/... to PE/COFF: a collection of "chunks" are linked into the image in a special section, such as ".chunks". in general, the chunks section is relatively unstructured, but each chunk could contain a header: { FOURCC magic1; //"\x89\n\r\x1A" FOURCC magic2; //"CHNK" FOURCC magic3; //payload-fourcc byte head_size; //base header size byte head_flags; //base header flags u16 head_crc; //CRC16 of header //(16-bytes) u32 chunk_size; //total chunk size (includes headers) u32 flags; //chunk flags //... } beyond this, each chunk header would start on a 16-byte boundary (not difficult, as linkers do this by default). note that it is likely that some amount of scanning/matching would be used (this being a major reason for making the header so bulky and including a CRC). the idea for how this would get loaded into PE/COFF images would be that the data would be converted into COFF objects which would be linked into the image (I am assuming for now a stock linker, such as "link.exe" or similar...). I am also considering the possibility of this coexisting with CLR metadata. now, what sorts of data would be encoded here?... matadata-DB dumps (maybe a deflated version of a textual dump?... well, it is that or devise a binary serialization...); maybe symbolic-linking info (would mostly be used to key the DB against the binary code/data/... mostly because my main DB does not directly hold references to code or data); JVM-style class and jar files; ZIP files (embedded sub-files, could be accessed via the VFS). the idea is that any unknown chunks will be ignored by default. although, I guess it may be worth looking and seeing if there is some other established convention for doing something similar to this... however, at present I often store info like this in sideband files, but this would allow packaging the info directly into the PE/COFF image... then, an API could be added which could iterate over the chunks, possibly looking for chunks with a given FOURCC and returning pointers to the payload, ... (technically, the core functionality for implementing this is provided by the Win32 API). don't know if all this is a good idea though... |