6
Exe gewrapped starten und direkten Zugriff auf die Originale Exe unterbinden
Hi@All,
wir haben hier ein sehr kurioses Problem und keine Ideen mehr, ohne den Aufwand ins extreme zu treiben:
Problem:
Ein Programm xyz.exe wird ausgeführt und sorgt dafür das der Ländercode nicht stimmt und zerhaut bestimmte Daten die weiterverarbeitet werden.
Setzt man vorher NLS korrekt stimmen auch die Daten.
Das Problem ist das NLS nur temporär für die Anwendung gesetzt werden darf, da auf den Clients andere Programme das für ihren Support mit einem anderen Wert im System vorbelegt haben.
Wird nun das Programm(xyz.exe) über eine Batch gestartet und bleibt weiterhin eine .exe läuft es, allerdings wird es IRGENDEINEN User geben der direkt auf die xyz.exe klickt, arbeitet und die Daten in der DB schrottet.
Wie kann ich das starten von xyz.exe für den User unterbinden, allerdings das Starten über batch oder cmd gleichzeitig erlauben, welche wiederum die xyz.exe mit vorgelagertem SET NLS=<wert> aufruft und im Userkontext startet?
Einer eine Idee?
Die "Zwischenlösung" schaut so aus das die xyz.exe umbenannt wurde in "DO_NOT_RUN_xyz.exe".
Das schützt allerdings nicht davor das einer daherkommt und trotzdem draufklickt.
Gruß
PS:
Fragt nicht wieso die Situation so ist wie sie ist, aber wir haben hier leider keinen Einfluss auf die Entwicklung dieser Software.
NEUE LÖSUNG:
Die Original xyz.exe wurde "versteckt" geflaggt. Somit ist die Datei nicht mehr sichtbar und nun müsste schon jemand sich die versteckten anzeigen UND mutwillig dadrauf klicken. =)
Wenn trotzdem einer eine andere Idee hat immer her damit.
wir haben hier ein sehr kurioses Problem und keine Ideen mehr, ohne den Aufwand ins extreme zu treiben:
Problem:
Ein Programm xyz.exe wird ausgeführt und sorgt dafür das der Ländercode nicht stimmt und zerhaut bestimmte Daten die weiterverarbeitet werden.
Setzt man vorher NLS korrekt stimmen auch die Daten.
Das Problem ist das NLS nur temporär für die Anwendung gesetzt werden darf, da auf den Clients andere Programme das für ihren Support mit einem anderen Wert im System vorbelegt haben.
Wird nun das Programm(xyz.exe) über eine Batch gestartet und bleibt weiterhin eine .exe läuft es, allerdings wird es IRGENDEINEN User geben der direkt auf die xyz.exe klickt, arbeitet und die Daten in der DB schrottet.
Wie kann ich das starten von xyz.exe für den User unterbinden, allerdings das Starten über batch oder cmd gleichzeitig erlauben, welche wiederum die xyz.exe mit vorgelagertem SET NLS=<wert> aufruft und im Userkontext startet?
Einer eine Idee?
Die "Zwischenlösung" schaut so aus das die xyz.exe umbenannt wurde in "DO_NOT_RUN_xyz.exe".
Das schützt allerdings nicht davor das einer daherkommt und trotzdem draufklickt.
Gruß
PS:
Fragt nicht wieso die Situation so ist wie sie ist, aber wir haben hier leider keinen Einfluss auf die Entwicklung dieser Software.
NEUE LÖSUNG:
Die Original xyz.exe wurde "versteckt" geflaggt. Somit ist die Datei nicht mehr sichtbar und nun müsste schon jemand sich die versteckten anzeigen UND mutwillig dadrauf klicken. =)
Wenn trotzdem einer eine andere Idee hat immer her damit.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263853
Url: https://administrator.de/forum/exe-gewrapped-starten-und-direkten-zugriff-auf-die-originale-exe-unterbinden-263853.html
Ausgedruckt am: 10.04.2025 um 11:04 Uhr
6 Kommentare
Neuester Kommentar
Hallo H41mSh1C0R,
ich glaube nicht, dass es eine sichere Lösung für dein Problem gibt (aber ich bin auch nur Administrator auf meinem eigenen Rechner, mag sein jemand weiß mehr ...).
Eine etwas unkonventionelle Lösung: Ändere die Dateiendung von .exe zu .dat
Im Explorer sollte die Endung .dat normalerweise nicht mit einem Programm verknüpft sein. In der Kommandozeile wird in dem Fall aber von einer ausführbaren Datei ausgegangen.
Grüße
rubberman
ich glaube nicht, dass es eine sichere Lösung für dein Problem gibt (aber ich bin auch nur Administrator auf meinem eigenen Rechner, mag sein jemand weiß mehr ...).
Eine etwas unkonventionelle Lösung: Ändere die Dateiendung von .exe zu .dat
Im Explorer sollte die Endung .dat normalerweise nicht mit einem Programm verknüpft sein. In der Kommandozeile wird in dem Fall aber von einer ausführbaren Datei ausgegangen.
Grüße
rubberman
Moin,
kleines AutoIT-Script als Wrapper:
FileInstall packt die EXE mit in das kompilierte Script(ebenfalls eine EXE) und entpackt sie nur für die Ausführung. nach dem Schließen wird sie dann wieder gelöscht.
Damit sich das Script kompilieren lässt muss die Exe im selben Verzeichnis liegen wie das Script.
Später ist die Exe dann mit in der kompilierten EXE enthalten...
Gruß jodel32
kleines AutoIT-Script als Wrapper:
FileInstall packt die EXE mit in das kompilierte Script(ebenfalls eine EXE) und entpackt sie nur für die Ausführung. nach dem Schließen wird sie dann wieder gelöscht.
#NoTrayicon
EnvSet("NLS","xyz")
FileInstall(".\xyz.exe",@TempDir & "\xyz.exe",1)
RunWait(@TempDir & "\xyz.exe")
FileDelete(@TempDir & "\xyz.exe) Später ist die Exe dann mit in der kompilierten EXE enthalten...
Gruß jodel32
Zitat von @rubberman:
Eine etwas unkonventionelle Lösung: Ändere die Dateiendung von .exe zu .dat
Im Explorer sollte die Endung .dat normalerweise nicht mit einem Programm verknüpft sein. In der Kommandozeile wird in dem
Fall aber von einer ausführbaren Datei ausgegangen.
Eine etwas unkonventionelle Lösung: Ändere die Dateiendung von .exe zu .dat
Im Explorer sollte die Endung .dat normalerweise nicht mit einem Programm verknüpft sein. In der Kommandozeile wird in dem
Fall aber von einer ausführbaren Datei ausgegangen.
Leider funktioniert das nicht, haben wir auch ausprobiert, da in der Exe ein .Net Loader steckt der prüft ob das Teil als .exe geladen wurde. =(
Trotzdem danke für den Tipp.
Zitat von @114757:
Moin,
kleines AutoIT-Script als Wrapper:
FileInstall packt die EXE mit in das kompilierte Script(ebenfalls eine EXE) und entpackt sie nur für die Ausführung.
nach dem Schließen wird sie dann wieder gelöscht.
Damit sich das Script kompilieren lässt muss die Exe im selben Verzeichnis liegen wie das Script.
Später ist die Exe dann mit in der kompilierten EXE enthalten...
Moin,
kleines AutoIT-Script als Wrapper:
FileInstall packt die EXE mit in das kompilierte Script(ebenfalls eine EXE) und entpackt sie nur für die Ausführung.
nach dem Schließen wird sie dann wieder gelöscht.
> #NoTrayicon
> EnvSet("NLS","xyz")
> FileInstall(".\xyz.exe",@TempDir & "\xyz.exe",1)
> RunWait(@TempDir & "\xyz.exe")
> FileDelete(@TempDir & "\xyz.exe)
> Später ist die Exe dann mit in der kompilierten EXE enthalten...
AutoIT ist in unserem Umfeld leider keine Option.
Allerdings haben wir sowas in der Art auch überlebt, leider musst du dann jedes Mal, wenn neue Sourcen geliefert werden diese Exe neu erstellen.
Dazu kommt noch das wir nicht sicherstellen können das die SW noch sauber funktioniert, wenn die xyz.exe aus dem Temppfaden aufgerufen wird.
Trotzdem danke auch für deinen Tipp.
Wenn Ihr eine Windows-Domäne habt, könnt Ihr auf einfachste Weise per GPO den Zugriff auf das Installationslaufwerk unterbinden. Wir machen das auf unseren Terminakservern regelmäßig mit Laufwer C:, funktioniert aber auch mit allen anderen Laufwerken und auch an Clients. Sollte dann natürlich nicht auch das Datenlaufwerk sein...
Die Folge in dem Fall: Der Zugriff auf das Laufwerk über welchen Weg auch immer funktioniert nicht mehr, da helfen auch keine eingeblendeten versteckten Dateien. Die Programmverknüpfungen dagegen funktionieren weiterhin. Dieser Weg unterbindet auch gleichzeitig solche Altlasten wie Kollegen, die vorzugsweise im Root von C: speichern
Eine andere Idee, die mir gerade kommt: funktioniert es evtl. den Parameter in die Verknüpfung einzubauen statt in eine Batch? Die könntet Ihr dann verteilen und es würde zumindest der Umweg mit der Batch entfallen.
VG
Y.
Die Folge in dem Fall: Der Zugriff auf das Laufwerk über welchen Weg auch immer funktioniert nicht mehr, da helfen auch keine eingeblendeten versteckten Dateien. Die Programmverknüpfungen dagegen funktionieren weiterhin. Dieser Weg unterbindet auch gleichzeitig solche Altlasten wie Kollegen, die vorzugsweise im Root von C: speichern
Eine andere Idee, die mir gerade kommt: funktioniert es evtl. den Parameter in die Verknüpfung einzubauen statt in eine Batch? Die könntet Ihr dann verteilen und es würde zumindest der Umweg mit der Batch entfallen.
VG
Y.
Hallo YotYot.
In den Eigenschaften der Verknüpfung
bei Ziel:
(Achtung die Anführungszeichen sind etwas verwirrend )
bei Ausführen in:
um das Arbeitsverzeichnis richtig zu stellen
bei Ausführen:
um das Aufblitzen der Console zu unterdrücken.
Natürlich lässt sich auch das Icon noch ändern ...
Grüße
rubberman
funktioniert es evtl. den Parameter in die Verknüpfung einzubauen statt in eine Batch?
Indirekt funktioniert das auf jeden Fall.In den Eigenschaften der Verknüpfung
bei Ziel:
%comspec% /c "set "NLS=wert" &start "" "C:\Pfad des Programms\xyz.exe""bei Ausführen in:
C:\Pfad des Programmsbei Ausführen:
MinimiertNatürlich lässt sich auch das Icon noch ändern ...
Grüße
rubberman
