Teach us your protocol reversing tricks oh wise PB

More
12 Feb 2014 02:06 #20154 by th9xer
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.

Please Log in or Create an account to join the conversation.

More
12 Feb 2014 06:55 - 12 Feb 2014 06:55 #20165 by SeByDocKy

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" ....
Last edit: 12 Feb 2014 06:55 by SeByDocKy.

Please Log in or Create an account to join the conversation.

More
12 Feb 2014 08:14 #20171 by victzh
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.

Please Log in or Create an account to join the conversation.

More
12 Feb 2014 14:56 #20194 by PhracturedBlue
Replied by PhracturedBlue on topic Teach us your protocol reversing tricks oh wise PB
Victzh answered better than I could.
The only thing I'll add is that I found my RaspberryPi really useful for the automation victzh talked about (when trying to find hopping tables, etc).
I ported the deviation protocol stack to the Raspberry Pi such that the Deviation protocol code can be run there with no modifications. since there is no upload step, it is nice to be able to change the code, compile and immediately test. For development of for a new chip or a complex protocol, it is really handy.
The relevant code is here:
bitbucket.org/PhracturedBlue/rpi_protocols

Note that it is currently in flux. I'm resyncing it with the latest protocol code at the moment, but in a couple days it should work again.

FYI, for an example of a protocol I wasn't able to figure out:
www.deviationtx.com/forum/protocol-devel...rotocol-analysis-crc
The protocol is trivial, but I wasn't able to figure out the checksum byte after several days of effort. I think we have everything we need to figure it out, I just don't get it.

Please Log in or Create an account to join the conversation.

More
12 Feb 2014 18:00 #20202 by victzh
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.

Please Log in or Create an account to join the conversation.

More
12 Feb 2014 23:55 - 12 Feb 2014 23:57 #20212 by th9xer
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.
Last edit: 12 Feb 2014 23:57 by th9xer.

Please Log in or Create an account to join the conversation.

More
13 Feb 2014 06:20 #20219 by victzh
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.

Please Log in or Create an account to join the conversation.

More
13 Feb 2014 06:23 #20220 by victzh
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.

Please Log in or Create an account to join the conversation.

More
15 Feb 2014 10:59 #20296 by th9xer
Again thanks for the replies and scripts, very insightful, just what I was after.

Cam.

Please Log in or Create an account to join the conversation.

More
22 Feb 2014 19:23 - 22 Feb 2014 20:41 #20754 by th9xer
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.
Last edit: 22 Feb 2014 20:41 by th9xer.

Please Log in or Create an account to join the conversation.

More
22 Feb 2014 20:52 #20756 by victzh
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.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 02:14 #20775 by PhracturedBlue
Replied by PhracturedBlue on topic Teach us your protocol reversing tricks oh wise PB
please keep the protocol development stuff in the proper thread. it makes finding it in the future a lot easier.

This is a really good find on 'reveng' though!

Please Log in or Create an account to join the conversation.

Time to create page: 0.048 seconds
Powered by Kunena Forum