2-FSK Sniffing with the YS1

[herzs11]

I am reverse engineering a sub GHz radio protocol. I have figured out the protocol, and am able to spoof the receiver transmitting from my Yardstick One with RFCat, using packets sniffed on another SDR (I know the YS1 isn't technically an SDR) and decoded using Inspectrum. However when I send the same packets with the real remote, or another SDR transmitter, I am unable to sniff them with my YS1 in RFCat, with the same settings I used to successfully transmit. Does receiving require different settings? (Besides putting it into RX Mode) Here is the printout of d.printRadioConfig():

`== Hardware ==
Dongle:              YARDSTICKONE
Firmware rev:        0616
Compiler:            SDCCv350
Bootloader:          CC-Bootloader

== Software ==
rflib rev:           616

== Frequency Configuration ==
Frequency:           916999877.929688 hz (0x263555)
Channel:             0
Intermediate freq:   281250 hz
Frequency Offset:    0 +/-
Est. Freq Offset:    0

== Modem Configuration ==
Modulation:          2FSK
DRate:               151977.539062 hz
ChanBW:              93750.000000 hz
DEVIATION:           234375.000000 hz
Sync Mode:           16 of 16 bits must match
Min TX Preamble:     3 bytes
Chan Spacing:        199951.171875 hz
BSLimit:             No data rate offset compensation performed
DC Filter:           enabled
Manchester Encoding: disabled
Fwd Err Correct:     disabled

== Packet Configuration ==
Sync Word:           0x8585
Packet Length:       11
Length Config:       Fixed Packet Mode
Configured Address:  0x0
Preamble Quality Threshold: 4 * 2
Append Status:       No
Rcvd Packet Check:   No address check
Data Whitening:      off
Packet Format:       Normal mode
CRC:                 disabled

== AES Crypto Configuration ==
AES Mode:            CBC - Cipher Block Chaining
Crypt RF Input:      off
Crypt RF Output:     off

== Radio Test Signal Configuration ==
TEST2:               0x88
TEST1:               0x35
TEST0:               0x9
VCO_SEL_CAL_EN:      0x0

== Radio State ==
     MARCSTATE:      MARC_STATE_IDLE (1)
     DONGLE RESPONDING:  mode :d, last error# 0

== Client State ==
========================================================================================================================
     client thread cycles:      105/55
     client errored cycles:     0
     recv_queue:                (0 bytes) ''
     trash:                     (3 blobs) "[128, 142, (1619706506.761202, '')]"
     recv_mbox                  (2 keys)  "['0x42', '0xff']"
       app 0x42 (2 records)
             [0x2]    (0 frames)  "[]"
             [0x7]    (0 frames)  "[]"

       app 0xff (6 records)
             [0x80]    (0 frames)  "[]"
             [0x81]    (0 frames)  "[]"
             [0x82]    (0 frames)  "[]"
             [0x86]    (0 frames)  "[]"
             [0x88]    (0 frames)  "[]"
             [0x89]    (0 frames)  "[]"`

[atlas0fd00m]

you're currently in MARC_STATE_IDLE, which means that the receiver is not listening.
if you're in this state (RfCat was designed to primarily always be in MARC_STATE_RX), i assume you got yourself there and know how to get back. but if not, d.setModeRX() should do the trick.

if you want to troubleshoot, a couple approaches might make sense:

d._debug=2 (or 1 or 3, ymmv) will enable debugging from the state of the Python client side.

d.discover() (with various options for lowball=) may prove interesting, as it disables most things in the radio which would get in the way of receiving bits.... warning: depending on the lowball value you choose, the bits will be shifted (not byte-aligned) or (for lowball=0) will be a continuous stream of bytes (which can be fun and even helpful at times)... but hey, these are debugging tools.

it's possible your receive threshold configs are inappropriate, including the Receive Preamble size, etc...

i once wrote an entire course about what you're doing (SDR for low-level details capture, RfCat configuration, and ultimately, how things can go wrong, and how it looks so you can identify it). ran it once as a one-day (at S4), converted it to a 2-day for BlackHat, but life happened and it's been sitting on the back burner since.

[herzs11]

Thanks for your response. I had put d.setModeRX and d.setModeIDLE in the script I was running. I should've mentioned this but I have received bits with d.discover or d.RFlisten with more relaxed settings, but once I narrow down on the protocol I'm working on I don't get anything. I'll try the debugging setting, thank you. Im sure this isn't a software or hardware issue, I just didn't know where else to ask haha. If you ever run that class again I would love to take it