84544
23.02.2010, aktualisiert am 03.03.2010
11943
22
0
.Bat in .exe umwandeln
Hallo Leute,
ich benutze schon etwas länger Bat2Exe 1.5
Jedoch ist mir jetzt aufgefallen, das dieses Programm einfach nur die ORIGNALE Batchdatei ins temp\ kopiert und die dann im Order wo die exe liegt ablaufen lässt!
Das ist natürlich überhaupt nicht akzeptabel wenn man den Quellcode verstecken will. Zudem schlägt jedes mal der Virenscanner an wenn was im temp\ passiert.
Die Funktionen wie ICON und Version/Firma/Beschreibung usw. finde ich zwar eigentlich super, aber wenn dafür der Quellcode sichtbar wird kann ich darauf gerne verzichten!
Deshalb wollte ich fragen ob hier jemand ein Kompilierungstool kennt, das WIRKLICH eine .exe erstellt und nicht eine .exe, die nur eine temporäre .bat einfach ausführt?
Kann von mir aus auch ohne die oben genannten Funktionen sein. Der Kompiler darf aber auf keinen Fall irgendwo einfach die Batch "offen ablegen".
Wenn ich könnte würde ich selber nach einem Programm suchen, nur leider steht überall nur "Versteckt den Inhalt Ihrer Batchdateien" und das hilft nicht gerade weiter. Bzw. will ich nicht 20 Programme testen...
Bei Bat2Exe müsste es auf jeden Fall heißen "Versteckt Ihre Batchdateien im Temp Verzeichnis"
Ich danke schonmal im Vorraus für eure Hilfe
MFG
Marci
ich benutze schon etwas länger Bat2Exe 1.5
Jedoch ist mir jetzt aufgefallen, das dieses Programm einfach nur die ORIGNALE Batchdatei ins temp\ kopiert und die dann im Order wo die exe liegt ablaufen lässt!
Das ist natürlich überhaupt nicht akzeptabel wenn man den Quellcode verstecken will. Zudem schlägt jedes mal der Virenscanner an wenn was im temp\ passiert.
Die Funktionen wie ICON und Version/Firma/Beschreibung usw. finde ich zwar eigentlich super, aber wenn dafür der Quellcode sichtbar wird kann ich darauf gerne verzichten!
Deshalb wollte ich fragen ob hier jemand ein Kompilierungstool kennt, das WIRKLICH eine .exe erstellt und nicht eine .exe, die nur eine temporäre .bat einfach ausführt?
Kann von mir aus auch ohne die oben genannten Funktionen sein. Der Kompiler darf aber auf keinen Fall irgendwo einfach die Batch "offen ablegen".
Wenn ich könnte würde ich selber nach einem Programm suchen, nur leider steht überall nur "Versteckt den Inhalt Ihrer Batchdateien" und das hilft nicht gerade weiter. Bzw. will ich nicht 20 Programme testen...
Bei Bat2Exe müsste es auf jeden Fall heißen "Versteckt Ihre Batchdateien im Temp Verzeichnis"
Ich danke schonmal im Vorraus für eure Hilfe
MFG
Marci
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator Biber am 03.03.2010 um 16:22:06 Uhr
Beitrag geschlossen.
Content-ID: 136669
Url: https://administrator.de/contentid/136669
Ausgedruckt am: 15.11.2024 um 01:11 Uhr
22 Kommentare
Neuester Kommentar
Hallo,
schau dir mal pcwrunas an.
schau dir mal pcwrunas an.
Hallo,
Batchdateien sind Skripte in einer sehr primitiven Skriptsprache, meines Wissens gibt es dafür keinen echten Compiler, die Mühe lohnt wohl auch nicht. Eigentlich gehört auch zur Definition einer Skriptsprache, dass sie interpretiert wird, allerhöchstens so eine Art "Laufzeitkompilierung" wie bei Perl durchgeführt wird. Es bleibt wohl nur der Weg, wenn man den Inhalt verstecken will (warum eigentlich?), eine echte Compilersprache zu nehmen, ggf. kann man ja da dann die Commandline-Befehle aufrufen, aber elegant ist was anderes...
Grüße
P.S.:
Ich glaube, ich muss meinen Nick in "Don Quichote" ändern....
Batchdateien sind Skripte in einer sehr primitiven Skriptsprache, meines Wissens gibt es dafür keinen echten Compiler, die Mühe lohnt wohl auch nicht. Eigentlich gehört auch zur Definition einer Skriptsprache, dass sie interpretiert wird, allerhöchstens so eine Art "Laufzeitkompilierung" wie bei Perl durchgeführt wird. Es bleibt wohl nur der Weg, wenn man den Inhalt verstecken will (warum eigentlich?), eine echte Compilersprache zu nehmen, ggf. kann man ja da dann die Commandline-Befehle aufrufen, aber elegant ist was anderes...
Grüße
P.S.:
im Vorraus
Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"! Mit einem "r"!Ich glaube, ich muss meinen Nick in "Don Quichote" ändern....
Zitat von @84544:
Mal ne dumme Frage... was will ich damit?
Mal ne dumme Frage... was will ich damit?
warumm willst du den inhalt deiner batch verstecken, wenn es nicht um ein passwort geht?
Hallo,
Peter
Also ich glaube schon, dass das irgendwie zu lösen ist. Ansonsten frage ich mich wo der Sinn eines .exe Compilers liegt.
Nur das eine Batchdatei nicht für einen Compiler gedacht ist. Ein Compiler erwartet deshalb auch einen Quelltext der seiner Syntax / Format entspricht.Peter
Hallo,
Du brauchst schone eine an dem Compiler angepasste Programmiersprache. Eine Lister der programmiersprachen findest du hier.
Du könntest ja mit Visiual Basic von MS anfangen.
Peter
Was ist denn mit .com dateien??? Kann man die ohne entpacken der Originalen Batch ausführen?
Nein. Es hat nichts mit .com oder .exe zu tun. Der Compiler kann einfach keine Batchdateien als Quelltext verarbeiten Der Compiler versteht nicht, was in der Batchdatei drin steht. Es hat nichts mit der ausführbaren Datei zu tun.Du brauchst schone eine an dem Compiler angepasste Programmiersprache. Eine Lister der programmiersprachen findest du hier.
Du könntest ja mit Visiual Basic von MS anfangen.
Peter
Hallo,
Peter
Auf jeden Fall scheint das der einzige (und wahrscheinlich einzige) Weg zu sein ein Batchdatei richtig zu schützen!
Eine Batchdatei kannst du nicht "richtig" schützen. Wenn diese abgearbeitet werden soll, dann entweder als Datei irgendwo im Dateisystem oder nur im RAM. Aber auch dort kann (und wird dann wohl auch wenn so Geheime Daten da drin stehen) gefunden und ausgelesen. Selbst wenn die schon abgearbeitet wurde, kann die noch lange im RAM stehen.Selbst kostenpflichtige Programme machen so ein Versteckspiel im Tempordner....
Wie denn auch sonst.Wenn mir einer sagen kann ob und wie das funktioniert und ob das wirklich sehr sicher ist (Reverse Engineering), dann wär
das Problem gelöst und derjenige bekommt von mir ein Bussi^^
Lösungswege wurden dir doch schon reichlich genannt. Programmiersprache / Compiler / Linker / Verschlüsselung der Ausführbaren Dateien usw.das Problem gelöst und derjenige bekommt von mir ein Bussi^^
Peter
Nochmal zu den Grundlagen:
Eine CPU "versteht" weder Batch- noch Perl- noch C- noch irgendwas Befehle, sondern nur die sogenannte "Maschinensprache", das sind zunächst einmal 8-,16-,32-,...Bit-Zahlen. Für diese Zahlen gibt es nun etwas menschenlesbarere Ausdrücke, die sogenannten Assemblerbefehle, die eine 1:1-Übersetzung dieser Maschinenbefehle in "Worte" sind. Aber auch damit ist das Programmieren schwierig. Also hat man Programmiersprechen, wozu im weitesten Sinne auch die Skriptsprachen gehören, entwickelt. Diese Befehle (Batch, Basic, Pascal, Algol,...) müssen nun, damit der Computer (die CPU) damit etwas anfangen kann, in Maschinenbefehle übersetzt werden. Das kann man entweder bei jeder Ausführung des Programmes Befehl für Befehl tun (Interpreter) oder einmal komplett (Compiler), so dass dann der Maschinencode direkt vorliegt, was natürlich in der Regel eine viel schnellere Programmausführung bedeutet. Der Sinn eines Compilers ist es also nicht, den Quelltext irgendwie zu "schützen", sondern, die Programmausführung zu beschleunigen. Da es sich bei Skriptsprachen (und insbesondere bei der "Batch"-Sprache) um Sprachen zur Automatisierung kleinerer, nicht laufzeitkritischer (ok, ok, Perl, Python & Co. entwickeln sich da gerade anders, aber sind das wirklich noch Skriptsprachen?) Aufgaben handelt, warum sollte sich da jemand die Mühe machen, einen Compiler zu entwickeln?
Abgesehen davon ist das Konzept, Quellcode zu "schützen", sowieso fragwürdig.
Eine CPU "versteht" weder Batch- noch Perl- noch C- noch irgendwas Befehle, sondern nur die sogenannte "Maschinensprache", das sind zunächst einmal 8-,16-,32-,...Bit-Zahlen. Für diese Zahlen gibt es nun etwas menschenlesbarere Ausdrücke, die sogenannten Assemblerbefehle, die eine 1:1-Übersetzung dieser Maschinenbefehle in "Worte" sind. Aber auch damit ist das Programmieren schwierig. Also hat man Programmiersprechen, wozu im weitesten Sinne auch die Skriptsprachen gehören, entwickelt. Diese Befehle (Batch, Basic, Pascal, Algol,...) müssen nun, damit der Computer (die CPU) damit etwas anfangen kann, in Maschinenbefehle übersetzt werden. Das kann man entweder bei jeder Ausführung des Programmes Befehl für Befehl tun (Interpreter) oder einmal komplett (Compiler), so dass dann der Maschinencode direkt vorliegt, was natürlich in der Regel eine viel schnellere Programmausführung bedeutet. Der Sinn eines Compilers ist es also nicht, den Quelltext irgendwie zu "schützen", sondern, die Programmausführung zu beschleunigen. Da es sich bei Skriptsprachen (und insbesondere bei der "Batch"-Sprache) um Sprachen zur Automatisierung kleinerer, nicht laufzeitkritischer (ok, ok, Perl, Python & Co. entwickeln sich da gerade anders, aber sind das wirklich noch Skriptsprachen?) Aufgaben handelt, warum sollte sich da jemand die Mühe machen, einen Compiler zu entwickeln?
Abgesehen davon ist das Konzept, Quellcode zu "schützen", sowieso fragwürdig.
Moin Marci3xXx,
ich sehe wenig Chancen, dass deine eigentliche Frage, sofern sie denn aus deinem Eröffnungsbeitrag eindeutig hervorgeht, hier sinnvoll beantwortet werden kann und wird.
Wie du merkst, gibt es hier grundsätzliche Vokabel-Verständnisprobleme und ganz ganz unterschiedliche Kontextbezüge bei dir auf der einen Seite und allen anderen Kommentatoren (entsprechend auf je irgendeiner anderen Seite).
Ich versuch mal den Ball etwas flacher zu halten:
Nein, wird und kann keine/r kennen, weil es keins geben kann.
Eine Batch-Datei ist halt immer nur eine unformatierte Plain-Text-Datei mit Inputbefehlen für ein ablauffähiges Programm (die CMD.exe).
Diese CMD.exe MUSS selbst alle Befehle in dieser Text-Datei ausführen und dazu MÜSSEN die Befehle wiederum als klar & unverschlüsselt vorliegende lesbare UND physikalisch im Dateisystem vorhandene Datei vorliegen.
Bei "physikalisch im Dateisystem vorliegende Datei" ist dann doch wirklich egal, ob im %temp%-Verzeichnis, ob in einem dafür angelegten (versteckten) Ordner oder gleich im Papierkorb. Es liegt für jeden, der nicht genauso unbeholfen ist wie mein nichtsnutziger Schwiegerneffe Klaus-Bärbel, offen auf der Platte rum.
--> Wenn damit die eigentliche Frage abgefrühstückt ist: bitte Haken dran.
--> Wenn jemand Interesse hat an einem Thread "Sind so genannte Batch-Compiler sinnvoll oder ein Treppenwitz der IT-Geschichte?". dann macht einen neuen Beitrag auf bitte.
Gern auch im Bereich Entwicklung, denn diese Fragen nach diesen Tools kommen ja doch immer hier rein.
Grüße
Biber
ich sehe wenig Chancen, dass deine eigentliche Frage, sofern sie denn aus deinem Eröffnungsbeitrag eindeutig hervorgeht, hier sinnvoll beantwortet werden kann und wird.
Wie du merkst, gibt es hier grundsätzliche Vokabel-Verständnisprobleme und ganz ganz unterschiedliche Kontextbezüge bei dir auf der einen Seite und allen anderen Kommentatoren (entsprechend auf je irgendeiner anderen Seite).
Ich versuch mal den Ball etwas flacher zu halten:
Deshalb wollte ich fragen ob hier jemand ein Kompilierungstool kennt, das WIRKLICH eine .exe erstellt und nicht eine .exe, die nur eine temporäre .bat einfach ausführt?
Nein, wird und kann keine/r kennen, weil es keins geben kann.
Eine Batch-Datei ist halt immer nur eine unformatierte Plain-Text-Datei mit Inputbefehlen für ein ablauffähiges Programm (die CMD.exe).
Diese CMD.exe MUSS selbst alle Befehle in dieser Text-Datei ausführen und dazu MÜSSEN die Befehle wiederum als klar & unverschlüsselt vorliegende lesbare UND physikalisch im Dateisystem vorhandene Datei vorliegen.
Bei "physikalisch im Dateisystem vorliegende Datei" ist dann doch wirklich egal, ob im %temp%-Verzeichnis, ob in einem dafür angelegten (versteckten) Ordner oder gleich im Papierkorb. Es liegt für jeden, der nicht genauso unbeholfen ist wie mein nichtsnutziger Schwiegerneffe Klaus-Bärbel, offen auf der Platte rum.
--> Wenn damit die eigentliche Frage abgefrühstückt ist: bitte Haken dran.
--> Wenn jemand Interesse hat an einem Thread "Sind so genannte Batch-Compiler sinnvoll oder ein Treppenwitz der IT-Geschichte?". dann macht einen neuen Beitrag auf bitte.
Gern auch im Bereich Entwicklung, denn diese Fragen nach diesen Tools kommen ja doch immer hier rein.
Grüße
Biber
Hallo Marci3xXx,
Um solche Kleinigkeiten zu erledigen, ohne dass mir jemand "in die Karten schaut" nehme ich immer AutoIT !
Ist eine leicht und schnell zu erlernende Script-Sprache und kann in eine exe-Datei kompiliert werden.
Schau es Dir mal an!
Gruss, thommy75
Um solche Kleinigkeiten zu erledigen, ohne dass mir jemand "in die Karten schaut" nehme ich immer AutoIT !
Ist eine leicht und schnell zu erlernende Script-Sprache und kann in eine exe-Datei kompiliert werden.
Schau es Dir mal an!
Gruss, thommy75
Zitat von @thommy75:
Hallo Marci3xXx,
Um solche Kleinigkeiten zu erledigen, ohne dass mir jemand "in die Karten schaut" nehme ich immer
AutoIT !
Ist eine leicht und schnell zu erlernende Script-Sprache und kann in eine exe-Datei kompiliert werden.
Schau es Dir mal an!
Gruss, thommy75
Hallo Marci3xXx,
Um solche Kleinigkeiten zu erledigen, ohne dass mir jemand "in die Karten schaut" nehme ich immer
AutoIT !
Ist eine leicht und schnell zu erlernende Script-Sprache und kann in eine exe-Datei kompiliert werden.
Schau es Dir mal an!
Gruss, thommy75
*möööp*
autoit decompiler
http://blog.nerdbucket.com/autoit-decompiler-for-v3-2-6/article
Au S......e!
@45877
Hab's gerade ausprobiert - funktioniert wirklich problemlos....
Bei AutoIt habe ich Forum mal gelesen, dass es früher möglich war, (ganz bewusst) eine exe wieder in das au3-Script umzuwandeln, dies wurde jedoch vor ein paar Releases entfernt.
Da habe ich mich eigentlich in Sicherheit gewogen, was das "einfache" Auslesen des Quell-Codes anbelangt. Aber nach den paar Mausklicks von gerade eben kann das ja ein jeder Laie...
Auf jeden Fall mal danke für den Hinweis!
@jhinrichs
Also bei einem ordinären Skript wüsste ich auf Anhieb eigentlich nur einen Grund, den Quellcode zu verstecken: Passwörter oder Benutzernamen im Klartext (z.B. bei net use o.ä.).
Ich schütze (oder besser gesagt 'schützte') meinen Code, da es z.T. kleine Programme sind, deren Quellcode man eigentlich nicht gerne weitergibt - kostet mich schliesslich auch eine Menge Zeit. Aber diese haben nichts mehr mit einem Skript zu tun...
Gruss, thommy75
@45877
Hab's gerade ausprobiert - funktioniert wirklich problemlos....
Bei AutoIt habe ich Forum mal gelesen, dass es früher möglich war, (ganz bewusst) eine exe wieder in das au3-Script umzuwandeln, dies wurde jedoch vor ein paar Releases entfernt.
Da habe ich mich eigentlich in Sicherheit gewogen, was das "einfache" Auslesen des Quell-Codes anbelangt. Aber nach den paar Mausklicks von gerade eben kann das ja ein jeder Laie...
Auf jeden Fall mal danke für den Hinweis!
@jhinrichs
Also bei einem ordinären Skript wüsste ich auf Anhieb eigentlich nur einen Grund, den Quellcode zu verstecken: Passwörter oder Benutzernamen im Klartext (z.B. bei net use o.ä.).
Ich schütze (oder besser gesagt 'schützte') meinen Code, da es z.T. kleine Programme sind, deren Quellcode man eigentlich nicht gerne weitergibt - kostet mich schliesslich auch eine Menge Zeit. Aber diese haben nichts mehr mit einem Skript zu tun...
Gruss, thommy75
Hi !
Naja...vielleicht könnte jemand dahinter kommen, dass man doch nicht so der absolute "Batchelor" ist ... :-P
mrtux
Zitat von @jhinrichs:
Hatte ich es schon gesagt? Welchen Sinn hat es, ein Skript zu "schützen"? Vor wem? Oder was?
Hatte ich es schon gesagt? Welchen Sinn hat es, ein Skript zu "schützen"? Vor wem? Oder was?
Naja...vielleicht könnte jemand dahinter kommen, dass man doch nicht so der absolute "Batchelor" ist ... :-P
mrtux
Hallo,
zu dem Thema Passwörter etc.: Klartextpasswörter in Skripten und sind keine gute Idee, selbst bei einem "kompiliertem" Skript/Programm wäre dass Passwort per Hex-Editor auslesbar. Hier ist die Standardlösung, die Zugangsdaten in eine separate Datei zu schreiben und diese dann mit seeeeeeeeeeehr eingeschränkten Leserechten auszustatten.
Was den "Schutz geistigen Eigentums" angeht, ist zunächst einmal zu klären, wie "schützenswert" das wirklich ist, also wieviel eigenständige Leistung da dokumentiert ist. Oder vielleicht gerade, wieviel "geklaut" ist...? Wenn es wirklich ein geniales Schnipselchen Quelltext ist, wird das auch bei Offenlegung angemessen bewundert werden können (s. hier im Forum insbes. die Beiträge von Biber und Bastla, aber auch von anderen Schnipslern), und alle lernen etwas dazu (auch die Codeschreiber). Man stelle sich vor, Linus Torvalds habe seinen Quelltext "schützen" wollen....
Grüße
zu dem Thema Passwörter etc.: Klartextpasswörter in Skripten und sind keine gute Idee, selbst bei einem "kompiliertem" Skript/Programm wäre dass Passwort per Hex-Editor auslesbar. Hier ist die Standardlösung, die Zugangsdaten in eine separate Datei zu schreiben und diese dann mit seeeeeeeeeeehr eingeschränkten Leserechten auszustatten.
Was den "Schutz geistigen Eigentums" angeht, ist zunächst einmal zu klären, wie "schützenswert" das wirklich ist, also wieviel eigenständige Leistung da dokumentiert ist. Oder vielleicht gerade, wieviel "geklaut" ist...? Wenn es wirklich ein geniales Schnipselchen Quelltext ist, wird das auch bei Offenlegung angemessen bewundert werden können (s. hier im Forum insbes. die Beiträge von Biber und Bastla, aber auch von anderen Schnipslern), und alle lernen etwas dazu (auch die Codeschreiber). Man stelle sich vor, Linus Torvalds habe seinen Quelltext "schützen" wollen....
Grüße
Ohne mich jetzt in die Tiefen der Diskussion zu begben, lang lang ist's her, da habe ich das 'Problem' mit bat2com 'gelöst'. Man konnte ein paar kB auf der Diskette sparen und ein bissl Eindruck machen Wer ein bissl Ahnung hat wird mit Hexeditor und Debugger immer rauskriegen was du eigentlich aufrufst. Wenn es um Sicherheit geht, mußt du dir schon was anderes einfallen lassen. No security by obscurity. Um eine pfiffige Batch-Konstruktion zu 'schützen' sollte es aber reichen. (Wobei das schade wäre, die Welt braucht guten Code.)
-BP-
-BP-
Also nee....
jetzt hat es dieser Beitrag in die Top-Beiträge des Monats geschafft... was ein Irrsinn.
Ich war der Hoffnung, dass jetzt zumindest mehrheitlich akzeptiert worden wäre, dass
Bitte @Marcys: Mach einen "Beantwortet"-Haken dran, danach (oder ggf. auch ohne Haken) schließe ich den Thread Done.
Und gerne an @allediskussionsfreudigen: Macht meinetwegen einen neuen Beitrag auf zum Thema "Sinn und Unsinn eines Batch-Compilers", damit wir irgendwann mal auf einen Referenz-Beitrag verweisen können.
Grüße
Biber
jetzt hat es dieser Beitrag in die Top-Beiträge des Monats geschafft... was ein Irrsinn.
Ich war der Hoffnung, dass jetzt zumindest mehrheitlich akzeptiert worden wäre, dass
- Batch-Skripte nicht zu Exe-Dateien kompiliert & gelinkt werden können und
- Jungfrau kein in der gesamten EU anerkannter Ausbildungsberuf ist und werden wird.
Und gerne an @allediskussionsfreudigen: Macht meinetwegen einen neuen Beitrag auf zum Thema "Sinn und Unsinn eines Batch-Compilers", damit wir irgendwann mal auf einen Referenz-Beitrag verweisen können.
Grüße
Biber