h41msh1c0r
Goto Top

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.

Content-Key: 263853

Url: https://administrator.de/contentid/263853

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: rubberman
rubberman 18.02.2015 um 21:02:55 Uhr
Goto Top
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
Mitglied: 114757
114757 18.02.2015 aktualisiert um 21:13:54 Uhr
Goto Top
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)  
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
Mitglied: H41mSh1C0R
H41mSh1C0R 18.02.2015 um 22:25:49 Uhr
Goto Top
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.

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.
Mitglied: H41mSh1C0R
H41mSh1C0R 18.02.2015 um 22:30:03 Uhr
Goto Top
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.
> #NoTrayicon
> EnvSet("NLS","xyz")  
> FileInstall(".\xyz.exe",@TempDir & "\xyz.exe",1)  
> RunWait(@TempDir & "\xyz.exe")  
> FileDelete(@TempDir & "\xyz.exe)  
> 
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...

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.
Mitglied: YotYot
YotYot 19.02.2015 um 08:42:59 Uhr
Goto Top
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 face-wink

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.
Mitglied: rubberman
rubberman 19.02.2015 um 17:35:59 Uhr
Goto Top
Hallo YotYot.

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""
(Achtung die Anführungszeichen sind etwas verwirrend face-wink)

bei Ausführen in:
C:\Pfad des Programms
um das Arbeitsverzeichnis richtig zu stellen

bei Ausführen:
Minimiert
um das Aufblitzen der Console zu unterdrücken.

Natürlich lässt sich auch das Icon noch ändern ...

Grüße
rubberman