Download files that are missing in VirusTotal from the Symbol Server for additional information

[IridiumXOR]

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 to
wrestool --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'

[m417z]

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?

[IridiumXOR]

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)

[m417z]

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:

• bug - downloads wrong files #139
• Symbol server PE files are being overwritten with different versions microsoft/Windows-Dev-Performance#102

[IridiumXOR]

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.

[m417z]

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.