Spørsmål:
Jeg slet virkelig med å finne ut av det. Nå kan noen hjelpe meg med å reversere denne kontrollsummen?
Jesper R
2016-01-20 18:40:03 UTC
view on stackexchange narkive permalink

Jeg har en enhet på jobb uten dokumentasjon om beregningen av sjekksummen. Jeg vet at den siste byten i hver melding er sjekksummen, og de fleste meldingene til enheten krever riktig sjekksum.

Jeg syntes det var lett å finne ut, sannsynligvis noe CRC eller noe, men jeg kan virkelig ikke finne ut av dette.

Jeg har noen meldinger (fra enheten) der bare en av byte endres for å gjøre det lettere å finne et mønster.

Den siste byten i hver melding er sjekksummen.

De nest siste byte-trinnene i disse meldingene: 

  00h 5Ch A2h 00h 04h D2h 38h00h 5Ch A2h 00h 04h 57h BDh00h 5Ch A2h 00h 08h AEh 1Ch00h 5Ch A2h 00h 00h 01h 7Fh00h 5Ch A2h 00h 00h 02h 80h00h 5Ch A2h 00h 00h 03h 81h00h 5Ch A2h 00h 00h 04h 82h00h 5Ch A2h 00h 27h 0Fh BCh

4. trinn byte i disse: 

  00h 5Ch A2h 00h 00h 01h 7Fh00h 5Ch A2h 01h 00h 01h 63h00h 5Ch A2h 02h 00h 01h 67h00h 5Ch A2h 03h 00h 01h 6Bh 00h 5Ch A2h 04h 00h 01h 6Fh

Jeg håper noen der ute kan hjelpe, det er virkelig en showstopper for meg.

EDIT - lagt til flere eksempler 

  00h 5Ch A2h 01h 01h 01h 65h00h 5Ch A2h 01h 01h 02h 66h00h 5Ch A2h 01h 01h 03h 67h00h 5Ch A2h 01h 01h 04h 68h00h 5Ch A2h 01h 01h 01h 65h00h 5Ch A2h 01h 01h 02h 66h00h 5Ch A2h 01h 01h 03h 67h00h 5Ch A2h 01h 01h 04h 68h00h 5Ch A2h 02h 01h 01h 69h00h 5Ch A2h 02h 01h 02h 6Ah00h 5Ch A2h 02h 01h 03h 6Bh

Et eksempel til av samme melding hvor de siste 3 byte er 00h: 

  00h 5Ch A2h 00h 00h 00h 7Eh

2nd EDIT- Lagt til en Pastebin-lenke til massevis av andre eksempler, alle av samme meldingstype

Det er en annen melding, men det er mange eksempler: Mange eksempler på meldinger i Pastebin

Har du flere prøver?
Hei @cimarron Jeg har nettopp lagt til noen flere eksempler.
Dette uttrykket fungerer for alle eksemplene unntatt en: `0x7e + d [5] + 2 * d [4] + 4 * d [3] - (d [3] + d [4] == 0? 0: 0x20)` (d [0..5] er dataene). Hvis du kan få flere eksempler som den sviktende, eller prøver som varierer de tre første byte, kan du sannsynligvis avgrense den ytterligere.
@hemflit, interessant, takk for tiden din! Jeg ser på det akkurat nå, og jeg vil legge ut flere eksempler på en annen melding senere.
To svar:
DarthGizka
2016-01-21 21:13:10 UTC
view on stackexchange narkive permalink

Nøkkelen er å få et megaton med prøver, slik at analysen har noe å mate på. Det hjelper virkelig hvis du kan feste prøvene i en databasetabell eller ordbok som kan spørres interaktivt , f.eks. fra en slags manuskall. Python burde fungere beundringsverdig, men jeg har ikke mye erfaring med det, siden jeg har brukt Visual FoxPro for interaktiv spillunking de siste to tiårene.

