Quelques corrections et améliorations liées a la sécurité sont inclues dans DriveSort v1.230:

• Du code supportant à moitié un usage en ligne de commande inclu par erreur dans la version précédente a été supprimé vu qu'il n'est pas encore prêt. Lorsqu'on essayait de s'en servir il produisait des messages incompréhensibles liés à la validation et ne faisait rien, donc pas une grosse perte.
• Le dialogue de sélection de disque se tient mieux à jour lorsqu'un disque apparait ou disparait, même quand Windows n'envoie pas de message WM_DEVICECHANGE pour l'occasion. J'ai remarqué que ceci se produit lorsqu'on monte ou démonte des volumes TrueCrypt pendant des tests mais c'est peut être possible avec d'autres périphériques, donc maintenant tant qu'il est affiché le dialogue de selection de disque utilise à la fois un polling sur le masque des lettres de lecteurs et l'écoute du message WM_DEVICECHANGE pour détecter les changements.
• Le dialogue de notification de nouvelle version offre maintenant un moyen d'ignorer une version sans avoir à désactiver les vérifications periodiques de version si vous ne souhaitez pas recevoir de rappel pour une version particulière. Lorsqu'une nouvelle version est disponible, vous pouvez donc maintenant choisir d'ouvrir la page de téléchargement, d'ignorer la nouvelle version, ou de décider la prochaine fois que la version sera vérifiée (oui / non / annuler). Si vous choisissez Non, la prochaine notification sera à propos de la version suivant celle ignorée, et proposera le même choix.
• L'user agent HTTP que DriveSort utilise lorsqu'il vérifie la dernière version a changé de "DriveSort Updater" à "DriveSort/1.230" pour mieux respecter la RFC. Ceci ne change pas grand chose vu que la version était déjà présente dans l'URL de vérification de version, mais ça à une meilleure tête sur le réseau.
• DriveSort tente maintenant d'activer pour son processus les fonctions de sécurité Windows et les politiques d'aténuation d'attaques suivantes lorsqu'il tourne sur une version de Windows qui les supporte: Prévention de l'exécution des données, Randomisation des images, Protection de la pile, Protection du flux de controle, Valider l'intégrité de la heap et de l'utilisation des handles, Bloque les polices non approuvées, Désactiver les points d'extension, Prefere les DLLs de system32, Evite les DLLs du dossier courant. Je n'ai pas remarqué de problème sur Windows 10.1709 qui les permet tous ou sur Windows XP SP3 qui à ma connaissance ne propose que DEP. Si vous remarquez des incompatibilités avec d'autres versions de Windows merci de m'en informer et je verrai ce que je peux faire.

J'ai aussi signé les executables de DriveSort avec des certificates que j'ai généré de manière à permettre la vérification simple de leur intégrité a l'aide du dialogue de propriétés de fichier Windows et de son onglet signatures digitales, bien que Windows va se plaindre de problème d'approbation car mes certificats n'ont pas été émis par une autorité de certification approuvée. J'ai appliqué une signature SHA1 et une signature SHA256 pour que les anciennes et nouvelles versions de Windows aie chacune quelque chose de compréhensible.

Le contrôle de compte d'utilisateur va afficher le même avertissement orange qu'avant lorsque DriveSort n'était pas signé lors de la demande de droits administrateur (qui sont nécéssaires car DriveSort a besoin d'un accès disque complet pour faire son travail). L'avertissement est parfaitement normal vu que Windows n'a aucune garantie que mon certificat auto-signé m'apartient bien vu que je n'ai pas payé une autorité de certification réputée pour le vérifier, donc la signature offre en pratique peu d'information de confiance en plus vu qu'elle aurait pu être ajoutée par quelqu'un sur un exécutable modifié en utilisant un certificat qui ressemble au mien. A terme j'acheterai peut être un certificat de signature de code à une des autorités de certification approuvées par Windows, mais c'est un peu cher pour un petit projet perso. Pour le moment si vous voulez vérifier que les signatures sont bien les miennes, mes certificats ont tous les deux f63a19f489360788049e2f7945ce4381ce644777 comme identificateur de la clef, le certificat de signature SHA1 a pour empreinte numérique 8272dfdaf3af740c6ead49dfb08dcc92a74c43f1 et le certificat de signature SHA256 a pour empreinte numérique f73185df917d9ae5382db34a5ad0edaa0417ff20.

Pendant que je testais comment les signatures se comportaient, j'ai été un peu surpris de découvrir que le contrôle de compte affiche le même avertissement pour un certificat non approuvé que le contenu de l'exécutable corresponde à la signature ou non, j'aurais supposé qu'une signature invalide aurait déclenché le message d'erreur rouge du contrôle de compte et empeché l'exécution vu qu'il semble dangereux de lancer un exécutable corrompu, que ce soit parceque la signature ou le code qu'elle signe qui soit erroné.
Le message affiché dans les détails de la signature numérique du dialogue des propriétés du fichier est plus précis, et distingue clairement les deux cas:

