Comment obtenir SHA1 cohérente de disque dur ou volume qui a EWF activé (Win 7 embarqué)

Question

Problème: Je ne peux pas obtenir le fichier reproductible, le volume ou même hash d'entraînement physique (par exemple, SHA1) même avec EWF activé sur Win 7 Embedded et utilisant les méthodes CreateFile/ReadFile de l'API Win32. Il me semble que ReadFile lit à partir de la mémoire RAM de l'EWF, mais j'en ai besoin pour obtenir les octets du disque.

Contexte: Nous mettons à jour un produit matériel + logiciel réglementé à partir de Windows XP Embedded (FAT32) vers Windows 7 intégré (NTFS). Le code de l'application est écrit en C# .Net et VC++.

Une exigence réglementaire est de pouvoir vérifier que tous les fichiers, y compris les fichiers OS, présents sur le disque dur sont des copies exactes des fichiers de référence qui ont été remis au régulateur. Le régulateur doit pouvoir effectuer cette vérification lorsque le périphérique matériel est fonctionnel (en production) sans arrêter les applications en cours d'exécution sur le périphérique. Dans les jours XP Embedded, nous pouvions obtenir des hachages de fichiers cohérents lorsque EWF était activé, et avec le périphérique opérationnel, en analysant le système de fichiers FAT32 et en lisant les clusters de disques via ReadFile (Win 32 API, kernel32.dll) . Les hachages n'étaient pas cohérents si nous lisions le fichier comme, disons, un FileStream. Notre système d'exploitation et nos applications sont déployés en tant qu'image de disque maître immuable. Nous clonons les disques durs à partir d'un maître à l'aide d'un octet pour le matériel de clone de lecteur de byte. Nous avons également fait le clonage via OSFClone (dd) sous Linux.

