X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/5ba84b59a210eafc0a4f9923d81fabdf1715ceac..cb2bffc9f0c093d20f059990477781700cd1f6a8:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index a642378182..36e4780002 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,84 @@ http://people.skolelinux.org/pere/blog/ + + Easier recipe to observe the cell phones around you + http://people.skolelinux.org/pere/blog/Easier_recipe_to_observe_the_cell_phones_around_you.html + http://people.skolelinux.org/pere/blog/Easier_recipe_to_observe_the_cell_phones_around_you.html + Sun, 24 Sep 2017 08:30:00 +0200 + <p>A little more than a month ago I wrote +<a href="http://people.skolelinux.org/pere/blog/Simpler_recipe_on_how_to_make_a_simple__7_IMSI_Catcher_using_Debian.html">how +to observe the SIM card ID (aka IMSI number) of mobile phones talking +to nearby mobile phone base stations using Debian GNU/Linux and a +cheap USB software defined radio</a>, and thus being able to pinpoint +the location of people and equipment (like cars and trains) with an +accuracy of a few kilometer. Since then we have worked to make the +procedure even simpler, and it is now possible to do this without any +manual frequency tuning and without building your own packages.</p> + +<p>The <a href="https://tracker.debian.org/pkg/gr-gsm">gr-gsm</a> +package is now included in Debian testing and unstable, and the +IMSI-catcher code no longer require root access to fetch and decode +the GSM data collected using gr-gsm.</p> + +<p>Here is an updated recipe, using packages built by Debian and a git +clone of two python scripts:</p> + +<ol> + +<li>Start with a Debian machine running the Buster version (aka + testing).</li> + +<li>Run '<tt>apt install gr-gsm python-numpy python-scipy + python-scapy</tt>' as root to install required packages.</li> + +<li>Fetch the code decoding GSM packages using '<tt>git clone + github.com/Oros42/IMSI-catcher.git</tt>'.</li> + +<li>Insert USB software defined radio supported by GNU Radio.</li> + +<li>Enter the IMSI-catcher directory and run '<tt>python + scan-and-livemon</tt>' to locate the frequency of nearby base + stations and start listening for GSM packages on one of them.</li> + +<li>Enter the IMSI-catcher directory and run '<tt>python + simple_IMSI-catcher.py</tt>' to display the collected information.</li> + +</ol> + +<p>Note, due to a bug somewhere the scan-and-livemon program (actually +<a href="https://github.com/ptrkrysik/gr-gsm/issues/336">its underlying +program grgsm_scanner</a>) do not work with the HackRF radio. It do +work with RTL 8232 and other similar USB radio receivers you can get +very cheaply +(<a href="https://www.ebay.com/sch/items/?_nkw=rtl+2832">for example +from ebay</a>), so for now the solution is to scan using the RTL radio +and only use HackRF for fetching GSM data.</p> + +<p>As far as I can tell, a cell phone only show up on one of the +frequencies at the time, so if you are going to track and count every +cell phone around you, you need to listen to all the frequencies used. +To listen to several frequencies, use the --numrecv argument to +scan-and-livemon to use several receivers. Further, I am not sure if +phones using 3G or 4G will show as talking GSM to base stations, so +this approach might not see all phones around you. I typically see +0-400 IMSI numbers an hour when looking around where I live.</p> + +<p>I've tried to run the scanner on a +<a href="https://wiki.debian.org/RaspberryPi">Raspberry Pi 2 and 3 +running Debian Buster</a>, but the grgsm_livemon_headless process seem +to be too CPU intensive to keep up. When GNU Radio print 'O' to +stdout, I am told there it is caused by a buffer overflow between the +radio and GNU Radio, caused by the program being unable to read the +GSM data fast enough. If you see a stream of 'O's from the terminal +where you started scan-and-livemon, you need a give the process more +CPU power. Perhaps someone are able to optimize the code to a point +where it become possible to set up RPi3 based GSM sniffers? I tried +using Raspbian instead of Debian, but there seem to be something wrong +with GNU Radio on raspbian, causing glibc to abort().</p> + + + Datalagringsdirektivet kaster skygger over Høyre og Arbeiderpartiet http://people.skolelinux.org/pere/blog/Datalagringsdirektivet_kaster_skygger_over_H_yre_og_Arbeiderpartiet.html @@ -550,52 +628,5 @@ fremdriften på web</a>.</p> - - Offentlig elektronisk postjournal blokkerer tilgang for utvalgte webklienter - http://people.skolelinux.org/pere/blog/Offentlig_elektronisk_postjournal_blokkerer_tilgang_for_utvalgte_webklienter.html - http://people.skolelinux.org/pere/blog/Offentlig_elektronisk_postjournal_blokkerer_tilgang_for_utvalgte_webklienter.html - Thu, 20 Apr 2017 13:00:00 +0200 - <p>Jeg oppdaget i dag at <a href="https://www.oep.no/">nettstedet som -publiserer offentlige postjournaler fra statlige etater</a>, OEP, har -begynt å blokkerer enkelte typer webklienter fra å få tilgang. Vet -ikke hvor mange det gjelder, men det gjelder i hvert fall libwww-perl -og curl. For å teste selv, kjør følgende:</p> - -<blockquote><pre> -% curl -v -s https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP' -< HTTP/1.1 404 Not Found -% curl -v -s --header 'User-Agent:Opera/12.0' https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP' -< HTTP/1.1 200 OK -% -</pre></blockquote> - -<p>Her kan en se at tjenesten gir «404 Not Found» for curl i -standardoppsettet, mens den gir «200 OK» hvis curl hevder å være Opera -versjon 12.0. Offentlig elektronisk postjournal startet blokkeringen -2017-03-02.</p> - -<p>Blokkeringen vil gjøre det litt vanskeligere å maskinelt hente -informasjon fra oep.no. Kan blokkeringen være gjort for å hindre -automatisert innsamling av informasjon fra OEP, slik Pressens -Offentlighetsutvalg gjorde for å dokumentere hvordan departementene -hindrer innsyn i -<a href="http://presse.no/dette-mener-np/undergraver-offentlighetsloven/">rapporten -«Slik hindrer departementer innsyn» som ble publiserte i januar -2017</a>. Det virker usannsynlig, da det jo er trivielt å bytte -User-Agent til noe nytt.</p> - -<p>Finnes det juridisk grunnlag for det offentlige å diskriminere -webklienter slik det gjøres her? Der tilgang gis eller ikke alt etter -hva klienten sier at den heter? Da OEP eies av DIFI og driftes av -Basefarm, finnes det kanskje noen dokumenter sendt mellom disse to -aktørene man kan be om innsyn i for å forstå hva som har skjedd. Men -<a href="https://www.oep.no/search/result.html?period=dateRange&fromDate=01.01.2016&toDate=01.04.2017&dateType=documentDate&caseDescription=&descType=both&caseNumber=&documentNumber=&sender=basefarm&senderType=both&documentType=all&legalAuthority=&archiveCode=&list2=196&searchType=advanced&Search=Search+in+records">postjournalen -til DIFI viser kun to dokumenter</a> det siste året mellom DIFI og -Basefarm. -<a href="https://www.mimesbronn.no/request/blokkering_av_tilgang_til_oep_fo">Mimes brønn neste</a>, -tenker jeg.</p> - - -