V6 Kaart niet meer te extracten ???

[Dr.Z]

Wat er inmiddels gebeurt kan ik erg slecht verklaren, maar het lijkt er op dat de kaart aan en uitgeschakeld word bij C+, en dat zonder dat je beeld op zwart gaat.

Zo'n vergelijkbaar idee krijg ik hier met het loggen tenminste!

Het ene moment zijn de key's geldig en een minuut later niet meer.

Vreemd hoor.

 

[Dr.Z]

Op dit stukje gaat het fout:

Incoming EMM Instruction

C1 40 03 80 58

Received Encrypted Data

EF 04 E6 F6 B5 49 FF 63 7B C3 20 32 BD A0 9F 0B

C6 2B 18 5F F9 C0 70 AF 94 9A B4 C9 79 84 78 80

8F 0C BB 9D D8 14 7A 84 E4 B8 FF D5 6D 3D 65 62

81 46 5B DB 31 20 FC 5F 77 A1 3D 9D 12 D9 57 7A

88 D0 87 6A 24 5A F4 C1 83 9B A0 E6 E4 3A AA F0

89 B7 C2 8B E9 6C F2 0D

90 1D-Signature Wrong!!

Incoming ECM Instruction

C1 3C 03 0C 2B

Received Encrypted CW

71 00 00 19 07 D2 00 0A 12 00 27 19 4A 13 01 13

09 D1 94 B9 0B 0A CA 5D 6A 5E DC 44 18 BC 5A B9

1B 00 82 AF 59 BE E8 CF E8 C6 3B

90 00

Bundle/Bitmap : 00 00 00 00 00 00 02 02

Signature OK!!

Request Decrypted CW

Is er iemand die mij kan helpen met het ophelderen van deze gebeurtenis?

 

[Kcplus]

Ik denk dat de mk00 die je in wallbanger hebt ingevoerd NIET past bij de UA waarover deze Ins wordt gestuurd (of omgekeerd, zie mijn vorige posting).

De gewone key-updates die WEL doorkomen bij jou zullen dan wel de reguliere 81 4E updates zijn.

Je kunt proberen de hierboven door jou geposte Ins eens te decrypten met een andere mk00, om te zien of er iets van te maken valt. Gelet op de LN- byte van 58 ben ik wel benieuwd welke data c.q. nano's er "extra" worden verzonden.

Het is al weer een tijdje geleden dat ik zelf heb gelogd. Ik weet niet beter dan dat LN=52, maar ja, de tijd staat niet stil .

 

[Kcplus]

Voor alle duidelijkheid:

Ins C1 40 03 80 58

.............. 90 1D

C1 40 = EMM Ins

03 = provider op plaats 03 in wallbanger

8_ = superencrypted

_0 = MK00 van provider 03 (zie hiervoor)

58 = lengte-byte

....

90 1D = primary key (00) is fout!

Of in termen van gelijke strekking....

 

[Dr.Z]

@kcplus, ik heb inmiddels alle andere providers uitgezet in WB om te kijken of die aanwezigheid soms de rarieteit aanmaakt maar dat bleek niet het geval.

Op plaats 3 van WB staat ID0003 en ID0019 op 9.

Met mijn orginele MK's gaat het loggen wel goed dus lijkt het alsof er duidelijk met de specifieke V6 kaart word gesleuteld.

Even tussen haakjes, de mk's van de V4 kaart, die op de kaart zelf verdwenen waren, zijn inderdaad niet meer geldig,en heeft deze kaart de nieuwe mk's gemist door de bpm lock.

Maar beste kcplus, is het niet zo dat er een complete serie kaarten met exact dezelfde MK's in omloop zijn met alleen een afwijkende PPUA?

En dan is de afwijking van de PPUA volgens mij beperkt tot te laatste bit waar WB ,als ik mij de technische kant van WB nog goed herriner, niet naar kijkt.

Of loop ik inmiddels met verouderde informatie rond in mijn hoofd?

 

[Dr.Z]

@kcplus, als ik jouw verhaal toepas betekent het dan dat de lengte van de byte niet klopt? ( de 58 instructie)

En dat de MK00 van provider 0019 dus niet meer geldig is?

 

[Kcplus]

