Um die Regelmäßigkeit aufrecht zu erhalten (SCNR) gibt es morgen mal wieder eine Projektvorstellungsrunde.
Grüße, Zoran
Wie grade gesagt, lerne ich grade Haskell und habe dazu ein git Repo:
https://github.com/zoranzaric/RealWorldHaskellExercises
Mitmacher sind gerne gesehen.
Grüße, zorzar
On Mon, Oct 21, 2013 at 10:29:44AM +0200, Zoran Zaric wrote:
Um die Regelmäßigkeit aufrecht zu erhalten (SCNR) gibt es morgen mal wieder eine Projektvorstellungsrunde.
Grüße, Zoran
Hallo Trolle, wie in der heutigen Projektvorstellungsrunde erzählt habe, sammle ich für meine Masterarbeit gerade mittels einer Android-App Daten darüber, wie oft und gut sich Devices über Bluetooth sehen und miteinander kommunizieren können. Ziel ist es, eine Forschungsgrundlage für die realistische Simulation von mobilen P2P-Netzen, z.B. für zensurresistente Kommunikation, zu schaffen.
Details und eine Anleitung zum Mitmachen gibt es unter http://mscthesis.janschejbal.de/ (Vielen Dank an alle, die schon mitmachen! Demnächst[tm] erscheint Version 8 mit angepassten Timings, welche dann die "Produktiv"-Phase darstellt und etwas weniger Strom fressen sollte - bitte updated zeitnah wenn die Version erscheint!)
Damit die Logs etwas aussagekräftiger werden, möchte ich in der Höhle einen "Beacon" haben - ein Bluetooth-Device mit einem bestimmten Namen, welches nix macht außer sichtbar zu sein. Wenn die teilnehmenden Handies so einen Beacon sehen, protokollieren sie diese Tatsache in den gesammelten Daten, damit man weiß, dass sich dieses Handy in der Nähe eines bestimmten Ortes befindet. Der Beacon selbst nimmt keine Verbindungen an, scannt nicht und kommuniziert nicht, sondern ist einfach nur sichtbar.
Meine Idee war, einen Bluetooth-Stick an whiskey anzuschließen und so diesen Beacon bereitzustellen. Man könnte natürlich auch einen Raspberry Pi und dauerhaft laufen lassen (oder ein beliebiges bluetoothfähiges Device), aber ich habe gerade keinen zur Verfügung und fände es auch etwas sinnlos, nur dafür ein weiteres Gerät zu betreiben.
Azrael will das aber nicht alleine entscheiden und hat mich gebeten, das hier anzusprechen. Falls also jemand etwas dagegen hat, möge er sich bitte hier melden.
Gruß Jan
Salut,
Am 10/23/2013 12:30 AM, schrieb Jan Schejbal:
Azrael will das aber nicht alleine entscheiden und hat mich gebeten, das hier anzusprechen. Falls also jemand etwas dagegen hat, möge er sich bitte hier melden.
Ich hab die Mail leider total überlesen, daher:
Magst du das morgen auf dem Plenum mit aufnehmen? Wir haben eben kurz mal hier in der Runde drüber geredet und da kamen noch Bedenken auf..
Liebe Grüße bios
Am 2013-10-28 22:12, schrieb bios:
Magst du das morgen auf dem Plenum mit aufnehmen? Wir haben eben kurz mal hier in der Runde drüber geredet und da kamen noch Bedenken auf..
Ich kann leider die kommenden dreieinhalb Wochen abends nur Freitags oder am Wochenende.
Nochmal zur Erklärung des Beacons:
Der Beacon loggt nichts*, er ist einfach nur da, wie z. B. auch ein WLAN-Accesspoint der seine SSID aussendet. Er dient als Orientierungspunkt für die App auf den teilnehmenden Geräten. Die Geräte selbst loggen dann in den Logs des Experiments, dass sie gerade den Beacon sehen. Leute, die am Experiment (http://mscthesis.janschejbal.de/) nicht teilnehmen, sind also nicht betroffen.
Ich selbst habe auf whiskey keinen Zugriff. Einer der Verantwortlichen würde ein initskript hinterlegen und ausführen, welches die folgenden Befehle ausführt (sowie den Namen in eine Configdatei schreiben):
hciconfig hci0 up # Bluetooth-Stick an hciconfig hci0 piscan # Bluetooth-Stick sichtbar hciconfig hci0 name P2P-Beacon-irgendwas # name festlegen
(siehe http://pastebin.com/ye2fvP75, ja, die Existenz von Schleifen ist mir bekannt ;-) die Syntax von || musste ich nicht nachschauen)
Bluetooth verwende ich, weil die ganze App auf Bluetooth basiert und ich nicht zusätzlich nochmal das gleiche für WLAN schreiben will, ansonsten könnte man als Beacons auch genau definierte WLAN-APs nehmen (die Liste müsste nur noch zusätzlich verwaltet werden).
Nochmal: Der Beacon betrifft was den Datenschutz angeht nur diejenigen, die *freiwillig* am Experiment teilnehmen und sich damit einverstanden erklärt haben. Das ist das gleiche, wie wenn jemand einen nicht mit einem Netzwerk verbundenen WLAN-AP da hinstellt, der eine SSID aussendet.
Falls jemand von euch der mitmacht (bzw. nur deswegen nicht mitmacht) das für zu invasiv hält, gebt mir bitte einfach Bescheid - wenn sich da mehrere Leute melden, lass ich das mit dem Beacon sein und stell die Funktionalität mit dem nächsten Update in der App ab.
Ansonsten bitte ich euch, Fragen per Mail (oder IRC, wenn ich on bin) an mich zu richten.
Gruß Jan
*) Da ich nicht den gesamten Debian-Bluetooth-Code gelesen habe, kann ich nicht persönlich garantieren, dass das Debian nicht von sich aus irgendwo irgendwas hindumpt. In meiner Test-VM konnte ich aber soweit nichts finden, kann mir nicht vorstellen dass sowas geloggt würde und es ist auch nicht Zweck der Sache. D.h. im extrem unwahrscheinlichen Fall dass da irgendwas geloggt würde, würde ich das höchstens mit rm anfassen (bzw. anfassen lassen, hab ja eh keinen Zugang).
Kurzzusammenfassung: ein SSH-Server, der auf Brute-Force-Angriffe aus dem Netz wartet und dann die Brute-Force-Passwörter gegen den Angreifer testet.
Ursprünglicher Autor: Tobias Fiebig (ichdasich@chaosdorf.de)
Paper: http://rp.delaat.net/2012-2013/p22/report.pdf (mit Python-Code drin, sehr schmerzhaft rauszukopieren)
Mein Code ist noch nicht in einem wirklich veröffentlichbarem Zustand, ich werd in bei gelegenheit aufräumen und irgendwo intern online stellen.
Viele Grüße, Schlafwandler
Am 21.10.2013 10:29, schrieb Zoran Zaric:
Um die Regelmäßigkeit aufrecht zu erhalten (SCNR) gibt es morgen mal wieder eine Projektvorstellungsrunde.
Grüße, Zoran _______________________________________________ Darmstadt mailing list Darmstadt@lists.metarheinmain.de https://lists.metarheinmain.de/mailman/listinfo/darmstadt