Eine der praktischeren Neuerungen in Version 1.0.107 betrifft den Community-Export. Die anonymisierten JSON-Dateien, die SSD Next für den Austausch von Messergebnissen erzeugt, lassen sich inzwischen auch direkt in SSD Next zurück- bzw. einlesen. Damit kann ich beispielsweise von Lesern eingesandte Messungen nicht mehr nur extern auswerten, sondern unmittelbar in der gewohnten Oberfläche öffnen, Diagramme betrachten, den Gesamtscore prüfen und die einzelnen Benchmarkbereiche miteinander vergleichen. Und die Leser können dies auch untereinander tun. Dabei bleibt die Trennung zwischen einem vollständigen lokalen Archiv und einem Community-Snapshot bewusst erhalten. Eine Community-Datei enthält keine lokale Laufwerksidentität, keine Seriennummer, keinen Rechnernamen und keine Dateisystempfade. Beim Import wird deshalb auch nicht versucht, solche Informationen vom aktuell eingebauten Laufwerk nachträglich zu ergänzen. Der Datensatz bleibt genau das, was er sein soll, eine anonymisierte Momentaufnahme der Messung.

Aus Sicherheits- und Nachvollziehbarkeitsgründen wird ein solcher Import nur schreibgeschützt geöffnet. Ergebnisse, Diagramme und der gespeicherte Overall Score können dargestellt und für einen PDF-Bericht verwendet werden, die importierten Daten werden aber nicht als lokaler Messlauf behandelt. Insbesondere fließen daraus keine G0-Historienwerte in die lokale Langzeitdatenbank ein. Auch ein vollständiger lokaler JSON- oder ZIP-Export bleibt für Community-Snapshots gesperrt. Ein erneuter anonymisierter Community-Export ist dagegen möglich. Mit Version 1.0.107 kam außerdem ein Rettungspfad für einige ältere Community-Dateien hinzu. Bei Messungen aus 1.0.105 und 1.0.106 konnte es vorkommen, dass mehrere vollständige Ergebnisgenerationen in derselben JSON-Datei landeten. Ursache war, dass SSD Next ältere Resultate für Vergleich und GUI weiterhin im Speicher hielt und der Export diese Liste ungefiltert übernehmen konnte. Neue Exporte enthalten deshalb nun garantiert nur noch einen aktuellen Ergebnisblock pro Test.

Bereits vorhandene betroffene Dateien werden nicht blind repariert. SSD Next prüft stattdessen den gespeicherten Laufbeginn und übernimmt eine doppelte Messung nur dann, wenn eindeutig genau ein Ergebnisblock zum eigentlichen Lauf gehört. Ist die Zuordnung nicht eindeutig, bleibt der Import gesperrt. Damit lassen sich viele ältere Einsendungen retten, ohne aus widersprüchlichen Daten einfach etwas zusammenzuraten. Für mich ist das vor allem deshalb hilfreich, weil Community-Messungen jetzt wesentlich leichter überprüfbar werden. Statt einzelne Werte aus JSON-Dateien herauszusuchen, kann ich eine Einsendung direkt in SSD Next öffnen und exakt in derselben Darstellung betrachten, die auch bei einem lokalen Test verwendet wird. Gleichzeitig bleibt die Anonymisierung erhalten und eine fremde Einsendung kann weder die lokale Laufwerkshistorie noch die aktuell angeschlossene SSD beeinflussen.

