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!
hier wird dir keiner helfen deine dummheit auszugleichen um eine kriminelle TAT zu vollziehen.
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
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!
probiere mal einfach alle Bytes zusammen zu addieren. Vielleicht ist es ja so eine einfache Prüfsumme. Gruß Hagen
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...
RFC1662 (http://www.ietf.org/rfc/rfc1662.txt) und davon der Teil zur FCS (Frame Check Sequence) ist von Interesse.
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!!!
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.
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 ?!
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.