Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 Misschien rare vraag, er zullen toch wel mensen zijn in Spanje die bv een Humax of iets anders hebben met een ASTON module ? Weet iemand..... de een beetje spaans kan ... of er iets over op de Spaanse boards staat ?? <img border="0" title="" alt="[Frons]" src="images/icons/frown.gif" /> <img border="0" title="" alt="[Frons]" src="images/icons/frown.gif" />
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 OOK HIER OP DE SPAANSE BOARDS ZIJN ZE ER NOG LANGGGGGGGG NIET UIT HET ENIGE DAT IK WEET DAT DE NIEUWE ORIGINELE SECA2 KAART VAN CSD WERKT IN EEN ASTON 1.05 ZODRA ER NIEUWS IS AAN HET FRONT WORDT DIT UITERAARD DOORGEGEVEN SALU2 JOPIE
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 Ik wil ook even mee discu-zeuren. Loop naar de eerste de beste computershop koop het pakketje BLEEM en je speelt dan toch ook playstation spelletjes op een PC en niet op een Sony Console. En dan is het zelfs nog zo dat je BLEEM niet mag duppen. Denk dat met dit voorbeeld het hele sat-hardware-crypto verhaal met een softwarepakketje wel mag?!? Feitelijk zou je kunnen zeggen dat met een dvb-kaart multicam proggies wel mogen. In de tussentijd op de POOL de seca2 file naar binnen gehaald, gebakken en is dus FAKE. Tocado.....esta loco
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 Hé Kimble. Als ik het eten op netjes probeer te serveren, roer jij alles weer door elkaar <img border="0" title="" alt="[Flinke grijns]" src="images/icons/laugh.gif" /> ASTON gebruikt de technologie van C+ niet. Het is een eigen systeem. Dat zeggen hun hé! Dus niet denken dat ik 1 van de 2 probeer te verdedigen of zo… Maar… een C+ kaartje levert wel beeld op in dat ASTON apparaat. (dat gebeurd natuurlijk door emulatie, maar daar lult verder niemand over <img border="0" title="" alt="[Flinke grijns]" src="images/icons/laugh.gif" /> ) Zoiets als een Betamax cassette afspelen in een VHS recorder. Het is gewoon een typisch geval van “ Ken Nét! “ <img border="0" title="" alt="[Glimlach]" src="images/icons/smile.gif" /> ASTON zegt tegen de rechter “wij snappen er niks van dat die betamax cassette in onze VHS recorder werkt” C+ zegt “ Ze liegen meneer de rechter. ASTON heeft onze Betamax recorder nagemaakt en zeggen dat het een VHS is”. Tja bewijs dat maar eens op een manier die ook geaccepteerd wordt…. En inderdaad gaat dat verhaal met die PS ook op. Als wij een kassie bedenken (met 1 eigen spelletje, die moet er juridisch even bij anders werkt het niet hé) die heeeeeeel toevallig ook Xbox schijjes kan draaien. Dan snappen wij daar natuurlijk niks van. Net als die grote bedragen op onze Arabische bankrekening <img border="0" title="" alt="[Flinke grijns]" src="images/icons/laugh.gif" /> Het Ken allemaal Nét
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 ik heb zwarte kaart nu kan ik wel taq zien maar dat komt omdat ze nu uitzenden op 0064 met 0066 anders deze is niet in range 1.05 ppippo is het ook met deze stelling eens en nog meerdere oudgediende de aston cam kan niet alles aan dus niet 100% compatible ECMs and EMMs are all well converted EXCEPT the EMMs with ilen=61, the ASTON CAM ignore them. [82006b] UA:[00000x xx xx xx] ProvID:[00 64] Mkey:[00 b0] [ 10 01 46 d7 af b1 10 8b d1 0c a2 c9 66 ff fe 78 ] [ a9 04 61 bd 6e 81 29 a2 30 59 6c 1a 56 01 91 29 ] [ 60 3f 6a d7 13 43 99 81 d4 31 45 e0 ed f6 ee e1 ] [ ac b8 69 83 00 5e 3a 17 51 a0 a4 a7 06 1c 35 e9 ] [ 9e e4 79 58 2d 33 f5 3e 97 f1 fc 5e 16 6b d3 38 ] [ 6d d0 5c e0 1f dd dd 2a fc d4 1b 5b 18 bb 47 ef ] [ 6b ] until now the max ilen was 5f (95 byte)
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 Dus gerard, je wil dus zeggen dat de aston niet compatible is met de second provider op de kaart. Waarom zouden ze de paclen veranderen voor de tweede provider. En by the way, the blackcard is dat een orginele of een fun cq ds9... \ grtx Afterburner
Gast Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 zwarte kaart is origineel dus. Is nog niet gekraakt dus geen andere kaart mogelijk. 2de providers bijvoorbeeld in toekomst de taq en de 3de voetbal of x kanalen (zonder preview dus) dit is natuurlijk speculeren ze zijn zelf nog aan het testen maar is waarschijnlijk het meest logisch. @geer
Unetwork Geplaatst: 12 april 2002 Geplaatst: 12 april 2002 >>Dus als jij een GameStation bedenkt dat compatible is met Xbox games en Sony Playstation schijfjes wil nog niet automatisch betekenen dat je strafbaar bent. Sterker nog, als de prijs een beetje gunstig is heb je een gat in de markt<< Dit kan natuurlijk nooit waar zijn want als je over Playstation spreekt je het hebt over een Operating system zoals Windows MS er ook een is! Je moet het zo zien dat Seca en en/decodeer sisteem is dat eigendom is van Canal+ Geld maakt niet gelukkig maar geluk is onbetaalbaar
Gast Geplaatst: 13 april 2002 Geplaatst: 13 april 2002 @Nl0Raf Astonvrypt is inderdaad een systeem van Aston en leuke bijkomstigheid is dat het werkt op seca 1. Aston crypt 2 zal er nooit komen omdat als deze op de markt gebracht is en dus compatible zou zijn met seca 2 het juridisch niet verdedigbaar is wat de economische noodzaak van AstonCrypt 2 is omdat niemand Astoncrypt 1 gebruikt. Canal + kan dan heel goed hard maken dat de introductie van AstonCrypt 2 alles te maken heeft met de komst van seca 2. Ook op je redenering dat Seca op een Magic CI en op Freecam te ontvangen is moet worden weerlegt in die zin dat het zeker kan maar dat het niets met de legale discussie rond de Astoncrypt te maken heeft. Software voor de freecam, magic ci en betacrypt in een Irdeto CI zijn niet officieel uitgebrachte softwarerelaeses en komen dus uit de hobbysfeer en zijn dus juridisch gezien altijd illigaal omdat het inbruik naakt op de geestelijk eigendom van andere coderingssystemen.
Gast Geplaatst: 13 april 2002 Geplaatst: 13 april 2002 ik heb op het spaans forem ditgevonden een log van een spaanse mosc cart First of all say that the ATR of the new cards is the same as the old v6.0, except the version number (7.0). Here are the struct of a new v7.0 spanish card: ****escEntidad00=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 ; 00 00 SECA PrimoescEntidad01=00 64 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 20 20 20 09 8F BF A6 19 9F 00 ; 00 64 CANALSATELITE SecondoescEntidad02=00 66 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 32 20 20 09 8F BF A6 19 9F 00 ; 00 66 CANALSATELITE2 TerzoescEntidad03=00 67 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 33 20 20 09 8F BF A6 19 9F 00 ; CANALSATELITE3 PBM SECA: ProviderBitMap=00 00 00 0F 00 10 DB PBM CANALSATELITE: ProviderPackageBitMap01=00 00 00 00 00 00 60 00 04 FF FF FF PBM CANALSATELITE2: ProviderPackageBitMap02=00 00 00 00 00 00 00 00 04 FF FF FF PBM CANALSATELITE3: ProviderPackageBitMap03=00 00 00 00 00 00 00 00 04 FF FF FF 00 01 F0 FF FF FF FF FF FF FF FF 15 00 80 00 02 70 FF FF FF FF FF FF FF FF 36 00 C0 03 00 07 03 00 47 00 64 04 1F 01 00 E0 04 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 00 05 01 00 00 00 00 00 00 00 00 00 10 E0 questro è lo startup...è fatto non seguendo l'ordine dei record ma l'appartenza al provider... sempre sullo 00... 00 78 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 00 F0 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 01 68 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 01 E0 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 passiamo allo 01: 00 06 F0 FF FF FF FF FF FF FF FF 86 00 81 00 07 50 FF FF FF FF FF FF FF FF 8B 00 C1 00 08 F1 FF FF FF FF FF FF FF FF F5 00 81 00 09 51 FF FF FF FF FF FF FF FF DE 00 C1 00 0A F3 FF FF FF FF FF FF FF FF C1 00 81 00 0B 53 FF FF FF FF FF FF FF FF 71 00 C1 00 0C FE FF FF FF FF FF FF FF FF 3A 00 81 passiamo allo 02: 00 0D F0 FF FF FF FF FF FF FF FF F5 00 82 00 0E 50 FF FF FF FF FF FF FF FF 84 00 C2 00 0F F1 FF FF FF FF FF FF FF FF E6 00 82 00 10 51 FF FF FF FF FF FF FF FF 36 00 C2 00 11 F3 FF FF FF FF FF FF FF FF 48 00 82 00 12 53 FF FF FF FF FF FF FF FF 82 00 C2 00 13 FE FF FF FF FF FF FF FF FF C6 00 82 03: 00 14 F0 FF FF FF FF FF FF FF FF BF 00 83 00 15 50 FF FF FF FF FF FF FF FF BB 00 C3 00 16 F1 FF FF FF FF FF FF FF FF 2A 00 83 00 17 51 FF FF FF FF FF FF FF FF 12 00 C3 00 18 F3 FF FF FF FF FF FF FF FF 5C 00 83 00 19 53 FF FF FF FF FF FF FF FF 4A 00 C3 00 1A FE FF FF FF FF FF FF FF FF 22 00 83 Ultimi dati: SerialNumStr=123.456.789 StartUpRecord=01 00 00 00 00 00 00 00 00 00 10 04 Version=00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 At this moment there are some spanish channels (i.e.: viajar, cartoon networks) who sends the two INS 3C (the old and the new) if the card has the ident 00 0C (old) and 0064 (new). For the other spanish providers (00 66 and 00 67) the still send nothing now. Here you have an example of log: ------------------ CAM -> CARD ----------------- CLAS: C1 INS : 3C P1 : 01 P2 : 0D LEN : 29 ------------------ CABECERA -------------------- C1 3C 01 0D 29 -------------------DATOS------------------------ 71 00 00 0C 07 D2 00 03 27 18 79 13 01 13 1C D1 4B 74 D4 97 E3 85 6E 7D EF BD 7F 1E 9E 9A 68 CA 82 xx xx xx xx xx xx xx xx 90 00 ------------------------------------------------ ------------------------------------------------ 25/03/2002 21:55:11 ------------------------------------------------ ---------------- CARD -> CAM ------------------- CLAS: C1 INS : 3A P1 : 00 P2 : 00 LEN : 10 ------------------ CABECERA -------------------- C1 3A 00 00 10 ---------------------DATOS---------------------- 14 10 54 81 40 40 51 1B 05 40 04 8D 04 05 10 65 90 00 ------------------------------------------------ ------------------------------------------------ 25/03/2002 21:55:12 ------------------------------------------------ ------------------ CAM -> CARD ----------------- CLAS: C1 INS : 3C P1 : 02 P2 : BE LEN : 5C ------------------ CABECERA -------------------- C1 3C 02 BE 5C -------------------DATOS------------------------ 10 01 54 7C C2 EB 3A F9 D1 14 D4 C8 31 D8 EB 55 B0 DD 38 DC F0 F0 C9 2C 6B 0A 5D EE E6 1B 37 D1 C5 9E E1 1C 8B CF 90 24 8C 31 23 ED 2F 03 9D 91 6B 94 8B 1C EF A3 47 E9 0A B3 1D A7 50 68 22 F6 1F 76 7B AD 4B FCDD 66 7A 0C 21 67 21 BF 2B 32 BE F8 A5 B9 94 31 A7 59 AD EA AB 2F 90 02 ------------------------------------------------ You can see that the new 3C INS is completely distinct as the old. The only same between two new INS 3C is the 10 01 at the beginning. So we think that the encryption algo is distinct, and they are using superencryption. What can mean this nano 10 with value 01: - It can be mean the provider who is directed by it's INS 3C (10 01, in this case P1=01 -> 00 64). When they send INS 3C for the other two providers, we can supose this. So for a) Provider 00 64 ; 10 01 Provider 00 66 ; 10 02 c) Provider 00 67 ; 10 03 - It can be a flag for a hash-table for encrypt the INS ...... At this moment, we doesn't know what will it mean. What follow now is a very interesant study of parisino about the new INS 3C, why are completely distinct after nano 10 all the bytes of two distinct new 3C. Chapter 1: Analyzing the result of the first 8 bytes of the INS 3C The prove is encrypt with some known simetric algos the input data with the same key and prove if the result of doing this several times es always the same. The used data are: DD DD DD DD DD DD DD DD = Input data KK KK KK KK KK KK KK KK = Used key RR RR RR RR RR RR RR RR = Result The algos we used are: IDEA, BLOWFISH, CAST128, 3DES, RC5 and SAFER, all in mode CFB. The result are that the ouput of the encryption of the first 8 bytes always are the same, if the input data and the key are the same, doing the proccess several times. So we think that the first 8 bytes ofter byte 2 of the INS 3C NO are the same in all the INS 3C, posibely this 8 bytes are always different between two INS 3C. To prove this, we made the follow example. It's an invented 3C. It's content before encrypt it with the key are: 10 01 04 D1 11 22 33 44 55 00 ....... - Nano D1 with the DW - Nano 04 for open all the channels - Nano 10 with the data 01 Of the 8 bytes after the "10 01" only will change the last 6. We will encrypt it with a key and view the results, the algo we used are the algo we knows all the life ( ). The key will be 11 22 33 44 55 66 77 88 - 04 D1 11 22 33 44 55 00 + 11 22 33 44 55 66 77 88 Instruction after encrypting = 10 01 1F 58 D8 E2 C9 01 BF B7 - 04 D1 11 22 33 44 55 01 + 11 22 33 44 55 66 77 88 Instruction after encrypting = 10 01 4F 97 EC 44 CC 75 71 FF - 04 D1 11 22 33 44 55 02 + 11 22 33 44 55 66 77 88 Instruction after encrypting = 10 01 19 CA 6B B2 E6 59 51 44 - 04 D1 11 22 33 44 55 0F + 11 22 33 44 55 66 77 88 Instruction after encrypting = 10 01 92 8D F4 0E 2D CE 50 71 If we can see we get similar instructions than they send us for the provider 00 64, so we can "cuasi" say that at least one byte MUST be change in the first 8 bytes to get that the 3C INS are always different. This means that we can forgett the brute-force attack , why we haven't a pattern to implement it. Also probably the algo is distinct, another reason to not apply brute-force. The design of the first 8 bytes can be have a lot of variants, here you have any: - 04 D1 11 22 33 44 55 66, nanos 04 and D1 - D1 11 22 33 44 55 66 77, nano D1 - 11 22 33 44 55 66 77 88, without nanos, the 8 first bytes are filling bytes - 7X 11 22 33 44 55 66 77, new nano 7X Everybody can choose who you want, but my favourite's are 4, 3, 2,1 in this order. Chapter 2: Analyzing the result of the rest of bytes of the INS 3C Now we can get yet an idea of what occurs in the first 8 bytes, but what will occurs in the rest of bytes. Here we found also differences with we know today. There are not groups of 8 bytes. Here an example: We have as input data: Data: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88 Key: 11 22 33 44 55 66 77 88 Result: EB 91 31 FE DB E7 61 A9 EB 91 31 FE DB E7 61 A9 We can see that the algo encrypt in groups of 8 bytes, it's the normal, but it has a problem, the groups are independent. In our case, all seems like this problem has ben deleted, because there are not repetitions between various 0x3C. How does it work's this proccess in other known algos...We use another parameter in the encryption proccess, the hash-buffer. * The actors of the actual system are 3: Input data, Key and Algo * The actors in the new system maybe are 4: Input data, Key, Hash-buffer and Algo. The proccess was (all is ficticious): Input Data: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88 Key: 11 22 33 44 55 66 77 88 Hash: 01 01 01 01 01 01 01 01 Result1: 32 94 00 37 04 C9 FB DE The first new thing was that the hash-buffer must be initialized by any way. If you remember for this con be used our new nano 10 with his data 01. We supposed that 10 01 doesn't are encrypted. This two bytes (10 01) DOESN'T BE encrypted why we need them for the decrypted proccess. With the data 01 we initialize the hash buffer. Without this two bytes without encryption, the proccess will give us the status bytes 90 24 or 90 02, because we need the same hash-buffer in the encrypt proccess than in the decrypt proccess. Well, now we will encrypt the second block of 8 bytes. The first we must do is building the has-buffer for this block. Here we make simply a XOR with the key and the result of the encryption of the first block. Hash-buffer of block1: 01 01 01 01 01 01 01 01 Encryption result of block1: 32 94 00 37 04 C9 FB DE Result of the XOR: 33 95 01 36 05 C8 FA DF So we have the next for the second block: Input Data: 11 22 33 44 55 66 77 88 Key: 11 22 33 44 55 66 77 88 Hash-buffer: 33 95 01 36 05 C8 FA DF Result1: 1F A8 78 0D 35 2C 85 6C Final Encrypting Result of the two blocks are: "32 94 00 37 04 C9 FB DE 88 1F A8 78 0D 35 2C 85 6C" We can see that we're using the same key and the same data in the two blocks, but the result is totally distinct, only adding a new actor, the has-buffer. With this simple test's, we can noticed that any more else have been present in the encryption proccess, because with the present algos it's impossible get the result's we can see with the new 0x3C. Maybe a hash-buffer, but who knows it? :b Chapter 3: What now..... If there's anybody who still follows this threat , please think about this.... Idea A: Can we say that the encryption proccess begins on the second byte of the INS 0x3C? Idea B: Can we say that the byte 0 and 1 with data 10 01, are the nano 10 and the data 0x01? Idea C: Can we say that in the encryption of the first block are randomize data who changes between the distinct INS 0x3C? Idea D: Can we say that the encryption proccess use a hash-buffer who will be initialized with any way by the data 01 of the nano 10? My answers are: -Idea A: It's possibely... -Idea B: It's possibely... -Idea C: It's possibely... -Idea D: It's possibely... Of course, there are a lot of other ideas we can have. We only can say at this moment that I only know that I know nothing... 8o At least say, that I think that the only way to crack this new system are: - There are a no-known bug to get keys. - We can do a dump, and so study the system. - Mr. Polanko & Cia tell us how the system work. We can't use brute-force methods because I (we) think that the algo is distinct and at the moment unknown. Another interessant change we still haven't told about is the possibely change of the firmware of our receiver's. Also there are more INS who have change, not only 0x3C, another INS who change is the 0x16: C1 16 00 00 07 ; 00 00 00 0F 00 10 DB 90 00 What will happen's tomorrow.... All was I related you, are extracted from the spanish boards and my spanish friends. At this moment I haven't yet a new "Black Card". I'm waiting for it to test all what I think. Guys, prepare the season's and the phoenix's.... Finally, viewing all I write you here, I think that we don't watch SECA2 a long time ago... Thank's to the reader who have come until here... Salu2 by MushoGraná P.D.: Sorry to write this in English, but I do this why it's a technical text, I prefer it. My German is worster than my English....
Gast Geplaatst: 15 april 2002 Geplaatst: 15 april 2002 het gaat hier nu niet over wel of niet namaak,het wel of niet strafbaar zijn van het maken van cams's,maar iemand heeft mij verteld dat er een wet gestemt was dat iedere pay tv aanbieder (dus ook c* en s*y) een module zou moeten maken waardoor de kijker zonder al teveel kosten zou kunnen overschakelen van de ene pay tv aanbieder naar de andere zonder een andere ontvanger te kopen.Als dit waar zou zijn zou c* en s*y een ci (al of niet land of regiogebonden moeten maken) waarmee abonnee's de pay tv aanbieder via cam zou moeten kunnen ontvangen.Is die wet nu goedgekeurd of is die nog altijd in de maak en zoveel mogelijk tegengehouden door pay tv aanbieders? <img border="0" title="" alt="[Geschrokken]" src="images/icons/shocked.gif" /> <img border="0" title="" alt="[Geschrokken]" src="images/icons/shocked.gif" />
Aanbevolen berichten