Es gibt unterschiedliche Ansaetze Werbung zu blockieren. Beliebt sind beispielsweise Werbeblocker in Browsern, wie Adblock fuer Chrome. Doch ich will einen Ansatz vorstellen, der viel weiter unten im System ansetzt und die nicht auf einen Browser beschraenkt ist. Meine Methode soll schon beim DNS-Request ansetzen.

Fuer die technisch weniger versierten Leser moechte ich kurz erklaeren was beim DNS-Request passiert. Der Browser weiss mit einer Adresse wie "example.org" erstmal nichts anzufangen. Was ein Browser braucht um die Webseite aufzurufen ist dessen IP-Adresse. Um diese in Erfahrung zu bringen fraegt er beim System nach, und dieses wiederrum fraegt beim sogeannten DNS-Server nach. Die IP-Adresse vom DNS-Server ist dem System bekannt, so dass dieses dort nachfragen kann. Die DNS-Server selbst wissen ueber "alle" Adressen bescheid und koennen dem System so sagen an welche IP die Anfrage zu richten ist. Diesen Aufruf nennt man DNS-Request.

Genau hier soll mein Verfahren ansetzen. Wenn ich also wuesste, welche Domains von Werbeunternehmen kommen, dann muesste ich nur noch die DNS-Requests umbiegen und schon wird keine Anwendung mehr Werbung laden koennen. Genau dies macht mein Ansatz.
Im Folgenden beschreibe ich, wie man einen DNS-Server aufsetzt, der lokal auf dem Rechner laeuft. Dieser wird vom System zuerst genutzt und beinhaltet eine Liste von Werbeserveradressen, dessen Aufruf er umbiegt. Fuer alle anderen Adressen gibt er die Anfrage einfach an einen anderen DNS-Server weiter, so dass wir sozusagen eine Art Blacklist anlegen koennen, in der wir die Adressen der Werbeseiten speichern.

Im Internet existieren zahlreiche Listen, die viele Adressen von Werbeseiten beinhalten und brav gepfelgt werden. Eine solche Liste findet sich beispielsweise hier.
Auf diese Liste werden wir zurueckgreifen, wenn wir spaeter unserem eigenen DNS-Server sagen, welche Adressen er umzubiegen hat.

Zunaechst einmal brauchen wir dazu dnsmasq. Dieses Programm ist unser DNS-Server, dem wir unsere Blacklist geben wollen.
Mittels

holen wir uns das Programm auf die Platte. Anschliessend bearbeiten wir mittels

die Datei /etc/dnsmasq.conf und fuegen ans Ende der Datei folgende Zeile hinzu: conf-file=/etc/dnsmasq.ads.conf.

Diese Zeile weist dnsmasq an die Datei /etc/dnsmasq.ads.conf zu beruecksichtigen, in der wir unsere Blacklist ablegen werden. In der Konfigurationsdatei muessen wir ausserdem dafuer sorgen, dass unser DNS-Server richtig eingerichtet ist.
Im folgenden ein Auszug der Datei mit den Stellen, bei denen das Kommentarzeichen (#) entfernt werden muss (Zeile 2,4 und 11 in meinem Auszug).

Nachdem wir die Datei bearbeitet haben legen wir noch unsere Blackliste als zunaechst leere Datei an:

Drueben bei debian-adminstration.org gibt es ein tolles Script, welches es uns erlaubt automatisiert die Blackliste aus oben genannter Quelle zu laden. Mein Dank geht an dieser Stelle an den Autor, die Rechte des Scripts liegen natuerlich beim Autor selbst!

Das Script lautet (ein wenig abgeaendert um unseren Beduerfnissen gerecht zu werden):

Dieses Script speichern wir unter /usr/local/bin/update_adserver_list ab.
Mittels

passen wir die Rechte des Scripts an und machen es ausfuehrbar. Die letzte Zeile sollte mit der Meldung Restarting DNS forwarder and DHCP server: dnsmasq. quittiert werden. Wenn dies der Fall ist funktioniert alles so weit in der Datei /etc/dnsmasq.ads.conf sollten jetzt eine Menge Eintraege stehen.

Jetzt sind wir schon relativ fortgeschritten und muessen nur noch ein paar Kleinigkeiten anpassen. Zunaechst muessen wir auf der IP 127.0.0.2, die wir im Script oben definiert haben, einen Dienst laufen lassen, der uns bei jedem Aufruf nur ein leeres Pixel ausgibt. Dieser Teil ist drueben bei flexion.org schoen erklaert. Vielen Dank dafuer! :)

Zunaechst holen wir uns den Pixelserver mittels

Im Anschluss daran muessen wir dem Pixelserver noch sagen auf welche IP er ansprechen soll. Dazu oeffnen wir die Datei im Editor

und aendern die den Teil

ab in

Es folgt der Befehl

wobei wir dort das folgende Script hineinkopieren:

Im Anschluss daran passen wir noch die Rechte an

Jetzt kann mittels

und

getestet werden ob das Script erfolgreich startet und beendet. Wenn alles passt, dann uebernehmen wir es mittels

in den Autostart.

