Teach us your protocol reversing tricks oh wise PB

So PB any chance you could put your Fravia hat on for 10 minutes and teach us some of your protocol reversing techniques? If I remember correctly I have heard you talk about test rigs involving Raspberry Pi's and Arduinos. A few tricks and tips might help more people to help you, do doubt you have learnt much through your various protocol travels.

Probably safe to assume people reading this far will already be familiar with the code of the current protocols.

I'll take anything you can offer but a few pointers and maybe some code from your test rig would be supreme. I realize it may not be well polished but it wouldn't bother me.

As a starter how on earth to you derive the channel hopping tables ?

Thanks so everything so far !

Cam.

th9xer wrote: So PB any chance you could put your Fravia hat on for 10 minutes and teach us some of your protocol reversing techniques? If I remember correctly I have heard you talk about test rigs involving Raspberry Pi's and Arduinos. A few tricks and tips might help more people to help you, do doubt you have learnt much through your various protocol travels.

Probably safe to assume people reading this far will already be familiar with the code of the current protocols.

I'll take anything you can offer but a few pointers and maybe some code from your test rig would be supreme. I realize it may not be well polished but it wouldn't bother me.

As a starter how on earth to you derive the channel hopping tables ?

Thanks so everything so far !

Cam.

+1 for me

Not only PB, but also victzh, hexfet, etc... .

"give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime" would be translated into

"give a man a protocol and you make him able to fly a new model; teach a man to hack a protocol and your protocol folder will be full" ....

The overall algorithm is easy - connect logical analyzer to SPI bus between the RF chip and MCU, record several stages of TX and RX operation - initialization, binding, stick movement. Study the RF chip datasheet and write decoding scripts - use mine for nRF24L01 and CC2500 if you'd like.

Then if you're lucky, you'll just understand what's going on - there are protocols without any frequency hopping, encryption etc.

If you're slightly less lucky, your protocol is using table frequency hopping - there is a limited table with base sequences and some variations thereof.

You need to get as many correspondences between TX id and frequency hopping sequence as possible. For this you need to put logic analyzer on RX and use mock TX algorithm to bind to many different TX ids. It is useful to make this as automated as possible - connect to bind or reset button on your RX and guide it from your program.

For this setup you also need some luck - some RXs when they get initial binding packet with new TX id start following the whole sequence, so you just record it using your logic analyzer.

Some wait for the first valid packet to follow the sequence - this is a bit more problematic. You need to generate bind packet, then listen to RX for the channel it expects packet on and then generate this packet and only after these dances RX follow with the whole FH sequence.

After you got many correspondences you need to understand the logic. You begin to stare at these long files and write scripts to analyze them - sort in various order, for instance. It can take days or minutes depending on complexity and your experience. It is somewhat close to cryptanalysis, but usually people don't try to protect their protocols very hard. The most complex protocol so far reversed, DSMX, took weeks and collaboration of many people. They also had some luck - authors of DSMX used Linear Feedback Shift Register (LFSR) from the literature with some variations.

Some protocols don't bother with secrecy so much that they just pass the sequence as a part of binding process - HiSky does this.

Also, there is CRC algorithms used by some protocols, they need similar approach.

Best way to learn is to try it yourself. Get soldering iron and cheap TX or RX with reasonably accessible SPI bus and try it.

I use much less advanced Arduino test rig. It requires to recode protocol for Devo, but operates in Devo's stick ranges (minimizes recoding as arithmetics holds) and fits my gutted Devo 7, so after I successfully test protocol I can actually control the model.

Wow guys. That was indeed just the insight I was after. All points understood. I guess now all I need is a little bit of luck and the ability to see the wood amongst the trees. Time to test my mettle. No doubt you will hear back from me when it fails

victzh where might I find your decoding scripts? I'll swap you for my A7105 script.

Instructions and link here:
code.google.com/p/rc-ppm-2-spi/wiki/Usingdecodepl

Also PhracturedBlue many thanks for the link to the RaspPi code.

Thanks again.

Cam.

My scripts are in Python, they're attached to www.deviationtx.com/forum/protocol-devel...a-s3x-protocol#20093 . nRF24L01 is much more used and reliable, it participated in reversing several protocols. CC2500 is a modification of the former using just another register set copy/pasted from data sheet and slightly modified to adapt different architecture.

They take as an input CSV files decoded by Saleae SPI protocol handler, so no extra signals like CE for nRF24L01 are present.

I took a look at yours - it expects the same input, so no surprise for you The only difference is my scripts expect 8-bit per transfer, not 4. I understand you use 4 because of 4-bit A7105 strobes.

Again thanks for the replies and scripts, very insightful, just what I was after.

Cam.

PB: Your comment about the Multiplex protocol and it's CRC problem set me pondering. So I did a bit of CRC research, read up etc.

Nice article here on guessing CRC's
www.cosc.canterbury.ac.nz/greg.ewing/ess...rse-Engineering.html It has some basic tests to prove it is a CRC at all, then deduce the poly, etc.

Essential reading: www.ross.net/crc/crcpaper.html (No doubt you already know this, mainly mentioned for the reference of others)

Interesting but not totally relevant www.danielvik.com/2010/10/calculating-reverse-crc.html

Then I stumbled upon this jem ! It can automate the guessing for you
sourceforge.net/projects/reveng/
I have just had a quick play with it and it would seem Multiplex are changing the initial CRC register contents on a per channel basis.

This testing is based on data from here www.deviationtx.com/forum/protocol-devel...art=0&start=20#16371

Feed the program this line:

reveng -w 8 -s 2309097e082d06db81 2309097e082d06dc02 2388058a043802e7a4 2388058a043902e70f 2388058a043802e7a4

Data is formatted so channel number is the first byte, checksum the last, the rest is the payload.

and it reports:

width=8 poly=0x31 init=0xf9 refin=true refout=true xorout=0x00 check=0xbc name=(none)

feed it:

reveng -w 8 -s 3b010a2708d6078460 3b110a2708d607849b 3b010791079107918a 3b8007910791079120 3b010a2708d5078484 3b010a2708d6078460

it reports:

width=8 poly=0x31 init=0x79 refin=true refout=true xorout=0x00 check=0x18 name=(none)

Mess with any of the data and it reports:

reveng: no models found

Sorry for poor formatting, the entire time I was typing this I got "Loading BBCode editor... ". Maybe you want to move this to the other thread, your call.

Exciting stuff

Cam.

EDIT: More testing done - It certainly doesn't hold true for all the data, some of the anomalies you found in the data where the same data has a different checksum obviously fail. like:

11 88 07 d8 07 d8 07 d9 00
11 88 07 d8 07 d8 07 d9 2d
11 09 07 d8 07 d8 07 d8 d9
11 09 07 d8 07 d8 07 d8 f4
11 88 07 91 07 91 07 91 21

Genuine errors perhaps ? (Although the 2nd and 4th lines potentially share a common CRC, not enough data to nail it to one)

again channel 1st, checksum last, payload the rest.

I have tested a good few others packets and checksums can always be found. Polynomial never changes, it's listed here en.wikipedia.org/wiki/Cyclic_redundancy_...nd_standardized_CRCs , so makes sense.

Thanks for the research and for the links, @th9xer. It's a treasure trove!

Different CRC for the same data can be explained by adding some other factor, say odd and even packets. If you add such info to checksummed sequence you'll get your variable CRC. To check this you need longer sequence of packets.