Welcome to CuVoodoo,
the sorcery of copper.
Previously we saw that we can clone these remote for garage doors
simply by recording the signal using a Software Defined Radio (SDR)
and then we take an off the self remote
which we wrote a firmware for the PIC micro-controller here for.
and then we can flash it through the computer and flash the specific code we want to send.
So this is if I have the remote.
What if I want to use the remote of let's say a neighbour,
or a friend, or somebody I would like to help,
in the general interest of everyone.
I could still use this,
but this is quite impractical.
particularly if you don't know where the other remote is and if you cannot control it.
Who knows why!
There is still a command in rtl_fm
where you don't have to exactly tune,
rtl_fm,
in rtl_fm where you don't have to exactly tune at the right frequency,
because the AM decoding doesn't work very well if you're not in the 10 kHz of the target frequency.
You could specify a range,
a squelch,
and the tuning gain by hand.
Here is the squelch level, the steps for the frequency range,
this is the tuner gain.
still AM.
and then decode.
And this helps a bit,
It has a wider range depending on the remote, and it works.
But the other problem is that to do that
you always need the computer on,
and use always the SDR.
And my laptop has a battery which only holds 30 minutes.
This is not practical if I want to snoop on lots of codes,
for one day long
'cause I still want to use my laptop.
It is working, but it's not very practical.
Another thing you could do it just ...
There are receivers already.
Why not look at the appropriate receiver for this transmitter.
And again if you go the the Linear Corp. website,
and we look at the MegaCode radio control,
we have here the transmitters,
MegaCode transmitters,
and here we have receivers.
You can see there is a wide choice of receivers.
MDR for 1 channel.
MDR-2 for 2 channels.
MDR-U and so on.
If we look at Amazon for MegaCode MDR,
you'll see the same products.
You'll see the MDR which is the Linear MegaCode receiver for 1 channel,
This is powered by external 24V.
They are used to receive the code.
and switch on the motors for the garage gates.
The same here, for the MDR-U.
But instead of having 24V, you simply plug it into the mains power
Here on the bottom you plug whatever gate you want to trigger.
And here it goes.
I prefer to take this one,
because first it's cheaper and we want to do cheap things,
but also because it's not connected on mains.
And working on mains is not very good.
You have to be cautious,
and if you're not cautious you can fry things.
With this one you just have to provide 24V.
If we look on the side we have one button to program the codes,
And actually how it works is that if you press on the button,
you then trigger the remote,
and then the antenna receives the signal and will program the code inside.
Now every time the code is received again
it will accept the code,
and when it accepts the code it will trigger the gate.
The connections on the back are very simple:
you have one time ground,
one time 24V to provide the board with power,
and in the middle you can connect the motor.
So whenever this right signal which has been programmed in is received,
it will just trigger the motor.
You can program up to 10 codes on the 1 channel receiver,
and 20 codes on the 2 channels receiver.
And that's the biggest difference.
If you look at the back you will find that is uses 318 MHz.
It corresponds to the remote.
Linear Corp., model: MDR.
The part number. And here is again the FCC ID.
As you can see the FCC ID is always the same:
EF4, which seems to stand for Linear LLC,
and then they use thew part number, which is similar to here.
Probably this is the 1 channel,
and they use the part number for the 2 channel for the FCC ID.
Using this information you can find out about the other projects.
And if you look at the FCC ID search, you can give parameters.
You can say I want every product from Linear LLC which works on 318 MHz.
Then it will list all the products Linear applied for.
But this is not like a remote which sends any signal,
where you have to prove that you respect the regulations,
and show at which power you are sending.
This one is only receiving.
They don't have to send any measurements,
And it this case they also didn't provide any schematic and so on.
Let's have a look inside.
As you can see the device is pretty simple.
What is characteristic is that it's all through hole components.
That makes it very easy to tap on different components,
since you can touch the leads directly.
And the layout is very spacious,
the component distance to one each other.
It's also a single sided board.
This makes it very easy to read which pin is connected to which other pin.
We can see big test points (TP).
Here is TP1. This is ground.
TP2. This is 5V. And so on ...
This is the modification I already did.
It's very easy to figure out which component is connected to what.
And here are the components.
This is the antenna,
which goes through here.
Here we have have an LM555.
This timer is probably used as clock reference for having the 318 MHz.
Here we have an LM358.
This is an op-amp,
and it's used to filter the signal,
so the micro-controller which is here gets a clear code,
which you can then compare with the database.
This is the 4 MHz crystal for this micro-controller.
And here we have an I²C EEPROM,
which will store the codes which are accepted or not.
So whenever a code which is received
and is present in the I²C EEPROM is received,
then it will trigger the relay here.
Here we have the power source.
This one is the voltage regulator.
This is the relay.
Here we have just one switch.
One red LED.
As you can see we have some unpopulated components.
Here you can put a second relay.
Here you can put a second switch.
And this is the only difference between the simple MDR and the MDR-2.
The MDR-2 is for 2 channels.
And 2 channels means there is a second relay.
The software should be exactly the same.
I've already modified this board,
but originally it came with a PIC16C54,
and this is a one time programmable (OTP) EPROM chip.
It also had code protection and data protection,
so I couldn't read neither the program which is inside,
nor the ROM which stores the code.
Correction: my programmer does not support this chip.
It's also not straight forward to read the data which is in the EEPROM,
since they do not use the I²C as it's intended.
It speaks the I²C protocol, and on I²C you need pull-up resistors on the clock and data lines.
Then you use open collectors to set the line to 0V.
This one does not use open collectors,
and they don't have pull-up resistors except for the data line.
The clock line in completely driven by the chip.
And the I²C is simple software bit-banging.
Because the board uses though hole components,
which are very spacious and have connections on the bottom, and because it's single sided,
so all the traces are on the bottom and you don't have any vias,
it quite easy to figure out and to read from the PCB itself which component is connected to which other.
You can still use the continuity test of the multi-meter to be sure,
but it's not really required.
What I did is recreate part of the schematic
to understand how it works.
The central micro-controller is a PIC16C54.
EPROM based, very cheap OTP chip.
And we can see that it controls two relays.
These are the two relays it can control.
The MDR which I have has only one channel,
so it controls only one relay.
It also has only one switch.
The MDR-2 has 2 relays,
and 2 switches.
The board is exactly the same. The software is exactly the same.
The difference is just the price and that more components are populated.
We also have a connection to the LED.
And here we have the chip that we saw, the LM358,
the op-amp which will filter and give a smooth result from the antenna.
We have a 4 MHz crystal clock,
to provide a stable clock for the receiver.
We need a stable external clock because we want to decode the signal very precisely.
And we have the external EEPROM, a 24LC256.
And probably this is where they store all the codes,
and verify if someone is allowed.
A small note:
you can see that they don't use a proper I²C
in that this clock line is actually no pulled up.
It is driven by the chip itself
high and low, and the chip controls the clock line.
Also this line is also not used with an open collector, but we'll se later on.
An interesting thing is that we have 2 wire jumpers.
Per default they us a pull-up to VCC,
but using the wire jumper you can set that to ground,
and this tells us that they probably use the exact same code on different boards,
and probably this is the way how they tell if it's a 1 channel or 2 channel board.
so that the micro-controller knows if there is only 1 switch or 2 switches.
And that's basically it.
Now we have the board and we can read the signals,
and figure out how it's decoded.
What we can also do since it's a single sided board
it's quite easy to remove the solder around the PIC chip using solder wick,
and the we can remove the PIC chip,
and place a socket.
This way we can put back the original PIC chip.
But if we want to replace it with something we can reflash,
we can remove the original PIC chip and replace it with a PIC16F which is re-flashable.
And since we soldered ...
This is the original chip.
Since we soldered, how about soldering directly some cables,
and be able to connect it to the logic analyzer which is here,
and to an oscilloscope, to figure out what the signals are.
Here is an overview.
This is the input voltage.
It says it requires 24V, but it can operate down to 17V.
And here I provide 19V,
and it still works quite fine.
Here we have a logic analyzer,
That a Saleae Logic 16.
This is the remote which I use to transmit my own code.
And these wires go to the micro-controller on the bottom,
and I can see the signal which is decoded by the op-amp,
given to the micro-controller,
and the micro-controller then talks to the I²C EEPROM
to figure out if the code is already in there.
On the oscilloscope you will see the decoded signal,
which you could also see through the logic analyzer.
Actually the implementation was a bit broken,
so my logic analyzer had a bit of issues to decode that.
And this is why the oscilloscope got quite handy,
because you can see how the data is transmitted and so on.
Here on this board I already did the modification.
But normally it comes with this original chip,
directly soldered on the board.
So what I did is remove the solder on this side,
unsoldered the PIC chip,
placed one socket.
Like this.
It's just a DIP18 socket.
Then I could either use the old chip again,
to analyze how the device works,
or I can put my own PIC device.
This is a PIC16 ...
I use this one.
It's a PIC16F1847.
It's one of the top end,
and this way I don't have to bother about the space
since it has 14kB flash.
Also this more powerful chip provides a hardware I²C,
but I couldn't use it 'cause first on the wrong pins,
and also because they don't use pull-up resistors, but do software bit banging.
So I had to re-implement the whole receiving part.
The signal comes from here, from this op-amp.
Decode the signal.
You can also use the switch and the LED for debugging or for testing.
Then I also re-implemented the whole I²C stack using software bit banging,
between this EEPROM and this micro-controller, which wasn't too hard.
In the end you can see I tapped on the voltage regulator,
so I can provide externally 5V,
instead of providing the 24V.
And actually you don't have to provide 24V,
it goes down to 17V.
Still, USB is a lot easier.
And then here I can tap on the chip.
I can either re-program it,
using my PICkit2 programmer.
Or I can connect a logic analyzer,
to listen to the communication between this chip, the micro-controller, and the I²C EEPROM
so I can figure out how they store the code,
or I can dump the codes.
I implemented the firmware from scratch.
And how it now works is that I can re-program it using the PICkit which is connector to the connector.
This is the flashable micro-controller.
And then instead of the 24V we can use the USB 5V.
Have it plugged it.
Remove this.
When I press on the button you can see the LED blinks.
This is more an indication status to know that the firmware works well.
So to debug.
And then whenever I use the remote and press for the fist time,
you'll see the LED stays on.
Whenever there is a new code the LED will go on and stay on,
and the new code will be written to the EEPROM.
If I press the button I just clear the LED state.
And if I press again on the remote you will see the LED briefly blinks,
but it does not stay on again,
because the micro-controller will verify if I already recorded the code,
and if I did it will switch off the LED again.
So whenever I receive a new code it will always be stored in the EEPROM,
and it only will be stored once.
Since this is a 256kb EEPROM
we have quite a lot of space for codes inside of it.
We know that the codes only take 3 bytes.
And if I want to clear the memory I just keep pressing on the button for 5s.
It will blink 10 times
and then it stays on.
Here you can see the LED stays on.
And this goes through the whole I²C memory and erases everything.
It sets it to 0.
We have to wait since it's a bit slow.
Almost finished.
Now it's finished. Now we see it's cleared.
And if I press again on the remote
you'll see the LED is on again.
So we've just cleared the memory.
Another feature is that whenever I provide power and it boots up
it will read all the codes.
And the purpose of that is that when I attach my logic analyzer,
here we just use the bus pirate in I²C sniffer mode,
then I can sniff the whole traffic between the micro-controller and the I²C EEPROM,
and this way I can get all the codes out which are recorded in the memory.
We'll have a look at this on the computer.
Now if we connect to the bus pirate ...
Here we can see we have the bus pirate.
We select mode I²C.
Setting the speed is not really too important since it will read the clock signal.
And if we list all macros,
we have macro 2 which is sniffer.
Let's start the sniffer.
We'll plug in the receiver.
Here it's plugged in. Here you can see it starts reading the codes.
The first code is 0x00 0x00 0x00,
which you can see here.
It knows there is not further code
because every code should start with the MSB of the first byte being a 1.
Let's sniff again,
and trigger the remote to see how it stores the code.
Here you can see that it tries to read all codes again.
But the first code is 0.
And the first being the last one it knows there is no further code.
So it will store at the same exact address the code which it received,
which is this one.
And if we again sniff and press the button ...
Here you see it reads all the codes,
It already found the right code at the first code
so it will not store is in any way.
I disconnected the receiver.
Now we'll connect it again. So I'll power it on again.
And her you can see it reads all the codes.
The first code is present, since we recorded it from the last time.
And in the second one there is nothing inside.
And this is why it stops to read out.
And if we press for 5s the clearing button
we will see that it writes all the memory with 0s.
And this way it clears the codes.
We'll wait a bit.
It's a lot of memory,
and my software bit banging implementation is not the fastest.
I implemented it in C.
Now it's finished.
If I power off and power on the device again
we can see the memory is cleared.
This way we have a receiver which we can power over USB,
or use any wall power to USB converter,
or a cigarette light converter,
and we can place the device wherever we want
and just record the codes which are transmitted nearby.
Since it's fixed to exactly this frequency,
the op-amp is tuned to that,
the antenna has the right size and is pretty long,
the receiving range is actually quite high.
So instead of having the 2-5m from the SDR
using this receiver I can receive codes up to 20m.
So from far away I could record any code which gets transmitted.
Here we have another receiver.
This is the MDR-U.
It's very similar to the MDR
and the main difference is that it uses the mains power socket to provide power,
and the you attach the relay on here to trigger the motor.
If we look inside,
take the board out,
we can see it's a mix between through hole components
and on the other side surface mount components.
I already have some modifications which you see here.
But the design is actually exactly the same.
Even the schematic is the same.
They just changed some wire jumpers to indicate it's the other configuration,
or the other device form factor.
We have the relay, one switch, the LED.
We cannot have two channels. It's only one channel.
Here we have the I²C memory.
Here we have the op-amp.
And here we have the timer.
The crystal clock.
This is the receiving part again.
Here we have the antenna.
And this is the somehow voltage regulator.
Actually the voltage regulator is this one.
And this is to transform mains to 5V.
And here I did some modification.
And same as the other device
it uses a PIC16C54,
which is OTP.
It had code protection.
So I unsoldered this one.
And I soldered my own chip on it.
The same as the DIP version, it's a PIC16F1847.
And I used the exact same code.
The same code can detect if it's the MDR or the MDR-U.
And it works the exact same way.
You press the button to clear the indication or memory.
And I did a last device.
It the same, but here I don't really like working with mains.
And particularly on this one, it's not really isolated.
They use the neutral pin as ground for the board.
So don't try to probe with some oscilloscope or some un-isolated circuit,
'cause you will create a short.
And this is why I blew one of the diodes.
I removed the voltage regulator.
This was a 7805 5V voltage regulator.
now I can also provide power over USB.
And the mains is completely disconnected.
But the firmware is exactly the same.
Now I have 3 receivers which I can place a bit everywhere in the apartment complex,
and listen and record the codes on here.
On this programming and sniffing connector I can just look at the I²C traffic
which is dumped whenever the device is powered on.
Now that we can record any code
we can leave the device just hanging around
with a USB power source,
and we can dump all the codes.
We parse all the dumped codes.
These are all codes with the bits.
And I want to analyze and find out if there is some kind of pattern for this building.
We know that the first bit is always 1,
since it's the sync bit.
We know the three last bits are the data bits.
As you can see they're quite similar.
But I wanted to find out if in the system code their is some kind of pattern
telling if it's the same facility
or if it's a different facility,
and then the remote code.
And this is why I show the distribution.
As we can see there are some bits which come more frequently than others.
These ones.
And the one in the beginning obviously.
We have 395 dumped codes.
These ones are in majority.
Also this one and this one.
But else it's quite random.
This tells us that they probably don't use any separation between the facilities,
or that the system code is almost completely random.
Another way to find out which bits in the code are really important
and which ones matter
is just: take one of the codes which work,
modify it,flash it on the device,
and then press again and find out if it still works,
since we have a flashable remote now.
This is what I did with this program.
It simply changes the code in the EEPROM.
You provide the original code.
It will flip the bits.
Then you just press the button.
if you are next to a gate you just press the button,
and if the gate opens you just press "Enter",
this means "yes, the code works".
Else you just input any character.
And once this is finished ...
So you go through all 23 codes.
We'll just say "yes it works".
It simply just changes the EEPROM value, flashes the EEPROM,
which is quite fast,
on the remote control.
Then you press on the button and see if the garage door opens,
or any other gate.
We just go through it.
I only flip the 23 last bits since the first one is always 1.
And this is what we get in the end. We get a pattern.
We know that the first bit has to be a 1.
The other ones aren't really important. This is where the bits were flipped.
And I entered "yes, the code still worked".
Since it still worked the bit is not important.
And this one is where I pressed one of the things to say "no",
"with this bit flip, the code didn't work again".
You just take several of the codes ...
You just take several of the codes
and you look at the results.
And here we can clearly see that the first bit is always a 1,
but on all codes the 4 next bits are not important.
And in the end the 2 bits are also not important.
And then is always worked with 10 at the end.
The most important bits are these ones.
This is a lot less.
Here we eliminated 5 bits.
Here we eliminated 4 bits.
This is 9 bits less for the actual information,
for the actual bits which are relevant for opening the garage doors.
What I also did
is actually sniff the communication between the original software,
on the original PIC micro-controller,
and the I²C EEPROM,
since I could switch all the time between my PIC chip with my own code,
and the original PIC chip with the original code.
I wanted to figure out how it stored the code.
You can only store 10 of the codes.
Let's assume this is the code we send.
How it works is actually it will go to this address.
So it will only take 4 of the 6 bytes,
go to the address,
and read what the values is.
At this address it's only one byte,
and the byte is actually a mask.
The value here ...
The value which is here is one byte,
but this is actually not what you will read out.
They do it in a clever way.
If there is a 1 here
it means every one which end with the value D ...
So this is how it works.
If there is a 1 in the byte which is read
the value D is allowed to be just 0.
Only this code is authorized.
If there is only a 2
the value D should be a 2.
And so on.
It's actually all the time an even number,
and how they did it is actually a mask.
So when the byte which they read is 3,
you have two bits enabled,
and what it enables is the 0 and the 2, which are authorized.
This is why it masks.
And then whatever is in between is also authorized.
It means it accepts ...
All odd numbers are just trunk to the previous even number,
and it only cares about even numbers.
This is quite clever.
And if you look at 7
we have 3 bits which are enabled here.
This way it enables 0,
2, and 4.
The 3 first bits.
This tells us that the value A is not really important.
And this is what we've seen previously.
The 4 first bits are not important.
For the value B the first bit is not important.
This is also what we've seen before.
Then we just use the 7 other bits of the value B,
C, D, and E are used in the address.
Actually it's F.
This D actually should be F.
And F stores what they name the data bits,
and it stores is as mask.
This gives us an indication which parts of the code are important.
The last thing I did is look again at this remote control.
So if we open it ...
Remember that this is the version with 4 buttons.
That's the battery on the back.
We have the 4 buttons.
And here we have the PIC12C508A.
which is OTP EPROM.
And it had code protection enabled.
So I did the same as the receiver.
I de-soldered the chip,
and I put my own micro-controller on it.
This is a re-flashable one.
It's again a high end, so I don't have to bother about the code size.
It's a PIC12F1840.
It's re-flashable.
The advantage of this remote over the other remote which has a programming header
is that I can still flash it by connecting to the pins,
but it has 4 buttons.
And that's very useful.
The firmware is almost the same.
I just had to change which pin goes to where,
that we have 4 switches.
The source code is also available.
I re-flashed it.
But I have 4 functions on the different buttons.
This one has the normal function which sends one code.
Like the other remote did.
You just program one of the codes inside and then it transmits.
But then on the second button,
which is the red button,
it will send the second code.
The second code could be anything else.
For example you could use the receiver to capture the code of the security guard,
which are running around all the time.
Once you sniff it, you could program it on there.
And then if you can not open a door with the normal code,
you could open the door with the security code.
That's just one possibility.
Or maybe you have two facilities.
Then we have two other buttons.
And the two other buttons are used to brute force.
If you press on this button
it will start sending random codes.
This is why it was important to figure out how the code are accepted by the building.
And using the traces from before we could eliminate 9 bits.
from the 24 bits.
That leaves use with 15 bits.
15 bits is not too much to brute force.
Whenever you start pressing on the button
it will send 4 codes per second.
And then you can stop here.
What it also does is that when it stops
it stores the 6 last codes.
Whenever you re-press the button it will re-transmit the 6 last codes.
The idea is that you start brute forcing
and whenever you find the right code
just press on the second button,
which stops the brute forcing,
stops draining the battery,
and store the last codes.
And this way you could go in every facility.
Because these apartment complex have hundreds, maybe thousands, of occupants
finding one matching code isn't probably too hard.
But I didn't try it out since with the receiver you can record any code.
And the idea is just to find out how secure it is.
If I can re-flash my code and if this attack was possible.
Also it's not read too interesting to flash the code or to clone these remotes
since whenever you go in the building
if you go to the garage door, or on one of the sides,
you will always find a door which is open which will allow you to access inside of the building,
or which allow you to access to the garage
So you really don't need one of these remote,
and one of these brute forcer to access the building.
It was just to test what security it uses
and as a hobby electronic project.
It was quite fun.
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