Toyota has some pretty laxed security standards...

[Sildaekar]

Ok, so after getting my HackRF (about a month ago) I've been doing a lot of playing around, from messing with Fan remote controls to radio astronomy but I decided to take on Keyfobs (the kind that lock/unlock your car) about a week ago. Sadly my truck doesn't have this feature, but one of my friends (thankfully) volunteered her Toyota Sienna to me to play around with.

Well I started off with the obvious, just recording the signal and looking at it figuring out it's modulation etc etc. I never was able to decode it (never really put forth the effort after I figured this next bit out) but I recorded the signal to a file and then just to play around, as I never expected it to work, I replayed the signal. It actually activated the "unlock" function about 4 -5 times before the key for it changed!

This was very surprising to me, as I was under the assumption that these keyfobs "rolling code" feature changed the key every time a button was pressed but apparently they still use the same key several more times before changing it. Security failure? I think so...good job Toyota.

[sud0nick]

What year was the vehicle made? I'm under the impression that newer vehicles absolutely change their code every time but I could be wrong. Still a cool discovery nonetheless as not everyone drives a brand new car.

[Sildaekar]

I'm not exactly sure what year it was made, but it's definitely between 2001 - 2009

[cooper]

It probably changes over time rather than over use, so the mitigating factor here is that you have to record the 'unlock' and within a presumably short timeframe you can replay the unlock to get the same result. This could be exploited on a parking lot where someone simply goes to their car to drop off some of the shopping only to immediately return to the mall again.

So what timeframe are we talking here? Seconds? Minutes?

With recent cars, where you don't even have to hit a button on the fob anymore, I'd expect the car to emit some sort of trigger signal when you (say) grab the handle. This signal will make the fob act as if the button was pushed. The fob encrypts something with the clock on the fob and sends that. The car picks it up, decrypts and verifies it. The only way to have a viable replay attack is to have a really shitty, low-res timesource. Problem for the car manufacturer is that they have to choose between a high-res timesource or a key that actually lasts more than 5 minutes on its battery charge...

If you can get your hackRF to emit the trigger signal and then record the fob's response you might be able to stretch the viable timeframe of the unlock signal.

Edited April 30, 2015 by Cooper

[Swamppifi]

That is a good question, how does the rolling code system sync itself??

if it changed everytime you press the button, then if you accidently pressed the button and not be in range of the car , it would go out of sync

key fobs and the deviec aren't transceiver, they don't talk to each other as far as I know.

I know that the rolling code system generates a key based on the roling code encryption of the keys serial number , then uses it to encrypt the open or closed code , this is what is transmitted, so it could be that if it matches a list of encypted keys for that fob, it would work.

it could be like the windows hash and rainbow tables, as long as the transmittion matches and encyption string for that fob serial number, then it should open.

If you search the internet, you find tons of threads of a mystery deviece used by thieves to open cars that owners have just left, i.e. recorded transmttion type thing.

http://www.dailymail.co.uk/news/article-2988836/Thief-caught-surveillance-footage-using-mysterious-electronic-device-easily-open-locked-car.html

http://www.dailydot.com/technology/wireless-car-unlock-hack/

http://www.cbsnews.com/news/high-tech-car-thieves-may-be-breaking-in-by-amplifying-key-fob-signal/

http://www.networkworld.com/article/2909589/microsoft-subnet/thieves-can-use-17-power-amplifier-to-break-into-cars-with-remote-keyless-systems.html

I have been going to get myself a hackrf to do simular research, I was thinking that if you have the encryption algorithm, then created a rainbow table like list of all possible encryption combination of open and closed commands, if you captured the transmittion, you could search the table and identify the serial number, and then you have a clone of the fob.

Just my thoughts on this subject, needs to be dug into a little more

be interesting to follow up.

Edited April 30, 2015 by Swamppifi

[Sildaekar]

It probably changes over time rather than over use, so the mitigating factor here is that you have to record the 'unlock' and within a presumably short timeframe you can replay the unlock to get the same result. This could be exploited on a parking lot where someone simply goes to their car to drop off some of the shopping only to immediately return to the mall again.

So what timeframe are we talking here? Seconds? Minutes?