Die bislang öffentlich verfügbare Version 1.0.72 von igor’sLAB SSD Next war bereits weit mehr als ein einfacher Durchsatz-Benchmark. Sie brachte das Score Model 2.0, eine überarbeitete pSLC-Logik und eine klarere Trennung zwischen Prognose, tatsächlich beobachtetem Cache-Verhalten und den Sicherheitsgrenzen eines Schreibtests. Seitdem ist intern allerdings so viel passiert, dass der Sprung auf Version 1.0.105 nicht mehr sinnvoll mit einer langen Liste einzelner Miniänderungen beschrieben werden kann. Die Oberfläche ist übersichtlicher geworden, der Diagnosebereich wurde deutlich ausgebaut, mehrere Messmethoden wurden methodisch nachgeschärft und auch beim Export, bei der Historie sowie bei der Controller- und NAND-Erkennung ist einiges hinzugekommen. Die beiden sichtbarsten Neuerungen sind der neue Kompaktmodus, der in der Oberfläche als Consumer bezeichnet wird, und der vollständig integrierte Dark Mode. Hinter diesen beiden Änderungen steckt allerdings kein zweites oder vereinfachtes Benchmarkprogramm. Consumer und Advanced verwenden denselben Benchmark-Core, dieselben Messfunktionen und dasselbe Score Model 2.0. Der Unterschied liegt ausschließlich darin, wie viele Funktionen und Einstellmöglichkeiten der Anwender sehen und wie der vollständige Score-Lauf orchestriert wird.

Der neue Consumer-Modus ist für Anwender gedacht, die SSD Next als reproduzierbaren Vergleichsbenchmark nutzen möchten, ohne vor jedem Lauf durch die zahlreichen Diagnoseoptionen gehen zu müssen. Sichtbar bleiben nur die Consumer-Startseite, der Gesamtscore und die Historie. Die Engineering-Reiter werden nicht entfernt, sondern lediglich ausgeblendet. Beim Wechsel zurück auf Advanced stehen sie sofort wieder zur Verfügung, und zwar mit exakt den zuvor gespeicherten Einstellungen. Ein vollständiger Consumer-Lauf führt genau die vier Benchmarkgruppen aus, die in Score Model 2.0 tatsächlich gewichtet werden: Synthetic, pSLC Streaming, Video und die Anwendungssuite. Optimierungsanalyse, Latency & QoS, Media State / Cache Folding und Full Span bleiben bewusst außen vor, weil diese Tests diagnostischen Charakter besitzen und den Score nicht verändern. Damit ist der Consumer-Modus keine abgespeckte Bewertungsmethode, sondern eine feste und nachvollziehbare Standardkonfiguration für denselben Score.

Das dafür definierte Profil trägt intern die Bezeichnung score_v1. Der Synthetic-Teil läuft mit fünf Pässen und ohne die zusätzlichen Capacity-Scaling-, Specification-Peak-, ATTO- oder Zero-Fill-Diagnosen. Für den pSLC-Test dienen jeweils ein Drittel der SSD-Kapazität und des freien Platzes als Prognosekontext, ohne dass daraus ein harter Schreibstopp abgeleitet wird. Der Video-Test verwendet das Profil 4K60, 10 Bit, 4:2:2 mit 64 GB Datenvolumen. Die Anwendungssuite führt alle für Score Model 2.0 vorgesehenen Workloads aus. Zwischen den Modulen erfolgt eine Zustandsnormalisierung über ReTRIM und 45 Sekunden Ruhezeit. Eine Vor-Konditionierung vor dem ersten Modul und das zusätzliche thermische Recovery-Gate werden im Consumer-Profil nicht verwendet, der Lauf wird anschließend automatisch in der Historie gespeichert.

Wichtig ist dabei die Isolation der Einstellungen. Consumer verwendet seine Standardwerte nur zur Laufzeit. Wer im Advanced-Modus beispielsweise neun Synthetic-Pässe, einen eigenen pSLC-Hard-Cap, ein anderes Videoprofil oder zusätzliche Diagnoseoptionen eingestellt hat, verliert diese Konfiguration nicht. Nach dem Rückwechsel auf Advanced ist der vorherige Expertenzustand unverändert vorhanden. Dadurch kann ich einen standardisierten Score-Lauf anbieten, ohne den bisherigen Charakter von SSD Next als Analysewerkzeug zu opfern.

