Hilfe: Decodieren einer Geheimschrift/Binärer Code!

3 Antworten

Vom Beitragsersteller als hilfreich ausgezeichnet
Nettes Rätsel. :)

Mir sind einige Sachen dabei aufgefallen, aber erstmal deinen Dump in verschiedenen Formatierungen, damit es etwas übersichtlicher wird:

Als String:

'b\x08\x02F\x12B)K\x19b\x08\x06K\x1aB,b\t%b\t$K\x1cb\x08+B)b\x00 B%B(K\x1aB5K\x1cb\x08+b\x08\x1aF\x12b\x08\x02B4B"b\x08\x1eB\'B6b\x00"ikjh'

Als Hex-Dump:

62 08 02 46 12 42 29 4b 19 62 08 06 4b 1a 42 2c 62 09 25 62 09 24 4b 1c 62 08 2b 42 29 62 00 20 42 25 42 28 4b 1a 42 35 4b 1c 62 08 2b 62 08 1a 46 12 62 08 02 42 34 42 22 62 08 1e 42 27 42 36 62 00 22 69 6b 6a 68

Als Dezimal-Dump:

98 8 2 70 18 66 41 75 25 98 8 6 75 26 66 44 98 9 37 98 9 36 75 28 98 8 43 66 41 98 0 32 66 37 66 40 75 26 66 53 75 28 98 8 43 98 8 26 70 18 98 8 2 66 52 66 34 98 8 30 66 39 66 54 98 0 34 105 107 106 104

Und jetzt die Punkte, dir mir sofort ins Auge gesprungen sind:

  • Merkwürdig "ungerade" Länge von 71 Byte

  • Bei fast allen Bytes ist das höherwertigste Bit gesetzt.

  • Die sechste Byte von hinten nimmt - wenn man das höherwertigste Bit ignoriert - den Wert Null an

  • Die letzten 4 Byte haben das höherwertigste Bit - im Gegensatz zu ALLEN anderen Bits - NICHT gesetzt.

  • Das fünfte Byte von hinten hat hat das höherwertigste Bit gesetzt, und sieht auch ansonsten unspektakulär aus, liegt aber GENAU zwischen unserem Null-Byte und den 4 letzten Bytes ohne gesetztes höherwertiges Bit - also gucken wir uns das auch mal genauer an. :)

Daraus folgend können wir folgendes annehmen:

  • Es ist KEINE professionelle Verschlüsselung (Dabei wären die Werte des höherwertigsten Bits gleichmäßiger verteilt)

  • Es könnte sich aber um eine primitive Verschlüsselung handeln, was bedeutet, dass sie verhältnismäßig leicht zu knacken sein müsste. (Kann man an der statistischen Verteilung sehen!)

  • Es ist definitiv KEINE Kompression. (Dabei würden die einzelnen Bitwerte DEUTLICH zufälliger verteilt sein!)

  • Die letzten sechs Byte sind eine Art Trailer. (Im Gegensatz von einem Header, der normalerweise am Anfang einer Datei oder eines Datenstroms steht. ZIP Dateien verwenden z. B. auch Trailer und keine Header!)

So, da die meisten Datentypen aber Header und keine Trailer verwenden, drehen wir deine Daten einfach mal um, und überprüfen auf Plausibilität (wie gesagt, wir lesen jetzt von hinten!):

  • Es ergibt sich eine Art Magic-Number - wie man sie oft an Datei-Headern findet - die auch ncoh exakt reiner ASCII Text ist und sich "hjki" liest. Allerdings haben wir die Daten ja umgedreht, und behalten auch erst mal "ikjh" im Auge.

  • Danach kommt ein Byte mit einem Wert, den wir erstmal noch nicht zuordnen können. (Dezimal 162 und in Hex A2 ... allerdings maskiert mit 0x7F erhalten wir 34 Dezimal und 22 Hex)

  • Darauf folgt ein Byte, bei dem alle Bits, außer das höherwertigste 0 sind. Das sieht verdammt nach einem "Trenner" aus, der den Header von den Daten trennt, und so viel bedeutet wie: "jetzt gehts los"

  • Es könnte auch sein, dass das fünfte und sechste Byte zusammen einen 16-Bit Short Integer ergeben, dessen Wert recht niedrig angesiedelt ist, sodass nur das niederwertigste Byte Verwendung findet.