With recent cars, where you don't even have to hit a button on the fob anymore, I'd expect the car to emit some sort of trigger signal when you (say) grab the handle. This signal will make the fob act as if the button was pushed. The fob encrypts something with the clock on the fob and sends that. The car picks it up, decrypts and verifies it. The only way to have a viable replay attack is to have a really shitty, low-res timesource. Problem for the car manufacturer is that they have to choose between a high-res timesource or a key that actually lasts more than 5 minutes on its battery charge...

If you can get your hackRF to emit the trigger signal and then record the fob's response you might be able to stretch the viable timeframe of the unlock signal.

That's a good theory, I had yet to think about that. The time between me recording the signal, and replaying it (up until the point it stopped working) was somewhere between 3 and 7 minutes. I'm not really sure so I'm being generous with my estimation. I'm going to try to do some more experimentation on this vehicle in the coming weeks and maybe find out if it is a specific time-frame or if it's based on uses.

I have seen the new vehicles similar to the one you are speaking of, but unfortunately no one I know around here has any, I would love to get the chance to play around with a system similar to what you've mentioned. I was originally under the impression that the keyfob was continuously sending out a message so the vehicle would only unlock when it was nearby, but from a battery life perspective it would make more sense for the vehicle to probe the keyfob when a person touched the handle instead of the other way around.

That is a good question, how does the rolling code system sync itself??

if it changed everytime you press the button, then if you accidently pressed the button and not be in range of the car , it would go out of sync

key fobs and the deviec aren't transceiver, they don't talk to each other as far as I know.

I know that the rolling code system generates a key based on the roling code encryption of the keys serial number , then uses it to encrypt the open or closed code , this is what is transmitted, so it could be that if it matches a list of encypted keys for that fob, it would work.

it could be like the windows hash and rainbow tables, as long as the transmittion matches and encyption string for that fob serial number, then it should open.