Die zweite sofort sichtbare Neuerung ist der Dark Mode. Er lässt sich unabhängig vom Consumer- oder Advanced-Modus umschalten und wird dauerhaft gespeichert. Dabei handelt es sich ausdrücklich nur um eine Darstellungsschicht. Weder Benchmarkkonfiguration noch Messmethode, Score, Historie, Telemetrie oder Exportdaten ändern sich durch die gewählte Darstellung.

Der dunkle Stil wurde nicht nur auf die Hauptfläche gelegt. Tabs, Treeviews, Comboboxen, Spinboxen, Eingabefelder, Scrollbars, Fortschrittsanzeigen, klassische Tk-Textflächen, Matplotlib-Diagramme, der Score-Radar, Ergebnisfenster, Info-Dialoge sowie die Start-, Lauf- und Exportfenster werden konsistent umgeschaltet. Auch das igor’sLAB-Logo wird für die dunkle Oberfläche zur Laufzeit angepasst, ohne dass das eigentliche Logo-Asset verändert werden muss. Eine wichtige Trennung bleibt jedoch bestehen: PDF-Berichte und die zu Reports gehörenden PNG- beziehungsweise JPG-Grafiken werden immer im kanonischen hellen Report-Stil erzeugt. Selbst wenn SSD Next im Dark Mode läuft oder eine globale Matplotlib-Konfiguration dunkel eingestellt wäre, erzwingt der Reportpfad wieder einen hellen Hintergrund mit dunklen Beschriftungen. Damit bleiben veröffentlichte Diagramme und PDFs unabhängig von der persönlichen GUI-Einstellung identisch.

Im gleichen Zuge wurde auch die Beschriftung horizontaler Balkendiagramme robuster gemacht. Zahlenwerte werden nicht mehr nur nach verfügbarer Breite skaliert, sondern zusätzlich anhand der tatsächlich gerenderten Balkenhöhe. Die Text-Bounding-Box darf weder die obere noch die untere Kante des zugehörigen Balkens überschreiten. Das klingt nach einer Kleinigkeit, verhindert in der Praxis aber genau jene überlappenden Zahlen, die bei stark komprimierten Ansichten oder ungewöhnlicher DPI-Skalierung schnell entstehen.

Wer SSD Next bisher wegen seiner zahlreichen Einzeldiagnosen genutzt hat, muss sich nicht umstellen. Der Advanced-Modus enthält weiterhin die vollständige Oberfläche und zeigt inzwischen sogar deutlich mehr als die öffentlich bekannte 1.0.72. Neben Synthetic, pSLC Streaming, Video, Anwendungssuite, Optimierungsanalyse, Full Span, Gesamtscore, Historie, Protokoll und SSD-Information sind inzwischen insbesondere Latency & QoS sowie Media State / Cache Folding als eigene Module hinzugekommen.

Damit lässt sich die Software künftig in zwei sehr unterschiedlichen Rollen verwenden. Für normale SSD-Vergleiche genügt der Consumer-Modus mit einem definierten vollständigen Score-Lauf. Für Reviews, Controlleranalysen, pSLC-Untersuchungen, Latenzdiagnosen und die Untersuchung von Cache-Folding bleibt Advanced die eigentliche Werkbank. Und was ist sonst noch neu?

Die größte methodische Erweiterung seit 1.0.72 ist der neue Bereich Latency & QoS. Die erste Fassung kam mit 1.0.73 hinzu und wurde danach mehrfach gegengeprüft und weiterentwickelt. Der aktuelle Stand ist Latency Method 1.8 mit der Method-ID latency_qos_l0_l4_reissue_pslc_handoff_v1_8. Das Modul ist bewusst diagnostisch. Seine Werte fließen deswegen weder in Score Model 2.0 noch in die Aging-Bewertung ein. Die Messung ist in mehrere Ebenen gegliedert. L0 bestimmt zunächst den Host- beziehungsweise QPC-Unterbau des Messpfades. Damit lässt sich abschätzen, ob die gemessene Latenz der SSD noch ausreichend weit über dem eigenen Messboden liegt. L1 misst anschließend die hostseitig beobachtete 4-KiB-QD1-Latenz für Lesen und Schreiben. Neben p50, p90, p95, p99 und p99.9 kann bei ausreichend großer Stichprobe auch p99.99 ausgewiesen werden. Höhere Perzentile werden nicht einfach aus zu wenigen Einzeloperationen extrapoliert, sondern besitzen eigene Evidenzgrenzen.

