Development of DIY Electronic Upgrades

They are, that's why we do lock unlock lock sequence prior to a remote start on vehicles with alarms and then remote start them before they get a chance to re-arm.

 

Are you saying 1ms continuous pulsing as opposed to a radiating signal? If you know the processor's scan time, you can put priority on this like a watch dog routine and lower latency if need be and use the fastest scan time possible. 1ms is an eternity. I would think you would be in the micro magnitude for this. But then this becomes a hog...I could see timing being off if caught in the perfect storm.

And yes, decrypting is what I was speaking of earlier to create a virtual key, as you now know, Fortin does it. I use the software all the time. The remote starter is taught to the vehicle's CAN system, then brought back in for a final decryption to create a virtual key and it works just fine. Different approach, yes, but more modern than the other way of wrapping a loop around a dedicated key and placing it in a box and stashing away in the vehicle. Point is, it's not impossible, but not easy if you have no resource info either.



I think the limitation here is that emulating a human versus digitally doing this will be the challenge and I would think human emulation is def the easiest approach.

The reason remote starters tie into CAN is to watch for system errors and signal status that would void a remote start such as hood open, door open, etc...that way you don't have to tie into a thousand connectors to do it via DIO since making plug n play harnesses minimal with respects to connectors is key to a simple install...plus you would be T-harnessing everything if it were based on DIO and not CAN. These are safety issues you would need to account for as in a system check similar to what most remote starters do, so that you ensure the vehicle is beyond ready for a remote start, and not just meeting the human emulation process/sequence.

 

I am saying the latency on a good day of an IP network is 1ms. I remember when I used to game and 8ms was an insanely good latency and that was wired. My point is that a cell network's data latency can be extremely bad at any given point.

The vehicle challenge / response pair happens almost instantaneously because its analog RF, that means the latency of the analog parts + the RF radiated latency. We are talking way less than sub 1ms. If I need the response to appear sub 1ms, and my IP network has latency >= 1ms - it won't work. And by sub 1ms, I am talking a handful of microseconds.

No, I do not think this is the case. Again, I will not assert certainty here, because I always stand to be corrected. The reason I do not think this is the case is because IFF (IFF = if and only if) they literally cracked the encryption on the fob, they could do whatever the hell they wanted. They could make new no compromise key fobs at will. The engine shutting down upon a door opening would be a thing of the past. Additionally, Toyota would catch wind of this extremely quickly. I have no doubt that Toyota has people that scours these systems to make exactly sure the encryption has not been cracked.

What they are doing is training their system on the CAN bus and I/O signals to figure out the best way to mimic them. This is a virtual key to the lay man. What's the difference between a virtual key and a real one if it gets the job done? The point is that the virtual key does not get the job done without compromises.

Now unless you can tell me what's going on under the hood, I hate to say it, but stating that "Fortin does it, I use the software all the time" means literally zero. I click buttons on my windows programs all the time that transfer large swaths of network data too. Do I claim that one program sending data to Amazon web has cracked their AES 256 encryption, because the data transferred successfully? Of course not. You see the end result of what's happening, not how it got done. I know that is a little hard to digest, because there is not a lot of information on this stuff at the embedded level for vehicles, so a people tend to make assumptions in the absence of information.

Yes, it quite literally is impossible to crack this type of encryption without days, months, years of man resources and dedicated super hardware. It took them how long to finally crack DST40? And that was an extremely easy one. I am not sure you understand cryptography enough to make such a statement. All Toyota would have to do is use AES 256 and "poof" even the most powerful supercomputer in the world could not crack it in under 10,000 years. I don't care what kind of server compute power Fortin is pulling, its not enough to crack whatever Toyota is using. The exact day that a particular encryption is cracked it the exact day it will be found out and another algorithm used in the next vehicle. Massive research teams spend their careers cracking encryption and they don't get to see many successful cracks in their lifetime.

Can Fortin make me an exact replica of a key fob that they did not in any way purchase or get help from Toyota for? "No! That would be a huge deal!" You have your answer on if they broke the encryption or not.

One other thing to add here. Ever wonder why these remote start systems advertise they offer security features like alarms and x, y, and z? Isn't that a feature of the car already? It's because they are trying to bypass huge swatches of the built in features by poorly spoofing portions of it. And it happens by doing this, they bypass the built in features and there are some side effects... like the fact that they can't quite takeover the vehicle. After a remote start, the ECU notices that the engine is running when the door opens but can't exactly tell why. The only thing it realizes is that "This is not right!" so it shuts the engine off. The remote start does not do a good job of putting the ECU in the correct state to tell it that everything is OK, because it has no way to do so.

