Digitally Colourful Mistifier

Hi ASD, probably a bit a late but it looks like we're looking into the same stuff. As stated by the other repliers I'm doing this with a HackRF. Feel free to join in on

Yet another step closer: On IRC I received two links on the #SDR channel: Cyberspectrum: Bay Area Software Defined Radio #7 (May 2015): https://youtu.be/BoFOt9AUWuE Cyberspectrum: Bay Area Software Defined Radio #9 (July 2015): https://youtu.be/NBfBnPPcuJw And they also pointed me towards RFtap (https://rftap.github.io/). Looking into this now. The docs indicate that Wireshark 2.3 and above have buildin support for this so I'm going to try that route.

Depends on what you look for I think. I suppose you mean anything audio related? In that case there are always plenty of babymonitors, intercoms, walkies, DECT-phones, ... Have a look here: http://static.ofcom.org.uk/static/spectrum/fat.html. This is a link to the UK Frequency Allocation Table, which is regulated by Ofcom, the UK's communications regulator. In this table you'll find all the possible frequencies that are out there on the radio spectrum, and it will state what the frequency is used for. A good place to start is in the SMI-band for Scientific, Medical and Industrial applications. Also fun to take a look at: https://en.wikipedia.org/wiki/Citizens_band_radio (CB radio)

alright, got that one working. Didn't know about SWIG before. It appears that this is some sort of linking library between C++ and Python. It appeared that have that installed but it was of the wrong version. I could verify this by doing over the build process. In the log of the build I could see the error: So, to fix this I did Then, I rebuild and the stuff worked. Now it's time to figure out how to use this thing...

Another update: Just_a_User gave me a hint on the #sdr-channel and pointed me to https://github.com/pavelyazev/gr-dect2 Now, I build and installed it and opened the example GRC-flow and replaced the USRP source with an OSMOCOM source to use my HackRF. But now if I run it, the thing stumples upon following error: My GRC flow looks like this:

Ok, seems that there is an old project 'Dedected' (https://dedected.org) on which there was a talk on 25C3 (2008) (https://dedected.org/trac/wiki/25C3) but unfortunately, one of the researchers wasn't able to explain his findings in English so I didn't manage to follow that. Since then there seems to be an update on the project, well more of a fork under the name 'Re-dected' that has been uploaded on github: https://github.com/znuh/re-DECTed I'm still figuring out how to get this last one working and wrapping my head around how dect exactly works, but we're moving forward.

Hi, Starting of on a new project again, I'd be interested to learn more about analysing DECT communication through a HackRF. Is there any specific research that you think I should read up on? I've done my first steps with the hackrf: hacking the garagedoor, listening in on the babymonitor, ... now I'd like to start learning about DECT phones, but I'm 100% new to the subject.

My name is C aka Digitally Colourful Mistifier Favourite game: Risk Favourite OS: Debian Favourite console: Retropi Nationality: European Accent: Depends on context Sex: Male Age: Old enough to have sex with mutual consent and drink alcohol Race: Errr, we got rid of that word about 70yrs ago... Height: My physique is not of any importance here Status: Father of two, loving wife Build: see 'Height' Favourite band: Too many to list and changes regularly Favourite book: The tipping point by Malcolm Gladwell Favourite author: Too many to list and changes regularly Favourite movie: Too many to list and changes regularly Favourite director: Tarantino Favourite TV Show: HAK5 & Primitive Technology (on youtube) Other hobbies: Walking, ice skating, skiing Car: Nihola cargobike Occupation: Business owner

I heard about it before. People in our hackerspace used them for some projects, forgot about it. Will look into it!

This blog https://medium.com/@rxseger/sdr-first-project-initial-setup-node-hackrf-gnu-radio-on-linux-os-x-rpi-3-w-fm-tuner-ee16cdc8fd82 suggests that the PI's ARM cpu indeed is too slow to handle the recommended minimum samplerate of 2e6 on the HackRF. He did have some success running on 1e6 samples/sec it seems.

Hi, we have been engaged for a pentest and we would like to build a device that will allow us to 1) drop an SDR in the vicinity of the radio-controlled gate of our client 2) the SDR should be listening for keys constantly, but only record when there really is traffic. For this I think the device should constantly buffer the past say 15sec and store those 15sec only to file if they actually contain significant data. 3) remote control the device to monitor the number of collected samples, battery-level and potential discovery of the device by security personnel I was thinking of a raspberry pi on a batterypack with a usb gprs-modem. But would the pi's CPU be fast enough to handle the samplerate from the hackrf? How long would a decent batterypack last with a pi, a gprs-modem and an hackrf running on it? Are there any examples in GNURadio that I could take a look at for this scenario? Anyone ever done such a thing before? Thanks!

Correct, that was the answer. When playing with SDR on a VM you can get messed up results. This is caused by the virtualisation layer, it slows down a whole number of things including USB-connections and audio-output. It was the latter which caused the error in my case. I discoverd I could fidle a little bit with the output sample rate (make it a little higher than 48Khz) which solved the audio-underrun problem, but which then in effect caused CPU-overrun :-). So yes, the solution to my problem was installation on a bare metal box.

Hi, I just got started with the HackRF One and it's really fun. I'm following the lessons at greatscottgadgets.com but with lesson 1 I'm already facing some issues I just can't seem to get solved on my own. The problem I'm facing is the classical 'choppy output' of the audio when demodulating FM radio. The schema that we're supposed to build is explained in great detail at https://greatscottgadgets.com/sdr/1/. I followed all the steps, I think my schema is exactly as what he told me to build, but still I'm getting choppy output, for as far as my googling learned me anything this means that I've messed up the sample rates at some point. It's not that my hardware can't keep up with the rate, already checked that by lowering the rate to ridiculously low levels but that didn't help to solve the choppy output. Anyone having some hints for me? I've included a screenshot of my workflow: My setup looks like this: - Physical machine is a recent macbook pro with 8GB RAM and 4 cpu-cores running OSX Sierra - Virtual Machine is a Debian 9 with 3GB RAM and 1 cpu-core

Hi, I'm trying to use a ducky to automate some stuff on a macbook :-) But it has this funky Azerty layout (see image). I encoded it with "-l resources/be.properties" and that worked fine, except for one character: the at-sign "@", this renders as "ë". So I was thinking, maybe I should create a properties-file for this keyboard layout. But how do I do this? Any thoughts?