Når du har prøvene dine klare til å bli spurt, kan du teste forskjellige enkle hypoteser og motbevise dem ved å finne moteksempler. Følgende eksempler ser for eksempel ut til å antyde at en forskjell i fjerde byte forårsaker en firdobbel forskjell i sjekksummen: 

  00h 5Ch A2h 00h 00h 01h 7Fh00h 5Ch A2h 01h 00h 01h 63h00h 5Ch A2h 02h 00h 01h 67h00h 5Ch A2h 03h 00h 01h 6Bh 00h 5Ch A2h 04h 00h 01h 6Fh

Nøkkelen er å finne prøver som bare skiller seg ut i den nåværende 'arbeidskolonnen' og kontrollsummen for å studere effekten som en endring i arbeidskolonnen har på sjekksummen. For eksempel, gitt inndataene ovenfor, kunne vi notere 4 * b [3] som foreløpig term for den fjerde byten, og deretter spørre eksempeldatabasen for moteksempler hvis dette ikke fungerer. Det vil si at du velger par med prøver som bare skiller seg ut i fjerde byte og kontrollsum og teller antall suksesser og feil for 

  delta (checksum) mod 256 == 4 * delta (byte [3]) mod 256.

Det er uansett ideen. Hva en ting som delta (checksum) mod 256 faktisk ser ut, avhenger tydeligvis av manuskriptet. Med VFP ville det være 

  mod (256 + asc (substr (høyre, 7, 1)) - asc (substr (venstre, 7, 1)), 256)

Det komplette uttrykket for testen ovenfor vil være ganske langt, så du vil normalt skrive små hjelperfunksjoner. Med en hjelper kalt byte_delta () som normaliserer resultatet til området [0, 255] du kanskje har 

  velg le.prøve som venstre, ri.prøve som høyre; fra all_samples le, all_samples ri; hvor ting (venstre (ri.eksempel, 6), 4, 1, "") == ting (venstre (le.eksempel, 6), 4, 1, ""); og le.sample <> ri.sample; inn i markøren byte_3_pairssel byte_delta (høyre, venstre, 7) == mod (4 * byte_delta (høyre, venstre, 4), 256) som ok, tell (*); fra byte_3_pairs; gruppere etter 1

I det aktuelle tilfellet vil du få et blandet bilde for dette spørsmålet (se forskjellen mellom første og andre eksempel ovenfor, som er E4 i stedet for 4). Normalt vil du gjøre en del med å velge forskjeller først, bare for å få en følelse av ting. "Forskjell" kan være aritmetisk forskjell, bitvis xor, uansett.

Derfor trenger du et interaktivt skall som Python eller VFP; med rediger-kompiler-kjøresyklusene til et kompilert språk vil dette være ganske tungvint. Jeg har gitt VFP-eksemplene fordi skriptspråk med databasestøtte kan gjøre ting mye enklere her.

For enkle vektede summer som de vanlige "menneskelige beregningsbare" kontrollsummene i ting som ISBN-er, gir dette ganske raske resultater . Jeg har brukt denne tilnærmingen for å bestemme alle sjekksifersystemene som brukes i tyske helseforsikringsnumre - som for det meste er papirløse (eller i det minste var på den tiden) - fra forskjellige mengder prøver. Selvfølgelig hadde jeg i så fall fordelen at den grunnleggende typen ordning - en vektet sum av sifre - var kjent, og prøvene allerede var bosatt i databasetabeller ...

Saken under diskusjon er vanskeligere fordi grunnordningen ikke er kjent ennå. Derfor er det viktig å se på bitmønstrene for å få en følelse av ting. For eksempel indikerer boblende bærer en additivfunksjon. Dette forklares mer detaljert i emnet Omvendt enkel melding + kontrollsumpar (32 byte), som også viser noen eksempler på endringsmønster.

PS: i tillegg til å prøve å plage ut forskjeller i sjekksummen for endringer i bestemte biter eller byte, er det mange andre ting som kan gjøres når prøvene er fylt i en slags spørbar tabell / ordbok / kart. Det første er vanligvis å kjøre et batteri med tester med eksisterende standardfunksjoner, som rett bytesum, rett byte xor, forskjellige CRC og så videre, for å observere forskjellen (aritmetikk og xor) til sjekksummen. Å vise resultater som bitmønstre - som vist i den koblede artikkelen - kan ofte være nyttig for kresne regelmessigheter som ikke er så tydelige i heksadesimalt eller desimalformat.

