[Hackrf-dev] hackrf_transfer -t issues?

[Mudge Zatko]

has anyone had luck with replaying captured signals via hackrf_transfer -t?

Going back through the mailing list I see that there were some comments on
-t having issues, but nothing more specific on the nature of the issues.

I believe Mike O. commented that these issues that did not show up when
using GRC... but I'm more interested in making use of hackrf_transfer for
this project.

Here's what's happening: capturing a 12.5kHz FSK signal via hackrf_transfer
-r (tried with varying baseband filter bandwidths and sample rates) and
then sending via hackrf_transfer -t with the same settings results in a
garbled and very narrow frequency transmission (looks to be around 1-2kHz).

thanks,

.mudge

[Michael Ossmann]

Post by Mudge Zatko
has anyone had luck with replaying captured signals via
hackrf_transfer -t?

There is definitely a bug:

https://github.com/mossmann/hackrf/issues/91

I haven't had a chance to look for the root cause yet.

[Mudge Zatko]

Thanks Mike.

Any idea when (if?) this will be looked into?

GRC is cool and all, but part of the allure of HackRF (at least to me) is
the ability to perform meaningful replay and mutation fuzzing from a
minimalistic unix environment.

To that end, hackrf_transfer -t would look to be ideal in quickly enabling
some initial security analysis of various receiver codecs.

Or perhaps there's another alternative to transfer -t that you or someone
else on the list is aware of they could point me to in the meantime?

thanks again,

.mudge

Post by Michael Ossmann

Post by Mudge Zatko
has anyone had luck with replaying captured signals via
hackrf_transfer -t?

https://github.com/mossmann/hackrf/issues/91
I haven't had a chance to look for the root cause yet.

[Michael Ossmann]

I started looking for the bug on an airplane, but I wasn't able to find
it without hardware to test with. I'm definitely hoping to get to it
this week.

I put together the attached flowgraph (.grc file and the generated .py
program) for GNU Radio 3.6. hackrfreplay.py may be an acceptable
alternative until hackrf_transfer -t is fixed. It's pretty easy to
change the sample rate, file name, etc. in Python and avoid GRC.

My next step on this when I get back to the lab will be comparing the
signal produced by hackrfreplay.py with that produced by
hackrf_transfer.

Post by Mudge Zatko
Thanks Mike.
Any idea when (if?) this will be looked into?
GRC is cool and all, but part of the allure of HackRF (at least to me) is
the ability to perform meaningful replay and mutation fuzzing from a
minimalistic unix environment.
To that end, hackrf_transfer -t would look to be ideal in quickly enabling
some initial security analysis of various receiver codecs.
Or perhaps there's another alternative to transfer -t that you or someone
else on the list is aware of they could point me to in the meantime?
thanks again,
.mudge

Post by Michael Ossmann

Post by Mudge Zatko
has anyone had luck with replaying captured signals via
hackrf_transfer -t?

https://github.com/mossmann/hackrf/issues/91
I haven't had a chance to look for the root cause yet.

[Mudge Zatko]

Thanks :)

Post by Michael Ossmann
I started looking for the bug on an airplane, but I wasn't able to find
it without hardware to test with. I'm definitely hoping to get to it
this week.
I put together the attached flowgraph (.grc file and the generated .py
program) for GNU Radio 3.6. hackrfreplay.py may be an acceptable
alternative until hackrf_transfer -t is fixed. It's pretty easy to
change the sample rate, file name, etc. in Python and avoid GRC.
My next step on this when I get back to the lab will be comparing the
signal produced by hackrfreplay.py with that produced by
hackrf_transfer.

Post by Mudge Zatko
Thanks Mike.
Any idea when (if?) this will be looked into?
GRC is cool and all, but part of the allure of HackRF (at least to me) is
the ability to perform meaningful replay and mutation fuzzing from a
minimalistic unix environment.
To that end, hackrf_transfer -t would look to be ideal in quickly

enabling

Post by Mudge Zatko
some initial security analysis of various receiver codecs.
Or perhaps there's another alternative to transfer -t that you or someone
else on the list is aware of they could point me to in the meantime?
thanks again,
.mudge

Post by Michael Ossmann

Post by Mudge Zatko
has anyone had luck with replaying captured signals via
hackrf_transfer -t?

https://github.com/mossmann/hackrf/issues/91
I haven't had a chance to look for the root cause yet.

[Mudge Zatko]

This is too heavyweight for the experiment I ultimately want to run, but it
was definitely useful to verify that I could transmit a meaningful signal
compared to hackrf_transfer -t.

Some quick notes to anyone else who might be coming up to speed like me...
I needed to change hackrfreplay.grc and hackrfreplay.py to get them
working with the versions of gnuradio (3.7.0) and osmosdr (v0.1.0-10) that
I built to test these.

hackrfreplay.grc:

replace osmosdr_sink_c_0 with osmosdr_sink_0.

hackrfreplay.py:

firdes is imported from gnuradio.filter rather than gnuradio.gr now, so
modify python imports appropriately, and the osmosdr object has method
osmosdr.sink() rather than osmosdr.sink_c().

thanks again :)

.mudge

Post by Michael Ossmann
I started looking for the bug on an airplane, but I wasn't able to find
it without hardware to test with. I'm definitely hoping to get to it
this week.
I put together the attached flowgraph (.grc file and the generated .py
program) for GNU Radio 3.6. hackrfreplay.py may be an acceptable
alternative until hackrf_transfer -t is fixed. It's pretty easy to
change the sample rate, file name, etc. in Python and avoid GRC.
My next step on this when I get back to the lab will be comparing the
signal produced by hackrfreplay.py with that produced by
hackrf_transfer.

Post by Mudge Zatko
Thanks Mike.
Any idea when (if?) this will be looked into?
GRC is cool and all, but part of the allure of HackRF (at least to me) is
the ability to perform meaningful replay and mutation fuzzing from a
minimalistic unix environment.
To that end, hackrf_transfer -t would look to be ideal in quickly

enabling

Post by Mudge Zatko
some initial security analysis of various receiver codecs.
Or perhaps there's another alternative to transfer -t that you or someone
else on the list is aware of they could point me to in the meantime?
thanks again,
.mudge

Post by Michael Ossmann

Post by Mudge Zatko
has anyone had luck with replaying captured signals via
hackrf_transfer -t?

https://github.com/mossmann/hackrf/issues/91
I haven't had a chance to look for the root cause yet.