Üdv minden kódolónak Nekem is hasonló gondom lenne, de nem akartam külön topikot nyitni, remélem, nem gond... Szóval kicsit át szertném alakítani a jelenlegi riasztómat /finomítások leginkább/ - szinte 1 az 1-ben megegyezik a Microchip AN645-ös app.note-jával, komplett kapcsolási rajz, részletes leírás. Az első oldal szerint a progit DS40149 rendelési számon lehet elérni, de nem találtam sehol, hogy meg kellene rendelni, le lehetne-e tölteni stb. Elvileg "KEELOQ Licensing disk" néven fut a dolog, de ez megint zsákutca...
Valaki összefutott már vele? D.

Nos ha lassan is, de halad a távirányító építés.
Marad az IR, működik 10m-re.
Az adó jelenleg próbapanelon kb 55X40mm, 3V-ról 10mA-t eszik, ha ad, 1uA-t, ha alszik.
Előzetes tervezgetés alapján bele fog férni egy 58X35mm-es TECO10010.9 műszerdobozba egy 3V-os lithium gombelemmel együtt
.
A protokoll egyszerűsödött, párommal konzultálva elfogadhatónak tartja e célra a PIN kód használatát. Így csak egyirányú az adatátvitel.
Kétirányú azért nehéz, mert az IR modul 5V-os, 4V-ról visítva még működne, 3V-ról meg se nyikkan.

Az adó lelke PIC16LF627, 6db nyomógomb (a PIC A portjára ennyit bírok rádrótozni, meg a dobozon se nagyon férne több) és némi körítés.

A PIN kód 4 jegyű, de 1 jegy a 6db nyomógomb bármilyen kombinációja lehet. (A kódbekérés addig tart, míg a port 0-ról visszatér 0-ra, közben OR művelettel a megfelelő kód beállítódik. Ez 64^4 kombináció, de már a 64X 6^3=13824 is elég. A bankkártya 10^4 védettségű.)

A véletlenszám generálás a PIN kódbekérés nyomógomb nyomás-szünet alapján valódi véletlen 8 byte mennyiségben. Egyirányú adatfolyam 8+128 bit, ebből 112 kódolva.
A számláló csak 2 byte, de az adó egy pl 32-es ablakba kell, hogy beletaláljon, különben a vevő eldobja. A számláló csak akkor lép, ha jó PIN kód került beütésre. Így idegen nem tudja elrontani a szinkront.

Az programot mikroPascal-al fejlesztgetem, az adat Manchester kódolással 500bit/s-el megy ki.

Akinek esetleg ötlete, kiegészítése van, szívesen fogadom.

Azt nem mondtam, hogy nem jó a DES, inkább túl jó. BASIC forrást biztos lehet hozzá találni, de ahány compiler annyi szintaktika, sőt parancskészlet. Sok nyelvjárása van a BASIC-nek, nehéz lehet a saját projektbe illeszteni.
A "szívásokhoz" annyit, hogy a fix "4"-es problémát porthiba adja (PortB.6 fix "H"), a WDT-t pedig hiába akartam, nem sikerült még eliminálni.
Folyt. köv, csak mostanában nem nagyon érek rá.

...

Mért ne lenne jó a DES? Van picre kész basic forrás,csak be kell lökni,fél nap alatt összeberhelhető a project ha működik a kommunikáció.Igazából a DES is ugyanaz matematikailag,amit ajánlottam,bitcserék és keverések sorozata,csak profik találták ki,azért biztos,hogy egyszerűen nem törhető.Egy ilyen kis információtartalmú feladatot,mint a kapu növekvő kódja,az idők végezetéig megvéd.
Én nem progiztam csak asm-ban 16c84-re,a basic még a stamp féle basic volt,amivel kezdtem.Vettem jó drágán egy "hobbi" gyári parallax programozót,az azóta is kiszolgál.

PICBASIC Plus2.0 tetszika legjobban, de van PICBASIC Pro és MikroBasic is. Tesztelésre a MISIM 1.79.
Egyelőre 16F84A az alany, mert erre van fejlesztőeszköz, de későbbiekben a 16F628 perspektivikus. Erre a vezérlési feladatra ezek az eszközök bőven elegendőek, nem trabantmotor. Igen, jobbat (biztonságosabbat, olcsóbbat, sajátabbat) szeretnék a gyárinál, de nem vadászgépet.

A titkosításról a linkek valóban hasznosak, de ide a DES és társai nem valók szerintem. Itt nem regényt kell átvinni a kommunikáció alatt, csak pár byte-ot kell elrejteni ügyesen.

A programozással most gyűlt meg a bajom először.
a hardver: 16F84A PortB-n 2db TIL311 kijelző.
Feladat: számoljon 00-FF-ig fél másodpercenként, majd kezdje elölről.Egyszerű FOR-NEXT ciklus.

Amit csinál: PortB4-7 beáll fix "4"-re, PortB0-3 számlál 0-tól 5-ig utána kezdi előlről.
WDT-t nem engedélyeztem. A programot kiolvasva a PIC-ből beadva a MISIM-nek tökéletesen működik. Még nem tudom, mi szívat.
A programozó PonyProg2000.

egyébként meg:
http://www.netacademia.net/konyv/kripto/kriptog2.pdf
http://www.netacademia.net/konyv/kripto/kriptog3.pdf

Milyen PIC-re milyen Basic-ban szeretnéd írni? (Ha már a példáknál tartunk:kezdettől van egy olyan érzésem,hogy trabantmotorral próbálsz sugárhajtású vadászgépet építeni,bízva benne,hogy jobb lesz mint a gyári)