Lastly, somebody mentioned, might have been you, that the reason they don't make such a remote start is in part due to liability. I have given this some thought, and I think the reason is exactly because they are not re transmitting the RF signals but because they are spoofing the communication to the ECU without properly dealing with the certification ECU and have not gotten it to fully work for takeover.

With that said, the liability part of it is easy to solve, because they can just lock the doors again once the remote start is executed. Just by doing this, you are already on par with Toyota's existing security system because their security can't even protect against a simple rolljam attack. Therefore if somebody broke into the truck after the doors are locked, you can blame Toyota for that one, because the user would have had to use the fob to unlock the doors.

 

Valid points. Wish you best of luck with your project.

 

Took apart the key fob to investigate. Turns out the key fob exactly matches many other Toyota Fobs. Found this one on image search one you put in the number at the top of the fob.

This fob was for a 2017 RAV4.

The fob I have matches this one except for part number of the chip in the top left. The PCB layout is exactly the same. The top left chip is some sort of unmarked automotive micro controller from TI: TMS37200 series. The chip in the bottom left is a denso part D151811. Can't find any datasheets on these two parts (obviously). PCB designers often like to put the year of manufacturer on these types of professional boards, therefore the 7/10 is interesting, because that tells me the PCB design was probably from July 2010.

My fob changes the upper left chip for a TMS37202B. I am guessing just a more modern variant of the older chip... more flash, RAM, etc..

Even if the PCB designs are from 2010, it doesn't change the fact that the RF protocol can be completely different between car models. This is because they can easily just change the firmware within the micro controller when they first load it or update it. The RF section can stay the same, because all they need is a transceiver. The micro controller is doing so little work, I wouldn't be surprised if they could easily bit bang any RF protocol they wanted in software.

@N2DesignsInc
A lot of what I say is educated speculation from my knowledge in the electronics field and the research I have done.

If you have concrete details on what is actually happening under the hood with your or other remote start system that negates anything I have said, I am willing to listen.

I never said this project was going to bear fruit, but at the very least we can learn about how the system works at a much more technical level.

 

Wow... I just found this "Keto" kick starter. The way it works is that you put a second fob in the car and the module only powers the fob when you need it. Something so goddamn simple and I missed that.

I think I want to go with the 2nd fob approach and see what happens. I personally am not trying to appeal to the masses. I started this thread to sate my own tinkering curiosity and give out those plans, so if other people don't like the idea.. then meh. I have specific requirements.. I want a remote start that doesn't suck and am willing to do whatever for it. I have one key fob attached to my lanyard that I carry along whenever I go out and the other fob is just picking up dust. Its been sitting in the same spot since I first bought the truck.

Now, the fact that Toyota doesn't pot these particular key fobs (and probably many others) works in my favor. This means I can simply take the PCB out of the fob and manipulate it electrically. I will have to do some testing to make sure powering ON / OFF the fob using a switch doesn't break anything.

Since we would be using the PCB from the fob here, it could easily just be integrated straight into a custom head unit.

 

So just wanted to give an update.

I found and bought a 2019 HVAC trim module from ebay for $100 so that I could dissect the electronics instead of taking the one out of my vehicle and screwing it up. The HVAC module in the 2019 Tacoma is a plastic module that can be removed by snapping the trim around the edges and pulling it out. There is a video on the forums of a guy removing the module in less than 5 minutes to change the control knob chrome pieces to aftermarket. The module contains the following buttons (on my 2019 TRD Sport): PTS button, 4WD selector, defrost, fan speed, A/C, ventilation, mode, hazard lights, and several LEDs for indication. The PTS button, and the 4WD selectors are their own little packaged module plugs and everything else is part of the same connector. The module connects to the body control unit & certification unit via 3 connectors: PTS plug connector, 4WD selector connector, and everything else connector.

What I was investigating is whether or not any electronics in the HVAC module would prevent a full customized trim / electronics solution from happening. My fear was that there was complex communication going on between the certification unit and the HVAC module. This is not the case. I have looked at all the connectors and electronics within the HVAC module and all of it is simple mechanical switching with a bunch of LEDs going from the connectors, except for the PTS plug.

I pulled apart the PTS and 4WD module plugs to investigate the electronics within since they each have a dedicated connector. The 4WD plug is easy and is just a bunch of mechanical switching.

