Názory k článku CRC (kontrolní součet)

Pekny a dobre citatelny clanocek, len v nom pre objasnenie nie je rozvinuta skratka...

No, my se to ucili jinak.

CRC - cyclic redundant code

Tak se mi zda, ze na poslednim miste takto vygenerovaneho CRC by byla vzdy nula. Totiz na 4. pridanou nulu se pri xorovani dostaneme jen v pripade, ze nulujeme jednicku na 1.miste pridanych 4 cisel, ale to uz je mimo definici. Takze GP je prilis kratky na to, aby zmenil posledni cislo. Je tomu tak?

no, to bude, a ted nevim, jestli je chyba ve me, nebo jestli je to vubec chyba ;-), mno, kazdopadne staci na konec pridat (je-li GP n-bitovy) n-1 nul, a vysledek je n-1 bitovy, ale fakt nevim kde je chyba, mluvi-li se o 16-bit CRC, nemelo by se raci mluvit o 15-bit CRC? Protoze GP je kazdopadne 16-bitovy a ta nula tam skutecne bude.

Je pravda, ze nestavim raketoplan :-), tak to hledat nebudu, ale jako pravdepodobne reseni bych videl, ze 16-bit CRC bude znamenat, ze se prenasi 16 kontrolnich bitu, ale GP bude 17 bit. GP se asi neprenasi, takze to nemusi byt zaokrouhleny :-).

Asi to tak bude (alespoň u některých doporučených GP, např x16+x12+x5+1). GP má 17 bitů, ale při použití tohoto polynomu pro zabezpečení dat na disketě končí pole dvěma byte CRC.
Dík za nasměrování.

Asi trošku pozdě, ale koukni se na:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/27

A co takhle dalsi dil o pocitani MD5? :-) A taky neco o samoopravnych kodech. :-)

Na kryptoseminar jsem v lete vyrobil nejake slidy o ruznych hash. funkcich, cim se lisi a tak. Ten se povaluje treba tady:
http://artax.karlin.mff.cuni.cz/~toman/crypto/img0.html

Po dlouhe dobe (bohuzel) neco opravdu zajimaveho. Diky

Neskodilo by procist nektere zaklady predchazejici teorii kodu, jmenovite co to je kodova vzdalenost, linearni kody, syndromy , operace na telesem GT2, pak by byl clanek jiste prinosnejsi ...

No, nemyslim si, ze by to bylo v pripade tohoto clanku ku prospechu. Tohle je clanek, ktery chce
alespon trochu libivou formou zaujmout a ne odradit.
Proste, jak pise Ondra, je to o rakete.

Ked to tu tak citam, tak ma napadla jedna otazka.
Mam 10 miestny ciselny retazec, z ktoreho potrebujem pouzit minimalne 7 miest na prenos dat a zbytok moze byt pouzity na kontrolny sucet, ktory bude mat vlastnosti:
1. Zisti ci je retazec konzistenty a nedoslo ku chybe pri prenose (nieje problem)
2. Ak doslo ku chybe pri prenose, a chyba nieje v kontrolnom sucte, budem vediet lokalizovat poziciu chyby.
3. asi sci-fi, ale neda mi. Budem vediet odvodit si mozne hodnoty na chybovej pozicii.

Mate niekto nejake napady ako by sa to dalo realizovat, popripade co by som mal hladat ?

V praxi sa na zabezpecenie takto kratkeho stringu pouzivaju algoritmy v style modulo 11 alebo kontrolna cislica ziskana suctom parnych a neparnych pozicii...co mi nevyhovuje, kedze si myslim, ze je to dost chabe.

Takove scifi to neni, jestli mas 7B a 3B kontrolni to znamena 56bitu-data, 24bitu-kontrola

To znamena kod (80,56)

Ted se mi zrovna nechce pocitac, uz ani nevim jestli bych to svedl, (zkousku jsem udelal za 3 pred 2 tydny :) Ale tenhle kod "hrubym" odhadem by umel detekovat dobrych dejme tomu 12 chybnych bitu nebo 6chybnych bitu opravit.

Pokud te zajima vice zkus hledat
bezpecnosti kody, linearni kody, Hammingovo kody

