Development of DIY Electronic Upgrades

Agreed, it was laments terms but your details are spot on. Why don't you research how "sophisticated thieves" intercept codes when you use your fob, and encode it to unlock your vehicle. I'm sure it operates the same way you've described and what you guys are getting at about re-transmitting it. Question is, re-transmitting it indefinitely would be a security issue (but essentially that's what your fob is always doing since it's presence is all that is needed), so triggering it via software/DIO when called/needed. It's the same device principle. I don't have the encryption method for Toyota...at-least not without sniffing software meant to read and decrypt it. It's not public info without digging. I'm sure the remote start companies have this info for sure, but it's too top secret for me to get.

 

Clearly you guys are WAY ahead of me on this, and you may have even studied the fob behavior, but here are some more observations with the fob and it's red light:

• Open the door = 1 flash,
• Shut the door = 2 flashes,
• Truck locked with fob inside = no flashes,
  
• Leave the fob inside unlocked = 5 seconds per flash for 25 seconds then flash stops,
• Foot on the brake = 5 seconds per flash for 30 seconds then flash stops,
• After flash stops = truck starts normal with no additional flashes,
• Truck running = no flashes,
• Take fob out of truck while running = no flashes,
• Shut door with fob outside while engine is running = key not detected warning,
• Trying to Lock/Unlock from fob inside or outside while engine is running = nothing happens.,
• manually locking the door while leaving the fob (smart key) inside = key detected in vehicle unlock/alarm,
• locking the door using the 2nd fob while leaving the 1st fob inside = truck locks normally (with 1st fob inside).

So, clearly the door switch has a lot to do with detecting the fob, with one request from the brake switch. And, while the engine is running, there is no "detecting" of the fob unless the door switch is open and then shut. Fob will not unlock/lock while the engine is running. This explains why I couldn't unlock the door in my previous experiment. At any point in time while the engine is running, truck will not lock manually unless the door is closed and locked from the inside. Cycling the door switch, with the doors locked, while the engine is running results in unlocking the doors. I don't have the @N2DesignsInc smart phone control module, so I can't comment on unlocking the truck with the phone app, while the engine is running.


To me it sounds like we could use a dedicated remote with a module that will start the truck using the "foot off the brake 10 - 13 PTS press to work" method, with a lock/unlock button that will override the manual unlock button in the door. The smart key can be left in the vehicle, but the Smart Handle will not work.

 

I have researched how thieves steel the vehicles. They don't encode anything, they are receiving, jamming, and transmitting signals already coming out of your vehicle or fob. They physically cannot encode the signals, because they do not know the private keys and encryption Toyota is using.

Encoding implies that I can generate a data packet using known information without hacking that the vehicle will recognize as valid.

I can tell you that I am 99.9% sure that the remote start companies, in fact, do not have the the private key information. Its all under key and lock within Toyota. The most that they could do is use a Toyota techstream like device to program a new fob. Even then, they won't have the ID keys of the fob. It all happens over a wire with the click of a button and the user never sees anything.

Remote start companies are spoofing some of the signals going to the "certification" ECU. The reason I know this, is because I paid the $20 to get a 2 day account to the TIS portal. I can see the FRM and wiring diagram of the truck in all its glory. Of course, the wiring diagram doesn't give you enough information to know the whole story. You have to fill in the blanks yourself. The FRM gives some information on a few of the signals going into the ECU / Cert. The rest you would reverse engineer.

There is nothing that I can see that explains anything about the internal operation of the key fob. The only thing that is stated is that each fob will have its own ID code that has to be programmed with the vehicle. Based on research, the data encoded in the RF packets will consist of both the ID code and private key information for encryption. Companies do this all the time. They may give you an API or a program that allows you to manipulate a device without actually having knowledge of what it's doing internally. I have experience with this, because I've done similar things for my job.

With regards to how the key fob is detected for a normal engine start. I am not going to post the excerpt in open forum (for obvious reasons). After the user opens the door (whichever way), they press the brake pedal. The cert ECU detects this and sends out an RF packet for the fob using Antenna 1. The key fob then receives the packet and generates a response. The response is received by Antenna 2 near the door handle (pointed inward). The cert ECU gets the response, verifies it and then moves on. It unlocks the steering wheel lock and does a few other things. This detection happens within 25ms. The user can press the PTS switch after the 25ms and the engine will start.

Guess I know what that annoying motor sound is when I turn my vehicle on or off.

Looks like for engine starting, the vehicle only asks the fob once and its not a continuous thing.

 

you can lock and unlock the truck while running using the

$180 ascl6 remote start cellular interface module allows you to start your car from your phone 1 year included

ascl6 module on Pts.

 

First of all let me start by giving a high five to a fellow embedded systems engineer... I've been writing firmware for 22years.

So for the remote start with takeover here's what I know.

