CRC Crack?

[Avr F. (hakkinen)]

Hallo Leute!
Versuche seit mehreren Tagen ein mitgeschnittenes Code zu knacken, bis
jetzt leider aussichtslos!:(.Ich wende mich an die Profis(an Euch!) um
einen Rat.
Es handelt sich um eine Internetverbindung über GPRS.
Dies ist ein Teil der Datenverbindung:

7E FF 7D 23 C0 21 7D 23 7D 21 7D 20 7D 2A 7D 22 7D 26 7D 20 7D 2A 7D 20
7D 20 6C 50 7E

7E = Flag
FF = Address
7D+23 = Control
C0'21 = LCP
7D+23 = Conf-Nak:
7D+21 = Id
7D+20'7D+2A = LCP length
7D+22 = Asynchronous Control Character Map, 7D+26 = length,
7D+20'7D+2A'7D+20'7D+20
CRC=6C'50
7E = Flag

Mir ist es unklar wie kommt CRC=6C'50 zustande. Falls einem von Euch
gelingt es diese CRC rauszukriegen,werde ich sehr dankbar!

[Pete Nerlinger (Gast)]

hier wird dir keiner helfen deine dummheit auszugleichen um eine
kriminelle TAT zu vollziehen.

[A.K. (Gast)]

Asynchrones PPP zu dekodieren ist kriminell?

[ab cd (Gast)]

....hier nur Engelsaeuglinge und Saubermaennchen ;-)

[Dirk Broßwick (Gast)]

es wird sich bestimmt um eine CRC16 handeln, aber man sollte schon
wissen von welchen datenblock oder bereich sie berechnet worden ist,
denk mal nicht das das alles war. und wenn nicht schau doch mal in die
doku zu ppp, da gibt es bestimmt eine RFC zu.

CA

[Alexander Dick (Gast)]

Niemand weiß das?

Übrigens die Dekodierung ist nicht etwa illegal. Sie klappt bei mit
nicht wegen Mangel an Informationen. Ich habe schon alles denkbare
ausprobiert, aber auf CRC=6C'50 komme ich einfach nicht!

Wenn das jemand schon mal gemacht hat, bitte helft!

[Hagen (Gast)]

probiere mal einfach alle Bytes zusammen zu addieren. Vielleicht ist es
ja so eine einfache Prüfsumme.

Gruß Hagen

[Alexander Dick (Gast)]

ist keine Summe, definitiv CRC16

Gruß Alex

[Xenu (Gast)]

Warum liest Du Dir nicht einfach die RFCs zum Point-to-Point-Protokoll
durch? Da wird doch die CRC-Berechnung haarklein erklärt!
Sogar mit Sourcecode...

[___Klaus (Gast)]

Hast du mal alle Bits invertiert?

[Christian (Gast)]

RFC1662 (http://www.ietf.org/rfc/rfc1662.txt) und davon der Teil zur FCS
(Frame Check Sequence) ist von Interesse.

[Alexander Dick (Gast)]

Es gibt eine Haufen von Verfahren und Arten zu dekodieren. Im Internet
findet man auch fertige Software und nicht nur das. In der Bibliothek
von AVR gibt es drei Verfahren, die CRC-16 bestimmen.Leider können
keine Software oder eine von den drei Funktionen mir den Wert 6C'50
liefern. Ich glaube, es handelt sich dabei um irgendwelche
Zahlendrehung.

Falls eine von Euch schon mal eine PPP Protokoll geschrieben hat,dann
kann er mir vielleicht ein Hinweis geben.

Vielen Dank Euch allen für die Beteiligung!!!

[Sonic (Gast)]

Wenn Du das Starpolynom nicht kennst wird's schwierig, ansonsten
gibt's wie oben genannt einige Möglichkeiten. Außer es handelt sich um
eine bestimmte Norm.

[Christian (Gast)]

Lies den RFC!

[TheMason (Gast)]

ich bin zwar kein crack im ppp und crc bereich, aber wenn du eine crc16
hast benötigst du doch noch die information welchen internen wert der
crc algorithmus hat, der sich aus den vorhergehenden werten ergibt oder
seh ich da was falsch ? oder wird der crc-generator mit dem start-wert
resettet wenn das paket (markiert durch 7e ?!) kommt ? fließt das flag
evtl nicht mit in die crc ein ?!

[A.K. (Gast)]

LESEN! Steht wirklich alles im RFC drin
(http://www.ietf.org/rfc/rfc1662.txt). Mitsamt Beispielcode für die
CRC-Rechnung.

Was du dabei vielleicht übersehen hast: Diese CRC gilt für den
Nettoinhalt ohne Flags, ohne Escapes, ohne ...  So werden die 7D,7E,7F
Bytes nicht mit einbezogen. Und auch die Control-Character-Map mischt
bei dieser Entscheidung mit.

Wenn du wissen willst, warum das so schräg ist, schau dir mal
synchrones HDLC an, die ursprüngliche Basis von PPP.