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!
Gast
#400853
hier wird dir keiner helfen deine dummheit auszugleichen um eine kriminelle TAT zu vollziehen.
Gast
#400854
Asynchrones PPP zu dekodieren ist kriminell?
Gast
#400855
....hier nur Engelsaeuglinge und Saubermaennchen ;-)
Gast
#400856
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
Gast
#400857
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!
Gast
#400858
probiere mal einfach alle Bytes zusammen zu addieren. Vielleicht ist es ja so eine einfache Prüfsumme. Gruß Hagen
Gast
#400859
ist keine Summe, definitiv CRC16 Gruß Alex
Gast
#400860
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...
Gast
#400861
Hast du mal alle Bits invertiert?
Gast
#400862
RFC1662 (http://www.ietf.org/rfc/rfc1662.txt) und davon der Teil zur FCS (Frame Check Sequence) ist von Interesse.
Gast
#400863
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!!!
Gast
#400864
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.
Gast
#400865
Lies den RFC!
Gast
#400866
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 ?!
Gast
#400867
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.