Shell Script als Binary erzeugen

[twisterchen]

Hallo

vielleicht rede ich grad grossen Müll nur ist es möglich ein .sh datei irgend wie in eine Binary Datei umzuwandeln.

Was ich möchte ist das mann den quellcode der .sh datei nicht mehr sieht

oder was stehen mir da für andere möglichkeiten zur Auswahl


Vielen Dank für eure hinweise

Gruss
Brandmeir Gerhard

[oxygen]

Hallo

vielleicht rede ich grad grossen Müll nur ist es möglich ein .sh datei irgend wie in eine Binary Datei umzuwandeln.

Was ich möchte ist das mann den quellcode der .sh datei nicht mehr sieht

oder was stehen mir da für andere möglichkeiten zur Auswahl


Vielen Dank für eure hinweise

Gruss
Brandmeir Gerhard

Alles was man ausführen kann, kann man auch lesbar machen.

[twisterchen]

Alles was man ausführen kann, kann man auch lesbar machen.

Hmm versteh ich jetzt net ganz.
Ok lesen bestimmt aber doch dann nur mit lauter Hieroglyphen

Oder versteh ich da jetzt was falsch ich möchte doch nur den Quellcode unsichtbar machen.

Wenn ich doch Src Code compiliere dann ist er doch in der erstellten datei auch nicht direkt lesbar.

Bitte um weitere erklährung und Hilfe

Gruss
Brandmeir Gerhard

[mattiass]

Wenn ich doch Src Code compiliere dann ist er doch in der erstellten datei auch nicht direkt lesbar.

Dann schreib ein kleines C-Programm und kompiliere dieses. Oder nimm Java und den GCJ...

[debcha]

@Twisterchen

Vor genau diesem "Problem" stehe ich auch. Ein normales Bash-Skript soll nicht einsehbar sein (zwecks Code bzw. zwecks irgendwelcher Passwörter). Nur möchte ich das gesamte Shell-Script nicht nach C portieren (da ich in C relativ unerfahren bin). Oder kennt jmd vielleicht eine einfachere Lösung? Manchmal sieht man den Wald vor lauter Bäumen nicht.

MfG

[twisterchen]

Hmm

also die .sh datei enthält eigentlich nur etliche if anweisungen ein par wget befehle

die if anweisungen dürften doch eigentlich gleich sein wie in c oder c++

Ich habe mal die .sh datei mit dem gcc laufen lasen und bekamm wie erwartet fehler

Code: Select all

twister:/test # gcc install.c

Code: Select all

install.c:3: error: syntax error before string constant

ok hier hab ich kein plan was ich mit der Fehlermeldung anfangen soll

Code: Select all

install.c:96:2: warning: no newline at end of file

und hier naja es gibt keine newline

das mir irgendwelche header dateien fehlen ok vielleicht habt ihr mir ja ne Anleitung wie ich eine .c datei aufbauen muss und beenden muss


Gruss
Brandmeir Gerhard

[mattiass]

also die .sh datei enthält eigentlich nur etliche if anweisungen ein par wget befehle

die if anweisungen dürften doch eigentlich gleich sein wie in c oder c++

Nein. Die Shell, vor allem die Bash arbeitet ganz anders!

[aubergine]

@Twisterchen

Vor genau diesem "Problem" stehe ich auch. Ein normales Bash-Skript soll nicht einsehbar sein (zwecks Code bzw. zwecks irgendwelcher Passwörter). Nur möchte ich das gesamte Shell-Script nicht nach C portieren (da ich in C relativ unerfahren bin). Oder kennt jmd vielleicht eine einfachere Lösung? Manchmal sieht man den Wald vor lauter Bäumen nicht.

MfG

Ja z.B. mit Unix File Rechten arbeiten alla chmod 700

[debcha]

@aubergine

Fällt leider aus wenn jenes Skript auf nem fremden System eingesetzt werden soll.

[aubergine]

Selbst wenn du die Befehle des Scripts nach C portieren kannst und dieses dann compilierst, hast du auch C das Passwort im Quelltext übergeben und es ist auch nach dem Compilieren lesbar.

[mattiass]

Selbst wenn du die Befehle des Scripts nach C portieren kannst und dieses dann compilierst, hast du auch C das Passwort im Quelltext übergeben und es ist auch nach dem Compilieren lesbar.

Wir sollten das Problem an der Wurzel packen und fragen, was das Script macht. Wenn Passwörter drinstehen, dann lässt sich möglicherweise eine PublicKey-Auth verwenden?

[tk]

Hi,

wie lang ist denn dein Shellskript? Poste es doch mal (mit veränderten Passwörtern), dann kann man eher sagen, ob und wie es Sinn macht.

