Why dont we write an app to bruteforce this protocol?

[alvarotorijano]

Hi, having a look at the table of the switches and having the signals, do you know ho the protocol generates the bitstream? would be possible to write an app that bruteforces this protocol...

[jimilinuxguy]

I have recorded all 256 combinations, although only 127 are used. There isn’t a clear pattern to how the data is generated. The encoding isn’t a known encoder like PT2212 or similar. It’s actually an STM8L MCU that is driving it. There are four pads that look like they were UART or similar but they are all tied to ground as well ass the RX and TX pins on the MCU.

I’m continuing to work on reversing the protocol with a buddy @pickeditmate.

for now though you have all possible cu8 and sub files. Given that there are only 127 combinations and they aren’t sequential, would a brute force be beneficial to you? It seems like it would be slower than just queueing up the known captures in a playlist app on the flipper or HackRfF?

What are your thoughts on the matter?

[jimilinuxguy]

Also I did write a little machine learning model to attempt to predict the output of any given combination of 8 but input. It has an accuracy of about 85%. It doesn’t tell us the algorithm used to encode the signal but looking at the weights and features may give us a clue

[alvarotorijano]

Well, a play list is definitely a good aproach. I've managed to modify the player to skip files but I'm not able to rewind the play list or jump to the previous file. Waiting for the debugger to continue this feature. I was writing down just to tell you to about using a MLP neural network. Might increase the size of the network in layers could help?. I'm going to check this out with @fcolecumberri.

[alvarotorijano]

On the other hand having the full truth table can also be valid to detect and capture a signal although it is not ideal in any way.

[alvarotorijano]

or increasing the input size of the vector because there's could be more bits added by the firmware wich the user cant switch

[jimilinuxguy]

Hey, soy de Zaragoza :) I just saw your profile. Are you guys on discord by chance? Would love to talk about this further and maybe collaborate ?

I can post the model that I wrote shortly, as well as pictures of the board and components as well.

[alvarotorijano]

find me at Alvaro Torijano#3306 Github still misses MP messages ¬¬

[alvarotorijano]

Hi jimmy find a POC code that will encode and decode the protocol https://gist.github.com/alvarotorijano/0298e515e3ec02d457c8f3d07be03d04 Now it is time to add this protocol to the flipper working protocols. Do you know if the modulation used is already implemented in the F0 or configured for the CC1101? (BTW I've done some projects with this uC and I could try to configure it and test it by sending the raw file from the hackRF).

[CaitSith2]

From my investigations into this protocol, it is a packet that is repeated 20 times, taking a total of ~2.75 seconds to transmit.

It consists of a blank period that takes 12ms to transmit, followed by a series of 0, (3 ms), 1 (6 ms) or 2 (9 ms), 20 digits total, sum of the digits must equal 20. Max of 5 1s in a row, Must end in 112, and ignoring any 1s, the pattern of 0s and 2s is 020202 etc.... In other words, once again removing the 1s, there is never two 0s in a row nor is there two 2s in a row in any of the packets. Given that a packet must end in 112, and that the sum of 0/1/2 must be 20, there is always an equal number of 0s and 2s, and always an even number of 1s in a given packet.

The blank is ~10.8 ms off, 1.2ms on, 0 is ~ 1.8 ms off, 1.2ms on. 1 is ~4.8ms off, 1.2ms on, and 2 is ~7.8ms off, 1.2ms on.

As a result of the rules for the packets, there is around ~57K possible packets for this protocol.

[RocketGod-git]

Amazing math on that.