I installed remote start in many cars with physical keys. Latest being a 2006 sienna. I used a fortin module for the immobilizer bypass and a prestige remote start. Worked great with full takeover.

After that we purchased a 16 sienna xle with keyless push to start. I used a similar setup because fortin published a way you would make the car think you had a key, pushed the brake pedal then pushed start. This worked 100%. Fortin published a guide on how to do this with a 2011 Sienna. Full takeover works.. Get in the van and push start twice. It keeps running when you push brakes and the door opening doesnt kill it.

Now, what the hiccup is, no one makes a guide on how to do this with a newer Tacoma.

But im spitballing here...what if you took the sienna guide and mirrored it to a Tacoma wiring diagram? Because you don't want to use the can bus remote start command. It makes the bcm watch for door open events.

 

Fortin no longer publishes the 11 sienna takeover on their site, but would be curious to see how they show it

 

Or, like Fortin told me, not enough people want it, it complicates the install, and the liability is too high.

 

Let me see if I have it saved.

 

This is interesting. Fortin claims they can decrypt key fobs. Many researches.

 

Fortin Guide 14961 is what I used. The new one is 32661.

 

I am looking briefly through this guide, and there is a lot of wiring specific to the particular electronic makeup of that car. I have the wiring diagram for the Tacoma, and while certain things exist between the two such as many of the switch sensors (door open, etc.), some of the more fundamental things do not. I am seeing reference to an "arm / disarm" pin here in this guide, which I think would be a pin that allows you to directly arm or disarm the alarm / immobilizer. If it was that easy on the Tacoma, I think we would have had this already on it. I have looked through the Tacoma diagram, and it seems like its pretty locked down making RF authentication the only way it can do its business.

I will keep looking, but I don't think the Tacoma allows a holy grail pin such as arm / disarm.

The Tacoma has several regular input / output pins that go between the various modules: ECU, Certification (immobilizer) unit, body control unit, etc.. Some of the pin names sound usable, such as IMI, IMO. Reading the reference manual and piecing some information together, the cert unit will set these pins to tell the ECU that the key fob authenticated. The problem is that it looks like once the cert unit sets those pins for the ECU / BCM, it then "asks" the cert unit if it is "OK". Kind of like asking "did you tell me that correctly?". I am assuming this is done over the CAN bus between the units and the data could even be encrypted. There are so many simple traps they can lay and any one of them can screw your plan completely. The only way I can see going with the reverse engineering approach is to spend lots of time looking at those signals to spoof them. That's what all of these companies do. I don't have access to the various control units right now.. and I am not exactly going to rip them out of my only working vehicle.

By the way, my state machine discussion in a previous response about why the engine shuts off and the alarm may sound is spot on. The manual actually shows you the state machine. The vehicle is tightly tracking the state of every single door and sensor that can possibly do with security.

The Tacoma employs a steering wheel lock and a shift lock, both used in the security system. Previous research indicated that they might have used the door jamb sensor to kill the engine on remote start, because they didn't include a shift lock to save cost. Debunked.

 

My thinking is that the arm/disarm are discrete signals from the master power door lock switch. Or even the driver door key cylinder (hence the note: 2x pulse).

 

I actually have an old Tacoma, but this thread intrigues me as I have a camry pts that is like to add remote start with takeover to

 

Two things i just learned. You can start your vehicle with a key fob that has a dead battery. This is probably already explained in another thread (that I did not read). Its interesting because I did see reference to an antenna of some sort near the steering column and was wondering what it was for. Looks like it is near the PTS button. The way this would work is a simple NFC type transaction. The PTS antenna powers the key fob when you press the brake pedal and the key fob can send back a response to start the vehicle. Wireless power / NFC type transactions are highly distance dependent, which is why you need to place your fob directly over the PTS button. I think the power transfer ratio drops off with the square of the distance.

The second thing I learned is that the Tacoma keyfob is NOT potted AND there are numbers on some of the chips. Holey moley. I have never taken the fob apart, so I just assumed it was under lock and key with potting compounds and numbers rubbed off on chips. Unfortunately, I cannot read the numbers with my eyesight. Loupe coming tomorrow. It's probably nothing.

 

I think the key to cracking this nut is to take the battery out of the key and check to see if this sequence works:

1) roll down windows
2) get out of truck
3) lock doors
4) wait a few minutes
5) unlock door with physical key.. by putting in door lock cylinder and turning right twice
6) do not open the door, but get in truck
7) hold key up to start button
8)hold down brake pedal and push start (truck should start)
9) Open door... truck should remain running

one question is whether or not the steering wheel is unlocked at step 7. Because for true takeover... #7 should not cause the steering wheel to unlock. Because on takeover scenario, you should have to push start twice to release the steering wheel.

Even if the steering wheel is unlocked at step 7 its not a big deal.. it just means that someone could theoretically could get into the truck and drive off. But if they shut it down.. it wont start again.

 

