Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3041 Thanks!
[Music]
all right I think we might
begin unlocked uh the upcoming talk
takes this year's Congress motto quite
literally based on the need for a
wireless doorlock solution members of
the Mainframe hacker space in aldenberg
came up with an unusual form of
lockpicking no wrenches or hooks needed
that sounds interesting to me so if you
want to know the ingredients for their
lockpicking recipe please stay with us
and listen to what our speaker Sebastian
AK s has to say as is not only
co-founder of the Mainframe hacker space
but also active in the thirt crew so
let's give him an extra warm Round of
Applause and welcome to the stage
[Applause]
s thank you so before coming to the lock
that we will have a look at most of this
talk uh let me present you with our
current solution which is the CFA 1000
it's quite common in a few hacker spaces
for a few years because you can remove
the radio
part from it and wire it to have a safe
system and also schematics are more or
less public so we using this for some
years um to lock our doors um in a more
or less secure way because no Wireless
things are
involved um but it has some issues first
of all the wiring is a little bit ugly
so we tried to find a different solution
uh for the future and the future well
was actually in in the past by now
because we got a really big CNC mill
that we put in the basement so we needed
a new solution and the obvious choice
was to have a look at the successor
product um which is supposed to use the
advanced encryption
standard so we used the well maker
solution wired some things to the remote
control added a Rasberry Pi and press
the buttons so that the door can be
locked and
unlocked um um knowing that the solution
might not be that secure but it's not so
easy to steal a 2ton CNC
mill but once we have this solution set
up uh I got curious and had a look at
what's going on on the radio frequency
is the protocol actually secure so I set
up an SDR and had a look and got this um
so it's a quite clear picture because in
the basement there's not lots of radio
traffic going
on so as you can see it's quite easy to
find the frequency where the uh remote
control is operating at and also it's uh
if you have some hem radio background
you can see that it's using some kind of
uh frequency modulation with the 100 KZ
deviation so next I started to um set up
a g radio project to try to decode this
and this is what I came up with
um so there's a input block which gets
the data from the software defined radio
and then puts it again into a waterfall
syn which is basically what we just saw
and then additionally uh I added a block
to demodulate the signal and then put it
into a syn that is just showing us the
uh demodulated data and after running
this I got this nice data so it's
already quite easy to see oh looks like
ones and zeros um but we still need to
decode it um what this data is already
telling us is the B rate if we expect
that these are ones and zeros which is
quite likely because if you're sending
data over radio you somehow need to uh
refine the clock so usually a
transmission starts with the one zero
pattern so looking at this we can count
the numbers of bits that are sent within
a specific time and then recover the B
rate from this and use that to improve
our decoding
pipeline which is what I did um there's
a nice block available from G radio the
uh Muller and Muller uh the H radio
people in the room will probably know
this so it's basically trying to recover
where a bit is starting and then
afterwards it's converted into B so that
we no longer have an analog signal but
nice bites so every bit will become a
bite what is still missing though is the
information where a bite is starting and
to figure that out it's needed to have a
look at the stream that is generated so
we get lots of ones and zeros and try to
find
patterns uh I did this next and I don't
want to bore you with like all the data
um so I will just give you the result um
so this kind of header is uh which could
be found lots of times in the data and
then there's a fixed amount of bits
falling
afterwards um and with that information
we can yet again improve the decoding
Pipeline and create nice packets uh
which is what you can see here uh so
this sync word is basically the pattern
that I just showed you and then there's
the fixed packet length on the output is
a nice packet that is sent to UDP U that
can be
postprocessed so the next step is having
a look at the data and for that I have a
really simple python script for you uh
which just receives the data that has
just been provided by G radio and prints
it on the
terminal and after all of this I got
this nice table
um so every line is a new packet and you
can see they are looking all quite
similar um the only differences are in
column 8 10 and
11 and often if we're doing data
transmission we end it with a some kind
of check sum so if one column is
different of course the check Su would
also be different so that's what I
expect and the other interesting part is
that in column 8 it looks a little bit
like a counter but then it swaps over in
some line over here here um and also the
data looks a little bit like it might be
scrambled which is something you often
do when doing radio transmissions in
order to avoid having long periods of
ones or zeros which are hard to
decode so the information information
missing is what kind of check sum is
being used and what kind of data
scrambling is being used um which
probably could be recovered by well
trying different things but what I did
was having a look at the hardware and
having a look at what it might
provide so this is the remote control
from the dooc system and it actually has
two chips which should be easy to see on
the picture and uh they haven't been
scrubbed so it's still possible to read
what is written onto them and to
identify them and one of them is a
microcontroller which has the buttons
and the LEDs connected to it and the
other one is a chip which is a radio
transmission
chip um and this specific chip it has a
public
documentation and if you look into it
you can see well it supports automatic
generation of a check sum and also
automatic checking of it and it has two
optional encodings one of which is a
manchest encoding and one is a linear
feedback shift register poal
um so both would be options that are
quite likely so first of all had to look
at Manchester encoding and in Manchester
encoding there can't be more than uh two
sequential identical bits so 0 0 0 or 11
one wouldn't be possible in this
encoding but the receive packets they do
have this kind of
sequence and I saw quite a few of those
sequences so it's unlikely that I
received data incorrectly so I assumed
that this is not Manchester encoding and
then tried the polonial
thing so I uh updated the python script
a little bit and added those two
algorithms the CSC and the encoding
thing and got this nice new table so you
can see the CSC check sums they are all
fine so it's highly likely that this is
being
used um also now lots of zeros are being
transmitted which looks kind of sensible
and our cter changed a little bit it's
now an decreasing counter starting at 99
and then counting down and there are no
longer any
jumps and also as a side effect we now
have 16 bytes of actual data and the
vendor officially says that this product
is youing a 128
bits no our packets are exactly 128 bits
so that seems quite
likely so in the next step I had to look
at the well folling packets as you might
have guessed the interesting part might
start once the counter reaches zero um
so the first messages that we saw there
are 100 of them and uh I will name them
message a here and then there's two
different messages that are following a
message B which is sent back from the
door and a final message C and some
cases so let's first of all have a look
at the message
a um as I mentioned that's sent 100
times and by using different remote
controls it's possible to see that there
are six byes that are using well some
kind of address for the remote control
um I myself call it a Mech address
because it's quite similar to it and
then there's a bite which tells the door
what the remote control wants to do if
it wants to lock or if it wants to
unlock then the counter that we already
saw and all the remaining data is
zero next the door
anas and it send this message B which
looks very similar um it effectively
sends back the address doing some bit
Magic on it sends back the command and
then the zeros are filled with some data
um at the end there's a status so even
without any encryption being done the
door already tells us hey I am unlocked
so if you ever want to know if your
neighbor's door is locked well you can
just ask it
um the other bit that is in there is a
some kind of challenge um you will know
what I mean with this by having a look
at the next message which is message C
and that point is only sent if the
remote control wants to lock or unlock
the door because if it only wants to
know the status it already got
told um and if it wants to well lock
then there's one more packet and that
seems to be in crypted like the daa is
pretty
arbitrary um but if I use like a fake
CFA 3000 like if I use a software
defined radio to well basically appear
like a a doog and then send the same
challenge again I will get the same
message again and that's why I say that
uh those bites contain a challenge
because if those bites change then the
message C also
changes
so what does this mean uh if we have a
look again at the protocol being used we
effectively can generate the first two
packets and what is missing is the last
packet so if we can somehow Break It it
means we can open all the
doors so I was wondering how hard could
it be but before having a closer look I
also looked at how does the pairing work
and that was quite interesting because
it's really simple you tell the door
lock please learn a new remote control
then you press any button on the remote
control it sends out the 100 packets and
then you're
done so if you follow the talk you will
notice the only thing that the door gets
told is if it should lock or unlock
which does not make sense for learning a
new remote control and the mech address
of the remote control but there's no key
exchange so the key must already be
there and it must be the same on all the
locks right so can I get the
key let's have another look at the
microcontroller so the microcontroller
being used is a quite small pick it only
has one memory block so if you remember
the talks from previous congresses there
is an attack that you can use on pck
microcontrollers where you're erasing
the first block and then flash some code
into the first block to read out the
second block but that's not possible on
this one because it only has one memory
block that lay off with well trying to
do power or voltage glitching which is
quite hard um maybe use a Chinese
service they offering to read out the
chips for around
$5,000 which well I didn't want it to
do then there's the option of using a
scanning electron microscope which I
well didn't really consider until the
member of my space told me well where's
the problem I have I I can get us one
it's on
eBay so well we bought a scanning
electron
[Applause]
microscope so um it was Mark is broken
so we thought let's ship it to us but um
the previous owner they told us well
it's better if you get it from us then
we can tell you how it works and and
give you some ideas how it could be
fixed so we went over there and it was
well not working perfectly but more or
less working and we got it running we
got some pictures these are not from the
pig they are from some parts from the
sking electron microscope that were
broken um but the problem with this
devic is it's quite old it leads lots of
Maintenance like uh maybe running it for
two hours then something breaks and
needs to be fixed
and also so far we failed to actually
open the pck um you have to deal with
like strong aets and to Edge it open and
uh yeah I'm not feeling comfortable with
this but we are still trying to do
this but I'm here so we found another
solution um during Co the batteries and
the door lock actually went empty so I
had to replace them and thought maybe
have a look at what is inside of the
door lock and I found this um so the
door loock has a lot bigger pck uh which
has multiple memory wings so I thought
great that means I can probably do the
same attack this has been shown before
um so I prepared a small breakout board
for the pig to do some
testing and also wired up the door lock
to raspberry pie which can be used as a
programmer and to get the
Cal and then dumbed the fuses and got
this nice result um so I can see it's
like all code protected so over the
programming interface I cannot just read
the code which is kind of
expected um but I also saw white in the
first block one of the fuses is missing
so that was interesting and I tried to
repeat the attack shown before which
works a little bit like this so you
erase the first memory block of the
device um and then you can write your
own code code into it leaving the other
blocks intact and the code written to it
looks more or less like this so there is
a Serial setup uh so that I can dump
data over serial then uh this address
the 1,000 in hexad decimal and the 2,000
that's the first block and I just Loop
over it read the bytes and print it out
and then I have the data
block unfortunately that only works for
this block and not for the others
because microchip introduced a new
protection feature that's the TBR that
you can read over here that means they
are table read
protected and this protection is
interesting because it does not fully
block the table read um what this fuse
bit does is it does not allow to read
data from a different block so if the
table read instruction is in Block zero
but the data that should be read is in
Block two and that has the table read
protection it will just return a fixed
value let's say
zero but if the table read instruction
is also in Block two then it will return
the correct data the idea behind that is
you cannot add a table read instruction
in Block two without erasing it and if
you erase it you also erase the um fuse
bits but knowing this I was wondering
maybe there's already a table read
instruction somewhere in there and there
you can see in the example assembly that
I show here the pointer that points to
what address should be read it's not
part of the instruction itself so if I
can prepare this pointer register and
then jump to the table read instruction
it will read something
else so I prepared a nice flowchart for
you my plan was first of all ask for the
address that should be read then
initialize the uh register where the
result is being stored then set up the
table read pointer enable the
interrupts and then the interesting part
happens I program a timer that I want an
interrupt in two
instructions the first instruction is
the falling jump which jumps to the
instruction where I hope that the table
read instruction is and the second
instruction will be the instruction that
should be hopefully the table read
instruction now what can happen is first
of all maybe the interrupt does not
trigger for example if I jump to an
instruction that disables interrupts
well the interrupt will never be
there then the second option is there
will be an interrupt and if there's an
interrupt I have again two options
either the register where the uh table
read instruction stores its results it's
still zero as I initialized it or it
changed now if it's still zero I know
100% that this is not a table read
instruction because the um address that
I try to read is the same address where
I jump to so it must be the bit sequence
for the table read
instruction so that was my plan and I
tried it with the development board that
I did build and everything worked fine
so then I tried it on the real device
and unfortunately there was not a single
table read
instruction So the plan failed um um but
the same mechanism can be used to find
other instructions so I modified the
pipeline a little bit so that I'm no
longer looking for table read
instructions but instead try to
see how the um program counter changes
so effectively I'm looking at this deck
um so if you'll read TSS that's top of
Stack I initialize it to that um just a
specific value that I will be able to
recognize then do the same thing again
enable the interrupts set up the timer
jump to the address hope that an
interrupt triggers and if it triggers I
have a look at this
deack if this stack is um the jump
address plus two bytes it means one
instruction has been done let's say an
add or a knob or
whatever um and now the program counter
of the normal code is one instruction
later um the reason for that is that the
triggering interrupt it takes the
current code position and puts it on the
stack so that once the interrupt returns
it will be back to where the code was
currently
running If instead the top of Stack
shows me zero St that's the value we
initially put there it means that the
instruction that I just executed is a
return
because the return looks at the top of
the stack and puts it to the current
program
counter so great we just recovered an
instruction um I can also have a look at
what is at the uh stack minus one and if
that is the jump address plus two or
plus4 then the code actually did a call
into some other
function and last but not least there
might be the option uh that the top of
Stack is not that but it's also not the
jum address plus two and in that case I
just found a go-to so this can be used
to figure out more or less every
function and and every
jump and also where the functions
return which is not all the instructions
but it's quite interesting to get a
better understanding of how the code is
uh being
structured but the same mechanism can
also be used to figure out any other
instruction
um so same concept again uh initializing
the device to a specific
State then do the interrupt trick jump
somewhere wait for the interrupt and
then dump the whole device State um
let's say for
example um I try to find an instruction
and I'm wondering if it's doing an add
um it needs to store the results
somewhere and it needs to get the
initial values from somewhere so if I
initialize the memory to 0 0 0 and
afterwards somewhere there is a
different value obviously that has been
changed by this
instruction um so let's take an
example um this was the output from the
previous code uh so we can see one of
the registers changed first it changed
from zero to FF then in the second one
where the memory was initialized
differently it changed from FF to Fe
then it changed from 42 to 41 then
changed from 11 to 10 so well most
likely this will decrement the
register um this looks quite simple but
in some cases it's a lot harder um I
have a second example um this is an in
this is an instruction that is located
at address 1337 da which is made up by
the way um and this register changed
from 0er to Da in all
cases um so it might be that this
instruction is just writing a fixed
value of
Da but it might also be involved to the
instruction somehow because the lowest
bite of the instruction uh address is
exactly the
same and um so the assumption that I had
is that this might write the working Reg
because the working register contains
the lowest uh bite of the uh instruction
position as a side effect of how the um
jump is
working so I was wondering if I can
somehow modify it and figure it out I
can
jump uh a little bit off so the
instructions are 16 bits which means
effectively there are only even
instructions but you can jump to an
uneven position and it will still
execute the instruction
just with a different working register
and I can see well now the register
changed to
DB um so it's very likely that this
instruction is actually writing the
working register into the specific
register so great I have a way to
recover instructions it's well a little
bit of work but should be possible to
get everything out without the scanning
electron
microscope except for the block zero
because well that's where the interrupt
Handler is so I might be lucky if the
interrupt Handler from the original
block jumps into some other block then
of course I get the code running again
if that's not the case um I need to find
a way to do all of this without
interrupts um well I
didn't um but of course it's still
possible to find returns because jumping
to it means the code will come back and
we can still enable the timer and figure
out how many instructions have been
executed and yeah one more thing that I
figured out by doing this I had quite
some issues initially that the device
resets all the time because well the fmw
enable the watch doog and if you do a
big long knob slide like you usually do
for doing this attack uh that's too long
so the watch doog will reset the device
so I have a nice tip don't use knobs
slides use call
slides uh that also has the nice side
effect that you know where exactly block
zero jump to um which is well always
nice to
know so after doing all of this I found
this sequence and I was like okay that
looks interesting so this is directly
after each other so it's a return and
the next instruction is also return and
the next instruction is also
return uh so it looks a little bit like
a lookup table and and some of you might
know this bite sequence um if you don't
you can just put it into your search
engine and it will come up with
this um which I took from Wikipedia it's
the uh s boox from the advanced
encryption standard which means I just
found the lookup table for it and as you
remember I already uncovered all the
function entry points and exit
points and what I did with this
information is I created a graph
um and now I know where in this graph
the sbox is and of course anything that
uses the sbox is related to the advanced
encryption standard and I also know how
many instruction it's
using so now I can try to well
investigate specific functions instead
of having to debug and uh reverse
engineer the whole
firmware so there's a nice webc coming
that I remembered from University um you
can find the O here it will explain how
to implement as but it starts with this
nice food shooting uh prevention
agreement which tells you ah please
don't do a custom implementation of the
advanced encryption standard because you
will probably not be able to implement
it without having lots of side Channel
attacks that will be possible on this
algorithm um so yeah it's usually you
you don't do it and also programmers are
lazy so they want to use uh well ready
to use implementation so I had to look
what kind of uh implementations exist
for the
pck and microchip is nice they are
providing two application notes one for
the pig 18 and one for the pig 16 series
which implement the uh the wind jail
algorithm so the advanced encryption
standard so I had a look at the first
one the obvious choice is the pig 18 and
that of course has a sbox inside but
it's using the table read
instructions which I already noticed is
not being used by the door lock so
probably they're not using the algorithm
from
that and afterwards I had a hinge and
also looked at the P 16 implementation
because that's used by the remote
control as you might
remember and that one had an ISS box
using lots of returns like exactly the
sequence that I found
with that information I try to match the
functions that they provided so it's
nice because it's all in assembly so it
actually fits exactly so I could update
my graph and had uh function names for
all the functions related to the
advanced encryption
standard so now I know exactly which
instruction I need to uh figure out uh
to understand where the key is being
stored and I did this and extracted all
the necessary
information which means we can update
the flowchart from before because now I
can also generate an encrypted
[Applause]
response so I updated my python script
from the beginning and renamed it a
little bit it's now named uh like the
remote control control and it's now B
directional and I can well provide the
mech address and also the instruction
like if the door should be uh locked or
unlocked and um then it will send 100
packets with the decreasing counter wait
for the challenge and send a nice
encrypted response and what you can see
here well actually works on a real
device except that you probably won't
find the remote control that has the
mech address bad coded as
um so all of
this all of this uh more or less
happened at the last uh remote Congress
so a few days afterwards I actually had
full access to the door and asked um our
nice people from CCC the disclosure
people if they had any prior experience
with the vendor uh I got a nice link we
actually had
um and I got told well it's probably
sensible to send this to the S which I
did and then it took quite a while uh
the idea was that uh hopefully they can
fix it but the response was well this
product is more or less end of life and
we don't think we can fix the bug we
consider it
unfixable um which kind of makes sense
like there's no user interface to update
the firmware so they would have to take
back all the locks and update the
firmware and also if they update the
firmware from the locks so that they are
secure they also need to update the
firmware from all the remote controls
and they will no longer be compatible so
here it's bit hard to
fix um so they got told yeah please uh
please provide this security information
to your customers that this device is no
longer secure uh then a long time
nothing
happened then we had the camp and during
Camp I got a nice message from theer
Bund and they told me well we plan to
take care of it ourselves now which they
did a few days later with a nice big
warning that this device shouldn't be
used at all
anymore
um but of course it's not nice to have a
device that is broken and doesn't work
and so I tried to find a way around it
and and
um well we now have a custom uh
implementation of a remote control for
our door loock and I asked dendor if
they would be willing to open the
firmware so that fixed one could be
written easily Unfortunately they denied
we do have some work arounds for
implementation but I don't intend to
publish them because um that would mean
that everyone can unlock everyone's
doors that have not been updated which
wouldn't be too nice so sorry about that
um and actually that's it and I'm
available for
[Applause]
questions okay thanks
s for this
talk we do have plenty of time for
questions and yes please we do have four
mics here in the in the s in the hall if
you have any questions now
don't shy away from them come on I know
there's
something in you otherwise I would ask
the signal Angels maybe we already have
some questions from the internet not
right
now all right we have to unlock the
questions
s yes please go to the yeah over there
nice thank you um Mike for please so
we've seen that the BSI has issued some
warning did Abus also issue some warning
or how did they
react after the BSI uh did a warning for
the product they updated their website
um because they got lots of customers
complaining and asking questions about
this so what was their like take on it
so sorry it's broken it's your fault now
um so they take that oppos course they
told well it's quite hard to do this and
uh you need to have a very Criminal Mind
to open a door in this
[Music]
way great
[Applause]
com all right uh looking at signal Angel
we are we all right so would you be for
free for questions and drinks and
congratulations and everything else
after the talk yes okay so I think then
if there aren't any questions left last
chance anybody no no no okay then we
wish you all the best for tonight and
thanks again s there's a question no
come back please we do have
time
okay hello I I I just want to make sure
the uh uh the as key is hard code inside
the firmware is it yes so there's not a
single one it's a little bit more
complex um they have some kind of
rolling key scheme inside but yes it's
fixed in the firmware okay thank you and
another one we unlocked the questions
now very good well first of all thank
you very much for your talk um did you
ever get the electron microscope to
work yeah so as I said we got it working
uh we we have it at our hacker space so
if you want to take a look come by and
and have a close look um the part that
is uh still not working is we didn't
manage to open the chip okay thank you
very much that's good good storytelling
I would say so now we have a question I
believe from signal the internet this
ask is
indeed sorry the internet is asking did
you do any experimentation with
glitching the pck or if not why not
uh I did not because I found the
alternative of doing it in software
which is a lot more stable and a lot
easier to
do short short answer to a short
question yeah guys if you want to ask or
everyone around here just come don't shy
out of talking into a
microphone I will give you a few more
seconds
maybe the mics are in here in the lanes
and the different ones so another
question
yeah okay then I will finally close this
session okay last chance I don't see
anyone okay okay so thanks s please
visit him afterwards thank you for your
talk
[Music]