Friday, January 23, 2009
More syscall ordinals
Daniel Reynaud has improved on the script I described a while ago and has posted on his blog the system call ordinals for Windows XP SP2 x64.
pefile and LOAD_CONFIG
Following a conversation in twitter I've noticed pefile was lacking support for parsing one data directory in the PE format that is rather interesting, the IMAGE_LOAD_CONFIG_DIRECTORY.
I've added support for it and fixed a few small bugs and released it as pefile-1.2.10-60
Now one can access this structure's fields like, for instance, pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SecurityCookie or pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SEHandlerTable and also modify their values and write the result to a new PE file, all the usual handling & mangling that pefile allows.
I've added support for it and fixed a few small bugs and released it as pefile-1.2.10-60
Now one can access this structure's fields like, for instance, pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SecurityCookie or pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SEHandlerTable and also modify their values and write the result to a new PE file, all the usual handling & mangling that pefile allows.
Thursday, January 08, 2009
Tips and tricks
A couple of interesting things I've found out lately:
When packaging the latest pefile I noticed the dot-underscore files in the tar.gz. If one extracts the contents there are no such files to be found (if you're working on OSX) while they will show up in other operating systems. Those dot-underscore files are OSX way of storing the resource fork (metainformaion). While it might be handy to keep it around when moving files between Macs, it's not nice to have such dot-underscore files show up in other systems. How to get rid of them is not too well documented.
There are two oddly named environment variables (they changed between OSX versions) that control the creation of such files. Setting the following envionment variables to 'true' will make tar not create those dot-underscore files when archiving a file with a resource fork.
One can just set them in the python setup.py script, so when the source distribution is created, no resource forks are dumped into those files.
In my case it was TextMate that was using a resource fork to store some metainformation about the Python files I was working with.
Now a useful tip for subversion. I always knew CVS and subversion had to have such feature but never was able to find how to use, I finally tracked it down.
This might not be knew to anyone that has spent some time with svn... but was to me. The things is, I was sure there had to be a comfortable way of having SVN automatically add the revision number to the source code. That would allow to have version numbers with a revision appended to them automatically, which would make lots of things much nicer, like tracking errors with specific versions.
To achieve that, one can use subversion keywords. SVN will replace those keywords with the appropriate information. In this case the cool one is "$LastChangedRevision$", whereever we write it, it will get replaced by "$LastChangedRevision: XXX $" where XXX is the revision number.
You need to tell subversion you want it to replace that keyword in a given file(s). To do that just issue a: svn propset svn:keywords "Rev" path/to/the/file to set the property on that file.
A practical example for Python code would be:
The keyword would be replaced as described above and then we can fetch the revision number and add it to the version number transparently. Subversion will handle it cleanly.
When packaging the latest pefile I noticed the dot-underscore files in the tar.gz. If one extracts the contents there are no such files to be found (if you're working on OSX) while they will show up in other operating systems. Those dot-underscore files are OSX way of storing the resource fork (metainformaion). While it might be handy to keep it around when moving files between Macs, it's not nice to have such dot-underscore files show up in other systems. How to get rid of them is not too well documented.
There are two oddly named environment variables (they changed between OSX versions) that control the creation of such files. Setting the following envionment variables to 'true' will make tar not create those dot-underscore files when archiving a file with a resource fork.
| COPYFILE_DISABLE COPY_EXTENDED_ATTRIBUTES_DISABLE |
One can just set them in the python setup.py script, so when the source distribution is created, no resource forks are dumped into those files.
| import os os.environ['COPY_EXTENDED_ATTRIBUTES_DISABLE'] = 'true' os.environ['COPYFILE_DISABLE'] = 'true' |
In my case it was TextMate that was using a resource fork to store some metainformation about the Python files I was working with.
Now a useful tip for subversion. I always knew CVS and subversion had to have such feature but never was able to find how to use, I finally tracked it down.
This might not be knew to anyone that has spent some time with svn... but was to me. The things is, I was sure there had to be a comfortable way of having SVN automatically add the revision number to the source code. That would allow to have version numbers with a revision appended to them automatically, which would make lots of things much nicer, like tracking errors with specific versions.
To achieve that, one can use subversion keywords. SVN will replace those keywords with the appropriate information. In this case the cool one is "$LastChangedRevision$", whereever we write it, it will get replaced by "$LastChangedRevision: XXX $" where XXX is the revision number.
You need to tell subversion you want it to replace that keyword in a given file(s). To do that just issue a: svn propset svn:keywords "Rev" path/to/the/file to set the property on that file.
A practical example for Python code would be:
| __revision__ = "$LastChangedRevision$" __version__ = '%d' % int( __revision__[21:-2] ) |
The keyword would be replaced as described above and then we can fetch the revision number and add it to the version number transparently. Subversion will handle it cleanly.
Wednesday, January 07, 2009
Updated pefile
I've just released pefile-1.2.10-56 which besides some new functionality it also fixes bugs for a few extreme cases and incorporates some performance improvements, the biggest of which is the one in the generation of the textual representation of the file. dump_info() is now much faster than it used to be.
This version adds onto the features provided by version 1.2.9 which introduced the ability to test and generate checksums for the PE file among a few other things.
Please refer to pefile's homepage for a detailed list of the changes.
Also, to get started with pefile it's often useful to take a look at usage examples. There's a wiki page in the project's page showing a few different recipes on how to go about doing different tasks. Some as simple as, for instance, extracing a DLL's exported symbols...
An all the way into more complex examples.
Enjoy!
This version adds onto the features provided by version 1.2.9 which introduced the ability to test and generate checksums for the PE file among a few other things.
Please refer to pefile's homepage for a detailed list of the changes.
Also, to get started with pefile it's often useful to take a look at usage examples. There's a wiki page in the project's page showing a few different recipes on how to go about doing different tasks. Some as simple as, for instance, extracing a DLL's exported symbols...
| import pefile pe = pefile.PE(‘/path/to/pefile.exe’) for exp in pe.DIRECTORY_ENTRY_EXPORT.symbols: print hex(pe.OPTIONAL_HEADER.ImageBase + exp.address), exp.name, exp.ordinal |
An all the way into more complex examples.
Enjoy!
Subscribe to:
Posts (Atom)