If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
filever?
On 1/30/19 2:37 PM, Carlos E.R. wrote:
On 30/01/2019 20.23, T wrote: On 1/30/19 6:26 AM, Carlos E.R. wrote: On 30/01/2019 07.47, T wrote: On 1/29/19 10:38 PM, Paul wrote: T wrote: Hi Paul, I was thinking of running an exe through hexedit, but I could be looking at thousands of line.Â* EEEEE. Also, the perl module will be running under Linux. Then just use the "file" command: Legolas:/windows/C/Windows # file *exe HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows Legolas:/windows/C/Windows # Hi Carlos, I will not be using Windows to do this, which is why I wanted to find out what the specification was.Â* But thank you anyway! Didn't you notice that I was doing that in Linux? ;-) Hint: look at the path slashes, the type of prompt... No, I missed that. Where is the file's version in your example? |
Ads |
#17
|
|||
|
|||
filever?
On 1/30/19 12:54 PM, Mayayana wrote:
"T" wrote | It seems that I have to use 3 Win32 functions: | 1. GetFileVersionInfoSize() | which gets the size of the version information. | 2. GetFileVersionInfo() | which retrieves the version information buffer. | 3. VerQueryValue() | to retrieve selected version information. | | Now, 1. and 2. work OK but 3. doesn't work! | Can someone help me please? | I don't get it. Was someone else asking about that, or you? You're on Linux but running under WINE? I don't know whether WINE has all the APIs you need, and they're somewhat funky, so it's anyone's guess whether WINE has implemented them in the same way. I think it would be easiest to just install the Windows Script Host under WINE and use that. If you want to just walk the file bytes then see my icon extractor and look up the details of the VS_VERSION_INFO resource structure. You didn't indicate whether you can use the API, but here's a basic rundown: GetFileVersionInfoSize returns the size of the data. You then allocate a byte array of that size (LSz) LSz = GetFileVersionInfoSize(filepath, junk) LRet = GetFileVersionInfo(filepath, junk, LSz, x) If LRet 0 then lret = VerQueryValue(x, "\", BufSz, LSz) if LRet 0 then CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz) x here is a pointer to the address of the first byte of the allocated array. LSz is the size of the array in bytes. BufSz is how many bytes were written to the array. The system writes the data to that array. You then copy that into a VS_FIXEDFILEINFO structure with CopyMemory. (RTLMoveMemory) VS_FIXEDFILEINFO { DWORD dwSignature; DWORD dwStrucVersion; DWORD dwFileVersionMS; DWORD dwFileVersionLS; DWORD dwProductVersionMS; DWORD dwProductVersionLS; DWORD dwFileFlagsMask; DWORD dwFileFlags; DWORD dwFileOS; DWORD dwFileType; DWORD dwFileSubtype; DWORD dwFileDateMS; DWORD dwFileDateLS; } VS_FIXEDFILEINFO; The structure is tricky. Another way of writing it is like this: DWORD dwSignature DWORD dwStrucVersion FileVerPart2 As Integer FileVerPart1 As Integer FileVerPart4 As Integer FileVerPart3 As Integer You then collect the parts like so, converting each part to a string and adding periods: part1.part2.part3.part4 to get the actual version string This looks like a Windows call. What I was after was doing a binary read on the file and locating the metadata myself. Wine does have a program for that. But then again, I was after doing it myself. |
#18
|
|||
|
|||
filever?
T wrote:
On 1/30/19 12:54 PM, Mayayana wrote: "T" wrote | It seems that I have to use 3 Win32 functions: | 1. GetFileVersionInfoSize() | which gets the size of the version information. | 2. GetFileVersionInfo() | which retrieves the version information buffer. | 3. VerQueryValue() | to retrieve selected version information. | | Now, 1. and 2. work OK but 3. doesn't work! | Can someone help me please? | I don't get it. Was someone else asking about that, or you? You're on Linux but running under WINE? I don't know whether WINE has all the APIs you need, and they're somewhat funky, so it's anyone's guess whether WINE has implemented them in the same way. I think it would be easiest to just install the Windows Script Host under WINE and use that. If you want to just walk the file bytes then see my icon extractor and look up the details of the VS_VERSION_INFO resource structure. You didn't indicate whether you can use the API, but here's a basic rundown: GetFileVersionInfoSize returns the size of the data. You then allocate a byte array of that size (LSz) LSz = GetFileVersionInfoSize(filepath, junk) LRet = GetFileVersionInfo(filepath, junk, LSz, x) If LRet 0 then lret = VerQueryValue(x, "\", BufSz, LSz) if LRet 0 then CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz) x here is a pointer to the address of the first byte of the allocated array. LSz is the size of the array in bytes. BufSz is how many bytes were written to the array. The system writes the data to that array. You then copy that into a VS_FIXEDFILEINFO structure with CopyMemory. (RTLMoveMemory) VS_FIXEDFILEINFO { DWORD dwSignature; DWORD dwStrucVersion; DWORD dwFileVersionMS; DWORD dwFileVersionLS; DWORD dwProductVersionMS; DWORD dwProductVersionLS; DWORD dwFileFlagsMask; DWORD dwFileFlags; DWORD dwFileOS; DWORD dwFileType; DWORD dwFileSubtype; DWORD dwFileDateMS; DWORD dwFileDateLS; } VS_FIXEDFILEINFO; The structure is tricky. Another way of writing it is like this: DWORD dwSignature DWORD dwStrucVersion FileVerPart2 As Integer FileVerPart1 As Integer FileVerPart4 As Integer FileVerPart3 As Integer You then collect the parts like so, converting each part to a string and adding periods: part1.part2.part3.part4 to get the actual version string This looks like a Windows call. What I was after was doing a binary read on the file and locating the metadata myself. Wine does have a program for that. But then again, I was after doing it myself. If Wine has code for this, maybe you could re-purpose that code ? Even if it isn't written in Perl. Paul |
#19
|
|||
|
|||
filever?
On 31/01/2019 19.14, T wrote:
On 1/30/19 2:37 PM, Carlos E.R. wrote: On 30/01/2019 20.23, T wrote: On 1/30/19 6:26 AM, Carlos E.R. wrote: On 30/01/2019 07.47, T wrote: On 1/29/19 10:38 PM, Paul wrote: T wrote: Hi Paul, I was thinking of running an exe through hexedit, but I could be looking at thousands of line.Â* EEEEE. Also, the perl module will be running under Linux. Then just use the "file" command: Legolas:/windows/C/Windows # file *exe HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows Legolas:/windows/C/Windows # Hi Carlos, I will not be using Windows to do this, which is why I wanted to find out what the specification was.Â* But thank you anyway! Didn't you notice that I was doing that in Linux? ;-) Hint: look at the path slashes, the type of prompt... No, I missed that. Where is the file's version in your example? I don't know if all the exes I tried are the same version, or simply it doesn't give that info. Just try "file" on those you have and see what it says... -- Cheers, Carlos. |
#20
|
|||
|
|||
filever?
On 1/31/19 10:24 AM, Paul wrote:
T wrote: On 1/30/19 12:54 PM, Mayayana wrote: "T" wrote | It seems that I have to use 3 Win32 functions: | 1. GetFileVersionInfoSize() |Â* which gets the size of the version information. | 2. GetFileVersionInfo() |Â* which retrieves the version information buffer. | 3. VerQueryValue() |Â*Â* to retrieve selected version information. | | Now, 1. and 2. work OK but 3. doesn't work! | Can someone help me please? | Â*Â* I don't get it. Was someone else asking about that, or you? You're on Linux but running under WINE? I don't know whether WINE has all the APIs you need, and they're somewhat funky, so it's anyone's guess whether WINE has implemented them in the same way. I think it would be easiest to just install the Windows Script Host under WINE and use that. Â*Â*Â* If you want to just walk the file bytes then see my icon extractor and look up the details of the VS_VERSION_INFO resource structure. Â* You didn't indicate whether you can use the API, but here's a basic rundown: GetFileVersionInfoSize returns the size of the data. You then allocate a byte array of that size (LSz) LSz = GetFileVersionInfoSize(filepath, junk) LRet = GetFileVersionInfo(filepath, junk, LSz, x) If LRet 0 then Â*Â*Â*Â* lret = VerQueryValue(x, "\", BufSz, LSz) Â*Â*Â*Â*Â*Â* if LRet 0 then Â*Â*Â*Â*Â*Â*Â*Â* CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz) Â* x here is a pointer to the address of the first byte of the allocated array. LSz is the size of the array in bytes. BufSz is how many bytes were written to the array. Â*Â* The system writes the data to that array. You then copy that into a VS_FIXEDFILEINFO structure with CopyMemory. (RTLMoveMemory) VS_FIXEDFILEINFO { Â*Â*Â*Â* DWORD dwSignature; Â*Â*Â*Â* DWORD dwStrucVersion; Â*Â*Â*Â* DWORD dwFileVersionMS; Â*Â*Â*Â* DWORD dwFileVersionLS; Â*Â*Â*Â* DWORD dwProductVersionMS; Â*Â*Â*Â* DWORD dwProductVersionLS; Â*Â*Â*Â* DWORD dwFileFlagsMask; Â*Â*Â*Â* DWORD dwFileFlags; Â*Â*Â*Â* DWORD dwFileOS; Â*Â*Â*Â* DWORD dwFileType; Â*Â*Â*Â* DWORD dwFileSubtype; Â*Â*Â*Â* DWORD dwFileDateMS; Â*Â*Â*Â* DWORD dwFileDateLS; } VS_FIXEDFILEINFO; Â* The structure is tricky. Another way of writing it is like this: Â*Â*Â*Â* DWORD dwSignature Â*Â*Â*Â* DWORD dwStrucVersion Â*Â*Â*Â* FileVerPart2 As Integer Â*Â*Â*Â* FileVerPart1 As Integer Â*Â*Â*Â* FileVerPart4 As Integer Â*Â*Â*Â* FileVerPart3 As Integer You then collect the parts like so, converting each part to a string and adding periods: part1.part2.part3.part4 Â*Â*Â* to get the actual version string This looks like a Windows call. What I was after was doing a binary read on the file and locating the metadata myself. Wine does have a program for that.Â* But then again, I was after doing it myself. If Wine has code for this, maybe you could re-purpose that code ? Even if it isn't written in Perl. Â*Â* Paul I looked at https://metacpan.org/pod/release/ALE...er-0.02/Ver.pm yesterday, but could not figure out where they were reading the metadata. I think Wine's stuff is all written in C. I can almost, sort of, kind of understand C. My hat is off to C programmers. |
#21
|
|||
|
|||
filever?
On 1/31/19 10:41 AM, Carlos E.R. wrote:
On 31/01/2019 19.14, T wrote: On 1/30/19 2:37 PM, Carlos E.R. wrote: On 30/01/2019 20.23, T wrote: On 1/30/19 6:26 AM, Carlos E.R. wrote: On 30/01/2019 07.47, T wrote: On 1/29/19 10:38 PM, Paul wrote: T wrote: Hi Paul, I was thinking of running an exe through hexedit, but I could be looking at thousands of line.Â* EEEEE. Also, the perl module will be running under Linux. Then just use the "file" command: Legolas:/windows/C/Windows # file *exe HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows Legolas:/windows/C/Windows # Hi Carlos, I will not be using Windows to do this, which is why I wanted to find out what the specification was.Â* But thank you anyway! Didn't you notice that I was doing that in Linux? ;-) Hint: look at the path slashes, the type of prompt... No, I missed that. Where is the file's version in your example? I don't know if all the exes I tried are the same version, or simply it doesn't give that info. Just try "file" on those you have and see what it says... $ file filever.exe filever.exe: PE32 executable (console) Intel 80386, for MS Windows Reading the man page does not show it reading metadata. I have been googling around and finding all find of windows calls but no definition of where metadata is stored. Perl 5 has has a version module, but as far as I can tell it is calling a Windows API |
#22
|
|||
|
|||
filever?
On 1/30/19 2:37 PM, Carlos E.R. wrote:
Hint: look at the path slashes, the type of prompt... I sometimes almost go out of my mind switching back and forth between back slashes in Windows and forward slashes in Linux. :'( The big funny in Perl is taming the \/\/\\\/\/\// monster in regexes :'( :'( Once you get regex's down, they are kind of fun. |
#23
|
|||
|
|||
filever?
"T" wrote
| This looks like a Windows call. | Yes. You posted something, apparently from someone else, about having trouble with the call, so I posted the way to do it. I assume you're in WINE if you're tryoing to explore Windows PE files. WINE supports most of the basic Win32 API. So if you write something in Perl that uses the Win32 Perl module it will probably work. | What I was after was doing a binary read on the file | and locating the metadata myself. That's certainly doable. As I said above, if you want to do it directly then download my icon extractor script and look up the layout of the VS_VERSION_INFO resource. Doesn't Perl have the ability to parse byte data? If so then you just need to walk the PE header to the resource section and get the data. Or if you want to use a half-assed hack that wil probably be fine in most cases, look for the string VS_VERSION_INFO, then look ahead from there for the file version string, then get the bytes after that. It should be hard to work out the layout by looking at the FILEVERSIONINFO enum. |
#24
|
|||
|
|||
filever?
T wrote:
On 1/31/19 10:24 AM, Paul wrote: T wrote: On 1/30/19 12:54 PM, Mayayana wrote: "T" wrote | It seems that I have to use 3 Win32 functions: | 1. GetFileVersionInfoSize() | which gets the size of the version information. | 2. GetFileVersionInfo() | which retrieves the version information buffer. | 3. VerQueryValue() | to retrieve selected version information. | | Now, 1. and 2. work OK but 3. doesn't work! | Can someone help me please? | I don't get it. Was someone else asking about that, or you? You're on Linux but running under WINE? I don't know whether WINE has all the APIs you need, and they're somewhat funky, so it's anyone's guess whether WINE has implemented them in the same way. I think it would be easiest to just install the Windows Script Host under WINE and use that. If you want to just walk the file bytes then see my icon extractor and look up the details of the VS_VERSION_INFO resource structure. You didn't indicate whether you can use the API, but here's a basic rundown: GetFileVersionInfoSize returns the size of the data. You then allocate a byte array of that size (LSz) LSz = GetFileVersionInfoSize(filepath, junk) LRet = GetFileVersionInfo(filepath, junk, LSz, x) If LRet 0 then lret = VerQueryValue(x, "\", BufSz, LSz) if LRet 0 then CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz) x here is a pointer to the address of the first byte of the allocated array. LSz is the size of the array in bytes. BufSz is how many bytes were written to the array. The system writes the data to that array. You then copy that into a VS_FIXEDFILEINFO structure with CopyMemory. (RTLMoveMemory) VS_FIXEDFILEINFO { DWORD dwSignature; DWORD dwStrucVersion; DWORD dwFileVersionMS; DWORD dwFileVersionLS; DWORD dwProductVersionMS; DWORD dwProductVersionLS; DWORD dwFileFlagsMask; DWORD dwFileFlags; DWORD dwFileOS; DWORD dwFileType; DWORD dwFileSubtype; DWORD dwFileDateMS; DWORD dwFileDateLS; } VS_FIXEDFILEINFO; The structure is tricky. Another way of writing it is like this: DWORD dwSignature DWORD dwStrucVersion FileVerPart2 As Integer FileVerPart1 As Integer FileVerPart4 As Integer FileVerPart3 As Integer You then collect the parts like so, converting each part to a string and adding periods: part1.part2.part3.part4 to get the actual version string This looks like a Windows call. What I was after was doing a binary read on the file and locating the metadata myself. Wine does have a program for that. But then again, I was after doing it myself. If Wine has code for this, maybe you could re-purpose that code ? Even if it isn't written in Perl. Paul I looked at https://metacpan.org/pod/release/ALE...er-0.02/Ver.pm yesterday, but could not figure out where they were reading the metadata. I think Wine's stuff is all written in C. I can almost, sort of, kind of understand C. My hat is off to C programmers. In the XS folder. https://metacpan.org/source/BRAD/Win...rsionInfo-0.07 Paul |
#25
|
|||
|
|||
filever?
On 31/01/2019 19.54, T wrote:
On 1/31/19 10:41 AM, Carlos E.R. wrote: On 31/01/2019 19.14, T wrote: On 1/30/19 2:37 PM, Carlos E.R. wrote: On 30/01/2019 20.23, T wrote: On 1/30/19 6:26 AM, Carlos E.R. wrote: On 30/01/2019 07.47, T wrote: On 1/29/19 10:38 PM, Paul wrote: T wrote: Hi Paul, I was thinking of running an exe through hexedit, but I could be looking at thousands of line.Â* EEEEE. Also, the perl module will be running under Linux. Then just use the "file" command: Legolas:/windows/C/Windows # file *exe HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows Legolas:/windows/C/Windows # Hi Carlos, I will not be using Windows to do this, which is why I wanted to find out what the specification was.Â* But thank you anyway! Didn't you notice that I was doing that in Linux? ;-) Hint: look at the path slashes, the type of prompt... No, I missed that. Where is the file's version in your example? I don't know if all the exes I tried are the same version, or simply it doesn't give that info. Just try "file" on those you have and see what it says... $ file filever.exe filever.exe: PE32 executable (console) Intel 80386, for MS Windows Reading the man page does not show it reading metadata. I have been googling around and finding all find of windows calls but no definition of where metadata is stored. I could, but I don't remember well. It is not metadata, it is just a header. There is a definition of the exe file, what is stored where. And there a header that tells where are the main things. The "internals" book explained it all. https://en.wikipedia.org/wiki/.exe See "dos stub" and "Portable Executable". The later has the table on the right with the structure, which you have to replicate. Perl 5 has has a version module, but as far as I can tell it is calling a Windows API Well, obviously, if the API is available it makes things far easier. I would be using Wine instead: it is impossible for wine to load programs unless it can decode the exe header properly. -- Cheers, Carlos. |
#26
|
|||
|
|||
filever?
| Perl 5 has has a version module, but as far as I can tell
| it is calling a Windows API | | Well, obviously, if the API is available it makes things far easier. I | would be using Wine instead: it is impossible for wine to load programs | unless it can decode the exe header properly. | It's pretty much all API. The winos have created libraries to translate Win32 API calls into Linux equivalents. It's hooking them as the calls are made. Unfortunately, the docs are wanting and the correlation is a mess. There's no way to check for, say, a user32 function because it might not be in the WINE version of user32. It would make sense for Perl to be using API because that's the root method. That's what Windows is: A lot of methods that allow software to use the hardware and perform various functions. Likewise, if you use Windows Script Host and call FSO.GetFileVersion, that's coming from scrrun.dll, which is wrapping the functions from version.dll. If you call a .Net function I have no doubt that's also just a wrapper around version.dll. Version.dll is the direct route, short of parsing the bytes directly. |
#27
|
|||
|
|||
filever?
On 1/31/19 6:07 PM, Carlos E.R. wrote:
On 31/01/2019 19.54, T wrote: On 1/31/19 10:41 AM, Carlos E.R. wrote: On 31/01/2019 19.14, T wrote: On 1/30/19 2:37 PM, Carlos E.R. wrote: On 30/01/2019 20.23, T wrote: On 1/30/19 6:26 AM, Carlos E.R. wrote: On 30/01/2019 07.47, T wrote: On 1/29/19 10:38 PM, Paul wrote: T wrote: Hi Paul, I was thinking of running an exe through hexedit, but I could be looking at thousands of line.Â* EEEEE. Also, the perl module will be running under Linux. Then just use the "file" command: Legolas:/windows/C/Windows # file *exe HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows Legolas:/windows/C/Windows # Hi Carlos, I will not be using Windows to do this, which is why I wanted to find out what the specification was.Â* But thank you anyway! Didn't you notice that I was doing that in Linux? ;-) Hint: look at the path slashes, the type of prompt... No, I missed that. Where is the file's version in your example? I don't know if all the exes I tried are the same version, or simply it doesn't give that info. Just try "file" on those you have and see what it says... $ file filever.exe filever.exe: PE32 executable (console) Intel 80386, for MS Windows Reading the man page does not show it reading metadata. I have been googling around and finding all find of windows calls but no definition of where metadata is stored. I could, but I don't remember well. It is not metadata, it is just a header. There is a definition of the exe file, what is stored where. And there a header that tells where are the main things. The "internals" book explained it all. https://en.wikipedia.org/wiki/.exe See "dos stub" and "Portable Executable". The later has the table on the right with the structure, which you have to replicate. Perl 5 has has a version module, but as far as I can tell it is calling a Windows API Well, obviously, if the API is available it makes things far easier. I would be using Wine instead: it is impossible for wine to load programs unless it can decode the exe header properly. I am using Linux Perl 6. The Windows Perl 5 module for this does a system call. Is this what you are referring to? https://en.wikipedia.org/wiki/Portab...VG_f ixed.svg I am not seeing the version number in the table. I could be blind. |
#28
|
|||
|
|||
filever?
On 1/31/19 5:50 PM, Paul wrote:
T wrote: On 1/31/19 10:24 AM, Paul wrote: T wrote: On 1/30/19 12:54 PM, Mayayana wrote: "T" wrote | It seems that I have to use 3 Win32 functions: | 1. GetFileVersionInfoSize() |Â* which gets the size of the version information. | 2. GetFileVersionInfo() |Â* which retrieves the version information buffer. | 3. VerQueryValue() |Â*Â* to retrieve selected version information. | | Now, 1. and 2. work OK but 3. doesn't work! | Can someone help me please? | Â*Â* I don't get it. Was someone else asking about that, or you? You're on Linux but running under WINE? I don't know whether WINE has all the APIs you need, and they're somewhat funky, so it's anyone's guess whether WINE has implemented them in the same way. I think it would be easiest to just install the Windows Script Host under WINE and use that. Â*Â*Â* If you want to just walk the file bytes then see my icon extractor and look up the details of the VS_VERSION_INFO resource structure. Â* You didn't indicate whether you can use the API, but here's a basic rundown: GetFileVersionInfoSize returns the size of the data. You then allocate a byte array of that size (LSz) LSz = GetFileVersionInfoSize(filepath, junk) LRet = GetFileVersionInfo(filepath, junk, LSz, x) If LRet 0 then Â*Â*Â*Â* lret = VerQueryValue(x, "\", BufSz, LSz) Â*Â*Â*Â*Â*Â* if LRet 0 then Â*Â*Â*Â*Â*Â*Â*Â* CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz) Â* x here is a pointer to the address of the first byte of the allocated array. LSz is the size of the array in bytes. BufSz is how many bytes were written to the array. Â*Â* The system writes the data to that array. You then copy that into a VS_FIXEDFILEINFO structure with CopyMemory. (RTLMoveMemory) VS_FIXEDFILEINFO { Â*Â*Â*Â* DWORD dwSignature; Â*Â*Â*Â* DWORD dwStrucVersion; Â*Â*Â*Â* DWORD dwFileVersionMS; Â*Â*Â*Â* DWORD dwFileVersionLS; Â*Â*Â*Â* DWORD dwProductVersionMS; Â*Â*Â*Â* DWORD dwProductVersionLS; Â*Â*Â*Â* DWORD dwFileFlagsMask; Â*Â*Â*Â* DWORD dwFileFlags; Â*Â*Â*Â* DWORD dwFileOS; Â*Â*Â*Â* DWORD dwFileType; Â*Â*Â*Â* DWORD dwFileSubtype; Â*Â*Â*Â* DWORD dwFileDateMS; Â*Â*Â*Â* DWORD dwFileDateLS; } VS_FIXEDFILEINFO; Â* The structure is tricky. Another way of writing it is like this: Â*Â*Â*Â* DWORD dwSignature Â*Â*Â*Â* DWORD dwStrucVersion Â*Â*Â*Â* FileVerPart2 As Integer Â*Â*Â*Â* FileVerPart1 As Integer Â*Â*Â*Â* FileVerPart4 As Integer Â*Â*Â*Â* FileVerPart3 As Integer You then collect the parts like so, converting each part to a string and adding periods: part1.part2.part3.part4 Â*Â*Â* to get the actual version string This looks like a Windows call. What I was after was doing a binary read on the file and locating the metadata myself. Wine does have a program for that.Â* But then again, I was after doing it myself. If Wine has code for this, maybe you could re-purpose that code ? Even if it isn't written in Perl. Â*Â*Â* Paul I looked at https://metacpan.org/pod/release/ALE...er-0.02/Ver.pm yesterday, but could not figure out where they were reading the metadata. I think Wine's stuff is all written in C.Â* I can almost, sort of, kind of understand C.Â* My hat is off to C programmers. In the XS folder. https://metacpan.org/source/BRAD/Win...rsionInfo-0.07 Â*Â* Paul That looks like C to me. I am not seeing how to find the version structure other than the GetFileVersionInfo ( file ) call. I am not real good at C. |
#29
|
|||
|
|||
filever?
On 2/1/19 3:57 PM, RBFrank wrote:
On Fri, 1 Feb 2019 15:31:29 -0800, T wrote: On 1/31/19 4:03 PM, Mayayana wrote: I assume you're in WINE I am in raw Linux and using Perl 6 (not Perl 5). I have WINE installed, but am not using it for this. That's certainly doable. As I said above, if you want to do it directly then download my icon extractor script and look up the layout of the VS_VERSION_INFO resource. Is that a Windows program? Doesn't Perl have the ability to parse byte data? beyond your wildest imagination. If so then you just need to walk the PE header to the resource section and get the data. Or if you want to use a half-assed hack that wil probably be fine in most cases, look for the string VS_VERSION_INFO Is this is your program or hex edit? , then look ahead from there for the file version string, then get the bytes after that. It should be hard to work out the layout by looking at the FILEVERSIONINFO enum. What do I look for in Hex Edit? Judging by the types of questions you're asking, it seems that you might not be qualified for this task. Mumble. Apparently, no one else is either. I have been googling my ass off looking for the definition of this metadata and where to look for it. I get back a lot of systems calls. Dot Net has a beautiful one. But no one will tell me where to look. In addition to what you've been given already, you could take a target file and check its version info in Windows, then do a byte-level review of the file to find the version string, then back up from there to see what any headers might look like. See if you can find a marker that tells you that you've definitely found the version string. After that, it's off to the races. I have been looking around various exe's with hexedit seeing if I can find some commonality. What I really, really could use if the definition of this metadata so I knew where to look. Once I know where to look, digging out the version is child's play with Perl (6). |
#30
|
|||
|
|||
filever?
T wrote:
On 2/1/19 3:57 PM, RBFrank wrote: On Fri, 1 Feb 2019 15:31:29 -0800, T wrote: On 1/31/19 4:03 PM, Mayayana wrote: I assume you're in WINE I am in raw Linux and using Perl 6 (not Perl 5). I have WINE installed, but am not using it for this. That's certainly doable. As I said above, if you want to do it directly then download my icon extractor script and look up the layout of the VS_VERSION_INFO resource. Is that a Windows program? Doesn't Perl have the ability to parse byte data? beyond your wildest imagination. If so then you just need to walk the PE header to the resource section and get the data. Or if you want to use a half-assed hack that wil probably be fine in most cases, look for the string VS_VERSION_INFO Is this is your program or hex edit? , then look ahead from there for the file version string, then get the bytes after that. It should be hard to work out the layout by looking at the FILEVERSIONINFO enum. What do I look for in Hex Edit? Judging by the types of questions you're asking, it seems that you might not be qualified for this task. Mumble. Apparently, no one else is either. I have been googling my ass off looking for the definition of this metadata and where to look for it. I get back a lot of systems calls. Dot Net has a beautiful one. But no one will tell me where to look. In addition to what you've been given already, you could take a target file and check its version info in Windows, then do a byte-level review of the file to find the version string, then back up from there to see what any headers might look like. See if you can find a marker that tells you that you've definitely found the version string. After that, it's off to the races. I have been looking around various exe's with hexedit seeing if I can find some commonality. What I really, really could use if the definition of this metadata so I knew where to look. Once I know where to look, digging out the version is child's play with Perl (6). My problem is, I can't even make a list of all the file formats to be analyzed. I can't be certain that I would have a complete set. It's one thing to find a little info in isolation, but does this cover everything I'll find in the wild ? For example, MINGW compiled programs are debugged in gdb, while Visual Studio compiled programs are debugged in windbg. Because apparently at some level, they're not the same thing. How many variants are there ? How many articles like this must I collect before writing a "windows loader with metadata spigot out the side". https://en.wikibooks.org/wiki/X86_Di...ecutable_Files Apparently one popular way of identifying one type of executable, is to "load" it. Rather than do static analysis. Maybe that's used for some .NET stuff. The Windows Ecosystem is exploding right now. Just yesterday I tried to use a Sysinternals program and it says "unrecognized reparse point". If would seem the Sysinternals (small) team can't keep up with the changes either. How is some small developer in the woods, without access to all the header files, going to figure stuff out ? I wouldn't even trust Visual Studio header files to do it, since they could easily just "toss unsupported OSes" on the side of the road, leaving a "historical gap" in any utilities you write which might be dealing with older disks. If you have an "authoritative utility" to emulate, at least that's a start. It's almost as bad as loading MS Office files from the dawn of time. There are two 500 page documents explaining how. But, do they include everything ? After all, no MS version of Office loads everything. There's always something that doesn't work properly. Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|