De door jou ontvangen instructie komt binnen over de UA en niet over de ppua!

Met plaats 03 bedoel ik verder dat dát dan de derde provider na S*ca is die je in wallbanger hebt aangevinkt (dus actief is).

De mk00 kan best nog geldig zijn, maar ik heb het gevoel dat je per ongeluk met een verkeerde UA aan het loggen bent (die dus niet bij die specifieke mk00 van die provider hoort).

Je kunt een UA bij S*ca invullen én bij provider 0019 kun je ook een UA kwijt. Deze laatste is echter in wallbanger pas actief als je daarvoor kiest in het menu providers (Cardserial/UA on: )!

En je kunt maar met één UA tegelijk loggen ; dus kies de juiste.

De actieve UA kun je terugzien meteen na een reset in wallbanger na de C1 0E 00 00 08.

Verder is het volgens mij zo dat iedere ppua "xx xx xx cc" een eigen mk01 heeft. Maximaal 256 CustWP (op de "cc"-plek) per groep dus. En wallbanger let inderdaad niet op de CustWP.

Zeker weten doe ik het niet, maar ik dacht dat de mk00 wel kaartspecifiek was. Maar nogmaals die wordt gebruikelijk slechts over de UA benaderd.

De lengtebyte is natuurlijk niet fout, maar de provider zendt klaarblijkelijk nog 6 extra bytes in de instructie mee: dat kunnen databytes en nanobytes zijn.

Ik hoop dat je toch een valid mk00 kunt vinden, want ik ben best benieuwd wat er nog voor extra data worden verzonden.

 

[Kcplus]

@drz

Ik ben denk ik ten aanzien van jouw logresultaten dicht bij een oplossing gekomen.......

Vanmiddag ben ik zelf gaan loggen met wat V6 kaartgegevens.

Inderdaad komen er naast de normale maandkey-updates (Ins C1 40 01 81 4E) ook speciale EMM's voorbij: Ins C1 40 01 80 58.

Bij één kaart zag ik twee verschillende EMM's van die soorts "langskomen". En wallbanger geeft dan aan 90 1D: signature wrong.

Goed, je wist al dat ik dacht dat je met de verkeerde UA aan het loggen was. Maar ik wist zeker dat ik het nu goed deed! .

Dus had deze foutcode een andere oorzaak.......

Het proggie Satangel dus even van stal gehaald, en de beide gecrypte data van de 80 58 Ins met de bekende MK00 van Provider 01 gedecrypt. Dat ging PRIMA!!!

De volgende gegevens kwamen naar voren:

Gelet op de LN-byte 58 moesten er 88 bytes data en nano's zijn.

In de eerste Ins als volgt:

Nano 80 met 8 bytes 00 00 00 00 00 00 00 00

Nano 90 met index 51 en 8 bytes voor de nieuwe primary key 01

Nano 91 met index 51 en 8 bytes voor de nieuwe sec. key 01

Nano 21 met 2 bytes voor de datum 19 7E

Nano 90 met index 5C en 8 bytes voor de maandkey 0C

Nano B0 met 11 bytes voor dat "rare" Seca PPV-record

Nano 90 met index 5D en 8 bytes voor de maandkey 0D

Nano 90 met index 5E en 8 bytes voor de maandkey 0E

Nano 41 met 4 bytes voor de nieuwe ppua

Nano 82 met 8 bytes signatuur

Totaal 10 Nano's en 78 databytes.

De tweede Ins is als volgt te ontleden:

Nano 00 onbekend

Nano 00 onbekend

Nano 10 gevolgd door te deleten key met index 03

Nano 10 gevolgd door te deleten key met index 02

Nano 80 met 8 bytes 00 00 00 00 00 00 00 00

Nano 90 met index 51 en 8 bytes voor de nieuwe primary key 01

Nano 91 met index 51 en 8 bytes voor de nieuwe sec. key 01

Nano 21 met 2 bytes voor de datum 19 7E

Nano B0 met 11 bytes voor opnieuw dat "rare" Seca PPV-record

Nano 00 onbekend

Nano 90 met index 5C en 8 bytes voor de maandkey 0C

Nano 00 onbekend

Nano 00 onbekend

