Welcome to CuVoodoo,
the sorcery of copper.
Today I want to talk about this.
This is the remote control for the garage doors of the building,
and also the main building's gates
Whenever you press the button the garage door opens, and then you can park your car.
Every resident of this building has these remotes if they want to access the building.
And I wanted to know if there is a lot of security in this remote control system, or if it's very easy to clone.
This is the device.
We don't have a lot of information about it.
There is nothing written on it.
There is has just one button.
We don't know at which frequency it operates,
who is the manufacturer,
or things like that.
And even if we open the device ...
This is how you open it.
This is the back.
There is not a lot in there.
There are some codes,
some battery,
and even if we take the plastic off ...
This is just the rubber for the button.
On the other side, if we look at the device,
there is not a lot of information on there,
or a lot of components.
One micro-controller, one crystal, one button.
Some unpopulated components.
But is does not seem to be anything fancy.
It also doesn't tell us anything about the remote itself.
We still don't know at which frequency it operates,
or who the manufacturer of this device is.
One way to figure at which frequency it operates would be to take a Software Defined Radio (SDR),
like this RTL-SDR.
That's a very inexpensive SDR which you can get for $20.
Then plug it into your computer,
press on the button,
and see on the spectrum if there is some activity going on.
This is a very hackerish way, which is not efficient, and you'll have to spend some time.
A more efficient way would be to gather first information about the device itself.
So we want to have more information about this device,
but the device itself doesn't provide any information.
What I did is go around the building
and because this is a sender,
there has to be a receiver at the other end.
So I look a the main entry and the garage entry which device could receive it,
and I didn't find a lot of information,
but at least I could find which is the company doing it (Linear).
So just by looking around I could already find the manufacturer.
But this is not enough.
We have to find more information about this remote.
Since this is used in the USA,
in the USA whenever you have remote transmitting signals,
you have to get accreditation from the FCC,
where you show that you respect some regulations.
On the device itself there is nothing written,
but if you look at the back,
here.
there is space for a sticker.
This doesn't have the sticker,
but what I did was just run around the building again,
and this time ask the other residents to have a look at their remote.
And after some time
I found someone which has also a remote,
which is a bit different.
This one has one button.
This one has four buttons.
But if you look on the back,
then you will see this has a lot more information.
It shows you at which frequency it's operating:
318 MHz.
And this already helps a lot.
But it also tells you is that it's from Linear Corp.,
that the model is ACT-34B.
This is a very good start already.
And this will save us a lot of time.
Now that we know that it operates at 318 MHz
we can use the SDR and have a look at what it transmits.
I will use my RTL-SDR dongle.
Plug it into the computer.
There is the antenna.
And I'll just press on the button.
To see the transmission I just use a tool called sdrangelove.
It's a quite convenient Linux tool which works well.
We start the acquisition.
We set 318 MHz, 'cause that's the frequency indicated on the remote.
The sample rate I set it at 1 MHz,
for better refresh rate of the graphic.
And now we press on the button and see ...
And here we can see some quite clear traffic.
On top we have the Fast Fourier Transformation (FFT), which indicates at which frequency the signal is transmitted.
It's around 318 MHz.
There's a small offset.
In the middle we have the waterfall diagram.
The idea is the same as the FFT but is also has the time component.
You can see the FFT just falling down.
That why "waterfall" diagram.
And on the bottom you just have the components of the signal.
We can see the signal is quite simple, and there are peaks of transmission.
This indicates that it uses just Amplitude Modulation (AM),
and simply ON/OFF.
No intermediate level.
Like Morse code.
sdrangelove allowed us to verify that it's really at 318 MHz.
And it gave us the neat piece of information,
that it's probably simply pulse code using AM.
Now we want to record the signal, to have a deeper look, and to find a pattern.
sdrangelove doesn't allow us to record the data.
But there are other tools which use the osmoSDR driver and can talk to the RTL-SDR.
The next tool tool is simply rtl_fm.
This is a very simple program which is actually used for FM demodulation using this RTL chip,
which you can find in the RTL-SDR.
So we'll simply use rtl_fm,
specify the frequency: 318 MHz,
specify the modulation: AM,
then we'll simply put the demodulated data into the test.pcm file.
So it starts the software defined radio, the dongle.
Press several times on the button, just to record several transmissions.
Then we just need to open this demodulated data.
You can do it for example with an audio editing tool, like audacity.
So we start audacity.
File, Import, Raw Data.
test.pcm.
This data is saved as sign 16-bits PCM.
It's just in the specification of this rtl_fm tool.
But the sample rate as you've seen in the output is 24 kHz.
And it's only 1 channel, little endian.
This parameters are quite important if you want to decode the data properly.
Here we have the data decoded.
I pressed four times on the button, and we can see four bursts.
We can look inside the bursts.
Then we have the clear pattern.
Now we want to figure out ...
This is probably just pulse code modulation.
And now we want to figure out what the encoding is,
and what kind of data is transmitted.
We could just ...
We know where the bits are, but we have no idea what the modulation is.
We can see that the distances between two pulses are quite regular.
We have here either 6 ms,
or we have 3 ms,
or we have 9 ms.
And this just repeats all along until here.
Here we have a longer space.
Probably this is a second transmission, because if you look at it,
you will see that the pattern is quite similar between this burst and this burst.
So it's probably two transmissions of the same signal,
And if you count the number of pulses which are in the signal,
you will find there are 24 pulses.
And that the interval between the pulses is quite regulated.
So we have 24 pulses within 150 ms,
and they have either 3, 6 or 9 ms separation.
This is a good start, but we want even more information.
We want to find more about the encoding.
And we have already looked at the signal,
but maybe the manufacturer will provide some more information.
And this is why it was important to get the sticker on the back of the remote.
We know it's a Linear product.
"linear remote control", let's Google that.
And yes, Linear Corp, as we saw.
We click on the Linear Corp. link and see what products they have.
They have lots of radio control, but we are only interested in the ACT-34B.
And we can see here the ACT-34B.
We are on the right path, and it already gives us the link to the product.
We see 4 buttons.
Again here: 318 MHz.
Number of codes: 1 000 000 codes.
Well, in 24 bits you can store 1 000 000 000 codes.
"read more".
Nothing interesting.
Again, 318 MHz.
Here the order number. This is also what we saw on the back of the remote.
Lets see about the documentation.
Installation manual.
Lets have it downloaded.
And here is just a manual which again tells us the same name.
It's part of the Linear MegaCode series.
So the encoding if probably the "MegaCode encoding".
It's the ACT-34B.
And you can see it has a small sister, the ACT-31B.
This is the remote I have, with only 1 button.
The other one has 4 buttons, which they also call 4 channels.
It has some ID encoding, "Block Coding".
But else it does not tell you a lot more information.
Except here: IMPORTANT.
"Linear radio controls provide a reliable communication link", then it talks about the FCC.
And this is a very good thing in the USA,
and we've seen it on the remote,
it's the FCC ID.
Remember, on the back of the remote we found the FCC ID.
In the USA whenever you have a radio transmission device
you have to be compliant to some regulations.
And the FCC ID allows you to read the documents, where this compliance is described.
If we look at the back ...
Let's go on the website, FCC ID.
FCC ID search.
The website is a bit slow, but it still works.
Redirecting..
Please redirect me.
And here.
On the back we saw EF4,
and then the product code being ACP00872.
And this is also the part number which we found on the bottom of the remote.
It matches what we need.
Search.
And here we have it.
We see again "Linear".
We saw the FCC ID matches.
And if we see here: "318 MHz".
This is exactly what we found.
If we look at the details ...
OK.
There are lots of documents, which are all quite interesting.
But let's have a look at the test report first.
This describes it complies to the FFC rules part 15,
for radio communication.
What's interesting is here: the modulation.
The modulation is pulse position A1D,
AM modulation (Amplitude Modulation).
If you look for the types of modulations,
A1D stands for:
A is double-sideband amplitude modulation (AM),
1 stands for 1 channel,
as we saw in the specification it's only 318 MHz,
and D means data transmission, telemetry or telecommand (remote controls).
It's simply AM signal, with only ON/OFF, like On-Off Keying (OOK) Morse code.
And here they say it's pulse position.
As we've seen it, we have different positios of pulses.
Either 3, 6, or 9 ms.
That already helps a lot.
But what's even more interesting ...
Here we can see a bit more compliance, which is less interesting.
But what is more interesting is
we saw that they're telling it's from the MegaCode series,
and here we have two MegaCode documents.
And if we lokk at the MegaCode documents,
it tells you approximately how the transmission happens.
Let's have a look at the second document too.
Wrong way around.
Rotate it.
And here we can see how it's transmitted.
You see again we have 24 bits,
like we saw in Audacity when we decoded the signal.
24 bits, so this corresponds to the MegaCode timing diagram.
Here they say there are 24 pulses.
The first pulse is a sync pulse.
And the last pulse is a blank cell. It's a frame with no pulse.
Each other frame, 20 system code frames and 3 data bits, have pulses,
which are every time 1 ms long.
And this 1 ms is within 6 ms.
This also corresponds to what we see.
The maximal difference we found was 9 ms.
And the minimum is 3 ms.
And we also find 6 ms.
This could represent this timing diagram.
If we look here there is a bit more description.
25 pulses.
The last one being not a pulse.
Pulse-keyed carrier, so either on or off.
Each pulse is 1 ms long.
This we've already seen.
And then one pulse occurs within a bitframe of fixed 6 ms.
And if you add 25 times 6 ms, you'll come to the 150 ms we saw.
24 bits of information which are sent.
So we know from this documents that there is one pulse every 6 ms.
We know that there are 24 bits.
There is a sync frame,
23 bits actually,
and a 24th which it just a blank cell.
We have 3 data bits and then we have the system code.
And this give us actually quite some information.
If we go back to the signal we recorded,
We can see one signal.
This is the 1 ms pulse, which we can see here.
1 ms.
Which happens within 6 ms.
If you look here, it's around 8 ms.
Here there is a small gap,
only a small gap, which is around 3 ms.
Beginning to beginning it's 3 ms.
Sometimes you find 6 ms.
Sometimes again you find 9 ms.
But we know there is one pulse every 6 ms.
And the position of the pulse is important.
So within this 6 ms,
it's either the position depending on the previous pulse,
or the position within these 6 ms.
And if we look at it, because we have either only 3 ms difference,
6 ms difference or 9 ms difference,
actually what is means is that,
if the pulse is within the first 3 ms of this 6 ms bitframe,
then it's probably a 0 or a 1.
And if it's within the next 3 ms, then it's a 1 or a 0, depending on the encoding.
And this is how they encode the signal.
This is also why we can see the time difference either being 3 ms.
Here we have 1 bitframe of 6 ms.
The pulse is in the second half of this bitframe.
In the first half there is no pulse.
Here starts the new pulse.
Again 6 ms.
And here the pulse is in the first 3 ms of this 6 ms bitframe.
This is also why we have only 3 ms difference.
This is 6 ms. This is 6 ms.
And then this is again 6 ms,
and we can see here the 9 ms difference
comes because the pulse in the previous bitframe was in the first half,
and the pulse in this bitframe is in the second half.
This is why we have either 3 ms difference,
6 ms difference,
or 9 ms difference.
Now we know how the encoding is done,
and we want to decode this signal.
Here we have the 24 bits.
This is the sync bit.
These are the 23 data bits.
And then there is a last blank cell.
The code is repeated again.
As you can see, the pattern is the same.
So now we found the encoding,
thanks to the documentation and a bit of thinking.
And now we want to write a software which does the decoding of this data for us.
To decode the data I wrote a little program called decode.rb.
It's just a ruby script.
We can feed it with test.pcm,
which we can see here.
So how it works is that it first detected the edges.
The edges are these things.
These things are edges, and this is what is detected first.
Then is knows that the bursts are 1 ms long.
This is 1 ms long.
And this is what we see here: it regroups all the edges.
It starts at this edge, and whatever is within these 1 ms is just ignored,
and put into a group of pulse.
These are the pulses.
Then we know that the pulses, the bursts, are separated
by at least 12 ms between two groups.
This is the group of bursts.
This is the next step the program does.
It separates the bursts from each other.
This is the first burst.
This is the second 24 bits burst,
because they are separated by at least 12 ms.
This is yet the third.
And the we have a small garbage just at the end.
This is what we see in this step.
Afterward, when we have these groups of 24 bits,
the 25th is just a blank cell,
we check if these a real transmissions.
A transmission needs 24 bits,
and also is has to have 1 pulse with 6 ms.
And this 24 times.
This is what I sort here.
And then from these 3 transmissions I extract the values (codes),
And these are the codes which I came to.
This is the hex code of the 24 bits,
We can see all 6 hexadecimals which represent 24 bits.
And this is just something which I try to decode.
The system code which we saw in the MegaCode description.
This is the system code.
Always starts with 1.
And then we have the data bits which are the 3 last bits in the end.
And this is what my decoding program does.
Now we figured out the remote:
at which frequency it operates,
what kind of modulation it uses:
AM modulation,
how the MegaCode code is encoded.
Thanks to the SDR we can read the code.
And as we can see it's the same code which is repeated all over again.
The remotes don't sync with the gate.
They don't have rolling code which change very often.
And this indicates it's very easy to clone.
Because once you figured the code, you just have to send exactly the same code over again,
and you can open the garage door.
This is probably simpler, so you can install just a receiver at the garage door,
preprogram the remote codes,
and tell only "open for these remotes",
on each garage door,
and you don't have to have a central system,
which manages all the remote codes.
On car keys which also use remotes,
they have a rolling code.
So every time you press on the button,
it will be another code.
In the central system, being the car,
there is the initial seed,
and then it know a which position you are,
and from the initial seed it can calculate all the next codes.
And every time you press on the button, you'll go to the next code.
This prevents against these replay attacks.
But this also means that every time you transmit,
The receiver has to know "OK, he is already a the next code",
I will remember this state,
and whenever I get the next press,
I just calculate the next code based on the seed and the previous number,
and I can know if it's the right code.
For this system you need a central management for the key.
which can always synchrosize with what the remote sends.
It costs a bit more money to implement,
and then you need also to have all receivers synced.
Because I could press to open the garage door,
but I could also got to the main buildings gate and press there.
And if the two systems are not synchronized,
then at one point I wouldn't be able to open one or the other gate.
And having a central system to synchronize the receivers on both sides cost also a bit more money.
This is probably why they didn't implement it.
Here it's the same code which is repeated over and over again.
There is almost no security.
Once you have the code you can replay the code.
And this is what we will do next.
We know that the code can be replayed all the time.
We'll try to flash the device, or to flash another device, with our code.
To program our code in the device.
Lets have a look at the device.
Lets look again at the device and see if we can flash it with our own code.
We'll open it.
These are probably some things corresponding to the codes we saw when we decoded,
but I couldn't figure out what they mean.
It's also not important what they mean,
as long as I respect the same data format which is sent it's really not important.
Here we have the batteries, as power source.
There is nothing else.
Some resistor.
Here we can see the antenna,
which is integrated in the PCB.
And then we have the main components.
The micro-controller, responsible for sending the code.
Here we have the 318 MHz clock, for sending at the right frequency.
And then we have some small components, which are just there to enable the transmission.
Here is the coil just before the antenna.
This is the connection to the antenna.
And here the button to trigger it.
But if we look closer ... can we zoom?
If we look closer at the micro-controller,
they use a PIC12C508A.
In the data sheet you will see that this is a One Time Programmable (OTP) EPROM chip.
So even if we know where the connections are,
it's a Microchip PIC,
and we have lots of test points where we could connect to,
or connect directly to the pins,
we won't be able to re-flash this device, since it's an OTP device with EPROM. actually my programmer does not support this device due to the higher EPROM voltage
But we won't stop here.
We saw from the PCB that is uses a PIC12C508A,
and actually you can even see it in the schematics.
This schematic (board layout) shows you where the components are,
it even indicates you the silk screen,
and the reference designators of the components.
And there is the second schematic,
which tells you what parts it uses.
Up to 4 switches,
because the ACT-34B has 4 buttons.
These are pull-ups.
The two batteries.
This is the antenna.
This is the inductor we saw.
Here we have a couple of the transistors we saw.
The 318 MHz crystal.
Passive components like caps, diodes.
And here the main chip, which is again a PIC12C508.
And then if we look at the PIC,
we will see that it's EPROM based CMOS controller,
and it's One Time Programmable only.
If we search a bit more on Amazon or eBay,
and we look for MegaCode remote control,
which are compatible with the first one,
we can probably see if somebody else did already that.
Because the device is quite simple.
All the FCC documents explain almost all the details need to re-implement this protocol.
Probably somebody already created a clone.
If we look at the products, you will find here:
Linear compatible keychain remote, by Transmitter Solutions.
And what interesting with this one ...
It operates at exactly the same frequency.
It uses the Linear MegaCode.
It's compatible with it.
Lets look at the product description.
Technical Data.
That's the name: 318LIPW1K.
And on the manufacturer page: Transmitter Solutions,
here we have again the 318 (probably for MHz) LIPW1K from Monarch actually.
It's the Monarch series.
We see it's only one button,
but what's interesting is this information: it's programmable.
It's compatible with the ACT-31B which we have,
and it's also programmable.
And if you look at the manual,
you will see here a section which is quite interesting,
which is called programming.
Programming.
It does not tell you a lot, but it indication a information which is interesting.
The second indication is this FCC ID.
We saw already for the first product that the FCC ID is very useful.
It provides a lot of documents.
Sadly this one doesn't provide as many documents.
It just provides the user manual,
the test setup for doing the measurements,
so you can prove that you comply to the FCC part 15 regulation.
But is also has one internal picture.
And if we look at the internal picture.
It's this one.
This is the inside of the remote.
The button is red instead of blue, but it's not too important.
Two batteries.
What's interesting is this detail here.
Here you can see you have a programming header.
So probably we can really program this micro-controller here.
Here we have the clock again. The antenna.
Some transistors.
Here the is even an LED.
But the most interesting part is here.
This programming header which is unsoldered.
So lets buy one of these remotes.
This is the remote.
We'll have a look inside to find out which chip it uses.
These are a bit harder to open than the other one.
On the back we can see again the FCC number,
the model number, the FCC ID,
and then some numbers.
Here there is a hole,
because on this one I already soldered the programming header which we found on the picture.
And to access it, whenever the case is closed, I just have this hole.
So I can access it all the time.
And here is the device.
Nothing more than 2 batteries,
the oscillator for the 318 MHz,
some components, the LED.
The button is actually on this side.
This is the button.
Here is again the number which will be transmitted.
And here is the micro-controller,
and this time it's a PIC12F series.
The F stands for flash.
So this one is re-flashable.
And with these headers,
we just have to find out which header is connected to which pin,
which programming pin.
The we simply get one of the PIC programming kit.
This is a PICkit2 clone.
It's less expensive than the PICkit2 but it's exactly the same hardware.
You just have USB on the one side,
and then RJ11 on the other side.
This is the cable which I already prepared.
And then you can plug it on,
and see if you can talk to the chip.
This remote,
the 318LIPW1K from Monarch,
uses a PIC12F629.
It's flash based.
We can reprogram it.
And I tried to look with the PIC chip programmer,
but they use code protection and also data protection.
So I cannot read the code which they use, the firmware itself.
And I cannot read what value they stored in the EEPROM.
Probably they stored the value which they want to transmit into EEPROM.
Since I cannot read it, I don't know the encoding which they use.
But that still won't stop us.
We have the chip.
We have a programmer.
So why not program the chip ourself.
The previous product had actually two schematics,
which was quite useful.
So here we have the schematic, so we would know which pin is connected to which peripheral,
so we could directly implement.
But this is not required by the FCC to be compliant with part 15.
Actually you only have to show at which frequency you transmit,
at which power,
how long,
how frequent,
how good you filter,
how much you transmit in the harmonic frequencies,
and so on.
And this is what Controlled Entry Distributors shows.
But they don't give any schematics,
and they also don't talk about the MegaCode.
Linear does not have to talk about it,
so we are lucky that we found the MegaCode document.
But this one does not talk about it.
We won't be able to use the schematic.
But simply using a multi-meter and the data sheet ...
This is the micro-controller,
with some description,
and here we have the pinout.
So we know which pin does what.
And then using the multi-meter and the continuity test,
I just figured out which pin if the chip is connected to which pin on the programming header we have.
and also he other peripheral which they use.
This is very simplified. This is not the complete schematic.
But it's enough to understand what is connected to what.
Here we have the programming header.
Here we can enable the clock to have 318 MHz transmission.
Then we have the input switch which is connected to ground,
so there should be some pull-up resistor, either external or internal.
Here we have a connection to the antenna.
This is where we enable the transmission.
The battery I didn't show it, but it's between ground and VCC.
And then we have one LED, which is quite nice
so whenever we program the micro-controller,
we can at least use the LED to have some debugging output.
Lets go to work and re-program the firmware for this micro-controller,
now that we know which peripheral is on which pin.
Here we are.
I wrote a firmware.
This is for PIC chips.
It's my first PIC implementation.
I'm more an Atmel AVR guy.
Now that I tested also PIC, I still prefer AVR.
I think The Linux support is a bit better for AVR than for PIC chips.
But still, it's a micro-controller, and it's not too complicated to program.
Once you understand one, you basically understand most of them.
They just have slightly different ways how they work.
On the left you can see the firmware which is implemented.
It's only 190 lines long, and it has lots of comments.
This is the program which will send the MegaCode code.
On the right this is the EEPROM, which will get flashed.
And this is where you simply put the code which we want to transmit.
And here we can flash the device.
If we "make" it,
it will compile it using SDCC,
and if it's compiled, it will flash it using pk2cmd.
And now we will test the program.
Here we have the original remote.
Here we have the 318LIPW1K remote which we flash with our own firmware.
And here is the SDR.
And now we want to try if with this remote I can send the code from this remote.
Again we can see here sdranglove,
to verify it's the same remote still acting on 318 MHz.
Stop the recording.
And if I look at this one,
this is the same code.
You see the groups are not right, but it's not a perfect scenario right now.
Now we want to try the other one.
First we have to look at which frequency it transmits.
It should be around 318 MHz,
but it's never exactly 318 MHz.
And as you can see, it's more 317.96 MHz.
Yep, 317.96 MHz.
And this slight difference is big enough for rtl_fm to make a bit of a difference.
317.96.
Switch it on.
Press on the button.
And then let's have a look.
And now we have the exact same code.
If I would have used the 318 MHz, rtl_fm wouldn't have found it decodes AM radio specifically on this frequency,
and the bandwidth is not very big.
But we've proven now that we can get a code from any remote,
using the SDR.
And using a off-the-shelf remote, which is just $20,
we can re-flash or own firmware, and sent the exact same code.
So now we can really clone remotes.
And we have seen that these garage doors are not very secure.
video blog: https://www.cuvoodoo.info documentation wiki: https://wiki.cuvoodoo.info source files: https://git.cuvoodoo.info Creative Commons Attribution Share-Alike 4.0 International