The PTS plug is a little more complicated, but would not prevent a full custom solution. The PTS plug contains both a mechanical switch for the button press but also an active antenna module for authenticating with a dead fob. If you look elsewhere, you will find out that the Tacoma can still be started from a dead fob. The way this works is that the PTS plug contains an antenna and an radio chip. The radio chip is a TMS3705. Basically this chip is a very dumb transceiver that does nothing but encodes / decodes analog RF signals into digital bit patterns. The fob uses around a 125kHz frequency. The system works very similar to an RFID chip or NFC; the PTS antenna provides power to a dead fob via wireless power transfer and allows the fob to authenticate with the vehicle. I am not sure of the exact sequence (look on youtube), but when the user puts the vehicle into accessory mode (I think the vehicle allows you to do this without fob authentication), the certification unit starts monitoring the antenna for a fob by sending out a short wave power burst continuously. Now, since the PTS plug only contains this dumb RF transceiver (which you can buy online) and doesn't contain any smart communication to the certification unit, the entire PTS button plug can be replaced. In fact, you could roll your own antenna if you wanted.

Looking at all the cool things that I could do with the HVAC module, I think this is a prime candidate for 3d printing a new trim. Structural integrity is not so much an issue here, because the plastic used in the trim is ridiculously flimsy.

For the remote start, sacrificing the 2nd fob and powering on demand should work fine given that I now know how the PTS switch works electrically. For some coolness, I am thinking about replacing all of the heater knobs and buttons and entirely redoing the controls. For example, I could 3d print some new knob mechanisms that have integrated round LCD screens. The LCD screens would replace the inner static decals. The knobs would turn like normal, but all the status and selection information would be on the LCD screens. Color schemes could be selected, etc..

Keep in mind that I also want to control the HVAC settings wirelessly, so that I can set the settings if I remote start the vehicle. For example, maybe you forgot to put the knob in the right position when you came out of your car last. Since the control is electronic, that would not be an issue.

 

Very curious to see what you're able to do with your HVAC ideas.

 

Just traced out the electrical connections for the HVAC control module. Jeez.. I have to just sit in awe at the weird and seemingly troublesome things people do just to save a few pennies. Keep in mind I have the full wiring diagram to the truck, so I wanted to see if I could trace it out on the PCBs.

So for the heater temperature and mode knobs, they are using potentiometers. Basically when you rotate the knobs, they will also rotate the pots and different resistance values can be read. I would have thought they were using rotary encoders... nope. I can sort of understand the pot for the heater temp knob, because its analog... but using the same system for the mode knob is just asanine, because it only has discrete positions. In this case, what they have to do to make the pot into "discrete positions" that can be read by the control unit is have a massive slop factor in the resistances read. This is because no 2 pots will be wound exactly the same. Since they play a mechanical shirade with the fan speed knob (get to it next), I don't understand why they couldn't have done it with the mode knob for the proper electronics design. The mode knob should be implemented as discrete switches. Now.. I can understand why they wouldn't want to do this outright, because you would need that many more pins (1 per mode) on the connector in the basic case. However! they could have easily put a decoder chip on here to encode a digital bit pattern onto the connector instead, which would only require log2(# modes) number of pins. This would have by my preferred choice, because it looks like there might be some unused pins anyways on the connector. Or, yet another way would have a simple serial communication to the body unit to encode every setting on this board and only use 2 - 4 pins overall. I guess they had to look at the cost / complexity requirements.

Now for the fan speed knob, they went to a lot of trouble fabricating some specialized parts for this. This section of the controls connects to the infamous blower motor resistor box. The way it works is that the speed knob is connected to some metal pieces behind the scenes. Depending on the speed selection, 1, 2, or 3 pins are shorted together that connect to ground. Depending on the path to ground, they can put higher / lower value resistors in the path in order to make a greater or less resistance to ground. This will cause the blower motor to sink more or less current and thus adjust the speed.

Since the fan speed setting electronics is so simple, this can be switched out to a complete analog solution using a transistor. If I am going with the same LCD mechanism explained previously, I could allow the user to mimic the original OFF, LO, 1, 2, and HI settings just by controlling the current through the transistor in the same way the resistor box would. Essentially you can have a knob like the heater temperature knob that allows a full range setting or we can have presets: 25, 50, 75, 100%. The blower motor resistor box is not needed in this case.

 

Thanks for the link to this forum. Guess I'll be following this one too. Stay tuned for more questions and comments.

 