Lorsque le certificat ayant produit la signature n'est pas approuvé mais que la signature correspond bien au contenu du fichier exécutable.

Lorsque l'exécutable a été modifié, peut importe que le certificat soir approuvé ou non.

J'ai aussi affiché un hash SHA1 au dessus de certains liens de téléchargement pour permettre à plus d'utilisateurs de vérifier leurs téléchargements. C'est surtout à l'intention d'utilisateurs qui ne souhaiteraient pas installer GPG4Win pour vérifier les signatures numériques des téléchargements avec ma clef publique GPG. Un hash SHA1 peut être calculé par de nombreux programmes tels 7Zip, sha1sum.

Nouveau jeu de couleurs pour le site.

Je commençais à en avoir assez des couleurs violet-bleu d'avant du coup j'ai décidé de changer le style pour passez à un thème orange sombre qui devrait être assez reposant pour les yeux.

J'ai re-rendu quelques images à partir de leurs modèles 3D avec la nouvelle palette, et en ai profité pour rendre la page d'accueil un peu plus compatible avec les petits écrans de téléphones / tablettes. J'espère que je n'ai rien oublié de bleu dans un des recoins reculés du site, si vous voyez quelque chose qui ne s'affiche pas correctement n'hésitez pas à le signaler.

Un utilisateur de DriveSort m'a remonté ne pas arriver à trier son disque de 2TO ce qui est un effet intéressant de la loi de Moore appliquée au stockage, ce programme ayant été initialement conçu pour trier des clefs USB de 128MB-256MB.

Après investigation, lorsque la taille d'une partition FAT-32 à trier dépasse quelque centaines de giga-octets les drivers de système de fichier de Windows deviennent plus récalcitrant à permettre l'écriture directe sur le disque aux programmes vu que des volumes de telle taille dépassent les recommandations de Microsoft concernant le formattage FAT-32 et de nombreux programmes ne sont pas conçus pour tolérer ces excès.

Dans ces conditions la lecture directe depuis le disque reste possible pour tous les programmes pré-existants, mais si un programme souhaite écrire directement dans les parties du disque réservées aux structures du système de fichier il doit prendre quelques mesures en plus pour signaler a Windows qu'il est pret a gérer les formattage FAT-32 dépassant les limites recommandées.

J'ai donc modifié DriveSort pour qu'il gère correctement ces grand volumes en:

• Désactivant les caches lors de l'ouverture du disque (FILE_FLAG_NO_BUFFERING)
• Utilisant une opération permettant de déleguer les controles de bornes de lecture et écriture au périphérique plutôt que de laisser le pilote de système de fichier FAT le faire (FSCTL_ALLOW_EXTENDED_DASD_IO)
• Alignant les tampons de lecture et écriture sur des adresses mémoires multiples de la taille d'un secteur en utilisant VirtualAlloc plutot que des allocations standard

Ces évolutions ont aussi été appliquées aux fonctions de sauvegarde et restoration du menu contextuel dans l'arbre des volumes du dialogue d'ouverture de disque, on peut donc maintenant travailler sur des disques de la taille maximum possible pour FAT-32 (2TO) sans problème.

Vu que mon ancien compilateur était vraiment dépassé (VC++6), j'ai du migrer les sources DriveSort pour être compatibles avec VisualStudio 2017, mais j'ai continué de viser la version de Windows la plus ancienne supportée par cet outil (Windows XP).

Pour que DriveSort puisse fonctionner sur les anciennes versions de Windows, il sera donc peut être nécessaire d'installer les nouveaux composants redistribuables pour Visual C++ (vc_redist.x86.exe dans les derniers téléchargements de Visual C supportés, [ Lien de Téléchargement Direct ]).

Les programmes compilés par cette version de Visual C++ requierent en effet la présence de certaines DLLs qui ne sont pas systématiquement fournies via Windows Update (mfc140u.dll, et les DLLs de la runtime C universelle nommées api-ms-win-crt-*.dll), mais d'après Microsoft le package VCRedist à l'air de faire le nécessaire pour installer tout ça la ou il faut.

Si vous rencontrez des problèmes pour lancer DriveSort, n'hésitez pas a me contacter.

En testant jSAVF avec un SAVF trouvé sur le net, je me suis apperçu d'un bug dans ma routine de décompression LZ1 (*HIGH) qui rendait parfois les données extraite illisibles ou faisait échouer la décompression. Cette mise à jour corrige ce problème et quelques autres plus mineurs (correction de l'URL de vérification de version, suppression des fichiers temporaires d'extraction, ...).