OpenSesame

Sub-GHz
#17

I’ve been playing around with my FLIPPER only for a few days, and I must say that it is a very enjoiable device, but I don’t think that it will be that easy to use it to hack wireless devices. You can’t expect to feed it with an unknown sequence and expect it to magically open gates and garage doors.
I’ve seen the OpenSesame and the DeBruijn sequences in the “UberGuidoZ” folder, but I think they can succeed only with very old and outdated systems.
I live in Europe, and most the equipments installed on gates and garage doors around here have protocols which are pretty complex (or, well, not so basic at least): they introduce the need to repeat the code multiple times to be accepted (therefore avoiding the chance of using the above mentioned OpenSesame or deBruijn sequences), they introduce “pauses” betwenn code repetition (therefore increasing the lenght of the of the sequence), and so on.
I made a “quick” estimation, if I could bake (and I will for sure, as soon as I will have enough time) the proper sequence for the flipper (taking into account all the above mentioned tricks) it would take more or less 6 minutes for the flipper to play it… and that sequence would probably work with that specific equipment only. It’s very unlikely that you can bake an “universal” OpenSesame sequence nowadays.
By the way, these are just my 2 cents…

2 Likes
Has anyone tried to port Open Sesame to the Flipper?
#18

You are correct, I had my flipper for a couple of weeks now, I already built bruteforce file for CAME 12 bit gate which is working just fine.

It would take 16 minutes to run the sequence. As you said you need to account for the pauses and leading signals, and I found out you that need also to add extra pauses between the codes or else your flipper will drop around 10 -25 % of the keys sent.

Now this is could be practical for a known protocol and 12bit protocol, but if the gate uses 24 bit forget about that completely, as it could take years to bruteforce it.

Regarding opensesame sequence its very old sequence and its extremely unlikely to find something use it now, as it depends on only sending 0’s and 1’s without any protocol.

1 Like
#19

Can you please share your code? How to use it?

#20

Very interesting
I hope we will have news of your research.

#21

Which news ?

#22

check this post

1 Like
#23

Did you success to implement this and open you garage?

#24

Yes, its working

#25

Can you please check explain the steps how to do it with flipper zero?

#26

Or post .sub file for example here - Flipper/Sub-GHz/Garages at main · UberGuidoZ/Flipper · GitHub …

#27

I am also asking for information on how to create a .sub file.
I don’t know much about Python, thanks.

#28

I add all sub files and the script to github

#29

Thanks !!!

#30

Thank you!

#31

This is actually very useful thanks. Would it be possible to create a program for the Flipper ti generare those codes “on the fly” instead of using pre-calculated files?

#32

Unfortunately I have no experience with flipper firmware development, hopefully someone can do it which I really doubt it can be done due to the flipper processor power.

#33

everything is possible within reason, and the performance of the flipper processor will be enough

2 Likes
#34

hmmm, the processing power of the FZ might be enough, but I think it’s not worth trying. If you need to bake a sequence hoping it will succed, you have to be prepared, well documented, and be well aware of what you need to produce. If you find yourself in front of an unknown brand of gates/garage doors, there’s no chance you can open it without knowing how the code is transmitted (the PROTOCOL). How many bits? How are ONEs and ZEROs coded? How many times the code needs to be transmitted? And so on.
And, if you have all of these informations already, it makes more sense to pre-bake the sequence when you’re home in front of a PC.
Or, if you are an android user, you can chroot a linux distro in your phone/tablet, install python and the neccessary libraries, and generate the sequences on your phone.

#36

#include “types.h”
#ifndef LOCAL
#include “flipper_zero.h” // ← Replace include statement for “cc1110.h” with this
#endif
#include <math.h>
#include “ioCCxx10_bitdef.h”
#include “display.h”
#include “keys.h”
#include “garages.h”
#include “rf.h”
#include “fbuffer.h”
#include “zsprites.h”
#include “pm.h”

#define title printl(0, " OpenSesame 1.0")
#define HIBYTE(a) (u8) ((u16)(a) >> 8 )
#define LOBYTE(a) (u8) (u16)(a)

#define SET_WORD(regH, regL, word)
do {
(regH) = HIBYTE( word );
(regL) = LOBYTE( word );
} while (0)

/* note sdcc wants reverse bit order from datasheet */
typedef struct {
u8 SRCADDRH;
u8 SRCADDRL;
u8 DESTADDRH;
u8 DESTADDRL;
u8 LENH : 5;
u8 VLEN : 3;

u8 LENL      : 8;

u8 TRIG      : 5;
u8 TMODE     : 2;
u8 WORDSIZE  : 1;

u8 PRIORITY  : 2;
u8 M8        : 1;
u8 IRQMASK   : 1;
u8 DESTINC   : 2;
u8 SRCINC    : 2;

} DMA_DESC;

__xdata static volatile u8 txdone = 1;
__xdata static volatile u8 ni = 0;

__xdata DMA_DESC dmaConfig;
__xdata u8 realbuf[MAXLEN+1];
__bit sleepy = 0;
__bit txFast = 0;

extern u8 _garage_id = 0;

void configureSPI()
{
// Modify this function to use the Flipper Zero API for configuring the SPI interface
flipper_zero_spi_init();
}

void setup_dma_tx()
{
// Modify this function to use the Flipper Zero API for configuring the DMA controller
flipper_zero_dma_init();

// Set up the DMA

Would something like this make things work on f0

#38

This is for European use only (433.98 MHz and 868.35 MHz). In the USA, the frequencies used are 300 MHz, 310 MHz, 315 MHz, 318 MHz, and 390 MHz. There may be others, but those are the main ones used for garage and gate openers, car remotes, alarm remotes, etc.