A while ago, I wanted to reverse engineer the remote for my LED strip.
I asked about it on a Discord server of my university and that's actually how I got to know the university CTF group since one of their members replied to me.
I don't remember the exact answer but he said it should be possible. I also should be able to find exact technical documentation for my remote online since they probably just used commodity hardware. In any case, something like a HackRF One will definitely work but that costs 300+€. So kind of overkill for my use case, lol
So far, I haven't been able to. I thought if something uses 2.4GHz which is the same frequency of WLAN, it should show up in Wireshark? Or at least get captured by my network card?
Now that I am writing this, the reason why it's not working is maybe because those aren't IP packets? Can network cards only capture IP packets? I was hoping it would capture literally anything that is transmitted over air on this frequency, lol.
Furthermore, I was also hoping I can emulate the remote control using a regular wireless networking card. Maybe that was too naive.
Maybe someone can enlighten me here? :)
Wireshark, in its typical usage, is designed for capturing and analyzing network packets, primarily those used in Wi-Fi (which is indeed on the 2.4GHz frequency). However, it's essential to understand that not all 2.4GHz signals are Wi-Fi signals. In your case, the remote control might use a different communication protocol that Wireshark may not directly capture.
But would my network card still capture it?
Network cards are designed to capture and process data that adheres to network protocols, such as Wi-Fi or Ethernet. They are not equipped to capture arbitrary RF signals.
going to pay you the bounty after I verified this :)
Or another question: what would you suggest I do to reverse engineer the remote control? And do I have to buy something specific which I can attach to my machine to send the same signals as the remote but now by pressing keys on my keyboard?
Might be difficult and tedious to reverse engineer a remote control as it involves understanding the communication protocol it uses and capturing or analyzing the signals it sends. Start by searching for technical documentation for your specific remote control or LED strip. Manufacturers often use standard communication protocols, and documentation might provide valuable insights.
Even if you can capture the signals sent by the remote control, you still need help to analyze these signals. Then you'll need to decode them and this involves identifying the modulation scheme, pulse length, and other parameters. If you want to send the same signals yourself by emulating the remote control, you may need to use a device capable of transmitting at the same frequency.
I hope you can all figure these out. Good luck!
https://i.postimg.cc/9fMjymjg/7015125e214bc9ef451616a3bf55aebf.webp
A remote most likely uses Infrared (300-400 THz) band
No, it's not IR, it's 2.4 GHz. Good idea though. I explicitly didn't buy a LED strip with an IR remote since IR needs direct line of sight afaik. And I struggled with IR remotes enough in my life already.
Forgot to include pictures of the package, will do in a few minutes
"in a few minutes"
https://i.postimg.cc/VNgXb3WB/signal-2023-10-16-235725-003.jpg
https://i.postimg.cc/9Qj9gWxY/signal-2023-10-16-235725-002.jpg
TL;DR: it is 2.4 GHz but it is not Wi-Fi, so no Wi-Fi card will ever decode it. Identify the radio chip first, then buy the matching ~€2 transceiver — the same chip both sniffs and transmits, which is exactly what you need for replay. Only fall back to an SDR if the chip turns out to be genuinely unknown. Do not buy an RTL-SDR for this.
Why monitor/promiscuous mode cannot see it
Monitor mode captures raw 802.11 frames; promiscuous mode just hands every L2 frame to the OS. Both only understand the Wi-Fi MAC/PHY. A remote using GFSK/OOK with a proprietary packet format is not an 802.11 frame, so the card never produces anything decodable. Same band is not the same protocol.
Worth ruling out first: if it were infrared it would need line of sight, and an IR emitter shows up as a purple glow through a phone camera. The previous comment claiming "most likely infrared" is wrong for a remote that works through walls.
Also: the common RTL-SDR dongles (R820T2, and the R828D in the Blog V4) top out at about 1.766 GHz, below the 2.4 GHz band, so they are blind to it without a downconverter.
Step 1 — identify the chip before spending anything
The cheap path (this is what I would do)
An nRF24L01+ module costs about €1–3 and pairs with an ESP32, Arduino or Pico. Scan RSSI across channels to find the active one (the register default address is
E7E7E7E7E7, and channel 76 / 2476 MHz is the common library default), then run a sniffer.One honest caveat people repeat wrongly: the nRF24L01+ does not have true promiscuous reception. You must know the channel, and you only need the upper two bytes of the address, because sniffer firmware turns off the module's internal packet/CRC and retransmit handling. Useful starting points:
TMRh20/RF24URL redirects here)Because the same chip receives and transmits, replay is a few lines once you have the bytes. That answers your second question directly: you do not need extra hardware to send.
If you want a purpose-built tool instead: Bastille's RFStorm
nrf-research-firmware(https://github.com/BastilleResearch/nrf-research-firmware) flashed onto an nRF24LU1+ Logitech Unifying dongle (the nRF24LU1+ variants are model C-U0007) gives sniffing and injection, and Bitcraze's Crazyradio PA (also nRF24LU1+, 20 dBm with LNA) does nRF24 RX/TX straight from a PC over USB.If the chip is not Nordic: CC2500 modules driven by an ESP32 work fine, A7105 and LT89xx have Arduino drivers, and BK2421/BK2425 registers are close enough to nRF24 that an nRF24-style driver can be ported.
The general path — a 2.4 GHz-capable SDR
Only if the chip is unknown or custom. You need something that can both receive and transmit at 2.4 GHz: HackRF One (1 MHz–6 GHz), LimeSDR Mini (10 MHz–3.5 GHz), or USRP B200 (70 MHz–6 GHz). Then record raw IQ and use Universal Radio Hacker (https://github.com/jopohl/urh) to auto-detect the modulation, demodulate, reconstruct the protocol and transmit it back — it has a record-and-send feature plus fuzzing. GNU Radio for anything custom.
This is the €150–300+ route, which is why it is step 4 and not step 1.
Replay: fixed vs rolling code
Press the same button several times and compare the captured packets (or the raw bytes if you only have the cheap sniffer):
Cheapest-first plan
Do not buy: an RTL-SDR (no 2.4 GHz coverage), a "monitor mode" Wi-Fi card, or a HackRF as a first move.
Legal, briefly
2.4 GHz is licence-exempt ISM, but transmitting is expected to stay low-power and adaptive under ETSI EN 300 328. Replaying to your own light strip is fine; never jam or interfere with links you do not own.