Hát nem tudom hogy állsz a PIC programozással, én az elsőket írom.
Ha Basicben 1 utasítás a
> SEROUT Pin, Mode, [Item{, Item...}]<
egyenlőre (amíg sebesség és méretproblémába nem ütközök) nem szándékozom ASM-el görcsölni.
Más kérdés a bittologatás. Arra valószínúleg jobb az alacsony szintű nyelv. Talán közben ráérzek az ízére. Lehet, könnyű leprogramozni/összeollózni ASM-ben egy modulált soros protokollt, de a forrasztópáka használatát sem egy diszkrét alkatrészekből összeállított első generációs műholdvevő építésével kell kezdeni (ahogy anno az RT-ben felhozta példaként a szerző)
Ha odáíg jutok egyszer, hogy működik, a forrást BASIC-ben ill a fordítását ASM-ben közzéteszem. A jólelkű kódmesterek talán jól kommentezve bemutatják, hogy lehetett volna echte ASM-ben megírni.

Ahogy gondolod ugy csinálod.Számomra jóval egyszerűbbenk tünik pár utasítással többet leírni,mint külön alkatrész,annak a környezete,bonyolultabb nyák,stb,stb.Ezt a szubrutinosdit sem értem,itt csak a számolásra van szükségünk,amit ugyis ASMban _kell_ a sebesség miatt írni,az EEPROM kezelés meg a SERIN-SEROUT kész dolgok,csak be kell rakni és fordítani..minek vacakolni akkor bármiféle basiccal meg 555tel?

A háromlábú, pl SFH5110-3x IR vevő/demodulátor már beszereztetett, a próba alatt a PIC SEROUT kimenetére egy NE(TLC7)555-ős IC fog 3x kHz-es modulációt biztosítani. Azt hiszem itt a hardverrel egyszerűbb megoldani a problémát, mint szoftverrel görcsölni. (A vevő szereti az 50%-os kitöltési tényezőjű vivőt, +/- 3kHz-es eltérésnél van a 3dB-es pont az érzékenységben.) Külön-külön nem probléma szoftverrel előállítani az adatfolyamot és a vivőt, de egyszerre... Nagy sorozatnál kifizetődő megspórolni 5-6 alkatrészt, a prototipus valszeg 555-el fog működni.
Az ASM szubrutinokkal barátkozom, de a teljes programot ASM-ben írni nem akarom.

Elvileg létezik ilyen soros adatot infrán átvivő rendszer,a PCs TVkártyám távrecsegője is így működik,ráadásul a vevője nagyon primkó,mintha egyetlen 3lábú tranzisztorhoz hasonló alkatrész venne és demodulálna.(sajnos egy betü nincs rajta,hogy mi az)
Az adó részt meg ugy kell pic-re megírni,hogy egyben a modulációt is rátegye,nem egy ördöngősség,amikor "serout" szubritinban 1ben tartanám a vonalat,helyette gyorsan kapcsolgatom,amikor 0ban,akkor nem csinálok semmit.NOPokkal meg az órajel beállításával be lehet lőni hogy király legyen.A bitforgatást és elég jó véletlent elfogadható sebességgel amugyis csak ASMban lehet írni..szerintem barátkozz vele.

Nos azt hiszem, ez a hosszászólás volt az, amiért indítottam a topikot:
Köszönöm szépen ezt a kimerítő és világos magyarázatot.

A következő lépés a kommunikációs hardver megépítése lesz, kipróbálandó, milyen adatsebbességre lehet számítani az új protokollhoz.

Most megpróbálom egyszerűen leírni,miért nem jó ez a "xorolgatósdi",illetve hogyan lehet feltörni!!!:
Ez esetben 256minta elegendő ahhoz,hogy a kaput kinyissuk egy 257edikkel,anélkül,hogy akár a mintákhoz tartozó RNDket akár a kulcsot ismernénk!!! Tehát a dolog nevetségesen gyenge,holott eszméletlen nehéznek tűnik..de hol a baj?

Pár alap,és egyszerűsítés:A xor műveletet váltsuk ki x műveleti jellel,tehát A xor B az AxB.Összefüggések amik fontosak: Ax0=A illetve AxA=0 továbbá a tagok bármikor szabadon cserélhetőek az egyenletben.Vagyis AxB=C ekkor AxC=B és BxC=A.

Ebből érdekes dolgok következnek..elrejtem A és B számot R kulccsal titkosítva.A titkosított adatok At és Bt..tehát:
AxR=At és BxR=Bt
De mi van ha most a két titkos adatot xorolom?
At x Bt=AxRxBxR vagyis AxBxRxR tehát AxBx0 ami AxB !!
A kulcsom "eltünt" a két adatot nem,de annak "bitkülönbségét" már ismerem.
Innen nagyon meggyengült a dolog,hiszen Tom12 féle algoritmusra csomó mindent fel tudok írni.Az MC1,2,3,4,5-öt hívjuk A,B,C,D,E nek.A számlálókat S1,S2,S3 nak.

A titkosított adat ekkor:
AxR1,BxR2,S1xCxR1,S2xDxR2,S3xExR1 komolynak tűnik,de nem az.

Az előbbi módszerrel valamennyi titkos soron elvégezve az
(AxR1)x(S3xExR1) műveletet,a számláló végéről eltünt a "védő" R1.
Mert:AxR1xS3xExR1 =AxS3xExR1xR1 ami AxS3xEx0 ami AxS3xE !!
Jójó,de még mindig nem tudom a 3 adat közül egyiket sem.Ez igaz,de van 256 mintám.
Tehát "kiemelve" (AxE)xS3 minden sorra megvan.

Most elkezdem AxE-t találgatni..256 féle értéket rápróbálok egy pillanat alatt.Ahol a kapott S3 monoton növekszik hiba nélkül,az a helyes AxE.(hiszen ez MC két byte-ja ami állandó minden alkalommal)
Mostmár tudom S3 értékét,tehát tudom ExR1-et is,hiszen csak vissza kell helyettesíteni,az eredeti tikos értékből pillanat alatt kijön.
Ezzel az első lépést feltörtem,mivel elég az utolsó sort megismételnem,eggyel megnövelt S3mal,a "vevő" felől ez ugy néz ki,mint egy másik jó sor,ugyanazokkal a véletlenszámokkal.