So... looking back at the mode selection buggery... Since it is using a pot for the mode selection just like the heat knob, I think both mode and heat setting are analog. However, the mode knob is exposed to the user as discrete positions. The wiring diagram for this portion of the controls shows the mode selection pot driving a motor. This means it would be possible to control the air flow valve in not just the discrete positions, but anything in between too.

 

The discrete positions are imposed via what, molding that forces the knob to seat in specific spots? Easy fix if so, I'd think.

 

Yes, that's exactly it. You should see the workmanship that goes into making these weird mechanical and plastic structures just to impose the discrete positions. It's not something that needs to be "fixed", just interesting that I think you can control the motor via an analog control. I am not sure what real world use it would be on top of the discrete positions and manual control. I can see the motor position being modulated with the automated controls, because its one more variable to "tune" the cabin temperature.

 

Real quick, going back to the FOB, not that it matters, but the sensor diagram was found over here

 

Just wanted to give an update. Stuff has been very slow the past few months.. and it will continue like this due to C19. I am also given the run around due to my job situation so...

Previously, I read the "tip" about being able to start the vehicle without pressing the brake pedal using the PTS button. I tried this sequence a few months ago, but it did not seem to work on my '19 Tacoma. I decided to give it another go this morning after tinkering with the PTS accessory states. This PTS sequence is verified to work on my '19 Tacoma. If this is old information, then you can ignore the next section.

How it works:
The PTS button manages essentially 4 vehicle states: OFF, Audio, Accessory, Engine ON. From an OFF, if you press the button once, you should go into the audio state and see your head unit come on. Press the button again, you will go into the ACC state and be able to mess with your HVAC controls. Press the button a third time, you go back to OFF unless your intention is to start the vehicle using the brake.. and so on. The engine start without pressing the brake pedal exists between the transition of Audio and ACC. Press the button once to go into Audio mode. Once you see your head unit come to life, wait a second or two and initiate a button hold. Your vehicle will go into the ACC state; however, the button is still being held down. Hold the button for (15 or more) seconds and your engine should now start. The LCD in the dash may be displaying a bunch of hogwash during this time such as a charging system error or press the brake to start the engine... ignore that. Your vehicle engine should now be started. I exited the vehicle, shut the door and waited for the system to be re armed and re entered the vehicle and it was still running. I waited outside my vehicle door and did not attempt leaving it for a longer distance before re entering.

What this means:
I have been trying to think of ideas of how to integrate a remote start utilizing the second fob that does not turn off the vehicle when re entered that may have had to utilize the break pedal switch. Since the mechanism above works, I can look at something else.

As mentioned in a previous reply, I think utilizing the second fob inside the vehicle for the remote start is much more doable than putzing with the immobilizer garbo that 99% of the existing remote starts do. COTS solutions require rewiring, this and that.. blah. I want something fairly simple. My second key fob literally gathers dust within my bed stand... so if I permanently install it inside the vehicle for remote functionality, I have zero problem with that.

After reviewing the PTS button, the entire thing is just one little slick module that is easily replaceable. What I am thinking is that I can just remake this module with a spot to integrate the key fob PCB and there you have it. It should be a simple module swap. So basically the module would have a custom PCB that includes the key fob PCB and a radio. When the radio receives a coded sequence remotely, say a text message, it selectively powers the integrated key fob and can start the vehicle. This is similar to how the Keto project worked.. that project now seems dead though because their (crappy) engineering could not follow through.

HVAC Controls:
I have been giving this some extra thought. I think I want to start with just the remote start and maybe move on to a custom HVAC remote control section. I was having some issues with the strategy here. If you integrate mechanical buttons on the panel but also want to remote control the HVAC settings, then how do you "sync" the current position of each knob to the remote settings? There could be several ways to do this, but they are not very practical.. such as installing motors to rotate the knobs to the remote setting. When it comes to vehicle controls, I feel everything needs to be very intuitive and work as it does currently with the end stops and haptic sensations.

I had a stroke of idea after I started using a macbook from my workplace and investigated how the touch pad worked. I am not a mac guy and do not have lots of experience with "haptics". Turns out the entire touch pad is not a mechanical button, but instead a touch sensor with integrated electro magnetic motors. I noticed that when the macbook was powered off, I was no longer able to get a "click" by pressing the touch pad.. so I wondered, how is that possible with a mechanical switch? If using a mechanical switch, regardless of the state of the machine, it would have the same sensations no matter what. However, what I was seeing is that the touch pad was dynamically enabling different click (single + double) sensations depending on the running app. What the hell?