L2 untersucht die Demand Intensity über QD1, 2, 4, 8, 16 und 32. Dabei werden nicht nur IOPS, sondern auch die zugehörigen Latenzperzentile betrachtet. Ein zusätzlicher Konsistenzcheck vergleicht Queue Depth, IOPS, mittlere Latenz und den gemessenen Reissue-Turnaround des Hosts. L3 betrachtet die für die Praxis besonders interessante Lese-Latenz unter gleichzeitigem Schreibdruck. Dazu läuft eine QD1-READ-Messung parallel zu sequenzieller und optional zufälliger Schreiblast. Der Hintergrunddurchsatz wird nur für das echte zeitliche Überlappungsfenster zwischen Leser und Schreiber berechnet. Dadurch wird vermieden, dass Vorlauf- oder Nachlaufzeiten des Writers eine scheinbar bessere Belastungsrate erzeugen.

L4 ist optional und deutlich schreibintensiver. Hier werden Zustandsmesspunkte S0 bis S4 aufgebaut, um zu prüfen, wie sich die Latenz nach definierter Konditionierung und anschließender Erholung verändert. Zusätzlich kann ein Vergleich vor und nach einem bestätigten pSLC-Übergang erfolgen. Seit Method 1.8 kann ein gültiges pSLC-Ergebnis aus demselben vollständigen Lauf als Handoff genutzt werden. Dadurch muss die Software nicht unnötig ein zweites vollständiges Konditionierungsregime erzeugen. Wenn ein echter Übergang nicht belastbar bestätigt wurde, wird jedoch kein alternativer Messzustand stillschweigend als echter Handoff ausgegeben. Auch die Datenerfassung wurde gegenüber den ersten Entwürfen deutlich robuster. Rohereignisse werden nicht als Millionen schwergewichtiger Python-Objekte im Speicher gehalten, sondern in kompakten 48-Byte-Datensätzen zwischengespeichert und bei Bedarf in den separaten Latency-Export gestreamt. Referenzvorbereitung, Hintergrundschreiblast und Konditionierung werden in der Host-Schreibbilanz erfasst. Abbruch, Zeitlimit, Writer-Hard-Cap, fehlende Evidenz und unvollständige Überlappung werden getrennt ausgewiesen, statt aus einem abgebrochenen Profil noch eine scheinbar vollständige Kennzahl abzuleiten.

Mit Version 1.0.89 kam ein zweiter großer Diagnosebereich hinzu: Media State / Cache Folding. Die aktuelle Methodik liegt bei Version 1.7 und versucht nicht, aus einem einzigen Durchsatzknick direkt auf einen internen NAND-Zustand zu schließen. Stattdessen untersucht sie beobachtbare Zustandsänderungen über definierte Vorher-/Nachher-Fenster, Ruhezeiten, Druckzustände und wiederholte Kontrollmessungen. Der normale Pfad kann zeitgetriebenes Folding nach einer Ruhephase und druckgetriebenes Folding untersuchen. Für die Lesevergleiche werden geschützte Pre-/Post-Fenster und ABBA-Sequenzen verwendet. Die Unsicherheit wird über Block-Bootstrap-Verfahren berücksichtigt, und die Auswertung besitzt explizite Gültigkeitsbedingungen. Eine nicht ausreichend getrennte Baseline ist damit ein dokumentierter Befund und kein Grund, trotzdem eine scheinbar präzise Schlussfolgerung zu erzwingen.