Nano 90 met index 5D en 8 bytes voor de maandkey 0D

Nano 00 onbekend

Nano 41 met 4 bytes voor de nieuwe ppua

Nano 82 met 8 bytes signatuur

Totaal 11 bekende en 6 onbekende Nano's en 71 databytes.

Ik denk dat wallbanger de B0 nano niet aan kan, en daarom de gehele instructie als onleesbaar beschouwt; wallbanger zegt dan dat de key niet juist is, maar dat blijkt dus geen juiste conclusie!!

We weten nu dus waar dat Seca PPV-record bij provider 01 vandaan komt. De functie? Geen idee.

Toch denk ik dat dát record er de oorzaak van is dat de V6 niet meer zo gemakkelijk zijn keys prijsgeeft.

We zouden eens kunnen testen met zo'n V6 eerst met dat record en dan zonder. Het record moet m.i. namelijk gewoon te verwijderen zijn.

Wat ik wel vreemd vind is dat de PBM op 8x00h wordt gesteld.

Nader onderzoek is hier op zijn plaats.

Zo, ga ik nu eens loggen met mijn nieuwe setje ppua/mk01 .

 

[Kcplus]

@drz

Het nieuwe setje ppua/mk01 loopt als een trein .

Als ik dit hele topic nog eens teruglees, en de geschiedenis van jouw V6 weer voor de geest krijg, denk ik dat op enig moment jouw kaart onbenaderbaar is geworden doordat in het startuprecord een exacte kopie van de mk00 S*ca (index F0) terecht is gekomen.

Kijk dat nog eens na in jouw MKF-logfiles van vlak voordat je kaart overleed, alsjeblieft.

Dit probleem blijkt zich inderdaad vaker voor te doen met kaarten die ofwel een pbm-lock hebben of waarvan het bugrecord gewoon 1556 niet (meer) op de kaart verschijnt.

En sinds ik dat nieuwe record 50....E1 op de kaart tegenkom is dit verschijnsel vaker voorgekomen.

Het is nu toch mosterd na de maaltijd , maar ik weet zeker dat de kaart op dat moment nog te repareren zou zijn geweest.

Ik heb inmiddels meerdere kaarten die dit euvel hadden kunnen helpen herstellen.............

Wordt die geschiedenis van jouw V6 toch wat logischer.

 

[Dr.Z]

@kcplus, ik zal dat log even opsnorren en hierzo publiceren.

Ik kan natuurlijk de gehele log ongecensureerd plaatsen zodat ook de wat minder fanatieke hobbyist een verse MK00 en MK01 serie heeft, maar denk ik dat dat niet op prijs word gesteld.

Zelfs niet als deze keys niet meer ,of tijdelijk geldig zijn.

Ik zal hem daarom maar censureren voor de fatsoenlijkheid. )

Er valt dus (eindelijk) weer wat te hobbyén!!!!!!!!!!!!!!

 

[rienk]

zit hier toch nog wat te kl**ten maar is het mischien mogelijk dat die blauw grijze kaarten een wat lagere spanning nodig hebben???

zit hiet met een phoenix en daar komt zo'n 5 volt af teminste de spaningsregelaar 7805 zit er op dus meer zal het dan ook niet worden maar is dit misschien nog teveel ?? iemand een idee ??

 

[Dr.Z]

De logfile is onderweg, kcplus, nog even geduld omdat het filetje in mijn expiriment pc opgeslagen is en ik deze nog niet kan benaderen wegens een VGA probleem......(de kaart had ik verkocht)

@rienk, de V6 kaart is voor de RTL4 update nog keurig uit te lezen en daarna niet meer dus lijkt het mij dat het echt een software probleem is.

Tenzij C+ inmiddels in staat is om de hardware te wijzigen in hun ontvangertjes, wat mij niet waarschijnlijk lijkt.

 

[jdelamain]

Ik had hier nog een splinternieuwe V6 kaart liggen en uit het hoesje gehaald. Ook hier was niets mee te beginnen geen backdoor key helemaal niets. Totdat ik het voltage terug bracht van 12 naar 6 volt. Ik kon er een 06 key opschrijven en ook de 00 key was tevoorschijn te toveren. Maar de ravage was al aangericht. Er waren een aantal rare key's op de kaart bijgeschreven en MKF vroeg om een startup reccord. Ik zie een aantal overeenkomsten maar ik heb nog niemand over het voltage gehoord. Met de V4 kaart heb ik nooit problemen gehad (altijd 12 volt) Misschien dat die V6 kaart daar meer gevoellig voor is.

 