There is no mechanical switches in the touch pad, its all haptics. When the touch pad detects a force upon it by pressing down, a motor is actuated to produce a click sensation. This is "haptic feedback". A primitive haptic feedback that you and I may be familiar with is that of vibration motors within digital watches.

What does this have to do with the HVAC controls? Well, imagine a knob that implements haptic feedback controls electronically. You can literally implement crazy complex sensations electronically, dynamically, and super easily, that would be almost impossible utilizing mechanical structures. End stops, detents, resistance turning, any combination of those, etc.. If you are able to control the feedback electronically, it also completely solves the remote knob "sync" problem. When the user sets a new HVAC setting remotely, you can just reprogram the knob on the fly to the new absolute position.

Haptic feedback control seems super complicated. I am doing some investigations now, and if they pan out, I can tell you that you can implement such a knob using a small COTS DC motor and it would require no input power. What?! Impossible!

Well.. let me ask you this question. If you are familiar with DC motors, then you know that if the motor terminals are just freely floating (not connected to anything) and you rotate the motor shaft, it will rotate freely. Now.. what happens if you take the 2 motor terminals and short them together and try to rotate the shaft? It becomes extremely hard to move.. you might even say the motor is stalled. Lastly, what would happen if you could electronically "control the short" through a transistor and a PWM signal? I will leave you with that

 

If anybody is interested, please read this reddit post that I started last night. If you have comments or would like to see the project go somewhere, then post a comment as it is appreciated. https://www.reddit.com/r/Toyota/comments/hq7zoi/3rd_gen_tacoma_possible_development_of_new_type/. I am trying to diversity the visibility to this problem.

 

So, I have been giving this more thought off and on.

The vehicle has a feature to start the engine from a dead fob. Inside the push to start button module is a base station chip (TMS3705) that uses RFID to transfer power and data to a dead fob to start the engine. This also happens to be a weak point in the system, because I think I have reverse engineered a method that uses an RF 'relay' method to remote start the vehicle as if the fob was inside the vehicle using the dead fob feature. It turns out that the signal timing on this is extremely tight. There was some talk earlier in the thread of being able to use cellular in order to create a fob relay; however, I don't think that is possible given the timing constraints. If the latency was in the tens of milliseconds, cellular might work; however, it looks like the communication has to happen within a couple of milliseconds otherwise the certification ECU will time out the request.

How would a dead fob relay work? Basically the TMS3705 chip uses RF to first charge a dead fob and then communicate to it using a data transfer. The amount of charge stored in the capacitors in the fob is enough for the data challenge / response process to start the engine. The caps only need to hold a few tens of milliseconds worth of charge. The TMS3705 communicates to the fob in 3 phases: charge, downlink and uplink. Of course, this could be repeated several times in order to transfer larger amounts of data inside a "session". The downlink portion uses OOK (on off keying) to send data from the certification ECU to the fob - something like "here is a engine start request, here is my private encryption key". The fob then responds with "here is the calculated passcode using that private key" in the uplink stage. The certification ECU crunches the data with the fobs registered with the vehicle to determine if that particular fob goes with the current vehicle. If all the data lines up, the engine starts.

All RF data is transmitted / received at either 134.2khz OR 123.4kHz. There would be two components to the system - a new push to start module "spoofing" the TMS3705 communication and a new "case" for a key fob PCB that is registered with the vehicle. Basically during the uplink portion (OOK), you can modulate a higher frequency RF carrier during the ON periods of the TMS3705 cert ECU TX data from the PTS module. This modulation is received by the fob module and it spoofs the 134.2kHz transmission to the original fob PCB. The fob PCB then sends its response data that is intercepted by the fob module during the downlink portion. The fob module modulates the data back at a higher carrier frequency to send out the binary bits to the PTS module. The PTS module receives the bits and spoofs the RX signal back to the certification ECU.

I use "spoof" very loosely here, because the communication is not really "spoofed". Its happening in real time with an actual keyed key fob.

