 Thema: Open Source CI-Cam ? |
|
|
Hallo,
gibt es eigentlich CI Cams, die sich problemlos
Programmieren lassen und deren Firmware evtl.
sogar Open Source sind ?
Ich bin auf der Suche nach einem billigen Cam,
welches (auf welchem Weg auch immer) ein
CW entgegennimmt und damit intern den
CSA durchführt. Es wäre nichtmal ein Cardslot
notwendig.
Der Hintergrund ist, daß ich einen möglichst
direkten Weg suche, das Cam an ein oscam
zu hängen.
Das einfachste wäre wohl, wenn das Cam eine
RS232 Schnittstelle hätte, über die man einfach
jeweils das CW übergibt.
Ich suche also eine Abkürzung (und billigere
Variante) zu: normales CI Cam + Season Interface
Danke schonmal,
cu Cyberdemon
|
|
| Thema: Daten in defeken Blöcken verstecken (SATA) |
|
|
Erstmal danke für die Antwort 
In der Aufgabenbeschreibung steht explizit drin:
| Zitat: |
Die Seminararbeit soll erläutern, wie solche Sektoren durch
Programmierung moderner SATA-Controller lesbar
gemacht werden können. |
Ich hab das jetzt so verstanden, daß es gerade darum geht
möglichst nah an der Platte (direkte Kommunikation mit dem
Festplattencontroller) diese Blöcke als fehlerhaft zu markieren
und sie nur über den Controller zu lesen/schreiben
(im Prinzip komplett am Betriebssystem vorbei, das Filesystem
wäre dafür zu weit weg).
Ein bißchen weiter bin ich schon gekommen...
hdparm unterstützt den Parameter --make-bad-sector,
der über WRITE_UNCORRECTABLE_EXT das
bad sector flag setzen kann, --repair-sector macht
das Gegenteil. Sieht ja erstmal hilfreich aus
|
|
| Thema: Daten in defeken Blöcken verstecken (SATA) |
|
|
Hallo an alle,
ich habe eine kurze Fragen und hoffe hier steckt jmd. tiefer in der Materie drin als ich
Für ein Informatik-Seminar haben wir die Aufgabe bekommen, Daten in scheinbar defekten Sektoren zu verstecken, um sie anschließend wieder zu lesen. Der Titel der Arbeit lautet "die SATA-Schnittstelle".
Ich habe mich mal kurz in das Thema eingelesen und bin ein wenig verwirrt...
Mein Ansatz ist bisher die GList (festplatteninterne Liste der defekten Sektoren) zu manipulieren und einen fehlerfreien Block als fehlerhaft (incl. Umleitung auf einen Reserveblock) zu kennzeichnen.
An der Stelle frage ich mich nun, ob das in die richtige Richtung geht, da ich meine, daß dieses eher Low-Level Festplattenbefehle sind, die sich von Hersteller zu Hersteller unterscheiden und mit der eigentlichen SATA-Schnittstelle eigentlich gar nichts zu tun haben (außer daß ich evtl. über libata die hardwarespezifischen Befehle an den Festplattencontroller senden kann).
Ist mein Denkansatz völlig falsch bzw. hat SATA eine eigene "bad blocks" Logik ?
Ich habe zusätzlich gelesen, daß Dateisysteme Blöcke als defekt markieren können und diese Markierung auch berücksichtigen (zB kann man einem mkfs eine bad blocks Datei übergeben), aber das wäre ja nun von der anderen Seite nicht auf SATA Ebene (liegt ja auf einer höheren Abstraktionsebene).
Die eigentliche Aufgabe besteht letztendlich darin, für forensische Untersuchungen eine Festplatte vollständig auszulesen (incl. der evtl. fälschlich als defekt gemeldeten Blöcken, dd würde also nicht ausreichen).
Denke ich in die richtige Richtung, oder gehts speziell über SATA viel einfacher (ich frag mich eben die ganze Zeit, was die Überschirft mit dem eigentlichen Thema zu tun hat 
).
Danke schionmal,
cu Cyberdemon
|
|
| Thema: Wie ist CS per Satellit möglich? |
|
|
Die Verschlüsselung könnte es dir aber extrem schwer machen das umzusetzen (zumindest wenn man Standard-Receiver als Zielgruppe auswählt)
Wobei ich doch schon sehr gerne das Gesicht des EOL/SkyDSL/Wasauchimmer Mitarbeiters sehen würde, wenn er MPG-Header in seinem Stream findet, auf den Sender schaltet und anstatt des erwarteten Pixelsturms two girls and one cup in Endlosschleife über seinen Bildschirm flackert (global rickroll anyone ?)
@$80
Klingt doch gut, zumindest weiß ich nun, wo ich meinen nächsten Urlaub verbringe... Woher weißt du, daß die nicht schon auf der Insel sitzen
?
Ist die Frage wie sehr Premiere/Sky daran interessiert ist Geld zu investieren
um das zu stoppen, wahrscheinlich würden sie Sky-Diver schicken um denen
das Handwerk zu legen, aber kommen die dann von oben oder von unten
?
cu Cyberdemon
|
|
| Thema: Wie ist CS per Satellit möglich? |
|
|
Ich hatte vor Jahren (so um 2000/2001 rum) sowas mal angedacht.
Damals gab es einen Internet-via-Sat Anbieter (ich glaube es war Europe Online) der wie heute auch eben den Internetzugang über Satellit anbietet.
Der Unterschied zu heute war, daß das Ganze unverschlüsselt ablief (
daher kamen diverse Programme auf, die es erlaubten den Datenverkehr der Anwender mitzuschneiden).
Viel interessanter war aber, daß man seinen Internetzugang auch durch Pings testen konnte. Man sendete also ein Ping-Paket an den Europe-Online Server (dessen IP freundlicherweise auf der Homepage zu finden war) und bekam über Hotbird (?) den passenden Ping-Reply zurück (hab den damals über SCSI von meiner DBox1 abgegriffen).
Praktischerweise brauchte man anscheinend nicht mal einen Europe-Online Account dazu
Als meine Pingantwort also den Rückweg über den Satellit gefunden hatte, hab ich mein eigenes Ping-Programm geschrieben, welches nicht nur Müll, sondern sinnvolle Daten in den Ping-Paketen unterbrachte.
Mein Testprogramm diente dazu Dateien von einem Rechner zu senden und an einem anderen Rechner wieder zu empfangen, was auch ganz gut klappte.
Besonders lustig war es, wenn man jpg Dateien damit übertragen hatte und die DBox einfach mal den Transponder anzeigen lies (ja, die erschienen, zwar ein bißchen mit Artefakten vermischt und bruchstückhaft, dann auf dem Bildschirm
).
Dann kam die Idee von einem eigenen Mini-TV Sender auf diesem Transponder auf, was ich allerdings aus Zeitgründen seingelassen hab (wahrscheinlich hätte das auch eine Menge Ärger gegeben...).
Sowas ist heute um einiges schwieriger, weil alle (?) Anbieter verschlüsselte VLANs über ihre Transponder betreiben, aber da gibts sicher viele Möglichkeiten das auszunutzen (zur Not eben mit einem gültigen Account).
Der riesige Vorteil das ganze über Satellit zu machen ist eben (wie schon gesagt wurde), daß ich sowohl (als Betreiber) meine AbsenderIP spoofen kann (gerade bei ICMP (Ping) und UDP sehr gut möglich), aber ich auf der anderen Seite auch keine Liste von ZielIPs benötige (die zurückverfolgbar wäre), sondern einfach einen Broadcast über Satellit mache, die Empfänger bleiben komplett unbekannt (ein Risiko für den Sender besteht allerdings noch, siehe tmbincs Post)
cu
Cyberdemon
|
|
| Thema: Streaming + Camd3 -> starkes ruckeln |
|
|
Jetzt funktioniert alles
Ich habe unter /var/etc die Datei .use_avia_gt_proc angelegt, dadurch
wird das avia_gt_proc Modul durch start_neutrino geladen und daran
lags wohl.
|
|
| Thema: Streaming + Camd3 -> starkes ruckeln |
|
|
Ein klein wenig weiter bin ich nun gekommen...
Eine andere DBox2 die Hardwaretechnisch identisch ist (Nokia 2xi, Avia500)
streamt völlig problemlos, auch mit angebundenem Cardserver.
Meine Vermutung ist nun, daß ich wahrscheinlich auf der anderen Box die falschen ucodes etc. geladen habe, zudem fehlt mir da das avia_gt_proc Menü, wobei ich jetzt noch nicht geguckt hab ob das gar nicht erst in der Neutrino-Version drin ist, oder einfach das avia_gt_proc Modul nicht geladen wurde. Ich denke mal eins von beiden wirds sein
Zur Not kopiere ich das komplette Image auf die Box.
cu Cyberdemon
|
|
| Thema: Streaming + Camd3 -> starkes ruckeln |
|
|
Kleines Update:
Ich habe jetzt mal den Datenverkehr mitgeloggt und am NW-Traffic
kann es eigentlich nicht liegen (der Stream kommt mit ca. 5MBit und
eine CW-Anfrage besteht aus 2 UDP-Paketen die alle 10 Sekunden auftreten,
zudem sollte der Stream ja auch nur dann jeweils abreißen).
Gestern hab ichs auch mal mit dem CCcam getestet, was zum gleichen
Ergebnis geführt hat.
Insgesamt führt mich das jetzt wieder zur CPU-Last, aber warum funktioniert
Camd3 + Streaming wunderbar wenn es über den internen Slot auf die Karte zugreift (macht Camd3 noch so viel nebenher, oder bringt das CW-schreiben auf den GTX das Streaming aus dem Konzept) ?
Hat irgendjemand Erfahrungen mit Streaming + Dbox2 + irgendeinem (Camd + Cardserver) ?
Danke,
cu Cyberdemon
|
|
| Thema: Streaming + Camd3 -> starkes ruckeln |
|
|
Hallo,
ich habe mal wieder ein kleines Problem und hoffe auf Hilfe
Ich würde gerne Hausintern über einen MPCS eine Karte sharen,
was auch soweit Problemlos zu klappen scheint. Auf der DBox2
greift eine Camd3 auf den MPCS zu und dekodiert das Bild, soweit
alles prima.
Das Problem ist jetzt, daß vor kurzem mein TV kaputtgegangen
ist und eine Neuanschaffung erst für später geplant ist (ein
Umzug steht bevor und bis dahin will ich mich anderweitig
über Wasser halten).
Die bisherige Lösung ist das Streaming von der DBox2 zum
Laptop+MPlayer/VLC.
Das Problem welches nun auftritt ist, daß sobald ich gleichzeitig
Streame und die Camd3 von der Box auf den MPCS im LAN
zugreift das ganze so stark ruckelt, daß kein Bild mehr ankommt.
Schiebe ich die Karte in den internen Slot und Streame dann
habe ich einen sauberen Stream (auch mit der Camd3).
Greift die DBox2 auf den MPCS zu, streamt aber nicht, scheint
dies auch zu klappen (ich habe auf den Cinch-Ausgängen der
DBox Ton, also dekodiert sie den Sender).
Sobald dann eben zusätzlich der Streamts angeworfen wird,
habe ich nur noch zerstückeltes Audio an den Cinch-Ausgängen
und der Stream kommt gar nicht erst an.
Meine Vermutung ist nun daß die 10MBit Half-Duplex Karte der
DBox2 überlastet ist und gerade das Half-Duplex die Probleme
macht. Auf der anderen Seite sollte doch nur ca. alle 6 Sekunden
ein neues CW angefordert werden, so daß der zusätzliche
Datenverkehr doch sehr gering sein sollte.
An eine CPU-Überlastung glaube ich auch nicht, top zeigt an
daß alles recht gut aussieht.
Was macht die Camd3 denn, wenn Sie übers Netzwerk zugreifen
soll, was dieses Verhalten auslösen könnte (doch CPU-Last,
NW-Last ?).
Wenn ich sicher wüßte daß es am Half-Duplex läge, würde ich ja
mal das Full-Duplex Mod in Angriff nehmen (wobei ich beim Router
leider nicht den Port fix setzen kann).
Vielleicht liegt ja auch an was völlig anderem.
Hat da jmd. eine Idee ?
Danke schonmal,
cu Cyberdemon
|
|
| Thema: Sharen im Originalslot der DBox2 ...doch möglich ? |
|
|
Hallo,
es heißt ja immer, daß es nicht möglich wäre eine Karte die sich
im Originalslot (also nicht Multicam oder am ComPort) der DBox2
befindet zu sharen.
Ich frage mich gerade warum das so sein soll.
Daß camd2 auf den Originalslot zugreifen kann ist relativ klar,
aber auch camd3 schafft dies.
Camd3 benutzt (ab einer Version 3.6-irgendwas) den internen
Bus des gtx Devices (das gibts evtl. nur auf Nokia Boxen, wenn
ich mich da richtig erinnere). Die gefundenen CWs werden
in einen 4096 großen Buffer gepackt (in dem weitere 16 Bytes
auf 0xff gesetzt sind und der Rest auf 0x00) und an
/proc/bus/gtx gesendet.
Kann man jetzt nicht einfach hingehen und diese Werte
abgreifen (die einfachste Lösung wäre den Dateinamen in
der camd3 abzuändern auf ein Loggerprogramm, welches die
CWs anschließend zu /proc/bus/gtx durchschleift) ?
Und das ist dann der Zeitpunkt, an dem ich wieder mit dem
ganzen Card-/Camcrypt Kram durcheinanderkomme...
Im Source einer alten MGCamd-Version sieht man, daß nachdem
ein gültiger Key gefunden wurde, auf diesem die Funktion
SessionKeyCrypt angewendet wird. Danach erfolgt die Berechnung
der Bytes 4 und 8 (Checksumme) des endgültigen CWs, welches
an den CSA übergeben wird, genau diesen Wert würde man dann
mit dem zwischengeschaltetem Programm abgreifen können.
Wenn ich jetzt in meinem Loggerprogramm z.B. per UDP diese
16 Bytes an eine andere DBox (bzw. einen anderen Receiver)
übergebe und die an geeigneter Stelle ebenfalls auf /proc/bus/gtx
schreibe, sollte ich dann nicht auf der zweiten Box ebenfalls ein
Bild bekommen (nach evtl. zuvor nötigen Initialisierungen) ?
Mich wundert einfach dabei die Aussage daß CW-Sharing mit dem
Originalslot nicht möglich wäre...
Wo liegt mein Denkfehler ?
Danke,
cu Cyberdemon
|
|
| Thema: Signatur der cam-alpha.bin |
|
|
Das setzt dann allerdings einen absolut sicheren (nicht möglich) Signaturüberprüfungsprozess voraus. Meine Frage zielt eher darauf ab, wie genau diese Prüfung funktioniert, wer sie durchführt und wo sich die Daten dafür befinden. Wenn das alles intern im SEC passiert (wovon leider auszugehen ist) ist es leider nicht mit vertretbaren Aufwand möglich daran irgendwas zu ändern.
Ich würde einfach gerne wissen, wie genau die Überprüfung funktioniert und ob dabei vielleicht Fehler gemacht wurden (vgl. Einsatz von strcmp statt memcmp bei der Wii).
Daß es nach all den Jahren noch nicht möglich ist die cam-alpha zu patchen macht es leider sehr unwahrscheinlich Schwachstellen zu finden, oder war
damals einfach die Lösung Multicam über den Modemport so bequem und ausreichend, daß gar nicht mehr groß gesucht wurde ?
Ich finde es sehr beeindruckend, falls Betaresearch es wirklich geschafft hat ein im höchsten Maße sicheres System (der SEC) zu implementieren das keine einzige (relativ leicht ausnutzbare) Schwachstelle hat.
Ich würde einfach nur gerne wissen, ob sich jmd. damit ernsthaft und länger auseinandergesetzt hat, weil die Informationen recht spärlich sind.
edit: das Posting bezog sich auf die erste Antwort, während des Schreibens gabs wohl weitere Antworten
Danke, das hatte ich ja schon vermutet 
|
|
| Thema: Signatur der cam-alpha.bin |
|
|
Hallo,
ich habe mal eine Frage zur cam-alpha.bin.
Es ist ja bisher nicht möglich die cam-alpha.bin zu patchen,
da diese verschlüsselt und signiert ist.
Ich habe gelesen, daß wohl mittlerweile einiges über die
Verschlüsselung bekannt ist, jedoch darüber bisher keine
weiteren Informationen gefunden.
Wenn das stimmt, bliebe noch das Problem der Signierung.
Weiß jmd. wie die Signatur aussieht (welches Verfahren) und
wer die Signatur letztendlich prüft (der SEC selber ?).
Wenn es sich um ein Public-Key Signaturverfahren handelt,
müßte ja der Public-Key irgendwo hinterlegt sein, mit dem
abgeglichen wird (OTP, wieder der SEC ?).
Wäre es möglich einen eigenen Public-Key dort einzuschleusen
(ok, wird relativ unmöglich, wenns im Chip sein sollte) so
könnte man ja wieder selber signieren.
Wie gesagt ich finde da bisher nur sehr wenig Infos drüber
(daß es keine Datenblätter gibt ist schon klar, aber auch
sonst findet man fast nichts), hätte da jemand weitere
Einsichten zu dem Thema
?
cu Cyberdemon
|
|
| Thema: OpenSource Softcam für die Dreambox ? |
|
|
Hi,
erstmal danke
Das mit "scam ?" hatte ich schon ausprobiert, allerdings
weiß ich eben nicht, ob der mir normalerweise einen ATR
ausgeben sollte, wenn die Karte einen gemacht hat.
Was ich damit erreichen will ist, ein aktuelles scam auf einer
DBox2 laufen zu lassen. Die neueren Scam-Versionen können
ja auch Unitymediakarten initialisieren, und leider schafft dies
bisher kein anderer Emu/Cardserver (soweit ich weiß).
Ich habe gehört, daß aber die neuen Scam Versionen keine
Comport unterstützung für externe Reader mehr haben,
was mir für meine DBox ein wenig im Wege steht.
Daher war meine Idee nun, ein Kernelmodul zu schreiben,
welches man auf der DBox laden kann, und das den
/dev/sc0 Node zur Verfügung stellt, wobei es die Aufrufe
entsprechend auf den externen Kartenleser umlenkt.
Blöderweise ist das mein erstes eigenes Modul und da Scam
sehr wenig sagt, weiß ich eben nicht, ob ich auf dem richtigen
Weg bin. Deswegen die Idee mit dem OpenSource Programm,
so daß man besser testen kann.
Danke,
cu Cyberdemon
Btw. kennt sich auf dem Gebiet "Kernelmodule" evtl. jmd. gut aus ?
Scam benutzt wohl die epoll-Aufrufe und mir ist noch nicht ganz klar,
wie das mit dem aufwecken und bereitstellen der Daten funktioniert,
bzw. wie ich überhaupt Daten in die Warteschlage einstellen kann.
|
|
| Thema: OpenSource Softcam für die Dreambox ? |
|
|
Hallo,
gibt es für die Dreambox irgendein Softcam, Emu, etc. der OpenSource ist ?
Ich versuche zu verstehen, wie genau die Smartcard-Reader (/dev/sci0 und
/dev/sci1) angesprochen werden, leider fehlt es an Beispielen.
Im Prinzip bräuchte ich erstmal nur ein Programm, welches auf die /dev/sci? Devices ansteuert und die Karte zu einem ATR überredet (ich versuche meinen eigenen sci-Treiber zu schreiben und teste den derzeit mit Scam, allerdings ist Scam sehr kommentarlos aus der Konsole).
Danke,
cu Cyberdemon
|
|
| Thema: /dev/sc0 unter DBox2 simulieren |
|
|
Hallo,
mittlerweile ist es für die Dreambox anscheinend kein großes Problem mehr
mit den UM01 Karten umzugehen. Ab Version 3.44 wurde diese Unterstützung in Scam implementiert. Blöderweise fiel irgendwann der Support für die DBox2 weg.
Ich würde nun gerne die Scam 3.47 (PPC Version) dazu bewegen, mit dem externen Cardreader am Comport meiner DBox2 zu reden.
Wie es aussieht spricht die Dreambox über das Device /dev/sc0 bzw. /dev/sc1 mit der Karte, welches ein, über einen STB04xxx von IBM angebundener, USB-Cardreader zu sein scheint.
Meine Idee wäre nun im /dev Verzeichnis der DBox ein virtuelles Device zu basteln, welches das Protokoll umsetzt und den Datenverkehr nach /dev/ttyS0 umleitet.
Hat damit jemand Erfahrung und könnte mir näheres zu dem Protokoll der sci-Cardreader der Dreambox sagen ?
Vielen Dank,
cu Cyberdemon
|
|
| Thema: Conax geknackt - auch Premiere betroffen! |
|
|
 03.02.2009 14:58 |