[Kcplus]

@drz

Nadat ik jouw logfiles heb bestudeerd kom ik tot de conclusie dat jouw V6 kaart ZEKER nog te repareren zou zijn geweest.

Je hebt er helaas niets meer aan, maar gelet op de cardrecords in jouw laatste logfiles was er sprake van een dubbele MK00 op de kaart in record 0001 in plaats van het startuprecord en nog altijd op de plaats waar die thuishoort in record 0003.

Deze situatie treedt wel vaker op bij de extractie van een V6, maar is zeker nog te herstellen.

Voor meer info over de extractiemethodiek van een V6 lees de faq van Satgirl (het origineel in het Frans, maar op het www is een vrije vertaling van mijn hand aanwezig). Ook de hersteloperatie staat daar beschreven. De link kan/mag ik hier niet plaatsen (denk ik), maar zoek eens op de bekende sites van Nederlandse sathobbyisten.

Jouw 80 58 Log heb ik kunnen decrypten. De uit de logfiles verkregen gegevens heb ik je al doen toekomen...........

Suc6 met je nieuwe setje ppua/mk01

@rienk @jdelamain

Ik heb nu al heel wat logfiles gezien van kaarten waarbij het extracten niet (meer) lukte.

Ik heb zelf een wat oudere V6 kaart, die ik altijd met 12V heb "behandeld". Zowel met de auoextract van MKF, SecaRL danwel de handmatige methode heb ik nimmer problemen gehad.

De enige overeenkomst in deze logfiles is dat op enig moment tijdens de extractie GEEN hulpproviders meer worden aangemaakt welke zorgen voor de aanwezigheid van het record 15 56 op de kaart. Hierdoor wordt extractie feitelijk ONMOGELIJK.

Waarom deze providers (vaak 0050 en 0051) niet meer worden aangemaakt, m.a.w. waarom MKF deze procedure op enig moment overslaat is mij nog niet duidelijk.

Ik denk inmiddels dat het "nieuwe" record 50...E1 ("S*ca PPV Record") er toch niets mee te maken heeft, daar blijkt dat dit record al op de kaart aanwezig is in situaties dat de extractie nog WEL lukt.

Wellicht dat het te maken heeft met het aanwezig zijn in de MKF-file van reeds bekende keys, die met de Ins C1 5A als valid worden gezien, zodat extractie door de soft niet "nodig" wordt geacht.

Het vervolgens aanhoudend proberen toch te extraheren zou dan tot die af en toe optredende fout bij de extractie kunnen leiden. Af en toe in die zin, dat soms ook geen backdoorkey meer wordt aangemaakt, dat de extractie van de MK00 bij P00 toch start, doch de soft vervolgens geen MK meer "alleen op de kaart" heeft om het startuprecord terug te kunnen zetten.

In die situatie (dus met de dubbele F0 bij P00 op de kaart) is kaart niet meer benaderbaar, anders dan door het handmatig uitvoeren van de V6 extractiemethode, waardoor record 0001 weer vrijkomt, en de F0 in record 0003 weer "gewoon"valid is.......

Iemand een ander idee??

 

[Dr.Z]

@kcplus, heb je al eens een oudere versie van mk4 geprobeert?

Er met welke progger kun je het voltage regelen?

Er zit in mijn phoenix een 5 volt stabo maar ik denk dat je de 12 volt spanning uit de seriëele poort bedoeld, en niet de werkspanning van de programmer.

Ik moet nu toch echt aan een nieuwe progger geloven als ik dit zo lees!

Ondertussen ben ik al dagen aan het loggen met de nieuwe keys, maar ik ben nog geen vreemde dingen tegen gekomen die stukjes van het nieuwe systeem aan het licht moeten brengen.

Misschien een een ander logprogramma proberen waar vriend Ghost mij op geattendeerd heeft!

 

[jdelamain]