Nous essayons de reproduire ceci (c'est-à-dire des hachages de fichiers vérifiables) dans Windows 7 Embedded (x64) qui nécessite une partition NTFS pour le système d'exploitation.

environnement de test:

• OS est Windows Embedded Standard 7 EWF est activé en mode RAM sur nos volumes (C :, D :)
• NTFSLastAccessUpdate a été réglé sur "1" le registre sous SYSTEM \ Control \
• Tous les fichiers Bootstat.dat ont été supprimés du lecteur avant d'activer EWF et les changements engagés par ewfmgr

Auparavant, pour vérifier si le lecteur est immuable, je l'ai fait ce qui suit:

• un dispositif de démarrage avec le lecteur et l'arrêt Win 7 sexies après avoir modifié (EWF activé)
• Branchez le Win7e disque dur dans un système Kali Linux et utilisez dd | sha1sum pour obtenir le hachage du lecteur entier
• Rebranchez le lecteur Win7e dans l'appareil et démarrez, effectuez les modifications (EWF activé) et répétez le dd | sha1sum marche à nouveau sur Kali Linux (par exemple, dd if =/dev/sda1 | sha1sum) où/dev/sda1 est une partition EWF protégée Windows.

Les signatures appariées dans ce test entre différentes amorces. Je refais le test ci-dessus mais cela prend du temps. [Edit: j'ai recommencé le test maintenant: l'EWF fonctionne et Linux retourne exactement les mêmes hashes pour/dev/sda1 entre les redémarrages du lecteur Win7e].NTFSLib et le code de test collé ci-dessous ne reproduisent pas les mêmes signatures du lecteur protégé EWF.

Problème: Nous avons essayé d'utiliser des méthodes CreateFile/ReadFile ainsi qu'un « NtfsLib » (https://github.com/LordMike/NtfsLib) pour lire des fichiers individuels, le volume et \ \ PhysicalDriveN mais nous ne recevons pas hash reproductibles entre les redémarrages du. dispositif. Autrement dit, nous obtenons un hachage SHA1 différent pour un fichier Windows (C: \ windows \ windowsupdate.log) à chaque fois; nous obtenons différents hashes pour \. \ C: à chaque fois, et nous obtenons des hachages différents pour \. \ PhysicalDrive0 à chaque fois.

Je colle le code C# ci-dessous que j'utilise pour calculer les signatures. Cela ne me dérange pas de réécrire la chose dans un autre langage, disons C ou C++, tant que je peux obtenir des octets bruts à partir du disque dur. S'il vous plaît dites-moi si je fais quelque chose de mal à lire les octets bruts. Je n'ai pas besoin de lire et de hacher des fichiers individuels en soi. Je peux lire le disque entier ou un volume entier et le hacher tant que ce hachage correspond aux redémarrages de l'appareil. Hashing le lecteur entier ou le volume satisferait à l'exigence réglementaire. Pour moi, il semble que les octets que je reçois de ReadFile montrent la vue d'EWF sur le système de fichiers.

J'apprécierais n'importe quels conseils n'importe qui peut me donner. J'ai lu divers articles sur ReadFile, mais je n'ai trouvé aucune indication sur ce comportement avec EWF.

Je cours le code ci-dessous en tant qu'administrateur sur Windows et mon app.manifest a l'ensemble de chose requireAdmin.

using System; 
using System.Runtime.InteropServices; 
using System.Security.Cryptography; 
using Microsoft.Win32.SafeHandles; 


namespace CSharpReadDisk 
{ 
    class DiskReader 
    { 
     public const uint GenericRead = 0x80000000; 
     public const uint FileShareRead = 1; 
     public const uint FileShareWrite = 2; 
     public const uint OpenExisting = 3; 

     [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)] 
     static extern unsafe IntPtr CreateFile(string lpFileName, uint dwDesiredAccess, 
      uint dwShareMode, IntPtr lpSecurityAttributes, uint dwCreationDisposition, 
      uint dwFlagsAndAttributes, IntPtr hTemplateFile); 

     [DllImport("kernel32.dll", SetLastError = true)] 
     static extern unsafe bool ReadFile(IntPtr hFile, void* lpBuffer, 
      uint nNumberOfBytesToRead, uint* lpNumberOfBytesRead, IntPtr lpOverlapped); 

     [DllImport("kernel32", SetLastError = true)] 
     static extern unsafe bool CloseHandle(IntPtr hObject); 


     public unsafe IntPtr Open(string filename) 
     { 
      // open the existing file for reading  
      IntPtr handle = CreateFile(filename, GenericRead, FileShareRead | FileShareWrite, IntPtr.Zero, OpenExisting, 0, IntPtr.Zero); 
      return handle; 
     } 

     public unsafe uint Read(IntPtr handle, byte[] buffer, uint count) 
     { 
      uint n = 0; 
      fixed (byte* p = buffer) 
      { 
       if (!(ReadFile(handle, p, count, &n, IntPtr.Zero))) 
       { 
        return 0; 
       } 
      } 
      return n; 
     } 

     public unsafe bool Close(IntPtr handle) 
     { 
      return CloseHandle(handle); 
     } 
    } 

    class Test 
    { 
     static void Main(string[] args) 
     { 
      DiskReader dr = new DiskReader(); 

      Console.Write("Enter path to drive, volume or file: "); 
      string path = Console.ReadLine(); 
      IntPtr fh = dr.Open(path); 

      try 
      { 
       SafeFileHandle sfh = new SafeFileHandle(fh, true); 
       if (sfh.IsInvalid) 
       { 
        Marshal.ThrowExceptionForHR(Marshal.GetHRForLastWin32Error()); 
       } 

       Console.WriteLine("Enter read buffer size (MB): "); 
       int bs = Console.Read(); 

       byte[] lpBuffer = new byte[bs * 1024 * 1024]; 

       uint bytesRead = 0; 
       SHA1Managed sha1 = new SHA1Managed(); 
       while ((bytesRead = dr.Read(fh, lpBuffer, (uint)lpBuffer.Length)) > 0) 
       { 
        sha1.TransformBlock(lpBuffer, 0, (int)bytesRead, null, 0); 
        Console.Write("."); 
       } 
       sha1.TransformFinalBlock(lpBuffer, 0, (int)bytesRead); 
       Console.WriteLine("\nSHA1: {0}", BitConverter.ToString(sha1.Hash)); 
      } 
      catch (Exception e) 
      { 
       Console.WriteLine("An exception occurred:\n HResult: {0}\n Message: {1}\n InnerException: {2}\n Source: {3}\n TargetSite: {4}\n StackTrace: {5}", 
        e.HResult, e.Message, e.InnerException, e.Source, e.TargetSite, e.StackTrace); 
      } 
      dr.Close(fh); // close filehandle 


      Console.WriteLine("\nPress any key to exit..."); 
      Console.ReadKey(); 
     } 
    } 
} 

Answer 1

Mise à jour pour quiconque est intéressé, vous pouvez réellement aller au-dessous de EWF via CreateFile/ReadFile à partir de Win32 API. Vous devez utiliser le handle \. \ PhysicalDriveN, puis lire les octets spécifiques qui correspondent au volume qui vous intéresse. Vous pouvez le faire en utilisant la fonction SetFilePointer également fournie par l'API Win32. Bien sûr, si vous voulez hacher le disque entier, vous n'aurez pas besoin de lire des octets spécifiques correspondant au volume. Les documents MSDN sur ce sujet ne sont pas très clairs et les documents ne prennent pas en compte le cas spécifique d'utilisation de l'EWF.