Forum: Conax |
Hi,
ist es nicht einfacher zunächst zu untersuchen, wie die QBox die Data.bin decodiert ? Das Diablo sollte das ja sehr ähnlich machen.
Sehr weit im QBox Code bin ich allerdings auch noch nicht drin,
ich kann nur sagen (was hier teilweise schon steht), daß ab Adresse 0x1FE0 (in der Data.bin) 384 Bytes gelesen werden, dann folgen einige noch nicht analysierte Funktionen und anschließend werden 16-Byte, dann 32-Byte Blöcke gelesen.
Weiß dazu schon jemand näheres ?
|
|
| Thema: Conax geknackt - auch Premiere betroffen! |
|
|
| 29.01.2009 09:15 |
Forum: Conax |
Hi,
ich hab die Underworld145 auch mal entschlüsselt, damits einheitlich bleibt
hxxp://uploaded.to/?id=q4q06r
und die ARM bzw FPGA Firmware ist hier:
hxxp://uploaded.to/?id=jkfer4
Allerdings sind die beiden noch in einem großen, verschlüsseltem
Filehaufen drin, die müssen noch durch die Process_Programming_File_Update
Funktion entschlüsselt werden.
Die Firmware wird in Blöcken von 48 Bytes Länge übertragen.
Jedem Block wird die aktuelle Adresse vorangestellt.
Die Blöcke werden mit einem xor über den CryptKey entschlüsselt (Crypt_Message Funktion), wobei ich noch nicht gefunden haben, wo
der Cryptkey gesetzt wird.
Edit: Der Cryptkey scheint nur für die Übertragung wichtig zu sein (wird von
einem Zufallsgenerator erzeugt und dem Cam mitgeteilt). Die Entschlüsselung der ARM und FPGA Firmware muß im Cam passieren
|
|
|