In de programmer zit inderdaad een 5 v stabilisator daarom heb ik ook altijd 12 volt gebruikt.

Getracht een backdoor 06 op de kaart te zetten dat lukte maar er gebeurde van alles. Er werd een tweede 00 key op de kaart gezet en ook was er een 0B key er was niets meer mee te beginnen. Wanneer ik een key wilde verwijderen vroeg MKF om een startup reccord. Nadat ik het voltage naar 6v had teruggebracht was de kaart weer aanspreekbaar en als mosc te gebruiken. Het enige wat niet meer kan is de kaart extracten en er ontbreekt een sec. 00 key van Seca. De kaart is zelfs AU.

Als het zo is dat de V6 kaart gevoelig is voor spannings verschillen kan hij bij het uit de decoder halen beschadigd zijn en daardoor ook niet meer te benaderen.

 

[Kcplus]

@drz

Ik heb alle MKF-versies geprobeerd, vanzelfsprekend.

Mijn eerste V6 heb ik "ontdaan" van de keys met versie 4.2, volledig volgens de handmatige methode op basis van de Satgirl.doc, eigenlijk de eerste theoretische benadering van de V6 extractie.

Alleen heb ik nooit die problemen ervaren die andere hobbyisten wel tegenkomen. Dus ik kan die situaties niet afzetten tegen mijn eigen ervaringen.

Heb ik steeds mazzel gehad, of doen anderen toch iets niet (helemaal) goed?

Ik weet het niet. Testen met een V6 kan ik op dit moment echter helaas niet....

En de schrijver van MKF ontwikkelt het proggie niet verder, omdat hij denkt dat het proggie nu "klaar" is. Via via heb ik het probleem destijds onder zijn aandacht gebracht, maar daar is bij mijn weten nooit op gereagreerd. Misschien omdat het geen probleem van MKF is (zoals gezegd, ik heb het dan ook zelf nooit meegemaakt) maar toch een probleem van "op welke knoppen drukt men" .

Naar mijn mening krijg je met je nieuwe keys/ppua alleen de C1...81 4E Ins binnen. De EMM waar het om gaat is de 80 58, en die heb ik al voor je gedecrypt. Er is waarschijnlijk ook bij jou nog een andere 80 58 (zie eerder), maar ook die zal niet tot nieuwe inzichten leiden. Anders dan dat dat 50....E1 record over nano B0 wordt gezonden. En ik weet echt niet wat dat record allemaal inhoudt of op de kaart "gedaan" krijgt. Nogmaals op een Italiaanse V7 heb ik dat ding eens eerder gezien, maar bijvoorbeeld in Spanje is daar nog niet over gerept (althans voor zover mij bekend).

O ja, die PBM op 00 00 00 00 00 00 00 00 (zie eerder) blijkt te maken te hebben met dat specifieke abootje . Dus toch geen reden tot bezorgdheid........

Bij jou stond-ie in de 80 58 immers op de te verwachten waarde.

@jdelamain

Alles wat er met je kaart gebeurd is heeft te maken met de methodiek van de V6 extractie.

Ik raad je aan op zoek te gaan naar de Satgirl.doc of de vertaling, dan weet je wat er precies plaatsvindt.

Ik wil je ook wel wat info (of een link) per PM geven.

Het AU zijn van de kaart heeft op zich niets met de (nog) aanwezige keys bij P00 te maken.

Dat jouw kaart niet meer te extracten is zou ik niet durven te bevestigen.

Geef eens aan (evt. via PM) hoe jouw recordindeling nu is?

Ik weet bijna zeker dat ik die indeling weer op orde kan krijgen.

Vervolgens kunnen we eens testen of een extractie met bijvoorbeeld SecaRL1.85 wel mogelijk is, dan wel met de handmatige invoer van de diverse Ins om tot het gewenste resultaat te komen.

Als dat allemaal ook niet lukt, dan komt jouw conclusie dichterbij.

Wellicht kunnen we dan vaststellen dat de al dan niet aanwezigheid van dat "nieuwe" record 50...E1 er al dan niet iets mee te maken heeft, maar nogmaals, dat lijkt mij inmiddels (na bestudering van de diverse logfiles) sterk......

Waar blijven de echte S*ca specialisten? Ideetjes?