Ha mégis védve lenne ez ellen(biztos ami biztos) egyszerűen végig XOR-olom az utolsó sort egy N tetszőleges értékkel.Belátható,hogy igy a vevő elvégezve a visszakódolást NxR1 és NxR2-t "lát".Arra vigyáznom kell,hogy N két felső bitje 0legyen,ne változtassam ezzel az általa "látott" RND-k felső bitjeit,vagyis a majdani válaszát "fedő" MCket.

Amint a választ megkapom,a szokott módon használom az azonosságokat.

A régi válaszom(amit ismerek):R1xA,R2xB
Erre a régi viszontválasz:S1xR1xC,S2xR2xD,S3xR1xE
(az A,B,C,D sorrendje nem biztos,de tökmindegy,mert arról gondoskodtam,hogy "ugyanaz maradhasson")

Most kaptam egy R1UxA,R2UxB választ.
használjuk a régi választ: (R1xA)x(R1UxA) =R1xR1U
ugyanez a másik rnd-re: (R2xB)x(R2UxB) =R2xR2U

Még mindig nem tudom a véletlen byteokat,de nem is érdekes,hiszen van egy jó válaszom,mivel S3-at tudom,könnyedén megvan R1xE.Igy "kicserélhetem" a régi S3at a megnöveltre,igaz ez még a régi R1-el és nem R1U van van titkosítva.

Innetől viszont elég ugyanazzal a módszerrel végigcsinálni a xor-t..vagyis:
(S1xR1xC)x(R1xR1U)= S1xR1UxC
Íme,R1 attól,hogy xoroltam R1xR1U val egyszerűen "kicserélődött" R1U-ra!!
Ugyanígy a többit is:(S2xR1xD)x(R1xR1U)=S2xR1UxD
Illetve:(S3sajxR1xE)x(R1xR1U)=S3sajxR1UxE

Ezzel megvan a 3 válasz byte,a kapu nyílik!!

Ha nincs 256mintám,játszhatok egy másik érdekes dolgot is:
Ax1=A+1 ha A páros,ha páratlan akkor Ax1=A-1.Vagyis ki sem kell derítenem semmit,egyszerűen a számláló valamelyik byte-ját (praktikusan egy felsőt) XORolok 1el..50% esélyem van,hogy nyerek és a számláló megnő.
A rátett titkosítás semmit nem számít,mert ugye:(AxN)x1=(Ax1)xN
Tehát a visszafejtő úgylátja,mintha a kulcs ismeretében a titkos A számot növeltem volna,ha az eredeti A páros volt.

Persze lehet számos buktatót beépíteni,szigorítást,bonyolítást,lehet mondani,hogy nem ismerem a protokoll-t,igy könnyű volt...de kicsit több munkával,esetleg zseniális képességekkel (ami nekem sajna nincs) elég hamar rá lehet érezni sok kombináció esetén a protokollra.Drasztikusan megnehezíteni pedig ezt a fajta titkosítást nem lehet,legfeljebb a számláló bonyolításával,a szóhosszúság növelésével,még több kulcs és véletlen bevezetésével lehet operálni,de az itt megmutatott módszerhez hasonlóan azok is támadhatóak.

Hali ViperNet! Végre valaki más is beleszól Neked mi a véleményed Tom kollega titkosításáról? Ezzel a változó hosszal és bitkeveréssel is sokat kell játszani,nehogy aztán összesen 10 féle kombináció legyen kis túlzással.A dátum jó ötlet,de elcsúszhat(óra kell a cuccba,ami pontos és nem felejt,mert éjfélkor percekig nem nyílik a kapu ha a 2dátum más ) Inkább valami az ugrókódhoz hasonló monoton számlálót lehetne alkalmazni,csak kissé "megvadítva".

jó ötlet ez a változó hosszúságú kód. talán én is megvalósítom.
amúgy pl ki lehetne azzal egészíteni, hogy pl az éppen akkori dátumot is beleszövi a kódba. de azt, hogy a kód melyik részében, ezt is külön kódrészlet tartalmazná.

1.Nos..megmondom min kellene változtatni:leírni egy papírra ezt az erősen túlgondolt "szupertitkosítást" és a papírt gondosan elégetni.
Majd elővenni és felfrissíteni a középfokú matek ismereteket,elolvasni néhány felsőbbfokú matek könyvet vagy jegyzetet,belemélyedni néhány a titkosítás és titokfejtés,valószínűség,információtartalom és egyéb kulcskérdésekkel foglalkozó könyvbe.Már ha saját "bombabiztos" titkosító algoritmust szeretnél kitalálni..ami 100% értelmetlen.
2.Van ugyanis 1000+1 algoritmus,akár készen is,amit nálunk okosabbak találtak ki.Általában C-ben vannak implementálva,de kis erőlködéssel átírhatók más nyelvre.Ha ilyesmi a feladat,a BASIC eléggé elvérzik,mivel gyenge és lassú..de talán házilagos feladatnál még épphogy megfelel egy kis trükkel.
3.Emlegettem korábban a DES-t...erről nagyon jó közérthető leírások vannak,esetleg tanulmányozd.Ezt az "ezzel xor azzal xor a végén már magam sem tudom mivel xor"-t meg felejtsd el,csak a magad életét keseríted,ha megpróbálod "javítani" ezt a dologot,igazán erős sosem lesz.
4.Amit inkább javaslok(ezek csak alapelvek és tippek):
Próbálj inkább léptetőutasításokkal kellemes bitkeveréseket írni.Itt maga az algoritmus a kulcs,tehát ahányszor "keverünk",annyira "elkutyulódik a massza".Ha akár gyenge véletlen biteket szúrunk közbe,és véletlen szám határozza meg a keverés lépésszámát is nagyon sok lehallgatott minta és kegyetlen bonyolult algoritmus kell a visszafejtéshez.Főleg mivel azt sem tudhatja a kommunikációt lehallgató,hogy hol vannak a byte határok,melyik bit igazi kommunikáció és melyik csak RND fake.
A dolgot tovább nehezíti a szokásos eljárás,a tévútra vezetés.Tehát az ajtó minden esetben válaszoljon,ha rossz a bitminta akkor is.Válaszoljon egy "hülyeséget",és tegyen úgy,mintha várná a választ,persze semmiféle válaszra ne nyíljon ki.A kisérletező hackernek fogalma nem lehet róla mikor "találta el" amit kell és mikor nem.Lehet továbbá olyat is,hogy 5rossz próbálkozás után 10percig nem lehet próbálkozni,igy maximum 30 próbálkozás/óra lehetséges,a többezerrel(tízezerrel) szemben.A véletlen adathibák és saját kizárásunk ellen CRC-t kell képezni és a kódban "elrejteni",ha a CRC nem jó,nem is kell tovább foglalkozni semmivel,még válaszolni sem muszáj.Így valóban képtelenség többszáz óra alatt is egyáltalán a crc-re rájönni..a kód többi "fedett" részéről nem is beszélve.A feltörő életét kegyetlenül megkeseríti,ha nem adott hosszúságú,hanem változatos és kaotkius hosszúságú bitmintát lát(pl a közé kevert RND bitek számának csak általunk ismert algoritmussal történő változtatása).Így nem képes semmilyen "sablonba" beilleszteni a néha 38bit néha 112 bit stb.. hosszú,garantáltan az őrületbe kergető üzeneteket.

Mindezt persze nem 4utasítás leprogramozni,de ez a 2oldalú kommunikáció,kultúráltan és üzembiztosan megvalósítva,amúgy sem egy kis feldat.

001011111111110101011001 Szerintem ez lett volna a helyes kód. Amint látod csak egy bitben tér el, valószínűleg valami elírás miatt. Így már feltörtnek tekinthető a protokoll. Az előző üzenet, amire nem kaptál választ, szintén 1 bit eltérést mutatott.
Az MC-t visszafejtetted, vagy más a trükk?
Mit kellene változtatni, hosszabbítani, hogy ne legyen feltörhető?
************
* MotoHacker *
************
Méltó vagy nevedhez!

A szinkronizálás nem tévedés. Ha a vevő számlálóit lenullázom 1 vevő MC kódjának átírása miatt, (vevő EEPROM törlődik) az adók számlálói az első működtetéskor visszaállítják a vevőt. Így nem az összes adót kell újraprogramozni, csak amelyiket támadták.

Igy van,azért is tévedés,amit korábban írtál,hogy a számláló automatikusan szinkronizálódik,csak az MC-t kell cserélni.

Most úgy vehetjük,hogy az első próbálkozásra megkaptam a választ,tehát nyilván nem próbálgattam tovább,hanem megpróbáltam azonos számlálóállással válaszolni,mint ahol "eltaláltam".
A viszontválaszom ez volt:
001011111111110001011001

A válasz erre 0011101111101101

A számláló bármennyivel lehet nagyobb a vevőben tárolt értéknél, a vevő elfogadja és válaszol rá, de egyben aktualizálja is a számlálót. Az adó részéről pedig ha a szinkron jó csak egy értéket fogad el. Ha az jó beenged, ha rossz, új, növelt számlálóval lehet próbálkozni. De mindig csak egyet.

Ui: Ha erre a módszerre nem nyílna ki a kapu, a valós távirányítóra már nem fog nyílni (hisz a számláló pár százezerrel arrébb van) gyanakvásra ad okot, -> Hazaérés után MC újraprogramozás!

Innentől csak próbálgatás kérdése.Mivel 256 kommunikációt kellene legallgatnom,hogy az utolsó számláló byte teljes ciklusát modellezhessem,ezzel szemben csak 8 minta ál rendelkezésemre,igy 16 találgatásra van szükségem.
Másik lehetőség,hogy ha nem nagyon bonyolítod el a programot,és nem próbál a kapu azon gondolkodni,hogyan nőtt meg a számláló hirtelen ennyivel,hamarabb is találhatok olyan számlálóértéket ami a kommunikáció folytatásához megfelelő.
pl valahogy igy:

1001111101101010011100101011010100000100

Ezuttal a számláló felsőbb byte-ját próbálom növelni.Sok matekra nincs szükségem,mert a vevő nem tud védekezni a fake távirányítók ellen.Tehát nem képes intelligens kritériumok alapján többször ugyanazt a véletlen számpárt elutasítani.(Hiszen igy a jogos tulajt is elutasítaná abban a csekély valószínűségű esetben,ha többször ugyanazok a számok jönnek ki)

1001111101101010011100101011011000000100
1001111101101010011100100100101100000100

Igazából sokminden múlik a lehetőségeken,hiszen ha "le tudom lopni" a távirányítóról a következő X kódot,azzal lemásoltam a távirányítót,a nővekvő kód nem véd tovább,hiszen a lopott kódokra a kapu mindenképpen válaszol.De ha nem tudok a tulajnál előbb odaérni időben,meglehetősen nagy mennyiségű kódhoz juthatok a rendelkezésemre álló időtől függően.Hacsak az irányító nincs pl maxiumum percenkénti gombnyomásra korlátozva,de ezzel a kezelési kényelem is jelentősen csökken.

A SZÁM3 és SZÁM2 stimmel, SZÁM1 viszont kisebb, mint az utolsó volt.
Erre a sorra nincs a vevő részéről válasz. De BÍZTATÓ a kisérlet.

Íme :

..
..
..
..
..

1000101101111110011001101010000000010000 Utolsó lehalgatott adat
1011111101001010010100101001010000111011 Saját próbálkozás

Az RND mért nincs meg? hiszen benne van a sorban MCvel kódolva.
Most megpóbálok "betörni" vagyis mondok egy látszólag megfelelő kódot,aztán ha jó,akkor válaszolsz,mint az ajtó...
én pedig megpróbálok ismét válaszolni..
aztán vagy kinyílik vagy nem.

Mivel én Hexa-ban te pedig binárisan dolgozol,meg kell írnom a hexa2bint a saját adataimra,de ha minden jólmegy félóra és jön a "törés" !!!

Igen az utolsó sor adatai az RND1 RND2 kivételével megvannak.

Nos,azthiszem megvan,de szeretném kipróbálni,hogy igaz-e.
Ennek az utolsó üzenetsornak az adatait tudod még? (a számlálót és a használt kulcsot)

Oda:
(RND1RND2 (SZÁM3SZÁM2SZÁM1 xor RND1RND2RND1)) xor MC 1-5

Vissza:
RNDaRNDb xor MCx,x+1

Oda:
(SZÁM3SZÁM2SZÁM1 xor RNDaRNDbRNDa) xor MC y,y+1,y+2

Oké.Visszafelé ugye a számok még a megfelelő MC-kel is kódolva vannak?

Nos talán elég lesz.
RND1 RND2 SZÁM3 SZÁM2 SZÁM1 RNDa RNDb SZÁM3 SZÁM2 SZÁM1
0111101000110110100101111110100011100110 1001000111110101 000001111001111011111010
0100000000101011101011011111010111011101 0010111101010110 001110110100011011000111
0001010111110101111110000010101110001011 1111110111110111 111010011110011100100001
0101111011011111101100110000000111000001 0010110011101010 010000110100111100110001
1011111011110101010100110010101100100110 1100100001000000 001001011001111011011100
1110011110111101000010100110001101111110 0111111010111100 001001101010001011011110
0000000000000101111011011101101110011010 0110000110110011 111101111101100000111011
1000101101111110011001101010000000010000 0101000000100100 010001000011010000110010

A protokollban a változás:

Az adó RND1-e első két bitje ugyan úgy határozza meg az MC byte-ját, mint eddig, viszont automatikusan az utána következő byte kódolja RND2-t.Pl:

ABCDE az 5 MC byte.
Ha RND1 01 -el kezdődik -> A vevő a B és C byte-okkal kódolja saját RND-it.

Ha a vevő új RND1-e 11-el kezdődik -> az adó DEA byte-okkal kódolja a számlálót az utolsó üzenetben.
Így egyszerűbb programozni és talán még nem megy a biztonság rovására. A sorok ismét kissé szét vannak csúszva, helytakarékosságból csak az érdemi fejtenivalót másoltam be, a szinkron és a címzés lemaradt. 5 byte oda, 2 vissza, majd 3 oda a struktúra.
Ha kell még minta, tudom folytatni, csak ez már nem 5 kattintás/sor, hanem kb 35/sor de az érdemi számolást az EXCEL végzi

Nincs miért visszküldeni, hisz a vevő azt már tudja . Csak a számláló megy.
Erre a 20 esetre már nem tudom, az RND értékek nincsenek visszamenőleg letárolva, a számlálót pedig időközben a protokoll-magyarázathoz változtattam meg. (Én már nem tudom helyreállítani az alapadatokat. Csak az MC maradt meg.)
Belegondolva az RND kevergetés miatt nem is lenne egyszerű EXCEL-el a választ előállítani. 2-3 választ esetleg kézzel kiszámolok , többre szerintem nem telik a türelmemből.

Érdemes az ASM-t megtanulni..akkor nem kell ennyit agyalni az algoritmuson.

Két kérdés:
1.másodjára is küldi az adó az RNDket vissza,vagy csak a számlálót?
2.megcsinálod a teljes kommunikációt erre a 20esetre? Szerintem ugy már szinte biztosan törhető..

Inkább hardveres beállítottságú vagyok. Hát ha az életem függne rajta, ASM-ben is biztos menne, de úgy az már messze kerül a hobbitól.
Esetleg, ha a compiler nem tudja beletenni 1-2k-ba, valamit görcsölök. Inkább lustaság, meg aztán ez az első teljesen önálló PIC-es projekt. A hardvert se 1-2nap lesz összepakolni, még próbanyákon se. (Család is van a világon ) Addig meg talán még forr egy kicsit a protokoll is. (Hátha erre téved egy progmatos )

Elméletileg boncolgatom csak a kérdést,gyakorlatilag már most is "jó",jobb mint az átlagos ugrókódos riasztók,főleg mert egyedi.IR-el gyakorlatilag a megfelelőnél is nagyobb biztonságot ad,a tipikus tolvaj-betörő maximum szériacuccok ellen van felszerelve,amikor látja,hogy csődöt mond,mechanikailag próbál bejutni,az meg egy külön történet
(legtöbbször nagyságrendekkel egyszerűbb mint kódokat fejtegetni)
Z80 ASM-al meg nem tudom mi bajod,az egyik legkellemesebb,évekig az volt az alap

Ha lehet BASIC-ben írnám, ha kell ASM beágyazással. Nem ez a kenyérkeresőm, régebben TPascal7-ig eljutottam programozásban (évek óta nem írtam programot) , a Z80 ASM pedig elvette a kedvemet az alacsony szintűtől.
A védelmi cél valóban egy átlag családi ház, ill egy kiskategóriás autó (a SUZUKI-kat is lopják ) megvédése. Biztonságosabb és fenntarthatóbb eszköz kellene mint a HCSxxx alapú. Megpróbálok összerakni egy próba adatátvitelt két PIC között IR alapon, mit lehet elvárni adatsebességben a technológiától. Nagyobb átviteli sebességen nem kell annyit trükközni a bitekkel, hossabb kódot lehet küldeni.
A HCSxxx Ha jól tudom 20 byte-os MC-vel bír, de ott az adat is hosszabb, mint 5 byte. Kérdés, hogy mennyi kell a már kellő biztonságnak, és mennyi a marketingnek.
Itt ha egy adóról 5 MC és 3 számláló byte-ot tárol a vevő, 16 adónál az már a PIC számára jelentős memória (külső EEPROM-ba pedig nem tenném, bár annak is volna értelme a gyakori átírások miatt).

