Open IridiumXOR opened 7 months ago
Hi,
Winbindex doesn't index ntoskrnlmp.exe
. Do you mean ntoskrnl.exe?
Also, Winbindex does extract the file version when the file is available. I'm not sure what you're referring to, is it some other metadata?
Hi, Winbindex doesn't index
ntoskrnlmp.exe
. Do you mean ntoskrnl.exe?
Yes, sorry the filename ntoskrnlmp.exe
is related to the PDB extracted from ntoskrnl.exe
, my fault... Yes, the file in Winbindex is ntoskrnl.exe
Also, Winbindex does extract the file version when the file is available. I'm not sure what you're referring to, is it some other metadata?
For example take the ntoskrnl.exe
with SHA256 a8ab1ac217c01ede2e8ec8a0d41fb6ca65844acaeb06e826e1e42844c2e28f09
this file is available to download but the reported version is ???
(Idk why, I dind't read deeply the Winbindex code for the version extraction, maybe you use the same metadata as me using the function get_file_version_info()
...)
However, in case like that I was able to extract the version from the ntoskrnl.exe
file looking for the metadata present in it (that are shown in Windows when you right click on it->Properties)
Winbindex doesn't download the files from the Symbol Server. It only downloads update packages, and queries VirusTotal for information. In this case, a8ab1ac217c01ede2e8ec8a0d41fb6ca65844acaeb06e826e1e42844c2e28f09
wasn't submitted to VirusTotal. You can submit it yourself, and you'll see that Winbindex will show its version the next day.
Also, sometimes the files that can be downloaded from the Symbol Server have a different hash. That's a known issue that Microsoft claimed is fixed for newer Windows builds, see:
Winbindex doesn't download the files from the Symbol Server. It only downloads update packages, and queries VirusTotal for information. In this case,
a8ab1ac217c01ede2e8ec8a0d41fb6ca65844acaeb06e826e1e42844c2e28f09
wasn't submitted to VirusTotal. You can submit it yourself, and you'll see that Winbindex will show its version the next day.
I have read your blogpost on how Winbindex works, not downloading from the windows symbols server. This was a suggestion to how recover the version for files for which is missing automatically (and in that case it requires, obviously, to download them...)
Also, sometimes the files that can be downloaded from the Symbol Server have a different hash. That's a known issue that Microsoft claimed is fixed for newer Windows builds, see:
* [bug - downloads wrong files #139](https://github.com/m417z/winbindex/issues/139) * [Symbol server PE files are being overwritten with different versions microsoft/Windows-Dev-Performance#102](https://github.com/microsoft/Windows-Dev-Performance/issues/102)
For kernel it happens, I think because original x86_64 kernels are called ntoskrnlmp.exe
and they continue to use this name for the PDB associated.
This was a suggestion to how recover the version for files for which is missing automatically (and in that case it requires, obviously, to download them...)
OK, I updated the title.
For kernel it happens, I think because original x86_64 kernels are called
ntoskrnlmp.exe
and they continue to use this name for the PDB associated.
That's not related. That happens because there are multiple files with the same image size and timestamp. Usually, those are files with the same code and data, but different metadata such as version info. I wrote about it in the blog post, too.
Hi, some of the kernels (
ntoskrnlmp.exe
) are reported with version???
however it is possible to extract the version of the kernel looking at its metadata. For example on Linux using something similar towrestool --extract --raw --type=version ntoskrnlmp.exe | tr '\0, ' '\t.\0' | sed 's/\t\t/_/g' | tr -c -d '[:print:]' | sed -r -n 's/.*Version[^0-9]*([0-9]+\.[0-9]+(\.[0-9]+?)\.[0-9]+?).*/\1/p'