I'm not exactly sure on how the system syncs at the moment, cryptography isn't my forte but I do know that most systems these days do use a rolling code feature. Also, different makes, models, even years use different systems (that's completely an assumption). You are correct in the fact that they aren't transceivers, one is a transmitter and the other receiver; however, if what Cooper stated is true about newer models then they are both transceivers.

Another interesting attack against newer models is the ability to continuously rebroadcast the signal being sent from the car to the keyfob in order to capture large numbers of keys (I'm thinking hackrf + RTL-SDR+Pineapple all in a backpack) you could possibly capture hundreds or thousands of keys over the course of a few hours and through that stand a better chance at decrypting the keys, it would kind of be like the replay attack using aircrack-ng on WEP :p

Either way, like I said I plan on doing more research into this over the next week or so, and probably ordering a few keyless entry systems to test out and see if I can figure them out. If anyone else has looked into this, or has ideas on how to approach it I'm all ears! lol

[Sildaekar]

Just came across another interesting article over at Wired (you can see it here) that stated:

During his testing, Cesare also was surprised to note that the car opened with the same code multiple times. That implies, he says, that the car may have a manufacturer-created backdoor that doesn’t change between unlockings, and could allow it to be opened on the first try once found. After using that instant-open code dozens of times, however, Cesare says it suddenly stopped working; he’s still trying to determine just how extensive the backdoor may be among cars of his make and model and whether it might be possible to use it consistently.

While I personally don't believe it is a "backdoor" persay, but I do believe that this is the same incident that was happening with me.

Also Swamppifi, I found a nice article over on HowStuffWorks that describes how they stay in sync:

If you are a mile away from your car and accidentally push the button on the transmitter, the transmitter and receiver are no longer synchronized. The receiver solves this problem by accepting any of the next 256 possible valid codes in the pseudo-random number sequence. This way, you (or your three-year-old child) could "accidentally" push a button on the transmitter up to 256 times and it would be okay -- the receiver would still accept the transmission and perform the requested function. However, if you accidentally push the button 257 times, the receiver will totally ignore your transmitter. It won't work anymore.

So, I'm just thinking here, assuming that the article I referenced is correct and most vehicles use a 40 bit key, and are programmed to accept anything up to 256 keys after that this would leave us with 4,294,967,296 possible attempts before we succeed.

40 bit key = 1,099,511,627,776 possible keys

Possible keys / Error possibilities (the 256 keys allowed at any time) = 4,294,967,296

Now let's go on to say that it takes each key 50ms to transmit (got the number from a keyfob I randomly looked up online with FCC ID of KOBGT04A, I added on a few ms). We can transmit about 16 different keys every second, low estimation for various reasons. Which means it would take us about 214,748,364.8 seconds to try every key or ....wow... 6.8 years

Well that was just me thinking out loud, lol. But I'm sure realistically it wouldn't take nearly that long, and I was making a LOT of assumptions and guesstimates as well.

Edited May 1, 2015 by Sildaekar

[cooper]

I don't think your carkey has what amounts to a bucket of randoms and just pulls one out each time you click the open key and it's actually trivial to prove it:

When you buy your car, you get 2 keys.

So unless after opening your car 256 times the extra key stops working, this isn't how they work.

One could argue that the car has a list of the next valid 256 keys for each fob, but I would still find that surprising.

Regarding your math - it's off. You don't divide the total keyspace by the amount of valid keys, you subtract them. Given the keyspace, out of 1,099,511,627,776 possible keys 256 are valid meaning 1,099,511,627,520 are invalid and only after you try all those invalid ones will there be a 100% chance of you discovering the valid one (i.e. an _actual_ brute force). At 16 keys per second that's 130744.8 years to try them all. So you're better off trying this at a used car dealership where there are a number of cars within range.

Looking at the FCC pages, it woult appear there's only an oscillator on board for the AM On-Off Keying they use to transmit the encoded signal. There doesn't appear to be anything like a clock on board, but I would consider this odd as it would imply that when you're, say, at work and a coworker left his keys on his desk, you could simply start your SDR, record the 315 KHz frequency, hit the 'open' button, stop the recording, walk outside and open up the sod's car him none the wiser... There really should be some sort of time-based variation going on. The alternative is, like I said, a clock that updates every 5-10 minutes, but this would imply that the key is fixed (since multiple keypresses result in the same sequence being sent for some time (not certain if that's the case), and the car accepting it). If this is true you could contemplate the ways in which the fob encrypts the key with the timesource. You could record keypresses at various times and try to work out the encryption (if we can call it that), the key and the clock state. But that would require some intense effort so best practiced on a car you do have near-constant access to.

[Swamppifi]

Thanks for the link Sildaekar to that page.

I had a quick read, and if what they say is correct, you shouldn't be able to capture and retransmitt the signal

"With a rolling code, capturing the transmission is useless. There is no way to predict which random number the transmitter and receiver have chosen to use as the next code, so re-transmitting the captured code has no effect. "

This is proven to be false with the countless reports of a deviece used to capture and resend the signal used by criminals to break in.

you could keep trying the signal that you captured, and see if it stops working, and how long it takes.

I will have a more indepth read over the weekend

[Xcellerator]

The understanding that I've always had (maybe falsely, I don't know) is that all cars and fobs from the manufacturer have built-in synchronised clocks (similar to the ones in GameBoy cartridges). Then using some arbitrary count off the clock and a unique code between the car and fob, they are combined in some manner and then transmitted. The car picks this up and verifies it.

The count would be fairly large (relatively, considering these clocks can usually accurately measure down to milliseconds) i.e a few minutes which would save a lot of power using the clock. Although the batteries for the transmitter part often need replacing (again, "often" is meant relatively), the clock is probably on a separate circuit with its own power source. If the clocks power dies, then the clocks go out of sync and you'd need a new fob. This would explain your observation of the code still working for a few minutes.

Of course, all this is from what I've always thought to be the case. I'd have to take a look at the PCB of the fob to confirm any of this. I live pretty close to Central London, so I've no need to own a car. And I'm afraid none of my friends would trust me to break open their fobs.

It'll be good to hear how you get on!

[cooper]

I tracked down the FCC documents for the ID he referenced which includes this nice set of inside images. Searching more I found this guy who pulled his apart after it broke and he references a similar chip's datasheet which talks about the KeeLoq cipher used.

A quick Google of that revealed this paper on a practical attack on the cipher whereby a "fully implemented attack requires 65 minutes to obtain the required data and 7.8 days of calculations on 64 CPU cores" to succeed. It should be noted that by the looks of things this paper was written in 2007 so the thought of having your GPU do all the work probably didn't occur to them (the word "GPU" doesn't appear in the doc).

[Swamppifi]

Cooper

That data sheet explains a lot, good peice of info

[Sildaekar]

I don't think your carkey has what amounts to a bucket of randoms and just pulls one out each time you click the open key and it's actually trivial to prove it:

When you buy your car, you get 2 keys.

So unless after opening your car 256 times the extra key stops working, this isn't how they work.

One could argue that the car has a list of the next valid 256 keys for each fob, but I would still find that surprising.

Regarding your math - it's off. You don't divide the total keyspace by the amount of valid keys, you subtract them. Given the keyspace, out of 1,099,511,627,776 possible keys 256 are valid meaning 1,099,511,627,520 are invalid and only after you try all those invalid ones will there be a 100% chance of you discovering the valid one (i.e. an _actual_ brute force). At 16 keys per second that's 130744.8 years to try them all. So you're better off trying this at a used car dealership where there are a number of cars within range.

Looking at the FCC pages, it woult appear there's only an oscillator on board for the AM On-Off Keying they use to transmit the encoded signal. There doesn't appear to be anything like a clock on board, but I would consider this odd as it would imply that when you're, say, at work and a coworker left his keys on his desk, you could simply start your SDR, record the 315 KHz frequency, hit the 'open' button, stop the recording, walk outside and open up the sod's car him none the wiser... There really should be some sort of time-based variation going on. The alternative is, like I said, a clock that updates every 5-10 minutes, but this would imply that the key is fixed (since multiple keypresses result in the same sequence being sent for some time (not certain if that's the case), and the car accepting it). If this is true you could contemplate the ways in which the fob encrypts the key with the timesource. You could record keypresses at various times and try to work out the encryption (if we can call it that), the key and the clock state. But that would require some intense effort so best practiced on a car you do have near-constant access to.

I see now, thanks for pointing out my mathematical error Cooper. Please keep in mind that keyfob that I listed was just some random generic keyfob that I located online and I'm not even sure if it comes from a vehicle manufacturer. I will be posting the ID of the actual keyfob in the future when I do more work on it. May try to tomorrow actually. I honestly didn't look at the circuit board on this particular keyfob but if what you are saying is true about no clock existing could there be a pseudo-random number generator such as what was explained in the article I previously linked to?

I'm still fairly new with using SDR in a security sense, and I'm really taking this as my first major step into that realm. Any and all information, is greatly appreciated. Actually if you're ever in the USA I'd love to buy you a beer and pick your brain, but until then I guess the forums will do :P

Do you have any ideas on other, realistic, attacks that may be possible on such devices? The best attacks I can think of a replay attacks, where the key continues working for some time after, and bruteforce but as we all know there are countless ways to defeat security systems. Also, please keep in mind that throughout my experiments I am always assuming that I will not have physical access to the keys or keyfob.

The understanding that I've always had (maybe falsely, I don't know) is that all cars and fobs from the manufacturer have built-in synchronised clocks (similar to the ones in GameBoy cartridges). Then using some arbitrary count off the clock and a unique code between the car and fob, they are combined in some manner and then transmitted. The car picks this up and verifies it.

The count would be fairly large (relatively, considering these clocks can usually accurately measure down to milliseconds) i.e a few minutes which would save a lot of power using the clock. Although the batteries for the transmitter part often need replacing (again, "often" is meant relatively), the clock is probably on a separate circuit with its own power source. If the clocks power dies, then the clocks go out of sync and you'd need a new fob. This would explain your observation of the code still working for a few minutes.

Of course, all this is from what I've always thought to be the case. I'd have to take a look at the PCB of the fob to confirm any of this. I live pretty close to Central London, so I've no need to own a car. And I'm afraid none of my friends would trust me to break open their fobs.

It'll be good to hear how you get on!

See this is what I've always assumed, and when the clocks say got out of sync they used some type of clock recovery system to sync back up. I plan on getting up with a few of my friends, as well as family members and comparing the FCC reports of all their keyfobs here shortly. Maybe I'll find something that just sticks out, and if not maybe I'll discover something in my tests. I would really like to see more people jumping in on these kind of talks in this forum and sharing more information.

[Sildaekar]

I tracked down the FCC documents for the ID he referenced which includes this nice set of inside images. Searching more I found this guy who pulled his apart after it broke and he references a similar chip's datasheet which talks about the KeeLoq cipher used.

A quick Google of that revealed this paper on a practical attack on the cipher whereby a "fully implemented attack requires 65 minutes to obtain the required data and 7.8 days of calculations on 64 CPU cores" to succeed. It should be noted that by the looks of things this paper was written in 2007 so the thought of having your GPU do all the work probably didn't occur to them (the word "GPU" doesn't appear in the doc).

Wow, thanks for the info Cooper! I'll definitely give this a read. Also, you're probably right about them not using GPUs, if I recall correctly GPU calculations didn't really start to become popular until 2007 or 2008.

[Swamppifi]

I have found this article, it show an experiemt using SDR to transmit and capture 1000s of button pushes then finds the pattern in the so called random numbers.

It then reduces the code trys done to a managable 10 000 or so

it is at http://www.wired.com/2014/08/wireless-car-hack/?utm_source=digg&utm_medium=diggtwitter

it as a video of the test with the sdr transmitting code, it opens at 1 minute, 4 minutes then 15 minutes

[Sildaekar]

I have found this article, it show an experiemt using SDR to transmit and capture 1000s of button pushes then finds the pattern in the so called random numbers.

It then reduces the code trys done to a managable 10 000 or so

it is at http://www.wired.com/2014/08/wireless-car-hack/?utm_source=digg&utm_medium=diggtwitter

it as a video of the test with the sdr transmitting code, it opens at 1 minute, 4 minutes then 15 minutes

Nice little find! The only issue I see with this is that this only works if they are using some sort of psuedo-random program to generate the keys, if they embed a TRNG on the device then I don't see the practicality of this approach....however, I don't see TRNGs being this small either. Either way this would be one approach to at minimum consider.

Sorry I haven't made any more posts on this, been busy working on a bunch of stuff IRL, and just ordered a Teensy so I plan on playing around with that and seeing what I can get it to do as well.

[Swamppifi]

Here is another interesting link I have just found

it is a pdf of the car hackers handbook

http://opengarages.org/handbook/2014_car_hackers_handbook_compressed.pdf

[Swamppifi]

Here is some more useful links for anyone wanting to research car ecu's

this link to a signit13 presentation on car fob hacking is interesting, claim that a 40 bit key can be brute forced in an hour using an 8 cluster beawolf

https://www.youtube.com/watch?v=7EpJuOrF4CM

He is even claiming that with the new generation of computer based ecu, it could be possible to inject code (XXS type attack) via email or face book that gets processed on board, this is mainly from the industry not taking seriously how poor a security system is being rolled out on ECU's

some more useful youtube stuff

https://www.youtube.com/watch?v=dvmSOEKfkug

https://www.youtube.com/watch?v=KHRPmjwXF1U

https://www.youtube.com/watch?v=zurrQiETDHA

https://www.youtube.com/watch?v=1f6ZqfZHalE

https://www.youtube.com/watch?v=hpwBmTw7Gm0

https://www.youtube.com/watch?v=oqe6S6m73Zw

some links to info on OBDII

http://www.obdii.com/

http://en.wikipedia.org/wiki/On-board_diagnostics

http://scantool.imechatronics.com/downloads.htm

This thread has my interest, mainly as I am tinkering with my car with the aim of mucking around with the ecu to reprogram it, and I have been browsing the internet for weeks to understand what I am tinkering with, before I stuff it.

I have brought this setup today, got the bluetooth plug from jaycar here in australia, and downloaded the pro version of the software to my tablet last night.

https://www.youtube.com/watch?v=vQSsUPrGLHs

tinker away....

Edited May 9, 2015 by Swamppifi

[Sildaekar]

This thread has my interest, mainly as I am tinkering with my car with the aim of mucking around with the ecu to reprogram it, and I have been browsing the internet for weeks to understand what I am tinkering with, before I stuff it.

I have brought this setup today, got the bluetooth plug from jaycar here in australia, and downloaded the pro version of the software to my tablet last night.

https://www.youtube.com/watch?v=vQSsUPrGLHs

tinker away....

Just be careful that you don't "tinker" the wrong way and mess up your ECU lol

I personally just ordered two different Keyless Entry Systems today (I know, I know, not the same) to hopefully do some more with Keyfobs. Thinking about just wiring them to a LED (turns on for lock/unlock) and setting it up at my workbench.