Gast Geplaatst: 12 augustus 2002 Geplaatst: 12 augustus 2002 Klopte wel alleen uitleg was verkeerd, nu hopelijk goed <img src="/ubbthreads/images/icons/smile.gif" alt="" /> 7122781 = 1600 * 4451 + 1181 (abcd) ab = 11 cd = 81 sumabcd = 0092 92 = hex 5c verder zouden ook goed kunnen zijn: 1249 1396 1462 1600 1831 1945 2498 2551 2792 2851 3197 3662 3676 3874 3890 4225 4381 4451 4702 4733 4871 5102 5587 5591 5606 5702 6169 6637 6652 6691 6734 7399 7499 7663 7748 7877 7925 8315 8425 8552 8807 8902 9155 9404 9466 9479 9742 Gr, Melt_Down
Gast Geplaatst: 12 augustus 2002 Geplaatst: 12 augustus 2002 Met deze gegevens kunne de wiskundigen onder ons toch wel iets lijkt mij. Vast gegeven is 007.122.781 de Formule 007.122.781 = a * b + c kan toch herleid worden naar een ingeklede vergelijking, of vergis ik mij? B.v. 007.122.781 - c = a * b 007.122.781 - c / b = a Ik geef maar een voorzetje hoor. Niet schieten als ik volledig fout zit. Avensis
Gast Geplaatst: 12 augustus 2002 Geplaatst: 12 augustus 2002 7122781 = x * y + abcd ofwel 7122781 modules x = abcd (y werd niet gebuikt in de checksum) Nog een whisky en dan naar bed <img src="/ubbthreads/images/icons/blush.gif" alt="" /> Gr, Melt_Down
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @Azazel Zijn er meer SN + REG code combinaties die JIJ kan gebruiken om te testen. Ik weet niet precies hoe privary gevoelig deze info is maar ik kan me voorstellen dat je deze info niet wil verspreiden. Maar het is zeker handig om een goede berekening op te stellen. <img src="/ubbthreads/images/icons/ooo.gif" alt="" /> @Everyone Wat ik nog niet helemaal begrijp wat doen alle andere bytes in de REG code. Zijn deze random of hebben deze een betekenis. <img src="/ubbthreads/images/icons/confused.gif" alt="" />
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 Die andere bytes zijn het serial nummer in hex Vb: Sn: 007.122.781 (6CAF5D hex) Reg: 00 5c 00 00 00 6C AF 5D Gr, Melt_Down
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 Tja een beetje dom dat ik daar overheen gekeken heb. Bedankt voor het ophelderen. Stukje bij beetje leer ik steeds meer. <img src="/ubbthreads/images/icons/grin.gif" alt="" />
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @BTSERVER Seca2 is het laatste waar ik nog wat mee wil stoeien, houdt het op de grand finale. @AVENSIS Is me inderdaad opgevallen, de checksumberekening lijkt op die van Seca1. Zoals de berekening in Seca1 gaat heb je te maken met 1 variabele (het serienummer). Pak je nu een V7 kaart dan zie je opeens een constante uit de lucht komen vallen die ergens vandaan moet komen. 007.122.781 wordt 00 00 00 00 00 6C AF 5D (waar is checksum 5C) 123.456.789 wordt 00 08 00 00 07 5B CD 15 (Checksum ???) 111.222.333 wordt 00 2D 00 00 06 A1 1E 3D (Checksum ???) Vroeger kon je dmv ingave 4 hex paren het serienummer tevoorschijn toveren. Bijvoorbeeld 00 6C AF 5D en je kreeg 007.122.781, en dat gaat nu niet meer. De keys zijn voor iedere kaart indentiek (Wel elke maand anders), dus heeft dit geen enkel invloed op de checksumberekening. Volgens de berekening SIN komt de 5C als resultaat eruit, maar dit blijkt vooralsnog niet te passen in een berekening. Zit meer te denken aan La Idea, en dan aan de vier verschillende methode. Mocht iemand ideen hebben of iets zien wat ik over het hoofd zie dan hoor ik het graag. Wil je wat meet weten over hoe Seca 1 werkt kijk op de site van Duwgati. (Voor de heren techneuten de kaart verbruikt 5,8 mA )
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @Kimble Ik ben het met je eens dat de keys geen invloed hebben op de checksum berekening. Wat ik echter niet begrijp zijn de serienummer met checksum berekeningen die jij doet voor 123.456.789 en 111.222.333. Waaruit haal je deze reg berekeningen?
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 Dus als ik het goed begrijp zoeken jullie naar een checksum berekening die bij serial 007122781 als antwoord 5C heeft en bij 123456789 als antwoord 08 en bij 111222333 anwtoord 2D geeft? Of heb ik het mis? Gr, Melt_Down
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @Melt_Down, allround, Wat ik eigenlijk niet begrijp waarom jullie er nu opeens vanuit gaan dat alleen het serienummer van de kaart gebruikt wordt om de checksum te bepalen. Als ik het stukje van Azazel lees begrijp ik eruit dat er nog veel meer input variabelen mogelijk gebruikt worden voor deze berekening. Hij gaf de volgende voorbeelden: ProviderBitMap, ATR, StartUpRecord, RecordActivacion, ProviderPackageBitMap01, DescEntidad00, DescEntidad01, KeysProvider00, KeysProvider01, Version, VersionStr. Of heb ik het allemaal verkeerd begrepen?? <img src="/ubbthreads/images/icons/confused.gif" alt="" /> <img src="/ubbthreads/images/icons/confused.gif" alt="" /> Het berekening zou natuurlijk stukken simpeler worden (anders gewoon niet te doen volgens mij) als we alleen rekening hoeven te houden met het serienummer. Dan is het inderdaad (zoals jullie ook al aangeven) een kwestie van zoveel mogelijk werkende voorbeelden van combinaties van SN en checksum-uitkomsten naast elkaar zetten en er dan een formule bij maken. @everyone Dus hier nog even de vraag aan iedereen: Kan hier iemand de beredenering neerzetten waarom we ervan uit kunnen gaan dat alleen het Serienummer van invloed is op de uitkomst van de checksum?
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @Kimble Jij schreef het volgende: "De keys zijn voor iedere kaart indentiek (Wel elke maand anders), dus heeft dit geen enkel invloed op de checksumberekening" vraag: Is het dan zo dat na een keywissel de uitkomst van de checksum gelijk blijft? Dit was bij Seca1 wel zo maar is dat ook bij Seca2 zo? @Everyone Kan iemand mij vertellen welke waarden naast het serienummer anders is op iedere kaart. Hierbij bedoel ik niet bijv. de keys maar uit het rijtje wat Azazel heeft gegeven: ProviderBitMap, ATR, StartUpRecord, RecordActivacion, ProviderPackageBitMap01, DescEntidad00, DescEntidad01, KeysProvider00, KeysProvider01, Version, VersionStr Alle waarden die namelijk op iedere kaart hetzelfde zijn zijn NIET van invloed op het bepalen van de checksum (kunnen we in een berekening van een key vervangen door een vaste waarden). Alle variabele waarden (zoals serienummer) zijn mogelijk wel van invloed op het bepalen van de checksum! (Of zeg ik nu weer wat wazigs <img src="/ubbthreads/images/icons/crazy.gif" alt="" /> )
Azazel Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 Hallo satvrienden, Helaas kan ik niet op alle vragen antwoord geven, en tsja.. meer sn en reg liggen een beetje gevoelig... Heb een aantal collega's gevraagd om dezelfde berekening toe te passen op de v7. Hoop op spoedig antwoord. - Checksum na keywissel blijft gelijk, dus we kunnen er vanuit gaan dat er geen variabelen worden gebruikt voor het berekenen van de checksum sn. Echter PPUA prov. wisselt na keywissel. hier kunnen we wel spreken van berekening met variabelen?? Interresant zou zijn als iemand weet hoe de checksum key's werden berekend op de 'oude' kaarten. Volgens mijn informatie is deze nog onbekend. Heeft iemand hier ervaring mee? Bedankt iedereen en ga zo door! Saludos! 'Azazel miembro del equipo RAIDEN, la resistencia.' [color:"red"] LLORAMOS JUNTOS, GANAREMOS JUNTOS! [/color]
Gast Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 gaat dit nu over seca 2 of alleen over checksum berekening . lees hier dus key wissel op s2 ???? naar mijn weten is tot nu toe geen sprake van key wissels . alleen datum wissel . ook ORBIT die veel langer met s2 speelt . die beruchte ontvanger zonder kaart werkt niet met keys. maar alleen met datums is maar 1 invals hoek hoor <img src="/ubbthreads/images/icons/smile.gif" alt="" /> je kan berekenen wat je wilt <img src="/ubbthreads/images/icons/smile.gif" alt="" /> eruit komen doe je er op deze manier niet . gr
Azazel Geplaatst: 13 augustus 2002 Geplaatst: 13 augustus 2002 @ask4it, De vermoeden bestaat dat er inderdaad weinig keywissels plaatsvinden. Gezien het feit dat er van mei naar juni de PPUA is gewijzigd van prov. 00 64, gaan we er vanuit dat er wel degelijk een keywissel is geweest, ervanuitgaande dat men hier wel berekeningen met variabelen toepast. Maar ja, wat is op moment wel met zekerheid te zeggen... Dit berust vooralsnog alleen maar op tests en vermoedens... Welke ins. worden verstuurd?? Over de checksum van sn. is inderdaad nu nog niet belangrijk, maar kan het zeker worden in de toekomst. Checksum van key's kunnen we nog niet toepassen daar enkele variabelen onbekend zijn. Nogmaals, dit is van belang, niet om direct seca2 open te krijgen maar om toe te passen op bv. bestaande mosc programmas zodat deze capabel zijn om de blackcard in zijn geheel uit te lezen.. Saludos! 'Azazel miembro del equipo RAIDEN, la resistencia.' [color:"red"] LLORAMOS JUNTOS, GANAREMOS JUNTOS! [/color]
Gast Geplaatst: 14 augustus 2002 Geplaatst: 14 augustus 2002 @Kimble De oude berekeing gaat volgens mij nog steeds op Als je een crc met 123456789 van 08 wil krijgen en met 111222333 een van 2d en je gebruikt bv 6900(3x 2300 ?!) krijg je deze checksum volgens mij. er zijn nog een paar andere mogelijkheden n.l. 4140 4979 5175 6210 6900 8100 Sla ik nu de plank mis of zit ik toch in de goede richting ?? Groeten, Chipmunk
Aanbevolen berichten
Maak een account aan of log in om te reageren
Je moet een lid zijn om een reactie te kunnen achterlaten
Account aanmaken
Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!
Registreer een nieuwe accountInloggen
Heb je reeds een account? Log hier in.
Nu inloggen