 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Feenfleisch
Anmeldungsdatum: 11.08.2005 Beiträge: 15
|
Verfasst am: 13.12.2006, 21:25 Titel: datei in datei verstecken |
|
|
hallo,
ich schreibe gerade ein programm mit welchem man dateien verschlüsseln und anschließend noch in eine andere dateien verstecken kann, den teil mit der verschlüsselung ist fertig und das verstecken an sich ist auch nicht das problem, weil ich die eine datei einfach an das dateiende der andere packen. das problem ist leider sie wieder zu trennen. mit der eingabe der stelle, wo der versteckkte teil anfängt, wäre es kein problem, aber das wollte umgehen. hat jemand vielleicht ne idee oder vorschlag. vielen dank im voraus.
greetz,
feenfleisch |
|
Nach oben |
|
 |
PMedia
Anmeldungsdatum: 14.08.2006 Beiträge: 2847
|
Verfasst am: 13.12.2006, 21:41 Titel: |
|
|
Warum hängst du die Position nicht GANZ am Ende an? Geht auch, und ist leicht zu ermitteln... |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 13.12.2006, 22:13 Titel: |
|
|
richtig.
deine daten beginnen bei LOC(1) + 1. Also wenn die vorherige datei (um einfache zahlen zu verwenden) 1 byte lang ist, und du hängst nun 5 byte daten ran, müsstest du zuerst LOC(1) [= 1] + 1 = 2 speichern. dann hängst du deine 5 byte daten an die datei und dann deine variable, die das offset enthält. die daten sind dann LOF(1) - offset - 4 (itneger-variable) - 1 bytes lang.
rechnung:
Stelle 1: 1 byte waren schon da
Stelle 2: 5 byte daten
Stelle 7: 4 Byte Integer
Stelle 10: Das ist LOF(1)
könnte sein dass irgendeine rechnung falsch ist....  _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
Feenfleisch
Anmeldungsdatum: 11.08.2005 Beiträge: 15
|
Verfasst am: 14.12.2006, 16:50 Titel: |
|
|
das mit dem offset hintenanhängen klappt, aber das auslesen macht probleme. genau das mit integer = 4 byte klappt net. hier mal den code den ich dazu geschrieben hab.
anhängen:
open dateiname_zieldatei$ for binary as #2
dateigroesse = lof(2)
put #2, (lof(2) +2), text$
put #2, , dateigroesse
close #2
abhängen:
open dateiname_ausgangsdatei$ for binary as #1
get #1,lof(1) - 3, dateigroesse
'4 = integer variable klappe einfach nicht, meine testdatei ist 156 byte groß, wenn 3 nehm klappt es wunderbar, aber halt nur mit dieser oder mit dateien die ähnlich groß sind'
text$=space(lof(1)-dateigroesse-5)
'dateigroesse + 2 (abstand zwischen zwischen orginal und angehängter datei) = 5'
get #1,dateigroesse+2, text$
close #1
vielelicht jemand ne idee wie man das hinbekommt? vielen dank im voraus. |
|
Nach oben |
|
 |
Michael Frey

