Is it possible to add debruijn sequence

[5l1v3r1]

Can you please add debruijn sequence support? Here are the links i found

http://code.activestate.com/lists/python-list/660415/

https://github.com/exploitagency/github-kali-scripts/blob/master/scripts/debruijn.py

Thanks a lot for attention. Regards

[0xDRRB]

Oh ! Nice idea. I will work on it.

[mcauser]

In the meantime, download this: https://github.com/exploitagency/github-kali-scripts/blob/master/scripts/debruijn.py and comment out from rflib import *.

Capture a signal from your transmitter and measure the timings.

• bit width
• 0 gap width
• 1 gap width
• number of bits in message

I use URH for both.

Generate the sequence and save to a file - my device uses a 13 bit long message.

python debruijn.py -c '01' -m 13 > 13.txt

Set the timing options and pipe in the sequence.

./hackrf_ook -s 0 -b 1020 -0 693 -1 354 -p 10000  -f 433920000 -r 2 -m `cat 13.txt`

Made my doorbell ring a few tones I've never heard before!

[mcauser]

I tried generating a 25 bit message, but hit the argument limit.

python debruijn.py -c '01' -m 25 > 25.txt
./hackrf_ook -s 0 -b 1020 -0 693 -1 354 -p 10000  -f 433920000 -r 2 -m `cat 25.txt`
-bash: ./hackrf_ook: Argument list too long

25.txt is 33.6MB!

If you could read the message from stdin, large messages could be piped in. Maybe add a quiet -q option to skip outputting the precalculated samples --__-_--_?

[mcauser]

If adding the De Bruijn sequence, might as well add brute force too.

Proposed new options:

-db number           length of message to be generated using De Bruijn sequence
-bf number           length of message to be generated using brute force sequence
-q                   quiet mode, less output

Where -db 5 would generate all possible combinations of 5-bit messages using the De Bruijn sequence and -p 1000 and -r 2 would send the sequence 2 times with a 1 ms pause in between. The pause and repeat would have to apply to the whole message, as the codes overlap.

Next -bf 5 would generate all possible combinations of 5-bit messages using a brute force method, where -p 1000 and -r 2 would behave slightly differently. It would send "00000", pause 1 ms, send "00001", pause 1 ms, send "00010" etc, then after the final "11111", repeats the whole range a 2nd time.

If brute forcing, and terminating early, it would be nice to know how far it got, so the process could be restarted from there with another new option.

Might be a good starting point: debruijn.c: https://gist.github.com/crowell/77b601db16562ac49834