12
Ps2exe kennt -AsArray nicht
Hallo zusammen,
ich hoffe, ihr könnt mir weiter helfen.
Mein PowerShell-Skript funktioniert (PowerShell 7.3.9 / .NET 7) Nun wollte ich alles in eine *.exe packen, damit der Code weder direkt sichtbar, noch editierbar ist.
Nach einer Recherche bin ich auf ps2exe (Version 1.0.13) gestoßen. Das hat auch super funktioniert, nur bricht die Ausführung beim Programmteil ab, bei dem ich "-AsArray" nutze (siehe Bild):
"Es wurde kein Parameter gefunden, der dem Parameternamen "AsArray" entspricht.
Benutzt wird es nur an dieser Stelle:
Ich bin mir nicht sicher, welche .NET Version ps2exe nutzt, aber eigentlich doch die Version, welche auch mein Skript nutzt.
AsArray gibt es scheinbar ja noch nicht so lange...
Kennt jemand das Problem bzw. eine Lösung?
Einen Workaround ohne "-AsArray" habe ich leider bisher nicht finden können.
Vielen Dank im Voraus, für Lösungen wäre ich seeehr dankbar!
Grüße
ich hoffe, ihr könnt mir weiter helfen.
Mein PowerShell-Skript funktioniert (PowerShell 7.3.9 / .NET 7) Nun wollte ich alles in eine *.exe packen, damit der Code weder direkt sichtbar, noch editierbar ist.
Nach einer Recherche bin ich auf ps2exe (Version 1.0.13) gestoßen. Das hat auch super funktioniert, nur bricht die Ausführung beim Programmteil ab, bei dem ich "-AsArray" nutze (siehe Bild):
"Es wurde kein Parameter gefunden, der dem Parameternamen "AsArray" entspricht.
Benutzt wird es nur an dieser Stelle:
$value_Json = $value_Base64Array | ConvertTo-Json -AsArray
Invoke-RestMethod -Uri $url -Method Put -Body $value_Json -ContentType 'application/json' -UseDefaultCredentials Ich bin mir nicht sicher, welche .NET Version ps2exe nutzt, aber eigentlich doch die Version, welche auch mein Skript nutzt.
AsArray gibt es scheinbar ja noch nicht so lange...
Kennt jemand das Problem bzw. eine Lösung?
Einen Workaround ohne "-AsArray" habe ich leider bisher nicht finden können.
Vielen Dank im Voraus, für Lösungen wäre ich seeehr dankbar!
Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 23084184646
Url: https://administrator.de/contentid/23084184646
Printed on: May 16, 2024 at 14:05 o'clock
12 Comments
Latest comment
Hi.
Gruß schrick
Einen Workaround ohne "-AsArray" habe ich leider bisher nicht finden können.
Das packt ja alles nur in Square-Brackets für ein Array. Einfach stattdessen so schreiben, kommt das selbe bei raus, dann brauchst du -AsArray nicht (den gibt es erst ab PS Version 7):$value_Json = $value_Base64Array | ConvertTo-Json
Invoke-RestMethod -Uri $url -Method Put -Body "[$value_Json]" -ContentType 'application/json' -UseDefaultCredentials 
1
Nun wollte alles in eine *.exe packen, damit der Code weder direkt sichtbar, noch editierbar ist.
Du bist dir bewusst, dass dieser Schutz nicht existent ist, oder? Wenn man die exe mit dem Parameter -u (wenn ich mich nicht irre) startet, dann entpackt sich das Ganze zu der ursprünglichen .ps1Edit: siehe @mbehrens: es ist -extract:<FILENAME>
1
Zitat von @DerWoWusste:
Nun wollte alles in eine *.exe packen, damit der Code weder direkt sichtbar, noch editierbar ist.
Du bist dir bewusst, dass dieser Schutz nicht existent ist, oder? Wenn man die exe mit dem Parameter -u (wenn ich mich nicht irre) startet, dann entpackt sich das ganze in zu der ursprünglichen .ps1-extract:<FILENAME>
Habe es ausprobiert - Funktioniert. Allerbesten Dank!!
Zitat von @mbehrens:
Zitat von @DerWoWusste:
Nun wollte alles in eine *.exe packen, damit der Code weder direkt sichtbar, noch editierbar ist.
Du bist dir bewusst, dass dieser Schutz nicht existent ist, oder? Wenn man die exe mit dem Parameter -u (wenn ich mich nicht irre) startet, dann entpackt sich das ganze in zu der ursprünglichen .ps1-extract:<FILENAME>Ja, das ist ein kleiner Schutz gegen Anwender, nicht gegen Entwickler.
Gibt es denn eine bessere Möglichkeit?
Habe vorher mal mit Verschlüsselungen experimentiert (Invoke-Stealth). Das hat leider nicht funktioniert.
Gibt es denn eine bessere Möglichkeit?
Vielleicht. Sag mir, warum du es verstecken willst und was du versteckt. Oft ist ein Ausführen als Systemkonto die Lösung.
Es werden Daten auf Geräte in der industriellen Produktion geschrieben - das soll nicht jeder machen können 
Und wenn jemand das Skript recht einfach manipulieren kann, würde ich es schon gerne verhindern - zumindest so gut es geht...
Und wenn jemand das Skript recht einfach manipulieren kann, würde ich es schon gerne verhindern - zumindest so gut es geht...
Du hast ja meinen Voschlag gelesen: verwende das Systemkonto. Innerhalb einer Domäne kann das auch im Netzwerk handeln, hat lokal alle Zugriffsrechte und sollte somit alles lesen und schreiben können.
Zitat von @North89:
Es werden Daten auf Geräte in der industriellen Produktion geschrieben - das soll nicht jeder machen können
Und wenn jemand das Skript recht einfach manipulieren kann, würde ich es schon gerne verhindern - zumindest so gut es geht...
Es werden Daten auf Geräte in der industriellen Produktion geschrieben - das soll nicht jeder machen können
Und wenn jemand das Skript recht einfach manipulieren kann, würde ich es schon gerne verhindern - zumindest so gut es geht...
Skript signieren und nur signierte Skripte erlauben. Credentials gehören auch niemals in Skripten gespeichert. Lass es dann über einen entsprechenden Service-Account ausführen je nach Aufgabe.
Ja, das Skript wird signiert. Es wird aber vom Kunden auf deren Rechner ausgeführt. Daher hilft nur ein Schutz "innerhalb" des Skripts. Aber danke für den Kommentar!
Bitte immer auf alle Kommentare antworten, sonst wird nicht klar, ob ein Kommentar übersehen wurde.
Zitat von @DerWoWusste:
Bitte immer auf alle Kommentare antworten, sonst wird nicht klar, ob ein Kommentar übersehen wurde.
Bitte immer auf alle Kommentare antworten, sonst wird nicht klar, ob ein Kommentar übersehen wurde.
Ist ok, danke.
Systemkonto klingt gut, ist aber wie geschrieben nicht möglich - da nicht in meiner Hand.
Werde versuchen das Skript zusätzlich zur exe zu verschlüsseln.