Anmeldungsdatum: 18.12.2004 Beiträge: 2577 Wohnort: Schweiz
|
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 14.12.2006, 22:56 Titel: |
|
|
So wie ich Dich verstehe, möchtest Du bestimmt eine Steganograhie-Routine schreiben.
So etwas hatte ich übrigens früher einmal erstellt:
http://www.dreael.ch/QB/PAL_STEG.ZIP
Als Trägerdatei dienen hier .BMP-Dateien mit 256 Farben. Für die Interessierten noch das gewählte Verfahren (geht zugegebenermassen mathematisch bereits etwas in die Eliteklasse!): Jeder, der schon einen BMP-Lader programmiert hat, weiss, was indizierte Farben sind. Die Farben als RGB-Werte sind als Palette definiert, in der eigentlichen Bitmap verweist jeder Pixel auf einen bestimmten Paletteneintrag. Letztendlich sind sämtliche QB-SCREEN-Modi so aufgebaut (QB kennt noch keine TrueColor-Grafikmodi wie FreeBasic).
Man studiere dazu folgenden QB-Programm ganz genau (ob unter FreeBasic 1:1 lauffähig kann ich nicht garantieren):
http://beilagen.dreael.ch/QB/PAL_PERM.BAS
Wie man feststellt, ändern wir den Inhalt im Video-RAM und in den Palettenregistern klar ab, aber optisch bleibt die Grafik nach dem Farbentausch 100% identisch! Solche Vertauschungen kann ich natürlich beliebig viele vornehmen => ich kann also optisch dasselbe Bild auf 16! (Fakultät von 16=1*2*3...*15*16) = 20'922'789'888'000 verschiedene Arten (=Permutationen) darstellen.
Normalerweise definiert man in der Farbpalette keine 2 identischen Farben, d.h. jede Farbe ist einmalig. Dies erlaubt uns eine Sortierung der Farbpalette. Die verschiedenen zuvor genannten Farbpalettenpermutationen lassen sich hierbei wie Wörter in einem Duden gewissermassen auch lexikografisch sortieren und durchnummerieren, womit jede Farbpalettenpermutation eine Ordnungszahl bekommt. Genau diese Ordnungszahl wird als Informationsträger für die zu versteckende Nachricht verwendet. Bei unserem SCREEN 7-Bild von vorhin lassen sich log2(16!)=44.25 Bits unterbringen, was etwa 4½ ASCII-Zeichen entspricht. Bei 256 Farben kann die Palette auf 256! verschiedene Arten angeordnet werden. Dies ergibt bereits log2(256!)=1683.996 Bits, was knapp 210½ ASCII-Zeichen entspricht. Dies reicht bereits für ein SMS locker aus.
Ausser der Palettenmutation verwende ich noch ein zweites Versteck in .BMP-Dateien: Wie ebenfalls jeder Programmierer einer .BMP-Verarbeitungsroutine bestens weiss, muss eine Pixelzeile immer 32-Bit-aligned abgelegt werden. Ist das Bild also 158 Pixel breit, so müssen wir 160 Bytes speichern. Es bleiben am Schluss 2 ungenutzte Bytes übrig, und in diese kann ich natürlich ebenfalls ein Teil der zu versteckenden Datei ablegen.
Die Programmbedienung selber ist sehr einfach (ich denke, es sollte problemlos 1:1 in FreeBasic lauffähig sein): Start STEG_ENC.BAS Eingabe Datei mit Träger, Datei mit geheimen Inhalt und anschliessend Zieldatei.
Mit Paint kann jeder feststellen, dass das Zielbild optisch immer noch absolut identisch ist.
STEG_DEC.BAS macht einfach das Umgekehrte wieder: Geheimdatei extrahieren. Noch einige Implementationsdetails: Wenn die Geheimdatei kleiner als die Kapazität der .BMP-Datei ist, so wird ein "Padding" (Auffüllung) mit Zufallsbytes gemacht. Schlussendlich noch ein Tipp, um möglichst viel Kapazität für die Geheimdatei zu gewinnen: Möglichst hochformatiges Bild und Breite MOD 4 = 1 (Breite=4*n+1 mit n=ganze Zahl), so dass mit 3 Alignment-Bytes die maximal mögliche Lückengrösse entsteht. Ein Foto eines Fernsehturms ist daher nicht schlecht geeignet. Falls es in der Palette identische (vor allem ungenutzte Paletteneinträge!) Farben gibt, so werden diese automatisch vereint und die Palette noch mit eindeutigen Zufallsfarben ergänzt, so dass die 256! Palettenanordnungen immer möglich sind.
Auf Dateisystemebene bei NTFS existiert sonst ebenfalls ein Versteck: sog. Alternate Data Streams.
Zum Abschluss noch eine kleine "Knacknuss":
http://beilagen.dreael.ch/QB/TEL_MAST.BMP
In diesem hübschen :-) Telefonmasten-Foto (mit Digitalkamera bei einem Ausflug in den Alpen abgeknipst) steckt doch noch etwas mehr drin. Hinweis: Das ZIP-Passwort lautet "Gehe1m". Wer schafft es den Inhalt rauszuholen?
An diesem Beispiel sollte man gleich die Methode des Profis erkennen:
komprimieren, verschlüsseln und dann steganografisch verpacken. Der Empfänger macht die entsprechenden Schritte genau umgekehrt herum. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
Mao
Anmeldungsdatum: 25.09.2005 Beiträge: 4409 Wohnort: /dev/hda1
|
Verfasst am: 15.12.2006, 15:47 Titel: |
|
|
Code: |
Mit Hilfe von Datenkompression können praktisch ganze E-Mails verpackt werden.
Nachfolgend einfach ein Ausschnitt aus http://de.wikipedia.org/wiki/Steganografie als
Beispiel:
...
|
 _________________ Eine handvoll Glück reicht nie für zwei.
--
 |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|