-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extracting resources does not always result in usable files #105
Comments
A small progress on this issue, in merces/pev@465cd8b we added support for (hopefully) proper ICO extraction. |
@rmenessec would you be able to test with the latest release? Thanks. |
I can not see a bug here however I do understand the issue. Compiled This file contains various info like original file name, copyright holder, etc. It is not a script tho but just stores information. Supporting this is not a bad idea but if I am being honest here it's low priority atm. Sorry. The info is readable with PS: Don't cat binary files. Binary files can contain control characters. I don't think anything bad can happen (don't quote me on that) but you can absolutely break your terminal session. I recommend using less to view files instead. |
Just out of curiosity, parsing
So, if you only need this, you could use v0.22. It does nothing else though. 😸 |
Hi! I'd like to be able to use peres or pev more generally to get version information out of EXEs and DLLs under UNIX environments, and pev looks almost ideal. However, the extracted resources don't appear to be valid files--and it's not clear that peres attempted to transform the compiled .RC at all.
As an example, extracting the PE32+ / x86-64 binary from SIV produces a lot of directory information, as expected, and a small resources/ tree with a number of .ICO and .CUR files. Various tools at my disposal, including ExifTool, ImageMagick, file(1), and so forth don't recognize any of these as valid cursor or icon bitmaps. file(1) identifies about half the .ICOs as dBase IV databases; dedicated image processing tools refuse to recognize the files at all.
The file I'm actually most interested in is resources/versions/1.rc, which I'm guessing is a compiled .RC generated from a resource script. (I'm not completely familiar with the process of compiling Windows executables.) There are some interesting strings in here--what I was looking for originally--and what I'm guessing might be some 8- and 16-bit bit fields indicating properties.
Catting the file gets me this:
...and strings -el gets me this:
This last output looks the most useful, but it's hard to be certain whether this is a simple key-value output in the format 'key\lvalue' with some missing fields at the beginning and end, or if some of the fields contain non-string data. At any rate, file(1) doesn't think that this is a text file of any kind at all until it's run through strings(1), so I assume it's not really a simple UCS-2 or UTF-16 text file.
Is peres normally supposed to translate this format? If not, would you mind adding this feature? It would be great to get the output formatted according to the -f flag, or, if that's not possible, perhaps a decompilation back to the original resource script format? I understand that it's generally a simple plaintext format. If it's not normally an ASCII or UTF-8 file, a final, optional step converting it to either ASCII or UTF-8 would be much appreciated.
Thanks!
The text was updated successfully, but these errors were encountered: