Checksum berekening (Principe)

[Gast]

Hier even een korte uitleg van checksum 32 (SFV)

 

De uitleg en vraag van Azazal is duidelijk, dus hier even een voorbeeld van een crc32 berekening.

 

Alles met de hoop dat er wat meerdere mensen aan het proggen slaan voor de vraagstelling van Azazal.

 

public class eSFVCheck

{

static StringBuffer buffer;

static StringBuffer buffertwo;

static String Test_String;

static String Test_Stringtwo;

static int blah = 0;

static int blahtwo =0;

static eSFVCheck ClassVariable = new eSFVCheck();

static StringBuffer OGChecksum = new StringBuffer("");

 

 

public static void main(String[] args) throws IOException

{

 

ClassVariable.ReadSFVFile();

}

 

void CalculateChecksum(StringBuffer OGChecksum)

{

CRC32 checksum = new CRC32();

 

try

{

System.out.println("Enter the location of the file to be checked.");

System.out.print("(_/-> ");

 

buffer = new StringBuffer("");

 

while ((blah = System.in.read()) != 13)

{

buffer.append((char) blah);

 

}

 

buffer.deleteCharAt(0);

Test_String = buffer.toString();

 

FileInputStream file = new FileInputStream(Test_String);

 

int length = file.available();

 

byte aofb[] = new byte[length];

file.read(aofb, 0, length);

file.close();

checksum.update(aofb);

 

long chk = checksum.getValue();

String hs = Long.toHexString(chk);

String hs2 = hs.toUpperCase();

 

System.out.println("\nFile read: "+ Test_String);

System.out.println("Bytes read: " + length + " bytes");

System.out.println("Checksum calculated: " + hs2);

System.out.println("Original checksum : " + OGChecksum);

if (hs2.equals(OGChecksum.toString()))

System.out.println("Not Corrupt");

else

System.out.println("Corrupt");

 

} catch (IOException e)

{

System.out.println(e.toString());

}

}

 

void ReadSFVFile()

{

try

{

System.out.println("Enter the location of the .sfv file to be read.");

System.out.print("(_/-> ");

 

buffertwo = new StringBuffer("");

 

while ((blahtwo = System.in.read()) != 13)

{

buffertwo.append((char) blahtwo);

Test_Stringtwo = buffertwo.toString();

}

 

 

FileReader SFVFile = new FileReader(Test_Stringtwo);

BufferedReader in = new BufferedReader(SFVFile);

 

boolean eof = true;

while (eof != false)

{

String FirstString = in.readLine();

if ((FirstString.charAt(0)) == ';')

{

eof = true;

} else

{

char chararray[] = new char[FirstString.length()];

 

chararray = FirstString.toCharArray();

 

int stringlength = FirstString.length();

 

for (int i = 8; i > 0; i--)

{

OGChecksum.append(chararray[(stringlength - i)]);

}

 

eof = false;

}

}

 

in.close();

 

ClassVariable.CalculateChecksum(OGChecksum);

} catch (IOException f)

{

System.out.println(f.toString());

}

}

}

[Gast]

Is dit nog een berekening voor seca (dus niet 2).

 

Is dit dus uitleg van een voorbeeld berekening voor hoe het nu gedaan wordt (seca1) ?

 

Kun jij een aantal voorbeelden geven van Seca2?

 

Dus wat gaat erin en welke checksum moet eruit komen (je hebt natuurlijk geen voorbeeld berekening). Als je daar een aantal voorbeelden van hebt dan zou ik (en ik hoop vele anderen) eens kunnen proberen daar een berekening bij te verzinnen (door computer laten berekenen).

[Gast]

Hoi Kimble, ik heb de indruk dat dit een java-script is. Dit is toch geen voorbeeld maar een progje wat er staat <img src="/ubbthreads/images/icons/confused.gif" alt="" /> Kan je dit wat beter toelichten aub. Bedankt <img src="/ubbthreads/images/icons/wink.gif" alt="" />

[Gast]

@lancelot

 

Dit is absoluut geen java

 

en ff iets meer uitleg gaat niet zo makkelijk

je moet bij de bodem beginnen in pizza taal gezegd

wil je eea kunnen begrijpen dan moet je toch wat

assembler,C enz. kunnen

 

en het is inderdaad een stukje van een prog.

maar dat is het hele codeer en decodeer gebeuren ook

[Gast]

Het is geen berekening voor de checksum zoals Seca1, waarom niet ?? Als je er vanuit gaat dat Seca2 dezelfde berekeningen uitvoert als Seca1 dan had het al lang open gelegen.

 

Feit is dat er gevraagd werd of er meerdere mensen zouden kunnen kijken naar checksum berekeningen. Gezien de reactie's dat er vele monden van verbazing openvielen en dat het ingewikkeld is, en wat knap allemaal, is volgens mij de vraag niet helemaal begrepen.

 

De vraag was duidelijk of er mensen zouden kunnen zijn die konden helpen met de checksum, niet om kompleet Seca2 te analyseren.

 

Het laat een duidelijke berekening zien van een crc32 zoals zelfs een winzip, rar pakketje gebruikt.

 

De vraag van Azazel was duidelijk hulp bij checksumberekeningen.

 

En ik neem aan dat iedereen wel iets van wiskunde weet zonder verder ook maar enige kennis van coderingen te weten.

 

Hoop dat ik nu wel duidelijk ben geweest, in ieder geval de vraag is al meerdere gesteld, alleen de reacties waren in mijn ogen geen antwoord op de vraag.

 

 

Resumerend, dit is een voorbeelberekening van een checksum (crc32) en van Azazel de vraag of er nog meer mensen kunnen helpen bij checksumberekeningen.

 

 

 

[Gast]

never mind...(bericht verwijdert door mezelf)

[Azazel]

Als eerse Kimble bedankt voor je duidelijke voorbeeld m.b.t. je voorbeeld berekening.

Hier wil ik aan toevoegen wat ik al eerder schreef in 'the study continues'.

Dan wordt het een beetje overzichtelijker.

In principe gaan we ervan uit dat voor elke kaart dezelfde berekening wordt gebruikt. Om de checksum van de key's te berekenen gebruikt men per kaart data als masterkey's, serie nummer, usertables, etc.)

D.w.z. zeggen dat elk kaart een andere checksum heeft op de key's 0C, 0D en 0E.

De kunst is om erachter te komen welke checksum je eigen kaart heeft, welk berekening kunnen we hiervoor gebruiken? Berekeningen op de vorige vesies kunnen we nu niet meer toepassen, maar mischien dat er met een kleine aanpassing ........

 

Alles wordt bereken d in decimalen en aan het einde veranderen we de

checksum in hexdecimaal.

 

1) Serie nummer wordt gedeeld door 2300 en we krijgen dan een xx

getal, dit getal zullen we 'abcd' noemen, en dat is een nummer

tussen de 0 en 2300.

2) Splitsen vanhet nummer "abcd" in twee groepen: "ab" , "cd"

3) Optellen van "ab" + "cd" en we krijgen dan weer een uitkomst

("efg"), deze ligt tussen de 0 en 198

4) De twee laaste cijfers ("fg") van de laatste uitkomst brengen

we over in hexdecimaal en verkrijgen zo dus de checksum.

 

VOORBEELD:

 

sn = serie nummer

 

1) Laten we aannemen dat sn is 123.456.789

123.456.789 / 2300 = 53676

123.456.789 - (53676 * 2300) = 1989

Dit is dus hetzelfde als:

123.456.789 = 53676 * 2300 + 1989

 

abcd = 1989 ------> 19 89

ab = 19

cd = 89

ab + cd = 19 + 89 = 108 = 0108 -----> 01 08

fg = 08

08 (dec) = 08 (hex) = checksum