Später hinzugekommen ist der High-Fill-Cross-Fill-Pfad. Er betrachtet den Zusammenhang zwischen Dateisystemfüllstand und beobachteter Größe des schnellen Schreibbereichs. Exakte Übergänge und nur als Untergrenze bekannte, rechtszensierte Beobachtungen werden getrennt behandelt. Längere Sweeps können crash-sichere .partial.json-Checkpoints erzeugen und aus einem gültigen Fortsetzungs-Seed wieder aufgenommen werden. Bei einer Fortsetzung wird ein Bridge-Punkt erneut gemessen und anschließend eine unabhängige Return-Control-Messung durchgeführt, damit ein fortgesetzter Lauf nicht stillschweigend mit einer alten Ausgangssituation vermischt wird.

Zusätzlich werden SMART-Snapshots an definierten Stellen festgehalten. Ein wissenschaftlicher Early-Stop darf den Sweep beenden, wenn die vorhandene Evidenz die vorgesehene Aussage bereits trägt, er darf aber keine nicht beobachtete NAND-Bit-Zahl oder einen vermeintlichen internen Modus erfinden. Gerade diese Trennung ist mir wichtig: SSD Next soll sichtbares Controllerverhalten beschreiben, nicht aus einer Kurve interne Firmwarezustände erraten.

Ab Version 1.0.96 wurde die SSD-Information um einen eigenen Controller-/NAND-Bereich erweitert. Das Ziel war nie, möglichst viele undokumentierte Vendor-Kommandos auszuprobieren. Genau das wäre bei unbekannten SSDs im schlechtesten Fall unverantwortlich. Der aktuelle Flash-Probe-Stand 1.4 arbeitet deshalb nach einem strikten Read-only- und Fail-closed-Prinzip. Ein unbekannter oder nicht ausreichend belegter Controller erhält keinen geratenen Vendor-Befehl. Der Probe-Manager trennt mehrere Evidenzebenen voneinander. Passive Geräteinformationen wie NVMe-Vendor-ID, PCI-Vendor-/Device-ID, ATA-IDENTIFY-Daten oder ein exakter Modellstring dürfen einen Controller oder eine bekannte Hardwareplattform einordnen. Eine externe Teardown- oder Produktspezifikation bleibt jedoch eine Hardware-Referenz und wird niemals als rohe NAND-ID ausgegeben. Erst ein separat belegter, zustandsneutraler DATA-IN-Pfad darf echte native Flash-ID-Evidenz liefern.

Diese Vorsicht hat im Laufe der Entwicklung mehrere zunächst naheliegende Wege bewusst blockiert. Innogrit-F2-Abfragen sind nur für verifizierte Device-IDs erlaubt und prüfen zusätzlich die zurückgelieferte Identität. Bei den freigegebenen Phison-Familien ist ausschließlich ein einzelner D2-Systeminfo-Read vorgesehen, D0 und Per-Bank-Fallbacks bleiben gesperrt. SMI-SATA-Pfade benötigen ein exaktes ATA-IDENTIFY-Firmware-Gate. Maxio, Samsung, Marvell, Realtek, Tenafe und weitere Familien bleiben ohne separat belegten sicheren Read-only-Pfad passiv.

Für einzelne bekannte Laufwerke kann SSD Next inzwischen passive Referenzen einblenden. Bei der BIWIN NV7400 4 TB wird eine exakt gegatete Hardware-Referenz auf Maxio MAP1602A-F3C sowie die im igor’sLAB-Teardown beobachteten Biwin-Pakete mit Micron-B58R-TLC geführt, ohne einen Maxio-Vendor-Probe auszuführen. Für die Samsung 9100 PRO wird bei passender PCI- und Modellidentität eine passive Samsung-/Presto- und V-NAND-TLC-Referenz gezeigt. Auch hier wird keine Samsung-NAND-ID-Abfrage freigeschaltet. Das ist weniger spektakulär als ein aggressives Vendor-Tool, dafür aber nachvollziehbar und für das Testlaufwerk erheblich sicherer.

