Modifiera Alex2 för SmartWI-liknande funktion

Har läst att utrustning som SmartWI, Clone+ och Card Caster har stöd för att dela kanaler mellan parade kort och mottagare alternativt CI/CI+ moduler.
Vad jag förstår uppnår den här typen av utrustning detta genom att läsa original-programkortet i en master-box som sedan kommunicerar trådlöst med ett antal klient-kort. Denna kommunikation lyckas, till skillnad från vanliga kortdelningsprotokoll som newcamd eller cccam, även att överföra data som möjliggör parning. Eftersom denna parningsdata är krypterad antar jag att SmartWI-liknande utrustning helt enkelt kommunicerar rådata mellan kortläsare och klient-kort.

Min fundering är om det är möjligt att modifiera mjukvaran i Alex2 för att skapa en liknande lösning, fast trådbunden. Alex2 kommunicerar i sin nuvarande form endast med newcamd-protokollet och kan därmed inte överföra data som krävs för parning. Såklart krävs det även någon ny form av kortserver motsvarande en "master-box" som kan läsa rådata från programkortet och sedan kommunicera denna data till de modifierade Alex2-klienterna över ett LAN. En vanlig kortserver med traditionell kortservermjukvara, exempelvis OSCam, borde kunna användas för att läsa programkortet, men OSCam stödjer inget protokoll för att kommunicera rådata till klienterna vad jag vet. Lyckligtvis är OSCam open source :)

Detta är såklart bara en fundering jag har. Jag saknar tillräcklig kunskap för att avgöra om detta ens är möjligt, men jag är nyfiken på vad ni som är mer insatta i tekniken tror. Är det möjligt? Hur avancerat skulle det bli att genomföra?

MVH
Runnerey

Nu tror inte jag att SmartWi och Clone+ m.fl. delar kortet på mjukvarunivå, utan på en lägre nivå.
Min gissning är att den multiplexar rent signalmässigt.
Att ett klientkort får "anslutning" till mastern under en transaktion. Om någon annan klient skickar en förfrågan så ställs den frågan i kö i väntan på att mastern åter blir ledig.
Eftersom ECM bara förfrågas var 10:e sekund, så har varje klient ett antal sekunder på sig att vänta på sin "tur"..

D.v.s. rent logiskt, så springer den runt med kortet till alla klienter minst var 10:e sekund.. (utan att mottagaren reagerar på att kortet har avlägsnat).

Den informationen bådar gott för att en lösning med Alex2 skall kunna fungera. Desto "dummare" mjukvaran i SmartWi är, desto mindre komplex behöver kommunikationen mellan klient och server bli. Bara att överföra bit för bit från ena sidan till andra. Att utrustning som SmartWi m.fl. kör trådlösa signaler spelar ingen roll, jag hade ändå tänkt mig att programkortet skulle läsas av en "vanlig" kortserver, d.v.s. valfri Linuxburk med smartcard-läsare och Ethernet. Det är enligt mig en stabilare lösning att kommunicera över Ethernet LAN än att skicka trådlösa signaler som i bästa fall bara räcker 15m.

För övrigt tror jag det kan finnas en stor efterfrågan på den här funktionen. Har på sistone sett en del säljannonser för Alex2, tror det kan bero på att Alex2 i nuläget egentligen endast kan dela Boxerkort på ett effektivt sätt, alla andra operatörer har infört någon typ av parning som gör Alex2 obrukbar för vanliga användare. Med denna funktion implementerad skulle Alex2 i princip kunna användas för de flesta kodningssystem med parning aktiverat. Det skulle kanske till och med väcka större intresse för Alex2 utomlands.

MVH
Runnerey

Idéen är inte så dum. Det borde vara relativt enkelt att bara ta status på RST och CLK signalerna samt överföra dataströmmen från I/O anslutningen, paketera det på något enkelt sätt och överföra via ethernet.
http://www.cardwerk.com/smartcards/s...ISO7816-2.aspx

Få se om någon tar upp idéen.

RAW-mode..:) Problemet är att man måste buffra anslutningen och vill undvika att starta om kortet mellan växling av klienter..
Ett annat problem är att olika mottagare vill ha olika klockfrekvenser med "mastern".
Klientkorten måste därmed då prata med mottagaren i den av mottagaren önskad frekvens, samt hålla igång "samtalet" med mottagaren i väntan på svar från mastern..
Kanske går att se i källkoden för OSCam om det finns någon "NOP" som kortet kan svara med i väntan på ett riktigt svar..

Buffringen är nog inget stort problem. De flesta dataprotokoll buffrar ju. Däremot är det kanske knepigare med de olika klockfrekvenserna och växlingen mellan olika klienter samt att hålla sessionen igång med väntande klienter.
Nåväl, sammantaget borde det inte vara mer komplicerat än att utveckla en Smartwi eller Alex så vi får hoppas att någon gör det. @mikaelk ;)

+1
Uppenbarligen har danskarna löst det tidigare.
Vore fint med en IP-baserad lösning istället för en trådlös som det är på ovan nämnda produkter. Tror att dom medvetet begränsat produkterna till "lokal" användning..
D.v.s. en implementation av "raw-protokoll" eller liknande i OSCam, samt en klientdel i en enhet som typ. Alex..

Det är väl inget av ovan nämnda system som klarar av videoguard(viasat)?
Och conax pairing över newcamd bör fungera ok. Bara klienten skickar rätt data till cammen vid initiering. Servern måste eventuellt växla mellan olika mode, pairing av/på, men det är inte helt säkert det behövs.
Så sammanfattningsvis så tror jag inte det finns något behov av ett nytt protokoll. Men via kan man nog glömma att kunna hantera på detta sätt, där finns för mycket hinder.

Linux card emulator fungerar med videoguard (viasat).

Citat:

---

Ursprungligen postat av Volvo3

Det är väl inget av ovan nämnda system som klarar av videoguard(viasat)?
Och conax pairing över newcamd bör fungera ok. Bara klienten skickar rätt data till cammen vid initiering. Servern måste eventuellt växla mellan olika mode, pairing av/på, men det är inte helt säkert det behövs.
Så sammanfattningsvis så tror jag inte det finns något behov av ett nytt protokoll. Men via kan man nog glömma att kunna hantera på detta sätt, där finns för mycket hinder.

---

Hej!

Det hade varit grymt om någon kunde ta upp detta!
Jag har en Smartwi Lite men har ett ganska stort hus vilket påverkar den trådlösa överföringen lite då och då.
Kabel åt folket!