Gruß

TK

[debcha]

@tk
Lässt sich leider nicht posten, firmenspezifisch. Lässt sich darüber vielleicht eine theoretische Aussage machen?


@aubergine
Ein C-binary kannst du ja nicht einfach mit nem Editor anschauen. Disassemblen/o.ä. mal ausgeschlossen ist es danach meines Wissens nicht mehr einsehbar.


Danke für eure Antworten
MfG

[mattiass]

@aubergine
Ein C-binary kannst du ja nicht einfach mit nem Editor anschauen. Disassemblen/o.ä. mal ausgeschlossen ist es danach meines Wissens nicht mehr einsehbar.

Lass mal über ein beliebiges Binary "strings" drüberlaufen...

[oxygen]

@aubergine
Ein C-binary kannst du ja nicht einfach mit nem Editor anschauen. Disassemblen/o.ä. mal ausgeschlossen ist es danach meines Wissens nicht mehr einsehbar.

strings programname und schon hätte man das Passwort.

EDIT: pfff, da war doch glatt einer schneller

[debcha]

Ok überzeugt *g
Man lernt nie aus. Danke für den Hinweis !

[hoschi]

Hallo

Hallo

vielleicht rede ich grad grossen Müll nur ist es möglich ein .sh datei irgend wie in eine Binary Datei umzuwandeln.

Auch ich bin auf der Suche nach soetwas - allerdings nicht um meinen Quellcode zu schützen, sondern um etwas zu umgehen, was ich für einen bug halte. Ich weiß, das es für DOS & Wwindows bat2exe gibt - sowas suche ich nun für shell-scripte.

Das Problem:
Ich habe ein Schell script, indem rsync aufgerufen wird. Das geht alles hervorragend. Nur sobald man das ganze als cron-job anlegt geht es nicht mehr.

Zum Testen habe ich rsync mal direct in die crontab gepackt, aber auch das ging nicht.

Cron schickt ja mails an den benutzer, der etwas startet. Wenn ich rsync im script hatte, bekam ich eine eMail mit der hilfeseite von rsync und unten stand was von Syntax-fehler. Und bei rsync direkt in der crontab wurde aus <Benutzername>@<Host> <User-Home-Dir><Benutzername>@<Host> (also anstelle von rsync@192.168... stand da in der eMail das /home/rsync/rsync@192.168... nicht gefunden wurde und das kann so natürlich nicht gehen). Meine Hoffnung ist, das sowas bei einem binary nicht passiert.

Ich hab's auch schonmal anders versucht und anstelle von rsnc@... -e 'ssh -l rsync' benutzt, aber da passiert auch nichts sinnvolles.

System: SuSE 10 mit dem Kernel der ausgeliefert wurde, aber sonst ist alles aktuell. Es gibt da noch das Problem, das SuSE den Raid-Controller nach einem Kernel Update nicht erkennt, da der Treiber nach einem update nicht mehr geladen wird. Muss man sich mal mit befassen, aber später.

[captaincrunch]

Meine Hoffnung ist, das sowas bei einem binary nicht passiert.

Fein! Wenns nach den Zeugen Jehovas ginge, gäb's uns alle schon längst nicht mehr. Anstatt blind solchen Theorien hinterher zu rennen, könntest du dich (z.B. per #!/bin/sh -x in der ersten zeile deines Scripts) mal mit ernsthaftem Debugging auseinandersetzen.

[lucki2]

oder was stehen mir da für andere möglichkeiten zur Auswahl

Code: Select all

chmod 500 

sonst 1. wahl:
perlcc

Aber was andere schon gesagt haben: Compilieren ist keine Methode, die irgendwie Sicherheit gegen Fremde bietet. Passwörter schützen durch Compilieren ist Sicherheitsrisiko Nr.1(neben Leuten die Server mit Spielzeug verwechseln).

Passwörter, die von einer Maschine benutzt werden, gehören in einfache Menschenlesbare Dateien an eine Stelle, an die niemand Unberechtigter hinkommt. Sonst kommt es zu den Fehler sich über Sicherheit keine gedanken zu machen. Du brauchst die nicht verschlüsseln, da ein Entschlüsselungsvberfahren in dem Falle ohnehin auf der Maschine sein muß. Im übrigen gibt es auch Leute, die sich so ein Progrämmchen nur im Hexeditor anschauen müssen um die Passworte zu finden. m.f.G.

@Hoschi Rechte überprüfen! und/oder *hihi* mal mit "bash -l" starten und wenn das hilft, diese pseudosicherheit abschalten.

[hoschi]

#!/bin/sh -x

Da ändert sich nichts am Inhalt der eMail, die Cron erzeugt - es steht nach wie vor nur dies in der eMail:

Date: Thu, 12 Oct 2006 11:38:01 +0200 (CEST)

rsync version 2.6.6 protocol version 29
Copyright (C) 1996-2005 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, ACLs, symlinks, batchfiles,

inplace, IPv6, 64-bit system inums, 64-bit internal inums, SLP

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

rsync is a file transfer program capable of efficient remote update
via a fast differencing algorithm.

Usage: rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
or rsync [OPTION]... [USER@]HOST:SRC [DEST]
or rsync [OPTION]... SRC [SRC]... DEST
or rsync [OPTION]... [USER@]HOST::SRC [DEST]
or rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
or rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]
or rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST

<Ich kürze das mal hier und mach dann mit dem Ende Weiter>
Use "rsync --daemon --help" to see the daemon-mode command-line options.
Please see the rsync(1) and rsyncd.conf(5) man pages for full documentation.
See http://rsync.samba.org/ for updates, bug reports, and answers
rsync error: syntax or usage error (code 1) at main.c(909)

Und mit -l passiert das genau so.

[captaincrunch]

Einfache Lösung: Script posten.

[hoschi]

Kann ich natürlich machen - aber wie gesagt: Nur als Cron-job funktioniert es nicht. Wenn man sich selbst per ssh anmeldet, kann man es so starten.

Code: Select all

#!/bin/bash

echo "Removing old archives..."
find /home/rsync/archiv/ -mtime 7 -name "*.tar.bz2" -exec rm {} ;
echo "Done."

echo "Synchronising files..."
/usr/bin/rsync -e 'ssh -l rsync' -aRvcz --delete --exclude "/home/samba/base/austausch" --exclude "/home/samba/base/lost+found" --exclude "/home/samba/base/software" --exclude "/home/samba/base/publish" 192.168.1.195:/home/samba/base/ /home/rsync/sync
echo "Done."

echo "Creating new archive..."
DATUM=$(date "+%F_%T")
tar -cvpjf /home/rsync/archiv/backup-$DATUM.tar.bz2 /home/rsync/sync

Wobei in der eMail nichts von dem steht, was vor oder nach rsync aufgerufen wird.

Ich hatte die Excludes auch mal so geschrieben: --exclude=/... und anstelle von -e 'ssh -l rsync' stand da -e ssh ... rsync@192.168....

[lucki2]

Vielleicht habe ich heute Nacht zeit - keine ahnung, dann schaue ich nochmal.
Aber kurz: "bash -l" und nicht "ssh -l" war die Idee, ist aber fast vom Tisch.

[hoschi]

Inzwischen läuft das - da musste nur mal jemand rauf schauen, der sich noch keine Gedanken dazu gemacht hatte und der also nicht "voreingenommen" war.

Es war ein cron Problem, wie ich es vermutet habe, und die Tatsache, das der user den Namen eines Befehls hat sorgte für Verwirrung. Irgendwie bin ich in der falschen crontab gewesen! Es gibt ja eine globale und dann für jeden User eine. Ich dachte ich wäre in der globalen und da gibt es eine weitere Spalte für den user, der den Befehl dahinter ausführen soll. In der crontab für die User gibt es das nicht. Da es den user rsync aber auch als Befehl gibt wird "rsync /home/rsync/bin/backup.sh" gestartet und nicht "/home/rsync/bin/backup.sh" Damit sollte klar sein, wieso es da einen Syntaxfehler gab...

Ein echt dämlicher Fehler, der vermeidbar gewesen wäre. Und hätte der user nicht den Namen rsync gehabt wäre sehr schnell aufgefallen, was falsch ist. Aber den habe ich ja nicht selber angelegt und ich habe mir bei cron dann zu wenig Gedanken dazu gemacht. GAY!

Aber kurz: "bash -l" und nicht "ssh -l" war die Idee, ist aber fast vom Tisch.

Ist mir klar - ein kleines mißvertändnis Deinerseits: bash -l stand da mal und da es nicht funktioniert hat, habe ich es wieder raus genommen. und ssh -l ist um den user für die Remoteverbindung fest zu legen - anstelle von user@host.

[lucki2]

Freut mich, wenn es tut. Nur kurz, daß *hihi* war kein Rant sondern mehr: Manchmal rufen Kunden an, bei denen Cron- oder Firewallscripts nicht gehen und ich eigentlich auf Rechte tippen würde aber alles passt und irgendwann: "aaach, Scripts können nur von Loginshells gestarted werden"(bash -l). So far. Ich weiß auch, was ssh -l (im Gegensatz zu bash -l) macht, gerade deswegen der Kurzhinweis zwischen Tür und Angel - aber richtig da habe *ich* nicht richtig gelesen.