Dus de register corresponderend aan de serie nummer moet zijn:

00 08 00 07 5B CD 15

waar 07 5B CD 15 is de nummer 123.456.789 in hexdecimal en 08 de

checksum.

 

Gezien deze manier van checksum berekenen voor de serie nummer moet

er ook een methode zijn om de checksum voor de key's te berekenen.

Wat ik weet is dat alle kaarten dus dezelfde keys hebben maar de

checksum per kaart verschilt...

 

Nog een voorbeeldje:

2) Serie nummer = 444.444.444

444.444.444 = 193236 * 2300 + 1644

ab = 16

cd = 44

ab + cd = 16 + 44 = 60 = 060 -----> 00 60

60 (dec) = 3C (hex) = checksum

Register : 00 3C 00 00 1A 7D AF 1C

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

[Gast]

Hoi,

 

Dit is voor het eerst dat ik durf te reageren (en vergeef me als mijn opmerking ronduit stom is).

 

Allereerst alle legale kaarten hebben een nummer (logisch)

In de nummering moet een bepaalde logica zitten.

Zodra die logica ontsloten is, door gewoonweg achter zo veel mogelijk kaartnummers proberen te komen. Mogelijk kan dit via loggen <img src="/ubbthreads/images/icons/confused.gif" alt="" /> <img src="/ubbthreads/images/icons/confused.gif" alt="" />.

Is in ieder geval een gedeelte van de bouwstenen voor de checksum bekend.

 

Verder lijkt het mij logisch dat voor elke kaart het zelfde rekensommetje

wordt gebruikt.

 

Okee als de kaartnummering logica is "ontleed" is er nog maar een klein gedeelte opgelost, maar er is in ieder geval 1 onbekende minder.

 

Hopelijk zit ik een beetje op het goede spoor <img src="/ubbthreads/images/icons/confused.gif" alt="" /> <img src="/ubbthreads/images/icons/confused.gif" alt="" />

 

Met Vriendelijke Groet,

 

Wil Weten

 

 

 

[Gast]

@Azazel

 

De berekening die je doet op het serie nummer van de kaart komt uit SECA1?

Zo,ja wat hoop je hier dan mee te doen? Een string te vinden in de byte code van de kaart zodat je deze plaatsen kan vast leggen als serienummer checksum?

Als je zeker bent van deze berekening is het simpleweg een applicatie maken waarmee je alle bytecode ingeeft en het serie nummer en de applicatie kan snel zien waar de eventueele checksum staat in de byte code.

 

De vraag blijft echter is de berekening wel juist. <img src="/ubbthreads/images/icons/confused.gif" alt="" />

Ik heb wel wat ervaring in het maken van checksum. Het is echter niet eenvoudig om een reverse berekening te maken. Ik denk dat het wat te simple is weergegeven. Eén extra variable en het word tienkeer zo lastig zo niet nog veel ingewikkelder. <img src="/ubbthreads/images/icons/frown.gif" alt="" />

 

Ik blijf het volgen en als ik iets kan bij dragen zal ik dat zeker doen.

Keep up the good work <img src="/ubbthreads/images/icons/cool.gif" alt="" />

 

Allround

[Gast]

Ik moet eerlijk bekennen (hoewel ik zelf sw engineer ben geweest) dat ik nog nooit met checksums gewerkt heb. Dus ben dan ook van de hele discussie niet zo op de hoogte. Wat ik hier echter zie is (zonder iemand te willen beledigen) "simpelweg" stoeien met getallen. De software is alleen een geautomatiseerde manier om aan de checksum te komen maar is niet direct nodig. Ik denk dan ook dat voor velen het laatste voorbeeld het meest duidelijke is (nogmaals zonder te beweren dat het simpel zou zijn). De software is denk ik voor velen een drempel geweest. Goed voorbeeld dus!!!!!!!!!

 