Jetzt muessen wir noch dem System mitteilen, dass unser DNS-Server genutzt werden soll. Dazu passen wir die aktuelle Internetverbindung im NetworkManager an und fuegen unseren Rechner mit der IP 127.0.0.1 als DNS-Server hinzu. Weiterhin muessen wir noch einen alternativen DNS-Server angeben, der die normalen Anfragen abarbeitet, die unser DNS-Server nicht verwaltet. In meinem Fall ist das die IP 8.8.8.8, welche den DNS-Server von Google adressiert.

Anschliessend koennen wir testen ob unsere Arbeit Fruechte traegt und in der Konsole folgendes ausprobieren:

Das Ergebnis sollte dann so aussehen:

Jetzt haben wir alles erfolgreich konfiguriert. Allerdings muessen wir unsere Blacklist auch immer aktuell halten. Dazu legen wir noch die Datei /etc/cron.d/update_adserver_list an. Diese Datei bearbeiten wir und fuegen folgenden Inhalt hinzu

Mittels diesem Cronjob wird die Liste alle 4 Stunden neu geladen und so immer aktuell gehalten. Damit brauchen wir uns um nichts mehr kuemmern, sondern haben alles automatisiert.

Zum Testen reicht es ein paar werbeverseuchte Webseiten anzusurfen. Von Werbung sollte jetzt nichts mehr zu sehen sein - ausgenommen der Werbeserver ist nicht in der Blackliste eingetragen ;)
Viel Spass damit!

Fuer APK-Dateien gibt es dabei unterschiedliche Ansaetze. Ein Ansatz, der sehr viel ueber den Quellcode verraet, sich aber nicht gut zum Manipulieren von APKs eignet will ich im Folgenden kurz beschreiben.

Zunaechst liegt uns also eine APK-Datei vor. Bei dieser Datei handelt es sich um ein zip-Archiv, welches zusaetzlich noch signiert worden ist. Diese Signatur weist den Autor der APK-Datei aus und ist sicherheitsrelevant fuer Android. Will man eine APK-Datei manipulieren, dann kann man dies zwar tun, kann die neue Datei aber nicht mit der gleichen Signatur versehen - es sei denn man verfuegt ueber den privaten Schluessel des Autors. Dies ist in der Regel nicht der Fall und das ist auch gut so!

Die Signatur braucht uns aber nicht weiter interessieren, wenn wir uns lediglich den Quellcode anschauen und keine manipulierte APK-Datei erstellen wollen.

Der Quelltext wird beim Erstellen einer APK-Datei kompiliert, so dass wir diesen Schritt zunaechst wieder rueckgaengig machen muessen. Mittels dem Programm dex2jar ist dies moeglich.
Nehmen wir an unsere APK-Datei heisst "Test.apk", dann koennen rufen wir unter Linux dex2jar wie folgt auf: sh /path/to/dex2jar.sh /path/to/Test.apk
Unter Windows und Mac OSX sind die Aufrufe aehnlich und koennen der Webseite des Programmierers entnommen werden.

Der Befehl erzeugt eine jar-Datei, die dann lautet "Test.apk.dex2jar.jar". In dieser Datei finden sich nun die class-Dateien, welche jedoch zunaechst ebenfalls nicht zu lesen sind. Um diese Dateien lesen zu koennen brauchen wir noch einen Java Decompiler, wie beispielsweise JD. Mittels diesem koennen wir uns den Quellcode ansehen.

Auf der oben verlinkten Seite gibt es beispielsweise JD-Gui, welches gleich eine komplette Oberflaeche mitbringt. Damit koennen wir nun das jar-Archiv einlesen und bekommen sogleich die Anwendung in leserlichem Code. Abstriche muessen wir bei den Kommentaren und einigen Variablennamen machen, welche beim Kompilieren automatisch verloren gehen. Alles in allem sollte der Code dennoch recht leserlich sein, so dass wir diesen benutzen koennen um die APK-Dateien zu analysieren.

Beispielseweise koennte eine APK-Datei, die damit wieder leserlich gemacht wurde dann im Programm JD-Gui so aussehen:

Damit ist es nun moeglich die Struktur des Programms zu untersuchen und Algorithmen nachzuvollziehen.

Vielleicht noch ein Hinweis an dieser Stelle: Diese Anleitung dient nicht dazu irgendwelchen Schabernack zu treiben! Es geht hier einzig um die Moeglichkeit APKs auf deren Sicherheit zu untersuchen und ggfs. schaedliche Anwendungen ausfindig zu machen.

[CaptureHeight]480[CaptureHeight]
[CaptureWidth]640[CaptureWidth]

Achtung:
Im Code muessen die eckigen Klammern "[", "]" durch spitze Klammern "<", ">" ersetzt werden.

In obrigem Beispiel wird die Aufloesung der Webcam dabei auf 640x480 Pixel festgelegt. Ein Neustart von Skype sorgt dafuer, dass die Aenderungen uebernommen werden.

Ueber die GUI habe ich keine Moeglichkeit gefunden die Einstellungen zu taetigen. Sollte ich etwas uebersehen haben, so bin ich ueber jeden Hinweis dankbar.