OPPDATERING For øyeblikket prøvene er for like (ingen forskjeller i de tre første byte), og det er for få av dem til å kaste hypoteser raskt. Det er med andre ord bare for mange potensielle funksjoner som passer til eksisterende data ...

For eksempel forutsier følgende enkle Fox-funksjon korrekt sjekksummen for den opprinnelige håndfull prøver, bortsett fra noen få tilfeller der den er slått av med 0x20: 

  -funksjon f (s) lokal x, ix = 0 for i = 1 til len (ms) - 1 x = bitand (bitlshift (mx, 1) + asc (substr (ms, mi, 1)), 0xFF) neste gang jeg returnerer bitand (mx + 0x8E, 0xFF)

Det kan være fordi det er en rotasjon i stedet for et skifte, eller noe xor er involvert, eller et annet skift (relativt primært til 8) som overlapper med bitantallet per byte for å skape en avstand på to bits mellom den fjerde byten og kontrollsummen. En rotasjon med 5 ville gjort det. Imidlertid er det mange andre muligheter ... Derfor trenger vi mange flere prøver. ;-)

Analyse av prøvene på PasteBin viser at en forskjell i den siste byteposisjonen før sjekksummen alltid er lik forskjellen i sjekksummen. Dette betyr at den siste byten og dens effekt på kontrollsummen kan fjernes fra prøvebasen. Dette øker antall prøver som er forskjellige i bare en byteposisjon, noe som betyr at det er mer lavthengende frukt for analyse ...

F.eks. prøvene 

  00 5C A0 00 00 00 00 00 06 00: 6900 5C A0 00 00 00 00 00 06 01: 6A ... 00 5C A0 00 00 00 00 00 06 FF: 68

alt tilordnes til den nye prøven (prikken indikerer en fjernet byte, bare for å forklare her): 

  00 5C A0 00 00 00 00 00 06. 69

Den forkortede prøvebasen viser umiddelbart tilfeller der 'power of two' -regelen ikke fungerer (den siste byten her er opprinnelig den nest siste): 

  00 5C A0 00 00 00 00 00 00. 7D00 5C A0 00 00 00 00 00 01. 7F00 5C A0 00 00 00 00 00 02. 61 <- forskjell -0x20 til forutsagt delta 200 5C A0 00 00 00 00 00 03. 6300 5C A0 00 00 00 00 00 04. 65 ... 00 5C A0 00 00 00 07 00 00. B5 00 5C A0 00 00 00 08 00 00. BD00 5C A0 00 00 00 09 00 00. A5 <- forskjell -0x20 til forutsagt delta 800 5C A0 00 00 00 0A 00 00. AD00 5C A0 00 00 00 0B 00 00. D5 <- tilbake på sporet med den tidligere sekvensen