Még 1-2 gondolat:Olyan nincs,hogy "végtelenségig lehet hallgatózni".Megfelelő számítási kapacitással,és mintavételezett titkosított adattal minden "feltörhető".Az,hogy mennyi a kritikus adatmennyiség,illetve a szükséges számítások mennyisége(legrosszabb esetben) valamely ezen a területen harcedzett matematikus tudná megmondani(kiszámolni) pontosan(adott algoritumsra).
A cél sosem az,hogy ne legyen feltörhető,hanem,hogy ne érje meg..jelentős különbség.A kódoló és a feltörő tipikusan mindig olyan harcban áll,ahol a kódolást nem,vagy nagyon ritkán változtatják.A feltörőnek tehát majdnem végtelen ideje van céljai elérésére.(ld német és japán kódok visszafejtése a szövetségesek által a 2.vh idején)

Tanulmányozd a PIC BASIC RND algoritmusát.Eleve XORon és bitforgatáson,keverésen alapul.Előfordulhat,hogy addig "bonyolítod" több egymásutáni számot "építve egybe",amíg már csak 40-50 féle számból álló sor lesz a kimenet,tehát a "megerősített" mintád párezer helyett párszor tíz érték után monoton ismétlődik.
Ugyan 20db lehalgatott minta még nem okvetlenül elég igy sem,de 100db már biztosan.
BASICben szeretnéd mikrokontrollerre megírni mindezt,vagy ASMban?

A válaszokat még nem tudja az EXCEL tábla, ha kell beleviszem. Lehallgathatatlannak nem tekinthető a további kommunikáció sem, ha valaki a rádiós megvalósítás mellett dönt. (Nem tudom miért ellenszenves az IR? )

Ha a PIC véletlenszám algoritmusa ilyen támadható, azt kell egy kicsit megkeverni, olyan utasítás(okkal) melyek elfedik az algoritmus hibáját, de men bonyolultak. Pl "RND1=rnd a XOR rnd b és RND2=rnd a XOR rbd c" Ez ismét kis változtatás a programban, de egy kiskapu bezárul. Kösz az újabb biztonsági rés becsukását.
A progmatosok véleménye tényleg sokat nyomna a latba, de a Ravasz Öreg Rókák tapasztalata se kutya.

Tom12: Excel..hja..ezért ennyire "erős" a dolog..azért még próbálkozok vele...
A baj,hogy a mikrokontroller elterjedt kis "álvéletlen" algoritmusai jóval gyengébb véletlent állítanak elő,mint az excel motorja(ahogy már utaltam is erre).Valószínű,már kezemben lenne a kulcs ennyiből,ha a PICbasic nyomorék véletlenével nyerted volna RND1 és RND2-t.A teljes védelmet ugyanis pont az RND adja,hiszen az ami "elfedi" a lekódolt adatsort,vagyis reménytelenné teszi a kulcs mintakereséses próbálgatását.De ha az RNDben is rendszer van(márpedig van),néhány álvéletlen algoritmust adott "init" értékekkel "rápróbálva" előbbutóbb "kiugrik" a séma,és innentől gyakorlatilag kezünkben van az (általad MC nek nevezett) kulcs.

Megadod a válaszokat is,vagy azokat tételezzük fel lehallgathatatlannak ? (szép szó:) )

A többiek is bekapcsolódhatnának..kíváncsi lennék más (pl prog. matekos ) véleményekre,én mint tudjuk csak egyszerű műszer-ész vagyok

ADR: Az a memóriafiók, ahol a vevő tárolja az adó "MC"-jét. Egy vevőhöz max 16 adót lehet rendelni.
CMD: Az adó max 15 féle parancsot adhat a vevőnek. Pl kapunál csak az egyik szárny nyíljon ki, vagy nyitás után 30sec múlva szabad fénysorompó esetén zárja a kaput, vagy a fénysorompó legyen felülbírálva (pl erős hóesés esetén) . Ezeket a parancsokat több gomb egyidejű megnyomásával érhetjük el.

A protokoll gyakorlatban:

---------SZÁMLÁLÓ --> 00100100 00010100 01010100
--------------------------- SZ1xorR1 SZ2xorR2 SZ3xorR1
--- RND1 --- RND2 ---------------- első kódolás
10100001 01000010 10000101 01010110 11110101
---------------------------------------- második kódolás
00101010 01100001 00101110 01110001 00111110 <-- ez az "MC"
MC1(00) -- MC2(01) -- MC3(10) -- MC4(11) -- MC5(neki nem jutott)

10001011 00100011 10101011 00100111 11001011 <--kisugározni való

(Ez a példa nem ugyan az, mint az előző 20-as sorozat )

Az RND-k első 2 bitje mondja meg az adónak melyik "MC" byte kódolja az új RND-ket:
A vevő új RND1-e MC3-al , RND2-je MC2-vel kódoltatik, s küldetik vissza. Ha ezt az eljárást folytatjuk az újra küldött számlálók esetében is, tényleg nagyon meg lesz nehezítve a visszafejtő algoritmus, lehet hallgatózni vég nélkül.

Mazoista nem vagyok, csináltam egy EXCEL táblát a kulimunkára.

Elég meredek,de semmiképp nem tökéletes.Részben még mindig nemértem,legalábbis a foylamat további részét.

"az adó 5 byte-os "MC" két , az eredeti "RND" által meghatátozott byte-jával lekódolja, visszaküldi,
az adó ez új "RND"-kel megint elküldi a "SZÁMLÁLÓ" byte-okat, "

Ez mint magyar nyelvű mondat is elég furcsa,a pontos értelme meg rejtély.Az RND byte(melyiké??) értéke határozza meg(mi módon?),hogy melyik byte-ok kódolnak? Ez a mondat valami ilyesmit jelent,gondolom mást szerettél volna írni.