OK, das sind so die Sachen, die mir spontan aufgefallen sind.

Es würde vielleicht noch weiter helfen zu wissen, wo du diese Daten her hast! :)

Naja, viel Spaß noch beim Knobeln!!! Schönes Rätsel, gefällt mir sehr gut! Muss jetzt aber leider erst mal arbeiten. :)

Schönen Tag noch und viel Erfolg beim Code-Knacken! :)

PS: Ich würde mich erst mal auf die letzten 6 Byte konzentrieren! Die führen bestimmt zum Ziel ... das rieche ich! :)

Hier nochmal die letzten sechs Byte UMGEDREHT (von hinten nach vorn!) mit 0x7F Und-verknüpft (das höherwertigste Bit wird gelöscht!) in verschiedenen Formatierungen:

String => 'hjki"\x00'
Hex => 68 6a 6b 69 22 00
Dez => 104 106 107 105 34 0

(Ich denke, Dezimal sieht man hier den größten Unterschied, oder?) :)


TeeTier  12.02.2015, 08:11

EDIT: Ich habe vergessen dazu zu schreiben, dass bei den kompletten String-, Hex-, und Dezimal-Dumps oben die höherwertigsten Bits gelöscht wurden.

Hier nochmal die unveränderten Dumps deiner Original-Daten:

'\xe2\x88\x82\xc6\x92\xc2\xa9\xcb\x99\xe2\x88\x86\xcb\x9a\xc2\xac\xe2\x89\xa5\xe2\x89\xa4\xcb\x9c\xe2\x88\xab\xc2\xa9\xe2\x80\xa0\xc2\xa5\xc2\xa8\xcb\x9a\xc2\xb5\xcb\x9c\xe2\x88\xab\xe2\x88\x9a\xc6\x92\xe2\x88\x82\xc2\xb4\xc2\xa2\xe2\x88\x9e\xc2\xa7\xc2\xb6\xe2\x80\xa2ikjh'

e2 88 82 c6 92 c2 a9 cb 99 e2 88 86 cb 9a c2 ac e2 89 a5 e2 89 a4 cb 9c e2 88 ab c2 a9 e2 80 a0 c2 a5 c2 a8 cb 9a c2 b5 cb 9c e2 88 ab e2 88 9a c6 92 e2 88 82 c2 b4 c2 a2 e2 88 9e c2 a7 c2 b6 e2 80 a2 69 6b 6a 68

226 136 130 198 146 194 169 203 153 226 136 134 203 154 194 172 226 137 165 226 137 164 203 156 226 136 171 194 169 226 128 160 194 165 194 168 203 154 194 181 203 156 226 136 171 226 136 154 198 146 226 136 130 194 180 194 162 226 136 158 194 167 194 182 226 128 162 105 107 106 104

Wie gesagt - beachte vor allem die letzten 6 Bytes! :)

0
Tanduyl 
Beitragsersteller
 13.02.2015, 02:59
@TeeTier

Ok super, danke! Ich schau mir das nochmal anhand deiner Tips an. : )

1

der Weg wäre, das ins Hexadezimalsystem umzuwandeln, das entspricht dann 2 Stellen für ein 8er-Päckchen, wie es hier vorliegt... und dann müsstest du evtl. mal nach dem "ASCI"-Code schauen..;)


Tanduyl 
Beitragsersteller
 12.02.2015, 03:29

Hab ich auch schon versucht aber leider habe ich noch keine sinnvolle buchstabenfolge herausbekommen : (

0

Schonmal den String aus den negierten Bits gebildet? Also ein bitweises nicht anwednen?