Im sure its an ASIC of some sort... and most of those types of security chips cant be dumped via a chip reader.

 

Ok, so after some formulating, I think that the re transmitter idea has the best chance for investigation and because it shouldn't involve me taking apart any of my truck. The first step will be an investigation as to how the car operates with the key fob. Depending on the results of this investigation, we can move to automation. The plan is to get the car to remote start without the key fob being anywhere in the vicinity with help from a human. Again, depending on the results, we can automate the human factor using an arduino and tapping into the sensor signals.

First Step
Here we have to analyze the signals sent and received from the vehicle. We can do this by using a laptop and an SDR. The goal of this step is to find the RF frequencies of the key fob and making sure we can decode the packet bit streams. Pressing the unlock buttons, starting the vehicle normally, with the fob in the vicinity will allow us to capture all of the RF data.

Second Step
This step involves trying to get the vehicle to authenticate without a fob being in the vicinity using a laptop transceiver and a variant of the rolljam method. This step is dependent on the results of the first step. The following list is based on how I think the communication works between the vehicle and fob.

1. Unlock / start the vehicle normally with fob in vicinity. Stop and exit the truck and lock the doors. This is to get the vehicle into a "known" state.
2. Bring fob out of range
3. Go next to the vehicle and press the unlock button. Capture the RF packet sent as a "challenge" to the fob. Vehicle will not open.
4. Go next to the fob and re transmit the RF packet from the vehicle to the fob. Capture the RF packet response from the fob.
5. Go back to the vehicle and press the unlock button again. Program the SDR to resend the fob RF response to the vehicle when a new wild RF challenge packet comes from the vehicle. Door should unlock
6. Open the door
7. Repeat from step (3) to (4), except do it by depressing the brake. (First brake press sends a challenge and won't allow the vehicle to be started). Make sure you leave the door open during this entire process.
8. Climb into the vehicle and shut the door. Repeat step (5) except using the brake. Vehicle should be ready to start. Press the PTS switch to start the vehicle.
9. Open the door

After step (9), the vehicle should remain running and all the while the key fob was nowhere near the vehicle: steps (2) - (9)

How does this work?
Essentially the authentication between the vehicle and fob works as a challenge & response pair. The vehicle sends a challenge signal out and the fob responds with a valid keyed packet. What we are doing here is very rolljam like. At each authentication step (unlocking the doors, starting the vehicle), we first trigger that authentication step and capture the RF challenge packet from the vehicle. Since there is no key fob in the vicinity, the vehicle never gets a response. We can then 'illicit' a response by "replaying" the RF challenge packet next to the fob to capture its response. When the vehicle spits out another challenge packet the second time, we can replay the stored captured fob response.

Will it Work?
Maybe. This is why its an investigation. Since we do not know much about Toyota's authentication system, its possible that each challenge and response is keyed together. I am not a cryptography expert, so I have no idea if that can be done. From my understanding, the vehicles work in a way that a delayed RF packet (possibly keyed by a previous challenge) should still work.

Why the Rolljam technique instead of straight re transmission?
When we look at how vehicles are being stolen, you can see that they employ a straight re transmission technique instead of a "delayed by 1" type of system explained here. The reason they can do this is because they are using straight RF using an analog amplifier. They can rebroadcast the RF signals instantaneously without any "latency". My theory is that network latency (as described by myself and @ksJoe ) will actually be a large issue and the system cannot tolerate it. Yes, 1ms is fast, but I fear not fast enough (and what if the latency is much worse!). Considering RF is basically instant, 1ms is an eternity. Its very possible that the vehicle wants its "challenge" packets to be responded to sub 1ms.

Another issue is range. Analog amplifiers are going to have a limited range and the power / range is going to be dictated by the laws. So yes, re transmission via RF will work to however many hundreds of feet. At a former job, the parking lot was 0.25 miles away from the building. I had a coworker who had a remote start, and on hot or wintry days would use the remote start for his vehicle. Range didn't matter, because it was using the cell network. If you have a use case that is over very long distances, maybe miles, RF just isn't a viable option.. not to mention the required power output would most likely jam anything in the area and get you in a lot of trouble.

One other major issue is technical. With the "delayed by 1" method here, we can actually digitize the signal for low bandwidth transmission over a wireless network (such as cell). Since network latency is taken out of the equation here, we can use simple SMS service to get the job done. I have mentioned that SMS service is an order of magnitude easier to work with compared to cell data.

 

The discussions not the drama

 

For anyone interested, Fortin remote start wiring diagram (19PTS) can be found on page 4 of the PDF here. Found on their Tacoma website here

 

Interesting. Fortin is attacking the BCM and not touching the CCM (cert unit). And therein lies the problem.

Good information on how they are making a product and splicing it into the system though.