Egyébként,ha már ezt "lehallgatja",akkor a teljes kommunikációt is,tehát a 20kérdésre az ajtó 20válaszát,illetve az arra adott 20 viszontválaszt..az pedig ripropp törhetőnek tűnik.
Kérdés továbbá,hogy ez a "kezdő kódsor" hogyan keletkezett,milyen "véletlen által"? PCs programaml szimuláltad a dolgot? Te találtál ki számokat és zsebszámológéppel végezted a műveleteket?
Biztos,hogy nincs benne "hiba" vagy elírás? Az elején az ADR CMD az mi a bánat? Az is részt vesz a folyamatban valamiképp,vagy csak "dísz"?

Próbáld az algoritmust szabatosabban megfogalmazni(tudom,hogy nehéz!),mert így csak találgatni lehet.

A két "RND" byte az "MC" által van kódolva.
1 gombnyomás max 1 sec. Tovább felesleges nyomni a gombot, csak lemerül a telep.
Az adó elküldi az alább mellékelt kódsorok eggyikét,
a vevő leellenőrzi, számláló nagyobb-e mint utoljára, ha igen, felülírja a vele a sajátját,
generál két új "RND" byte-ot, az adó 5 byte-os "MC" két , az eredeti "RND" által meghatátozott byte-jával lekódolja, visszaküldi,
az adó ez új "RND"-kel megint elküldi a "SZÁMLÁLÓ" byte-okat,
ami ha jó, nyílik a kapu.
Ha a vevő jó szinkronnal rossz választ kap, befejezi a sessont, újra a bejelentkező kódot fogadja el, de már csak a növelt számlálóértékkel.

Most pedig egy kis kódtörésre kérem fel az ez irányba elhivatottságot érzőket
SZINKRON -- ADR CMD -- RND1 -- RND2 -- SZÁM3 -- SZÁM2 -- SZÁM1
01101010000100010101111110001111101000100101000111010010
01101010000100010111101000100001100001111111111111110100
01101010000100010100101111001001101101100001011111000100
01101010000100011010111001001101010100111001001100100110
01101010000100010101111001110010101000111010110011010111
01101010000100011001100100101101011001001111001100010011
01101010000100011111010000100100000010011111101001111111
01101010000100010101110111101010101000000011010011011001
01101010000100011010101110011010010101100100010000101110
01101010000100010011110111010011110000000000110110111011
01101010000100011101110110011010001000000100010001011010
01101010000100011010111010101010010100110111010000101110
01101010000100011100111011011000001100110000011001001111
01101010000100011011110101110100010000001010101000111111
01101010000100010100110111000011101100000001110111001110
01101010000100010001010010000101111010010101101110001000
01101010000100011010011110011001010110100100011100111010
01101010000100011100100111101100001101000011001001010111
01101010000100011010111000001110010100111101000000110001
01101010000100010100010100100001101110001111111111011101

A fejléc kicsit elcsúszott, a kötőjelek között lennének a bytehatárok.
Ez a távirányítóról lelopott 20 db bejelentkező kód. A rendszer feltörtnek tekinthető ha az 5 byte-os "MANUFACTURA CODE" visszafejthető belőle.
Az első 16 bit csak a teljesség kedvéért van itt. A soroknál a számláló minden esetben 1-el növekszik, nem "0"-ról indul, és csak az utolsó 5 bitben van változás.

A kódolás menete:
1./ A 2db "RND" generálása.
2./ "RND1" kódolja "SZÁM3" és "SZÁM1" byte-okat XOR függvénnyel
3./ "RND2" kódolja "SZÁM2"-t XOR függvénnyel
4./ A fejléc szerint az utolsó 5 byte XOR a "MC"-al --> ezek vannak a táblázatban.
Bocs ha kicsit szájbarágós, minden segítséget szeretnék megadni a töréshez, ne félreértés védje a kódot.

Jó vadászatot!!!

Meglepően növeli a biztonságot,ha a távrecsegő gombja nem nyomkodható őrült módjára,illetve a tápfesz megszakításával sem lehet a "türelmi időt" megkerülni,mert eleve több másodperc pihenéssel indul a kütyü.Igy már kellően hosszú kód esetén a véletlen számos fiksz kulcsos dolgok is megfelelhetnek.Esetleg valami gyenge DES szerüséget jobb lenne a PICre leprogramozni.Persze ha nem kerülhet a távrecsegő illetéktelen kezekbe,ez felelsleges energiapocsékolás.

Mi van akkor, ha két kód között minimum 1 másodperc késleltetést csinál a vevő? így meghosszabítja a variációk kipróbálásának idejét (mint szervergépeknél).
plusz:
1. távirányító küld egy üzenetet vevőnek (hitelesítéskérés, kódkérés)
2. vevő visszaküld egy üzenetet, benne véletlen számsorozatot
3. a távirányító a véletlen számsorozatot valamilyen speckó algoritmussal megváltoztatva visszaküldi
4. a vevő ellenőrzi a kapott, és maga által megváltoztatott kódokat, ha megegyezik, beereszti a kutyát; ha nem, 1 másodpercet vár.......
ehhez persze CRC ellenőrzés-fajta is kellene
Vélemény?

Most vagy nekem nem világos valami,vagy semmit nem ér az egész..már bocsi.A két RND szám amivel kódolsz,ott van az üzenetben kódolatlanul?
"SZINKRON"-"ADR-CMD"-"RND1"- "RND2"-" SZÁMLÁLÓ 3 BYTE"
Vagy mivel is kódolsz?

Valóban van egy gyenge pont. Mivel a számláló két felső byte-ja 255 gombnyomásnyira ugyan az marad, valamint a "MANUFACTURA CODE" (továbbiakban "MC") is változatlan, ezért ~65000 próbálkozásra a két középső MC byte megfejthető. Bár ezzel még nem nyílik a kapu.

Mi a helyzet, ha 2 RANDOM (továbbiakban "RND") byte-ot alkalmazunk, úgy, hogy az "RND1" az 1-es és 3-as számlálót, az "RND2" a 2-es számláló byte-ot kódolja.
"SZINKRON"-"ADR-CMD"-"RND1"- "RND2"-" SZÁMLÁLÓ 3 BYTE"

