Iterating through the reports, I found that these are actually from 5 different versions of the same (renamed) DLL. Here is the info shown by WinDbg for each variant:
```
Timestamp: Mon Apr 11 13:29:20 2016 (570B8A90)
CheckSum: 00000000
ImageSize: 00062000
File version: 1.0.0.26638
Timestamp: Thu May 5 15:38:44 2016 (572B4CE4)
CheckSum: 00000000
ImageSize: 00062000
File version: 1.0.0.26793
Timestamp: Sun Aug 7 14:12:28 2016 (57A725AC)
CheckSum: 00000000
ImageSize: 00061000
File version: 1.0.0.27567
Timestamp: Sun Nov 19 11:31:29 2017 (5A115D81)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.29915
Timestamp: Tue Jun 11 12:55:52 2019 (5CFF88B8)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.31122
```
I believe the combination of the 4 first info (Timestamp, CheckSum=0, ImageSize, File version) should make collisions unlikely, so I prepared a patch to block the DLLs based on that and would be curious to have your opinion.
I also prepared a DLL that matches with the latest variation of the malicious DLL, which we can use for QA testing. Attached is the result in a custom build (right) compared to regular Nightly (left). Below is how WinDbg parses the info from the DLL:
```
start end module name
00007fff`52280000 00007fff`522dd000 Delicious (deferred)
Image path: C:\repos\HookTests\x64\Release\Delicious.dll
Image name: Delicious.dll
Browse all global symbols functions data
Timestamp: Tue Jun 11 12:55:52 2019 (5CFF88B8)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.31122
Product version: 1.0.0.1
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
Information from resource tables:
ProductVersion: 1.0.0.1
FileVersion: 1.0.0.31122
```
Bug 1841751 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Iterating through the reports, I found that these are actually from 5 different versions of the same (renamed) DLL. Here is the info shown by WinDbg for each variant:
```
Timestamp: Mon Apr 11 13:29:20 2016 (570B8A90)
CheckSum: 00000000
ImageSize: 00062000
File version: 1.0.0.26638
Timestamp: Thu May 5 15:38:44 2016 (572B4CE4)
CheckSum: 00000000
ImageSize: 00062000
File version: 1.0.0.26793
Timestamp: Sun Aug 7 14:12:28 2016 (57A725AC)
CheckSum: 00000000
ImageSize: 00061000
File version: 1.0.0.27567
Timestamp: Sun Nov 19 11:31:29 2017 (5A115D81)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.29915
Timestamp: Tue Jun 11 12:55:52 2019 (5CFF88B8)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.31122
```
I believe the combination of these four pieces of information (Timestamp, CheckSum=0, ImageSize, File version) should make collisions unlikely, so I prepared a patch to block the DLLs based on that and would be curious to have your opinion.
I also prepared a DLL that matches with the latest variation of the malicious DLL, which we can use for QA testing. Attached is the result in a custom build (right) compared to regular Nightly (left). Below is how WinDbg parses the info from the DLL:
```
start end module name
00007fff`52280000 00007fff`522dd000 Delicious (deferred)
Image path: C:\repos\HookTests\x64\Release\Delicious.dll
Image name: Delicious.dll
Browse all global symbols functions data
Timestamp: Tue Jun 11 12:55:52 2019 (5CFF88B8)
CheckSum: 00000000
ImageSize: 0005D000
File version: 1.0.0.31122
Product version: 1.0.0.1
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
Information from resource tables:
ProductVersion: 1.0.0.1
FileVersion: 1.0.0.31122
```