Próbuję obliczyć wartości mieszania SHA1 w Pythonie na pliki binarne do późniejszego porównania. Aby upewnić się, że wszystko działa, użyłem kilku metod, aby sprawdzić ważność mojego wyniku. I cieszę się, że to zrobiłem. Powershell i Python zwracają różne wartości. Funkcja SHA1 7zip jest zgodna z wynikami Powershell, a FCIV firmy Microsoft zgadza się z wynikami Pythona.Dlaczego otrzymuję inny skrót SHA1 między Powershell i 32bit-Python w systemie DLL?
Pythonie
import hashlib
with open("C:\\Windows\\system32\\wbem\\wmiutils.dll", "rb") as f:
print(hashlib.sha1(f.read()).hexdigest())
PowerShell:
PS C:\> Get-FileHash C:\Windows\System32\wbem\wmiutils.dll -Algorithm SHA1
Wyniki:
Python: d25f5b57d3265843ed3a0e7b6681462e048b29a9
Powershell: B8C757BA70F6B145AD191A1B09C225FBA2BD55FB
Edycja: 32-bitowy Python i 64-bitowe PowerShell na dll system32. Problem polegał na tym, że . Mam trochę pracy domowej, ale w zasadzie 32-bitowe i 64-bitowe aplikacje otrzymują inny plik, a tym samym różne wyniki hash . Uruchomiłem 64-bitowy python i uruchomiłem dokładnie ten sam kod przeciwko dll i 64-bitowemu procesowi powershell. Otrzymano spójne wyniki , gdy oba procesy działają jako 32-bitowe.
EDIT2: Znaleziono ten zasób, który trochę wyjaśnia. Przynajmniej pomógł mi zrozumieć, co się dzieje: https://www.sepago.com/blog/2008/04/20/windows-x64-all-the-same-yet-very-different-part-7-file-system-and-registry
Nie pamiętam dokładnie, jak Windows to robi, ale czy to możliwe, że Python jest 32-bitowym procesem i dostajesz 32-bitową wersję pliku wmiutils.dll? Przetestuj go na innym pliku, który nie jest biblioteką dll, a nie systemem32. –
Nailed to! Uruchomiono 32-bitowe okno Powershell, które powróciło: D25F5B57D3265843ED3A0E7B6681462E048B29A9 – mustbenewhere
Może to być spowodowane różnicą w sposobie konwersji ciągu znaków na bitach Pythona/FCIV i 7zip/Powershell: patrz [Czy SHA-1 jest zawsze taki sam] (https: // security.stackexchange.com/questions/18290/is-sha-1-hash-always-the-same) – JGreenwell