Az adóról akárhány jelsort szednek le nem lesz benne fogodzkodó, hiszen a két változatlan számláló byte más-más RND-vel van kódólva.

A további kommunikáció szerintem támadhatatlan, a 3. üzenet eltalálásának valószínűsége 1:4,2milliárd, de az első üzenet is ugrókódos, a próbálkozásokra a valószínűség nem nő.
A kód tehát nem túl rövid. (Így 250 bitnyi a kommunikáció 210 helyett.)

A vevők természetesen ismerik a hozzájuk jogos adók MC kódjait, az adók csak a sajátjukat.
Adó elvesztés esetén a vevőből csak egy MC kódot kell (PIC újraprogramozással) az új távirányítóhoz változtatni, a szintén vesző számlálóállások az első használatnál automatikusan szinkronizálódnak.

Az összes bitbillegetés "XOR" függvénnyel történik.

Köszönöm MotoHacker igen hasznos észrevételét, ha van még várom továbbra is.
Ha nem lesz több javítás a protokollban (és van rá igény) megpróbálok beszerkeszteni pár (tucat) 1. üzenetet (mintha a távirányítóról lenne lelopva), aki visszaadja az MC kódot pirossal bekeretezem a nevét.

Van ezzel pár baj.A kódolás kulcsának hosszúsága az első.Az adatok kis mennyisége és benne az egyetlen véletlen byte a másik.Nemtudom a kódolást milyen algoritmussal és kulccsal gondoltad.
Ellopva a távirányítót,(vagy lehallgatva a kommunikációt)hányszor kell megnyomni,hogy minden lehetséges kombinációt kiadjon? Ebből már véges idő alatt visszafejthető a kulcs és az egész haccacáré.(ekkora adatmennyiségnél pár nap nincs a szükséges számolás)
További problémát okoz,hogya mikrokontrollerrel előállított véletlen szám,csak álvéletlen,és a kontroller csekély matematikai képességei folytán igenigen rossz "véletlen".(pontosabban egy jól saccolható,elég gyakran ismétlődő függvény)
Mostmár a belépést tudjuk,tehát lehet menni a garázst "zaklatni" amikor nem vagy otthon.Amint a helyes kódot eltaláljuk,azonnal megkapjuk a 3byte-ot,a kulcsot már tudjuk,voilá,szezám tárulj.

Akkor egy kicsit a protokollról és a kódolásról

MotoHacker javaslata szerint a vevő alapban csak figyel. Az adó egy 6 byte-os sorozattal indít (ami a vonalon 11 byte-os lesz az RZ miatt).
Felépítését tekintve:
1 byte szinkron: kódolatlan, nem fordulhat elő benne egymás után 2db "1"-es.

1 byte 2 részre osztva 4 bit address, 4 bit command. 1 adó max 16 vevőt utasíthat, max 15 féle paranccsal. Kódolatlan. (bővebben esetleg később)

1 byte RANDOM: minden gombnyomásra véletlen számot generál a számláló szkremblerezéshez.

3 byte számláló. Minden gombnyomásra növekszik eggyel.
A RANDOM byte-onként XOR a számláló, majd egy 4 byte-os "MANUFACTURER CODE" XOR az utolsó 4 byte-ot.
Ezután RZ átkódolás és mehet a vonalra.

Idáig egyszerű ugrókód, Ha a számláló nagyobb mint utoljára volt, és a vevőnek elég ennyi, a történet befejeződik és pl a világítás felkapcsol.

Egyéb esetben a kód validálására a vevő generál egy új RANDOM-ot és az eredeti RANDOM első két bitje által meghatározott "MC" byte-al XOR, RZ és a szinkronnal visszaküldi az adónak. Ez a vonalon 3 byte.

Az adó az új RANDOM-al csak a szinkron + számlálót küldi el a kódolások után. Ez a vonalon 7 byte.

Összesen ~210 bit, még spóroltunk is valamennyit.

Kérem a közösségtől a protokollt és a kódolást támadni, esetleg kiegészíteni. (Szem előtt tartva a PIC számítási- és memóriakapacitását és a kódolás programozhatóságát, de nem a biztonság rovására!!!)

Ros-Co.: Az RZ nem ügy, félbe kell vágni a byte-ot, majd minden minden bit után be kell szúrni egy "0"-t. Csak egy rakás bitművelet. Az egymás mellett 2db "1"-es a startbit miatt lesz.

Ybanez: Rádiós cuccal addig nem akarok foglalkozni, amíg az infra be nem fuccsol. A projekt szempontjából nincs nagy különbség a két megoldás között, ki mit rak a PIC után. Az RZ a rádiónak is kell, ha jól sejtem.

MotoHacker: Valóban elgondolkodtató az állandó kódküldés a vevő részéről, abból a megfontolásból, hogy nem minden vevő lenne adási képességekkel ellátva. Ezek mint sima ugrókódos vevők működhetnének kevésbé kritikus helyeken. Ekkor azonban 3x kell megjáratni a kódokat az eszközök között, ->kicsit gyorsítani kell az adatátvitelt.

A mobilos ötlet tetszik,a mobilhálózat eleve 10x jobban "védett" mint bármi amit házilag lehet építeni.Még nem tapasztaltam,hogy tévedne a szám átküldésekor.
Az viszont,hogy egyfolytában "villog" a garázskapu kifele,nem olyan jó ötlet,az energiafogyasztás,illetve az IR led és a kapcsolás amúgyis véges élettartama miatt.

Ha megnézed a doksiját, a biztonságos adatátvitel Xx100m lehet, antenna és frekifüggő. Ezt nem csak "remote controll"-ra, hanem gépek közötti Wireless adatátvitelre találták ki. A datasheet ott van az integration.com-on sok segédlettel.
DE: Riasztó távkapcsolóhoz 30m-nél több minek?? Azt meg önmaga is csípőből tudja. 868 Mhz-en 57 Kbps, cca. 350m (Fig. 15)
De ha "csak" távkapcsoló kell, adó: 4220, vevő: 4320....sztem...