[linux-l] *****SPAM***** Hits: 8.1 Hardware ausspionieren (was: DVD Lese-speed begrenzen)

[Steffen Dettmer]

* Axel Weiß wrote on Mon, Mar 06, 2006 at 22:07 +0100:
 [...] 
> Content analysis details:   (8.1 points, 5.0 required)
> 
>  pts rule name              description
> ---- ---------------------- --------------------------------------------------
>  0.1 FORGED_RCVD_HELO       Received: contains a forged HELO
>  1.0 RCVD_IN_NJABL_PROXY    RBL: NJABL: sender is an open proxy
>                             [85.178.227.155 listed in combined.njabl.org]
>  2.5 RCVD_IN_XBL            RBL: Received via a relay in Spamhaus XBL
>                             [85.178.227.155 listed in sbl-xbl.spamhaus.org]
>  0.1 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
>                             [85.178.227.155 listed in dnsbl.sorbs.net]
>  2.8 RCVD_IN_DSBL           RBL: Received via a relay in list.dsbl.org
>                             [<http://dsbl.org/listing?85.178.227.155>]
>  1.7 RCVD_IN_NJABL_DUL      RBL: NJABL: dialup sender did non-local SMTP
>                             [85.178.227.155 listed in combined.njabl.org]

(Ist ja geil, so ein Spamfilter: von dynamischer IP gesendet, gibt 8
Punkte, weil 5 mal Regeln passen 
   - nur leider immer auf den gleichen Fakt :-) 
Versteh' ich da was falsch, oder sind Spamfilter immer noch weit davon
entfernt, ansatzweise brauchbar zu sein oder gar zu funktionieren?)

Content-Description: original message before SpamAssassin
> Da fällt mir der Trick mit dem Dekodieren mitgeschnittener
> Hardware-Kommandosequenzen (in diesem Fall war das JTAG) ein. 

(Was Du nicht alles rumliegen hast :))

> Die zwischen dem Evaluation-Board und dem Windows-Debugger
> ausgetauschten Bytes lagen hexadezimal in Textform vor (von einem
> schnell zusammengezimmerten FPGA-Analyzer in Dateien mitgeschrieben).
> 
> Wie analysiert man das jetzt? Dateigrößen: 92,4 - 268,6 kB. Mein erster
> Gedanke: awk. Als ich dann versucht habe, den JTAG-Automaten durch
> awk-Code in den Daten zu finden, kam mir die Idee, das mit lex und yacc
> (bzw. flex und bison) zu machen. Damit gings dann ganz schnell (über
> Nacht):
> 
> - 67 loc für die lexikalische Analyse
> - 470 loc für den Parser
> - 1052 loc Registerliste (von der API geklaut)
> - 39 loc erweiterte Steuerlogik (Watchdog-Kommandos)
> 
> Mit awk habe ich dann noch die Parserausgaben schöngemacht, und man
> konnte genau nachlesen, was auf der JTAG-Schnittstelle passiert ist.

CooL! Fetzt.

Der Parser parst dann die Hexbytes und "compiliert" das zu was
menschenlesbaren? Klingt nach einer spannenden Idee! Wir haben auch
diverse Loganalyser-Scripte, das ist meist "Perl zu Fuss". Prima Idee,
muss glatt mal gucken, ob das für uns auch was wäre :)

> Achja, gebraucht habe ich das für das von Infineon nicht dokumentierte
> JTAG-Interface für den Tricore, das ich an gdb rangestrickt habe. (Bei
> Interesse erzähle ich auch Details).
(keine Ahnung wo von Du sprichst, aber macht nix)

JTAG ist doch ein Hardware-interface, oder?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.