Getestet mit der Pidgin-Version: 2.5.2 (unter Ubuntu 8.10 Intrepid Ibex)

(via ubuntu-forum.de)

Im Netz habe ich jetzt die Loesung des Problems gefunden. Dazu laed man sich die passenden LPR- und CUPS-Treiber aus dem Netz herunter. In der Konsole wechselt man anschliessend in das Verzeichnis in dem die beiden Dateien liegen und fuehrt nacheinander folgende Schritte aus:

sudo apt-get install lpr
sudo dpkg -i --force-all brhl2030lpr-2.0.1-1.i386.deb
sudo dpkg -i --force-all cupswrapperHL2030-2.0.1-2.i386.deb

Danach findet man in den Druckerkonfigurationen (Systemverwaltung -> Drucken) einen neuen Drucker mit dem Namen "HL2030" (laeuft intern als Typ "Brother HL2030 for CUPS"). Dieser druckt nun ohne stoerende Pausen.

Hinweis:
Bei meinem System musste ich die Geraete-URI in usb://Brother/HL-2030%20series aendern (davor: usb:/dev/usb/lp0), da sich der Drucker sonst nicht angesprochen fuehlte. Nach dieser Aenderung klappt aber alles wunderbar.

(via ubuntuusers.de)

Vor ein paar Monaten kaufte ich mir ein Acer Aspire 7720G (benutztes BIOS: InsydeH2O V1.35), welches ich auch gleich in Betrieb nahm. Anfangs ging alles wunderbar und das Notebook bootete genau so wie es sein sollte. Einen guten Monat spaeter trat zum ersten Mal das Problem auf, dass das Notebook beim Kaltstart (sprich: es war zuvor laenger als 5 Minuten von jedlicher Stromversorgnung getrennt) einfror und nicht starten wollte. Ich musste das Notebook ausschalten und wieder anschalten und erneut booten. Beim zweiten Booten klappte es dann und das Betriebsystem wurde geladen.

Dieser Fehler trat zunaechst nur ein einziges Mal auf, wurde aber mit der Zeit immer haeufiger. Das Notebook blieb beim Booten einfach haengen und egal wie lange man wartete, es passierte nichts.
Interessanterweise blieb das Notebook nicht immer an der gleichen Stelle haengen, sondern die Stelle variierte. Im Ganzen gab es drei Stellen, an welchen das Notebook haengen bleiben konnte.

1. Vor dem Laden des Acer-Logos und damit eigentlich auch vor dem jeglichem Output des BIOS. Zu sehen war dann nur ein blinkender Unterstrich, welcher immer brav vor sich hin blinkte.
2. Beim Laden des Bios.
3. Bei der Meldung "Prepare to Boot to OS". Das BIOS ist hier zwar scheinbar schon vollstaendig geladen und es erschien zwar die Meldung, dass das Betriebsystem geladen werden soll - passiert ist dennoch nichts!

Obwohl ich zunaechst von einem Hardwaredefekt ausgegangen war und auch schon den Support angeschrieben hatte, habe ich es mir nicht nehmen lassen ein wenig das BIOS zu durchforsten. Besonders ist mir dabei die Option Main -> Quiet Boot aufgefallen. Ich liess es darauf ankommen und deaktivierte diese Option (Disabled). Das Ergebnis war beeindruckend! Bei inzwischen mindestens 20 mal Booten ist der Fehler nicht mehr aufgetreten. Diese Option scheint schuld daran zu sein, dass das Notebook nicht mehr starten wollte.

Die Funktion legt fest ob das Logo des Notebookherstellers, in meinem Fall also Acer, angezeigt werden soll, oder nicht. Warum genau das Anzeigen des Logos zu Problemen fuehrt ist mir leider nicht bekannt.

Ich bin jedenfalls gluecklich, dass der Rechner wieder aufs erste Mal bootet und bin zuversichtlich, dass das ab jetzt auch so bleibt.

Nachtrag
Nachdem das gleiche Problem nach kurzer Zeit wieder aufgetreten ist, habe ich mich dazu entschlossen das Notebook einzuschicken und reparieren zu lassen. Dort wurde die CPU als defekt ausfindig gemacht und gewechselt. Seit dem habe ich keine Probleme mehr - auch nicht bei Kaltstarts. Daher bleibt jedem, der das selbe Problem wie ich hat, vermutlich ebenfalls nur das Acer Repair Center als Ausweg.

-------------------------------------------------------

English short version:

I've had some problems with my BIOS (InsydeH2O V1.35) running on an Acer-notebook. I was not able to boot my system when the notebook was more than five minutes out of electricity. Sometimes it loaded the Acer boot-screen and sometimes not - but everytime the system freezes and needed to be turned off and booted up again. I first blamed the hardware but later on I recognized that one single setting at the BIOS was responsible for the malfunction.
To fix the problem go to Main -> Quiet Boot. If you disable this setting (it is enabled by default) the notebook will boot up normally and the problem will be gone.

Edit:
After a short period of time the same problem occured again and so I decided to deliver my notebook to the Acer Repair Center. They blamed the CPU for the error and substituted it. From then on my notebook worked fine and i'm happy again.