Eine kleine, aber im Alltag nützliche Ergänzung betrifft außerdem die Temperaturanzeige im Kopfbereich. Wenn zwei materiell unterschiedliche Temperatursensoren vorliegen, kann nun ein zweiter Wert in Klammern erscheinen. Nahezu identische Windows- und NVMe-Repräsentationen werden für die Anzeige zusammengeführt. Die Rohtelemetrie bleibt davon unberührt.

Zwischen 1.0.72 und 1.0.105 steckt auch viel Arbeit, die man auf dem ersten Screenshot nicht erkennt. Der PDF-Report wurde zu einem deutlich besser lesbaren technischen Bericht ausgebaut. Ergebnisdarstellung, Diagramme, strukturierte Analyse und optionale KI-Ausgabe wurden voneinander sauberer getrennt. Der Hinweis auf KI-generierte Reportteile kann in den Einstellungen gesteuert werden, während der Messdatenteil weiterhin aus den lokal ermittelten Ergebnissen stammt. JSON-Import und -Export, lokale Historie und Community-Export wurden mehrfach gegen Randfälle abgesichert. Ein besonders unscheinbarer, aber realer Fehler trat bei sehr großen pSLC-Stichproben auf: kombinatorische Zuweisungsräume können dabei Zahlen mit mehreren tausend Dezimalstellen erzeugen. SSD Next materialisiert solche Integer nach dem Wechsel auf eine Approximation nicht mehr unnötig als gigantische Dezimalstrings. Für ältere beziehungsweise sehr große exakte Werte nutzt das lokale Exportformat nun eine getaggte Hex-Darstellung, die beim Import wieder exakt rekonstruiert werden kann. Der getestete Referenzfall umfasst eine Zahl mit 4617 Dezimalstellen, ohne dafür die Sicherheitsgrenzen des Python-Interpreters global abzuschalten.

Auch die Fehlerbehandlung wurde überarbeitet. Preflight-Meldungen nennen heute den auslösenden Test und den berechneten Speicherbedarf, statt nur allgemein auf zu wenig freien Platz hinzuweisen. Rückgabefehler eines Benchmarks werden von echten Worker-Exceptions getrennt. Laufwerksauswahl und verschiedene GUI-Zustände werden persistenter behandelt. Exportvorgänge, insbesondere große Latency-Archive, blockieren die Oberfläche nicht mehr unnötig während der Dateierzeugung.

Trotz der vielen neuen Diagnosefunktionen bleibt Score Model 2.0 der gemeinsame Vergleichsmaßstab. Das ist auch der Grund, warum der neue Consumer-Modus keine eigene Normalisierung erhalten hat. Ein Consumer-Lauf und ein in Advanced äquivalent konfigurierter Lauf sollen direkt vergleichbar bleiben. Zusätzliche Diagnosemodule können mehr über das Laufwerk erklären, sie dürfen aber nicht im Hintergrund Bonus- oder Strafpunkte in den normalen SSD-Score hineinmischen.

Der Score bleibt als Index aufgebaut. 100 Indexpunkte auf einer Achse entsprechen der versionierten Referenzhülle des Modells, Werte oberhalb von 100 sind ausdrücklich möglich. Der Overall Score kombiniert die vier Anwendungsachsen Gaming, Workstation, Creation und Office. Fehlende Messwerte werden nicht als Nullleistung interpretiert, sondern reduzieren die Abdeckung. Das ist gerade bei abgebrochenen oder bewusst verkürzten Läufen wichtig, weil ein unvollständiger Lauf nicht künstlich schlechter aussehen soll als ein langsames, aber vollständig gemessenes Laufwerk.

Damit ist Version 1.0.105 damit weniger ein kosmetisches Update von 1.0.72 als die Zusammenführung zweier Ziele. Wer nur einen reproduzierbaren SSD-Score möchte, bekommt mit dem neuen Kompaktmodus einen wesentlich geradlinigeren Weg. Wer tiefer einsteigen will, erhält im Advanced-Modus inzwischen deutlich mehr Diagnosewerkzeuge als zuvor. Dark Mode, robustere Reports, vorsichtige Controller-/NAND-Erkennung und die signierte Auslieferung runden diesen Stand ab, ohne den gemeinsamen Benchmark-Core oder das Score Model 2.0 in zwei inkompatible Welten zu zerlegen.