After figuring out that its probably possible to start the engine of the vehicle as if the fob was inside, the question now becomes security. The vehicle, as we all know, has a "catch all" with the brake pedal. Now that this security feature would be disabled, how would we prevent somebody from breaking the window and driving off? The short answer is that you won't prevent it and this has been my sticking point for several weeks. All added electronics and sensors to attempt to prevent somebody from doing this lead to a dead end, because they are not "foolproof" like what Toyota currently has implemented with the brake pedal. All of the control units in the vehicle (ECU, skid ECU, etc.) are keyed to each other in lock step, so if anything is funny, the engine will shut off. With bypassing the brake pedal and starting the vehicle as if the fob was inside, what is stopping somebody from say disconnecting the brake sensor and defeating an extra check we try to put inside the custom PTS module? Let's say we implement a brake pedal check or whatever in our custom module. A thief could break the window, disconnect the brake sensor... OR cut power to the custom PTS module and off they go. As much as we hate the brake pedal engine kill, it really is a catch all, the more time I think about it - its hard coded right into the ECU firmware. The only way to defeat it would be for a thief to break the window and replace the entire ECU with something else, which is not happening. By contrast, by 'disabling' the brake check in this custom mechanism, a thief could just rewire a few things or cut power to a few things and the module would be none of the wiser. I just can't figure out a foolproof method of detecting a thief breaking the window and rewiring our "addons" to bypass them and drive off.. even with all different types of sensors (proximity, IR, cameras, E-field).. and at the same time maintain the 'ease of use' of the system. A glass break sensor you might say! Apparently they would work for the side windows, but not the windshield because its made of different glass. An attacker could cut a hole in the windshield and get in that way. yadda yadda. We need to brainstorm to see if security is as big of an issue as I think it is - and if it is, what we can do about it when we bypass the built in brake "catch all".


I have another thought I would like to test out, but am not willing to do it on my own vehicle. I don't have the luxury of running these types of scenarios / test where I am living currently. Now.. we know that the whole "Can you kill the engine while you are in drive and you press the push to start button" is an actual question that has been investigated in a few videos. Basically the theory is that it would be dangerous for the vehicle to kill the engine if the vehicle is in anything other than park, by itself. However, you can kill the engine by holding the PTS button in, in such a scenario.. but its not standard. We also know its possible to bypass the shift lock solenoid by a mechanical button, hell, you could just electronically spoof that signal as well to bypass the lock. So the question is this: What happens if you trick the vehicle into thinking that the brake pedal has not been pressed AND you 'manually' shift into something other than park? Once the brake signal is restored, will the vehicle kill the engine while its in drive for example?

The scenario is this: We know that the vehicle relies on the door sensor switch and the brake pedal switch to detect when to kill the engine with aftermarket remote starts. Let's unplug the door sensor AND the brake pedal sensor and manually shift into a different gear so that the vehicle does not know about it. Once you reconnect the brake pedal sensor and depress the brake so the vehicle knows about it now, will the vehicle try to kill the engine while you are in drive, for example? My guess is that it will; however, if it doesn't, we have the first steps of finding a loophole in the Toyota system to bypass the engine cut off using more "conventional" and less complex means.

An electronic system could tap into the door and brake sensors and spoof those signals and as well spoof the shift lock sensor. All of this could be tracked electronically. The system could spoof the sensors while you are in park, so the vehicle does not see them, but then "unspoof" them once it detects you have shifted out of park. This would be very easy. We may have to disconnect more sensors than the ones mentioned, such as the shift position switches. The point is to see what the vehicle will do by putting the shifter in an "invalid" state and then "re exposing" it to the vehicle. If it wants to maintain its "safety" of not cutting the engine while 'not' in park, then the engine won't shut off.


Also.. as a last note. Anything that I intend to implement to bypass the engine kill will still be a two step system for security reasons. The question is how to make the system 'more' secure in the case that a thief tries to rewire the addons by breaking a window. The plan would be to bypass the built in engine kill, but also re implement its features with a secondary authentication. For example, once you enter the vehicle, you would have to do an NFC swipe with your phone to a tag in the custom PTS module to "authenticate" it to release control. The system would be wired up to various sensors, such as the brake pedal sensor. If it sees that you didn't do the NFC swipe, it would kill the engine. What I would strive for is 'properly' implementing the two step takeover process that most other companies have actually done correctly for remote starts.

 

Dear LostTime77,
You had me at "hello". Any chance you can "explain it like I were 5 years old"?

BTW, we appreciate your enthusiasm and persistence!!! Thank you!

 

OP, this is amazing stuff. I hope it turns out well!

 

Interesting, but what would be more interesting would be if you actually wired up the remote start in the truck and got it working without shutdown when you enter the vehicle instead of just talking about all of the different theories about how to do it.... Just my 2 cents.