Ook ik zou er wel mijn steentje aan willen bijdragen maar dan moet er voor mijn gevoel wel iets meer info zijn (waarmee ik me aansluit bij vorige berichtgevers). Bij reverse engineering gaan we toch uit van de uitkomst en werken naar de berekening toe. Mijn vraag is dan ook:

 

Zijn er uitkomsten bekend van checksumberekeningen (bij voorkeur meer dan 1) met de mogelijk gebruikte data (dat er nog een aantal onbekenden zijn lijkt me logisch)? Mocht deze info al ergens staan dan zou ik graag weten waar.

 

Wellicht zou ik er wat vrije uurtjes aan kunnen spenderen. Heb wiskunde altijd wel een leuk vak gevonden. Ik heb nou niet meteen de indruk dat het mij wel even gaat lukken (waarschijnlijk niet) maar dan is het toch leuk geweest om mee te doen en er wat van op te steken.

 

Groeten

[Gast]

@Pink Panther

 

totaal mee eens!

 

@everyone

 

we moeten voorbeelden hebben van werkende SECA2 checksum uitkomsten en de daarbij behorende variabelen! Verder alleen nog maar de wiskundige berekening erbij zoeken. Het later in een programma gieten is totaal het probleem niet.

[Azazel]

Hallo satvrienden,

Als eerste bedankt iedereen voor het meedenken omtrent dit probleem. Aan de reacties te lezen was ik denk ik niet helemaal duidelijk...

Goed.. korte uitleg:

 

Het enige nut dat dit tot nog toe heeft is het proces begrijpen, om in de toekomst te kunnen gebruiken om de berekenig te maken v/d checksum van de key's t.a.v. de blackcard. Deze gegevens hebben we nodig om programmas te kunnen ontwikkelen die het geschikt maken om de v7 te lezen, schrijven, etc. De berekeningen die nu gedaan worden zijn bep. door een aantal factoren, vb. mk, serienr., tabellen, PPUA, etc.. Ik zal verderop een checksum en serie nummer geven van de blackcard en je zult zien dat de voorbeeld berekening die ik eerder heb gegeven hier niet geldt.

De kunst is dus een logische reverse berekening te kunnen achterhalen voor je eigen kaart, let wel, op dit moment moeilijk gezien het feit een aantal factoren onbekend zijn.

 

De berekening die ik eerder schreef werd zeker toegepast op de vorige kaarten.

Ik zal als voorbeeld mijn eigen oude Canal plus kaart gebruiken:

 

Sn.: 012.209.096

Reg. 00 02 00 00 BA 4B C8

 

12209096 = 5308 * 2300 + 696 (abcd)

ab = 06

cd = 96

6 + 96 = 102 -- 01 02

Dec 02 = Hex 02.

Reg. 00 02 00 00 BA 4B C8

 

Ik zou zeggen probeer deze berekening met je eigen kaart en je zal zien dat het altijd uitkomt. Lees je eigen kaart uit met bv. het zeer gemakkelijke en snelle programma CSDinfo.

 

Betreft de v7, dan gaat deze berekening niet meer.

 

Vb:

Sn: 007.122.781

Reg: 00 5c 00 00 00 6C AF 5D

 

Als je de berekening hierop toepast zul je zien dat de uitkomst ab + cd 100 zal zijn, (klopt niet met de checksum 5c).

 

Enkele gegevens van dezelfde kaart:

SerialNumStr =007.122.781

SerialNum =00 5C 00 00 00 6C AF 5D

ProviderBitMap =00 00 00 07 00 10 DB

ATR = 3B F7 11 00 01 40 96 70 70 07 0E 6C B6 D6

StartUpRecord=01 00 00 00 00 00 00 00 00 00 10 04

RecordActivacion=02 20 04 20 02 00 00 00 00 00 00 04

ProviderPackageBitMap01=00 00 00 10 80 00 30 8E 04 FF FF FF

DescEntidad00=00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00

DescEntidad01=00 64 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 20 20 20 0A 18 AE F1 18 DE 02

KeysProvider00 =FF FF 0F 6C 00 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

KeysProvider01=FF FF 0F 6C 00 F0 51 F3 5D 5C 5E FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Version=08 10 11 71 30 14 0D 03 64 00 FF B8 1E 8F FB 85 C4 17 3D 76 44 55 C7 14 AC 06 DC 96 04 01 FC B0 AF EC A8 97 3E BA 59 FE D5 91 28 43 29 53 45 43 41 2D 3E 31 39 39 34 2D 2D 3E 31 39 39 39 2A 2A 56 36 2E 30

VersionStr =©SECA->1994-->2001**V7.0

 

Hier is het dus interessant te weten welk berekening men toepast (hoe moeilijk het ook zal zijn).

 

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

 

[Gast]

En als toevoeging op Azazel een uitreksel van de Blackcard (V7.0) met

MasterKeyFind v4.4

 

MKFIND 4.4:

 

[GeneralInfo]

ATR= 3B F7 11 00 01 40 96 70 70 07 0E 6C B6 D6

UAhex= 0x xx xx xx

UAdec= xxx.xxx.xxx

SuppProv= 0000000000001111

 

[00 00]

Name= SECA

SECAStartup= 00 00 00 00 00 00 00 00 00 10

SECAPPV= 07 03 00 47 00 64 02 17 01 00

PrimaryKeys= F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

 

[00 64]

Name= CANALSATÉLITE

Date= 31/12/02

PPUA= 0x xx xx xx

Region= 00

PBM= 00 00 00 00 00 00 60 00

PrimaryKeys= F0 F1 F3 FE FF FF FF FF FF FF FF FF FF FF FF FF

 

[00 66]

Name= CANALSATÉLITE2

Date= 31/12/02

PPUA= 0x xx xx xx

Region= 00

PBM= 00 00 00 00 00 00 00 00

PrimaryKeys= F0 F1 F3 FE FF FF FF FF FF FF FF FF FF FF FF FF

 

[00 67]

Name= CANALSATÉLITE3

Date= 31/12/02

PPUA= 0x xx xx xx

Region= 00

PBM= 00 00 00 00 00 00 00 00

PrimaryKeys= F0 F1 F3 FE FF FF FF FF FF FF FF FF FF FF FF FF

 

[Card Records]

Pr: Index = Record - Description

00: 00 01 = F0 FF FF FF FF FF FF FF FF CC 00 80 - Clave Primaria 00

00: 00 02 = 70 FF FF FF FF FF FF FF FF 43 00 C0 - Clave Secundaria 00

00: 00 03 = 00 07 03 00 47 00 64 02 17 01 00 E0 - Registro SECA PPV

00: 00 04 = FB 28 0A 9D 46 D2 75 87 28 B5 9C D0 - Registro de credito PPV

00: 00 05 = 01 00 00 00 00 00 00 00 00 00 10 E0 - Registro SECA Start-up

01: 00 06 = F0 FF FF FF FF FF FF FF FF 8F 00 81 - Clave Primaria 00

01: 00 07 = 50 FF FF FF FF FF FF FF FF 56 00 C1 - Clave Secundaria 00

01: 00 08 = F1 FF FF FF FF FF FF FF FF 98 00 81 - Clave Primaria 01

01: 00 09 = 51 FF FF FF FF FF FF FF FF 36 00 C1 - Clave Secundaria 01

01: 00 0A = F3 FF FF FF FF FF FF FF FF F2 00 81 - Clave Primaria 03

01: 00 0B = 53 FF FF FF FF FF FF FF FF 6B 00 C1 - Clave Secundaria 03

01: 00 0C = FE FF FF FF FF FF FF FF FF 0F 00 81 - Clave Primaria 0E

02: 00 0D = F0 FF FF FF FF FF FF FF FF C4 00 82 - Clave Primaria 00

02: 00 0E = 50 FF FF FF FF FF FF FF FF 39 00 C2 - Clave Secundaria 00

02: 00 0F = F1 FF FF FF FF FF FF FF FF A8 00 82 - Clave Primaria 01

02: 00 10 = 51 FF FF FF FF FF FF FF FF 9C 00 C2 - Clave Secundaria 01

02: 00 11 = F3 FF FF FF FF FF FF FF FF 5A 00 82 - Clave Primaria 03

02: 00 12 = 53 FF FF FF FF FF FF FF FF 49 00 C2 - Clave Secundaria 03

02: 00 13 = FE FF FF FF FF FF FF FF FF A2 00 82 - Clave Primaria 0E

03: 00 14 = F0 FF FF FF FF FF FF FF FF A5 00 83 - Clave Primaria 00

03: 00 15 = 50 FF FF FF FF FF FF FF FF B0 00 C3 - Clave Secundaria 00

03: 00 16 = F1 FF FF FF FF FF FF FF FF 59 00 83 - Clave Primaria 01

03: 00 17 = 51 FF FF FF FF FF FF FF FF 7C 00 C3 - Clave Secundaria 01

03: 00 18 = F3 FF FF FF FF FF FF FF FF F6 00 83 - Clave Primaria 03

03: 00 19 = 53 FF FF FF FF FF FF FF FF BB 00 C3 - Clave Secundaria 03

03: 00 1A = FE FF FF FF FF FF FF FF FF 3C 00 83 - Clave Primaria 0E

00: 00 78 = FB 28 0A 9D 46 D2 75 87 28 B5 9C D0 - Registro de credito PPV

00: 00 F0 = FB 28 0A 9D 46 D2 75 87 28 B5 9C D0 - Registro de credito PPV

00: 01 68 = FB 28 0A 9D 46 D2 75 87 28 B5 9C D0 - Registro de credito PPV

00: 01 E0 = FB 28 0A 9D 46 D2 75 87 28 B5 9C D0 - Registro de credito PPV

 

 

@Azazel

 

Voorbeeld ident 0064 :

 

Incoming ECM Instruction

C1 3C 0E BE 5C

Received Encrypted CW

10 01 79 CF 03 DE A7 5F E9 74 17 7A A4 43 E5 B8

F5 C0 64 85 67 7C 97 3D DD 4E 00 CF AD AD 15 96

20 85 A8 9E 66 74 51 F6 87 8C DF 3F ED 9F BC 9A

43 47 98 84 60 34 66 5C 1A DC B0 C5 93 9C 52 C2

49 F5 A3 1F DC B0 3B 43 C0 7B F6 3D BF 50 1A 9E

94 49 EA CB 54 68 D1 BB 34 26 73 70

90 02

 

Key in gebruik is 0E, bit 7 is set(superencryption, sla de eerste 8 bytes over) bits 4,5,6 zijn gelijk aan 3, dus die kan je ook overslaan, resulteerd 10 01 79 CF 03 DE A7 5F E9 74 17 (moet kloppen ??)

 

Ben nu bezig met Blowfish, Cast128, 3DES, RC5, La Idea, Seguro en CFB als encryptie.

 

Volgende week beginnen de scholen weer en zal mijn zoon dit "probleem" aan de wiskundeleraar voorleggen.

 

 

 

 

[Gast]

ik hoop dat je nog niet stopt.

maar waar haal jij een blakecard vandaan.

ik probeer via via aan een te komen maardit gaat niet.

ik heb wel een irdeto2 kaart maar niet eeen blake.

kun je mij daar niet aan helpen.

gr bt

 

[Gast]

Heb je meer voorbeelden van seca2 serials en met checksum uitkomsten, is makkelijker testen of de berekening klopt

 

Een opvallende tot nu to 1600 ipv 2300 <img src="/ubbthreads/images/icons/smile.gif" alt="" />

 

7122781 = 1600 * 4451 + 1181 (abcd)

ab = 11 cd = 96

abcd = 1196

96 = hex 5c

 

Gr,

 

Melt_Down