A Windows XP help forum. PCbanter

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.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

filever?



 
 
Thread Tools Rate Thread Display Modes
  #16  
Old January 31st 19, 06:14 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old January 31st 19, 06:17 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old January 31st 19, 06:24 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 31st 19, 06:41 PM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default 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  
Old January 31st 19, 06:49 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old January 31st 19, 06:54 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old January 31st 19, 06:57 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old February 1st 19, 12:03 AM posted to alt.comp.os.windows-10
Mayayana
external usenet poster
 
Posts: 6,438
Default 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  
Old February 1st 19, 01:50 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old February 1st 19, 02:07 AM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default 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  
Old February 1st 19, 03:55 AM posted to alt.comp.os.windows-10
Mayayana
external usenet poster
 
Posts: 6,438
Default 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  
Old February 1st 19, 11:20 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old February 1st 19, 11:25 PM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old February 2nd 19, 12:31 AM posted to alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default 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  
Old February 2nd 19, 01:35 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 06:13 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.