A taky si zkus stahnout z
http://makr.misto.cz/bk.zip
slidy o bezpecnostich kodech. (Je to od nas ze skoly (FEL CVUT) - predmet navrh logiky pocitacu

Nevim jestli z tech slidu neco pochopis, ale urcite
tva sci-fi predstava zas takove sci-fi neni.

MaKr

No, nejsem žádný odborník, ale jestliže se při kontrole CRC vygeneruje chybový vektor, tak ten při porovnání s přenášenými daty ukáže, které bity jsou chybně přijaty. A jelikož binární číslo může nabývat jen hodnot 0 a 1, tak pokud je nad jedničkou v chybovém vektoru (při porovnání) jednička v datech, tak je z principu CRC považována za chybu. A jestliže je považována jednička za chybu, má být na tom místě nula. Takže by !teoreticky! mělo jít chybné bity invertovat a tím data opravit.

Problem je v tom, ze ziskat ten chybovy vektor z prijatych chybovych dat a CRC nemuzeme. Sice se v clanku objevi jako "mezivysledek", ale to proto, ze autor nezduraznil, ze v tomto pripade xoruje GP na stejnych mistech, jak to delal pri zakodovani. To se ale neprenasi. Takze klasicky postup pri zjistovani by byl takovy, ze se spocita CRC prichozich dat a ta se porovnaji. Pokud nejsou stejna CRC, pak je mozne akorat odhadnout, kde je chyba a s jakou pravdepodobnosti. (Pri vhodne volbe GP a predpokladane pouze 1 chybe bych rekl, ze po obtiznem pocitani se podari spocitat ktery bit to je.)

Nehlede na to, ze autor omylem pouzil odeslanou sekvenci misto prijate, takze mu mel vyjit prazdny chybovy vektor pri jeho vypoctu ( 1 xor 0 xor 1 neni 1 ale 0 ) Stane se :-).

Ha diky, uz jsem si myslel, ze neumim spocitat xor :-) Preci je tam chyba.

OK, to je CRC, ale existuje i CRC check, kterej se používá na ochranu proti crackování - program se načte do paměti a provede se kontrolní součet programu - jestliže nesouhlasí, program hlásí, že je porušen a ukončí se. Jak toto naprogramovat?? Když načtu program do paměti a se všema datovýma záznamama a spočítá se CRCcheck tak je potřeba,...no zkrátka asi takhle

void main(){
}

CRC:545454

Přidáš

if(!Crc_check(handle)=545454){
MessageBox("Fuck you");
return 0;
}

Ale tím, že tohle přidáš do progu, taxe CRC změní na např.5454AA a sem zase v prdeli - přepíšu to na:

if(!Crc_check(handle)=5454AA){
MessageBox("Fuck you");
return 0;
}

A CRC se zase změní.

Co s tím dělat?? To mám počítat součty jen pro crackera zajímavý sekce. Nebo si tu proměnnou mám uložit do souboru a během ověřování CRC získat pomocí debuggeru(v SoftIce pohoda)???


Omluvte chyby v mý parodii na C, je to jen myšlenkovej postup:-))

Proboha! A proc bych to delal?

To je sranda :) Muzete se s nami podelit, ktery program neco takoveho na svoji obranu pouziva? :)

Pripada mi to celkem vtipne - kdo mi zabrani, abych nekam pred volani Crc_check() vlozil par instrukci, ktere ten check preskoci? Sice takto ten program modifikuji a jeho konstrolni soucet se zmeni, ale to mi vubec nevadi, protoze on uz ho nekontroluje. :)

no, jako jo, kdyz ses tak sikovnej. ale v kazdym pripade uz je to nemila komplikace, kterou obejdou jen lepsi hackeri, jako ses treba ty :).
btw. me taky ucily crc = cyclic redundancy check

No jo, tohle odradi polovinu hackeru, druha polovina pouzije DisAssembler, najde si instrukci porovnej checksum, pripadne krokuje k tomu algoritmu a pak nastavi instrukci, aby odpoved byla vzdy ANO :)))

To je asi to same, jako se sifruji programy a zpracovavaji na dvakrat :) Hacker si to samozrejme necha nejdriv rozsifrovat a pak hleda algoritmus, ktery ho zajima :) Ale zas to polovina lidi neumi nebo nepochopi, ze zbytek programu se teprve dekoduje a ze hledaji algoritmus marne...

Nevím jestli to někde v článku, či v příspěvcích není zmíněno, nebo jestli to není informace nezajímavá, ale:

Hlavním rozdílem mezi normálním kontrolním součtem (prostý součet všech byte) nebo LRC (Longitudinal Redundancy Check, tj. XOR přes všechny byte) a CRC je v tom, že CRC rozpozná dva prohozené byte. Pokud někde v datech prohodíte dva byte, tak se jejich prostý součet nezmění (ani LRC).

Další zajímavou vlastností CRC (platí i pro LRC) je, že pokud se udělá CRC přes všechna data včetně připojeného CRC na konec dat, tak je výsledkem 0.

To jenom tak na doplnění.

veta:
Nejprve k datům přidáme nakonec tolik nul, kolik je délka GP - resp. kolika bYYYtové je počítané CRC. V našem případě 4:

Díky moc za vysvětleí , protž z toho co nám vysvětlovali ve škole sem to zas tak nepochopil

Nevite nekdo v cem muze byt chyba, kdyz se mi pri instalaci programu, her nebo rozbalovani archivu ukazuje chyba nesouhlasi CRC?

princip CRC nie je v kontrolnom sučte, ale v zapamatani zvysku po deleni polynomom, kontrolny sucet je nieco ine