Mit der aktuellen Auslieferung kommt noch eine Änderung hinzu, die nichts an der Messmethodik verändert, für die Windows-Verteilung aber wichtig ist. Sowohl die EXE als auch die native SSD-Next-DLL werden nun mit einem von Certum ausgestellten Code-Signing-Zertifikat signiert. Windows kann damit prüfen, von welchem Herausgeber die Datei stammt und ob sich der signierte Inhalt seit der Signierung verändert hat. Die Signatur ist damit eine Integritäts- und Herausgeberprüfung, kein zusätzlicher Benchmarkbestandteil. Hier mal als Beispiel der AudioAnalyzerNext, den ich nächste Woche launche:

Trotz einer gültigen Signatur kann Windows SmartScreen bei einem neuen Download unter Umständen weiterhin erscheinen. Das ist kein Widerspruch. SmartScreen bewertet nicht nur, ob eine Datei korrekt signiert ist, sondern verwendet zusätzlich Reputationssignale. Eine neue Programmversion besitzt einen neuen Dateihash, und eine frisch veröffentlichte beziehungsweise bislang nur selten heruntergeladene Datei kann deshalb zunächst noch wenig Reputation besitzen. Auch die bisherige Reputation des Herausgebers beziehungsweise Zertifikats und der Downloadkontext können in diese Bewertung einfließen.

Mit zunehmender Verbreitung kann sich diese Reputation aufbauen, eine Code-Signing-Signatur ist aber grundsätzlich keine Garantie dafür, dass SmartScreen niemals eine Nachfrage zeigt. Entscheidend ist die Unterscheidung: Eine gültige Authenticode-Signatur bestätigt Herausgeber und Dateiintegrität, SmartScreen ist darüber hinaus ein separates reputationsbasiertes Schutzsystem. Deshalb kann eine frisch signierte 1.0.105 beim ersten Auftauchen auf einem System noch geprüft oder hinterfragt werden, obwohl EXE und DLL technisch korrekt signiert sind.

SSD Next wird als ZIP-Datei bereitgestellt, damit Programmdatei und gegebenenfalls zugehörige Komponenten als unverändertes Paket übertragen werden können. Das Archiv besitzt mehrere praktische Vorteile:

• ein eindeutiger Downloadname,
• kontrollierbarer Gesamtinhalt,
• zuverlässigere Übertragung über Browser und Webserver,
• einfachere Veröffentlichung einer Prüfsumme,
• geringere Gefahr, dass der Dateiname der EXE beim Download verändert wird,
• gemeinsames Ausliefern aller benötigten Bestandteile,
• saubere Trennung vom übrigen Downloadordner.

Das ZIP-Archiv dient nicht dazu, eine Schadsoftwareprüfung zu umgehen oder Inhalte zu verstecken. Windows Defender und andere Schutzprogramme können sowohl das Archiv als auch die entpackte EXE prüfen. Je nach Browser, Defender-Version und Reputationslage kann die direkte Übertragung einer unsignierten EXE frühzeitig blockiert oder abgebrochen werden. Ein ZIP-Archiv reduziert solche fehlerhaften Transportblockaden teilweise, beseitigt die anschließende Sicherheitsprüfung aber nicht. Nach dem Download wird das Archiv in einen eigenen Ordner entpackt. das Programm sollte nicht dauerhaft direkt aus dem ZIP-Archiv heraus gestartet werden. Anschließend sind Dateiname, Größe und SHA-256-Prüfsumme zu kontrollieren.

• Size: 91,557,262 bytes (87.32 MiB)
• SHA256: 398e15c7b3d2c83eb8ce11bcddf9eb195c99fa308d8de6b86c43a73faacbd9a4