Hei @DarthGizka, Jeg vil først og fremst si at jeg setter pris på det detaljerte svaret ditt. Har du hatt noen suksess med å konstruere en kontrollsum med tilnærmingen du beskriver ovenfor? Jeg tror jeg vil prøve det i morgen med tilnærmingen din - Jeg er god på Python, så det kan være mitt valg da. Jeg antar at jeg trenger mye flere prøver som også varierer i lengde. Jeg lar spørsmålet være åpent i noen dager til, men hvis jeg får sjekksummen riktig i morgen, vil jeg godta svaret ditt skjønt - Takk igjen !!
@Jesper: Jeg vil gjerne ta knekken på dette selv, men dessverre må jeg bruke fritiden min til reversering av en stinkende haug med eldre kode for øyeblikket (VFP; det er så ille at det er lettere å forstå etter kompilering og dekompilering objektkoden). Imidlertid, hvis du har problemer med å komme inn i ting og på en eller annen måte en lenke til en fin feit haug med prøver på et sted som PasteBin skal vises i morgen, så er jeg sikker på at jeg - og ganske mange andre her - ikke ville være i stand til å motstå. ;-) Det ville også være fint om en Python-guru kunne slå inn med nyttige tips ...
Det høres kult ut, eller ikke :) .. Jeg har ikke brukt VFP, faktisk har jeg ikke engang hørt om det før. Jeg prøver å løse det nå, men jeg vil legge ut en lenke til en haug med prøver senere på PasteBin som du foreslo. Jeg setter stor pris på innspillene dine! Spør meg alltid om Python-ting, jeg vil gjøre mitt beste for å svare ,. Selv om jeg ikke har noen erfaring med reverse engineering med Python.
@Jesper: Jeg påkalte inngripen fra gudene til Python fordi interaktivt spørring og massering av data ved en Python-melding ser radikalt annerledes ut enn å utstede SQL-kommandoer i Fox (VFP). For det første vil du sannsynligvis oppbevare arbeidsdataene dine i en liste / ordbok, ikke i en databasetabell / markør som i Fox ... Verken Fox eller Python er hamret i stein, skjønt. Du trenger bare et interaktivt miljø som lar deg modifisere og påkalle funksjoner, modifisere / instantiere klasser og massere / vise data effektivt i mengder. AutoLisp var mye sånn også (men jeg har ikke brukt det på flere tiår)
Jeg redigerte spørsmålet for nå å inkludere en Pastebin-lenke som du foreslo med en lang liste med eksempler. Det er en annen melding. Jeg tror 00 i begynnelsen av meldingen kan utelates, men husk at det kanskje har vært foran prøvene som er gitt i Pastebin
Takk, det er ** mye ** bedre allerede! Dette bekrefter at - for det meste - forskjellen i en bestemt byteposisjon er lik kraften til to som tilsvarer avstanden til enden, noe som indikerer å summere med venstre skift med en bit (som vist i prøven Fox funksjon i artikkelen min). Det viktige nå er å finne ut de blodige detaljene, som krever utvinning av prøvene for par der forskjellen ikke er lik den forventede kraften til to (den berømte 0x20 forskjellen fra mitt eksempel eller hemflits formel). Og gruvedrift etter gullstøv krever store mengder malm ... ;-)
Du går virkelig fremover med dette !! Jeg kan ikke virkelig få funksjonen din til å fungere i python: bare for å være sikker, ** bitlshift **: er bit venstre shift (<<, C-ekvivalent) og ** bitand ** er bare AND (&, C-ekvivalent), høyre ?
Ja, du har de rette operatørene. Funksjonen var imidlertid bare et eksempel som tilfeldigvis fungerte på den opprinnelige lille håndfull prøver, bortsett fra 0x20-tingen (som kunne løses på samme måte som blødning gjorde). Funksjonen fungerer ikke med mengden prøver på PasteBin.
user14656
2016-02-11 06:08:46 UTC
view on stackexchange narkive permalink

Jeg lurer på om du hadde gjort flere fremskritt på sjekks dekodingen. Jeg har et veldig lignende problem, og jeg tror metoden din også kan fungere for saken min. Dette er dataene mine som jeg ønsker å finne ut av kontrollsummetoden, som lenge gikk tapt i tidligere utvikling:

00 8a 51 0b a0 b8 a100 8a 51 0b a1 b8 a300 8a 51 0b a2 b8 2300 8a 51 0b a3 b8 2500 8a 51 0b a4 b8 a300 8a 51 0b a5 b8 a500 8a 51 0b a6 b8 2500 8a 51 0b a7 b8 27

Setter stor pris hvis du kan diskutere mer om fremgangen din som kan bidra til å løse denne. Dessuten fant jeg ut at jeg kan bytte napp, og den har også samme kontrollsum. takk på avansert.

Beklager at dataene er ødelagte: [00 8a 51 0b a0 b8 a1] [00 8a 51 0b a1 b8 a3] [00 8a 51 0b a2 b8 23] [00 8a 51 0b a3 b8 25] [00 8a 51 0b a4 b8 a3] [00 8a 51 0b a5 b8 a5] [00 8a 51 0b a6 b8 25] [00 8a 51 0b a7 b8 27] Generelt påvirker bitforskjell i 5. byte den siste byten av sjekksummen.


ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...