Hallo Gemeinde,
hat jemand schon einmal eine Exe entwickelt die ein "Ablaufdatum" enthält, was z.B. sicherstellt, dass die exe nicht mehr benutzt werden kann wenn sie zu alt ist?
Welcher Ansatz wäre da am sinnvollsten?
Hintergrund: es soll nur das aktuelle Release eines Programms benutzt werden, da dieses u.a. auf Bios-Optionen zugreift, die sich ja nach einem Bios-Update durchaus ändern können
oder sogar wegfallen (z.B. Num-lock-Aktivierung bei Keyboards ohne Nummernblock).
Ablaufdatum für kompilierte exe
-
hipfzwirgel -
20. Juni 2024 um 16:06 -
Unerledigt
-
... eine Exe entwickelt die ein "Ablaufdatum" enthält, was z.B. sicherstellt, dass die exe nicht mehr benutzt werden kann wenn sie zu alt ist?
1. Datumsvergleich
Eine triviale/rustikale Variante wäre, ein Ablaufdatum im Quelltext festzulegen. Beim Start des Programmes wird dieses Datum mit dem aktuellen Systemdatum verglichen und falls größer -> Meldung und Exit.
Ein mögliches Problem hierbei wäre allerdings, dass man bereits wissen müsste, wann das nächste Release erscheinen wird (es sei denn, man hat feste Intervalle, z.B. alle 3 Monate).
2. Releasenummer prüfen
Flexibler wäre es, die Releasenummer der aktuellen Version von einem Server (online) zu lesen. Diese wird mit der intern vergebenen Nummer verglichen und falls größer -> Meldung und Exit.
Bei einem lokalen Netzwerk könnte man die aktuelle Nummer auch in einer Datei ablegen und gegen diese prüfen.
-
Da du spezifisch auf das BIOS eingehst:
Du könntest schauen, ob sich die BIOS-Version in der Zwischenzeit geändert hat.Einfach in der CMD "systeminfo" eingeben und mal durchschauen, dort gibt es einen Eintrag dafür. Das kannst du dann mit AutoIt auch automaitisert auslesen.
-
Wenn Du nachhaltig verhindern willst, dass die exe nach dem Ablaufdatum benutzt wird, musst Du verhindern, dass jemand das Sytemdatum zurücksetzt. Da könnte man auf folgenden Trick verfallen:
Du suchst Dir eine Datei, die Windows bei jedem Start aktualisiert, nimmst das Datum dieser Datei und gleichst es mit dem Sytemdatum ab. Dateidatum neuer als Systemdatum? -> Manipulation des Systemdatums.
Gruß
Peter
-
Ich hab das auch mal gemacht. Meine Lösung war, dass sich die Datei beim Ausführen selbst gelöscht hat, wenn das Datum überschritten war.
-
Ich habe auch einmal etwas gemacht, was in die Richtung ging: Ich habe geprüft, ob es auf einem Server eine neuere Version gibt und dann konnte man entweder diese neue Version installieren oder das Programm beenden - ein Start der alten Version war nicht mehr möglich.
-
Du kanmnst Dir die aktuelle Uhrzeit aus dem INet holen und vergleichen.
Spoiler anzeigen
#include <Constants.au3>
Local $String = BinaryToString(InetRead ("http://worldtimeapi.org/api/timezone/Europe/berlin.txt%22,1))
Local $Time = StringRegExp ($String,'datetime: (.+?)T(\d+:\d+:\d+)', $STR_REGEXPARRAYMATCH)
MsgBox ($MB_SYSTEMMODAL,"",$Time[0] & " " & $Time[1])
Ist die aus dem INet geholten Zeit größer als das was Du, z. B. im Script als Startzeit stehen hast, dann ....., sonst ......
.
Ich würde bei der Installation das Datum verschlüsselt in die Registry schreiben und dann mit der aus dem INet abgleichen. -
so kannst du in autoit direkt die BIOS Version abfragen:
AutoItLocal $iPID = Run('Powershell.exe -Command (gwmi Win32_Bios).SMBIOSBIOSVersion', @DesktopDir, @SW_HIDE, 6) If ProcessWaitClose($iPID, 10) = 0 Then SetError(1, 2, 0) Local $sOutput = StdoutRead($iPID) ConsoleWrite($sOutput & @CRLF)Ich denke in deinem Fall sollte man erstmal identifizieren, was der Trigger für ein Software Update darstellt. Zeit ist da ein sehr stumpfer Ansatz wenn es um Usability geht.