[email protected]_12.23.rar (1.3 MB)
rstmwservice.exe (2022.11.21 → 2023.01.02)
The core content is the same, only the digital signature has changed.
[email protected]_12.23.rar (1.3 MB)
rstmwservice.exe (2022.11.21 → 2023.01.02)
The core content is the same, only the digital signature has changed.
@westlake
Thanks for the info and the link to Intel’s “updated” pure RST VMD driverpack v19.5.2.1049 WHQL, but I have serious doubts, that the related files have been correctly updated by Intel and digitally signed by Microsoft:
Since it seems to me, that only the VMD driver files, which are part of the complete Drivers & Software Set, have been properly updated by Intel and correctly digitally signed by Microsoft, I have replaced my previously linked VMD driverpack by the really updated one.
If you should not agree with me, please let me know it.
Thanks again!
Quick reply as to why 1) could be happening.
I’ve seen build dates stay the same even if compilation happened at different times in C and C++ codebases in order to get deterministic builds, although mostly in open source scenarios where they want to have some validation that X source release led to Y binary so anyone could check.
The size difference is because of the Microsoft countersignature, I just took a look at the binaries and save for the signatures they’re the same (i.e., signtool.exe remove /s file
produces binary identical files). I’ve seen at least one vendor (Realtek? I can’t remember) sign the same binary at different dates (and not because it was once SHA-1 and another time SHA-256), but they were not countersigned by Microsoft, it was only them and I never figured out what that was about.
Anyway, both those releases are from Nov. 2022, forging a digital signature based on SHA-256 would be news for me, there is no (known) easy way to get collisions there that I know of.
#2 Makes more sense to me, that they’re not using deterministic builds and it just was a mishap (them signing an older service executable at that time), I’d take a Microsoft countersigned binary over a vendor one any day.
Sorry to cause a problem, but the date of the files I upload in the file manager is not informative, as I always modify them. I have quite a large driver collection and it’s better for me. For me, this date is always the date in the inf file (yy.mm.dd 00:00). Otherwise, this date is not so important, since I can find out the timestamp to the second for almost every file. True, the timestamp is often earlier than the build date, but the difference is minimal (a few days at most). The old rstmwservice.exe has two digital signatures (Intel 2022.11.21, Microsoft 2022.12.23), the new one has only one (Intel 2023.01.02). The other files are indeed identical, I didn’t want to upload just the exe.
Thanks for the tip, removing the digital signatures does indeed match the two files mentioned.
I will be more careful next time.
@westlake
Thanks for your clear statement, but its content shocked me. Until today I had no doubt, that all driver files, which were uploaded and attached/linked by you in the past, were the untouched original ones.
Now I know it better.
It may be better for you and your personal driver collection, but not for the members and visitors of the Win-RAID Forum. They expect, that all attached or linked driver files, which are not clearly flagged as being modified, are the untouched original ones (as they have been released by their manufacturer).
They are indeed not untouched, but we both know that it doesn’t really matter. Its content does not change in any way. And the content is what matters. That said, I understand your point.
@westlake:
Thanks for your reply and your understanding of my point of view.
Yes, you have obviously just manipulated the file’s date, which is shown within the File Explorer, but even such “tiny” modification is absolutely misleading and not acceptable for the visitors of this Forum.
By the way - please remove the word “updated” within >this< post. The addition/removal of a digital signature is not an update of the related file.
I will remove it, but it is a factory file. Not modified by a third party. Intel has done this before, I have seen it several times. I have uploaded such a file here.
Dates in the explorer have never been reliable information. They cannot be signed and certified. We need to look at the date in the PE Header.
Example:
That was not the topic of the recent discussion. Not everyone is able or willing to use a PE Editor to find out, whether an offered driver is untouched or not.
Win-RAID Forum visitors expect to get here original or as being modified flagged drivers and not silently manipulated files.
Latest Intel RSTe driver v SATA SSDs, version 7.8.3.1006 for: SATA, sSATA, NVMe VROC.
https://support.hpe.com/hpesc/public/docDisplay?docId=a00112943en_us&docLocale=en_US&page=GUID-31F71CCE-611E-4150-8718-7FCB4A1A3346.html
Hello Fernando
I wanted to ask you if you can pass the link of the sata drivers intel 8 series type b for windows xp, I can’t find it
Thanks
@MoielHumano
Welcome to the Win-RAID Forum!
I have moved your request into this already existing thread, because you can find download links to matching Intel AHCI/RAID drivers within its first post.
If you want to install Windows XP in AHCI mode onto your Intel 8-Series chipset mobile system, I recommend use the Intel RST AHCI driver v13.2.8.1002 WHQL. You can either integrate it into the XP CD image by using >this< Guide or load it via pressing F6 at the beginning of the XP installation.
Good luck!
Dieter (alias Fernando)
The first post has been updated today by me.
By the way - the Intel RST AHCI driver v16.8.5.10214 WHQL runs fine with my old Intel Z170 chipset system.
Look here:
Intel RSTe VROC NVMe RAID drivers v8.0.3.1012 WHQL
Intel RSTe VROC SATA RAID drivers v8.0.3.1012 WHQL
@Dagal Thanks for the new Intel RSTe drivers v8.0.3.1012.
@all The first post has been updated by me.
The start post has been updated by me just now.