Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Ingenext Boost Modules [aftermarket]

This site may earn commission on affiliate links.
I sent email to their support, and they've confirmed that it is transferable for a $100 fee. You have to send the module back to them for reprogramming, to get it ready for another vehicle.
Im personally going thru this right now. Sent mine back to them to wipe clean. Sold it to another dual motor owner.
I purchased a actual m3p instead. I can personally vouch the boost 50 kit is worth every penny.
Having both the boost 50 and now a m3p there is very little difference EXCEPT from the launch.
The launch on the P is gut wrenching which is how it knocks it down to 3.2.
 
  • Like
Reactions: mrau
Im personally going thru this right now. Sent mine back to them to wipe clean. Sold it to another dual motor owner.
I purchased a actual m3p instead. I can personally vouch the boost 50 kit is worth every penny.
Having both the boost 50 and now a m3p there is very little difference EXCEPT from the launch.
The launch on the P is gut wrenching which is how it knocks it down to 3.2.

Good to hear! Has it been completed yet? Any issues on either end?
 
Its on its way back to me currently then off to the new owner.
I purchased the "Bonus Module" for my m3p which Im going to be installing.
I loved the features of the boost 50 and really miss the auto door present and some of the other features included
with the boost 50.
 
I think I want to wait and see if V11 will enable canBUS encryption.

If that isn’t enabled then I’ll probably get the Ghost upgrade. From my limited understanding the encryption will make all mods piggybacking the canBUS useless.
Easy solution...Don’t upgrade to V11. To me the car is perfect as is. Tesla updates way too much anyways.
 
Eventually we will have to thank those guys for CAN bus encryption that Tesla can turn on any day if they want. And then good bye all those critically important loggers.

I have some knowledge programming CANbus networks. I have yet to hear how someone would go about encrypting regular broadcasting CANbus data streams and still adhere to the CANbus protocol itself. Do you know how this would be done? Can you explain a little of the implementation to me or point me to some reference material somewhere?
 
I have some knowledge programming CANbus networks. I have yet to hear how someone would go about encrypting regular broadcasting CANbus data streams and still adhere to the CANbus protocol itself. Do you know how this would be done? Can you explain a little of the implementation to me or point me to some reference material somewhere?

Why would it need to adhere to the CANbus protocol?
 
I suspect robust CAN encryption will require hardware changes. Here's an interesting paper on CAN security, which happens to reference Tesla.

(PDF) Evaluation of CAN Bus Security Challenges
You don't need changes - all MCUs already have certificates of each other and Tesla. They all have encrypted chatter between them through the ethernet. Nothing stops them from exchanging a key for any encryption method of CAN messages. They can keep unencrypted headers with address and salt, but encrypt the content itself. And while tiny encrypted blocks is not very robust encryption - that still would be end of the story. You refer to the article that assumes CAN is the only means of modules communication, but it's not the case for Tesla.
 
My understanding is that the physical layer connects CANbus transceivers at all the devices and those transceiver chipsets that are not capable of being modified via software to handle non CANbus related serial coms traffic. But, I could be wrong about this.
I doubt that Tesla uses HW implementation of CAN since even lumbar has ethernet with firmware updates and encryption. But it doesn't matter - you can encrypt values only anyway.
 
You don't need changes - all MCUs already have certificates of each other and Tesla. They all have encrypted chatter between them through the ethernet. Nothing stops them from exchanging a key for any encryption method of CAN messages. They can keep unencrypted headers with address and salt, but encrypt the content itself. And while tiny encrypted blocks is not very robust encryption - that still would be end of the story. You refer to the article that assumes CAN is the only means of modules communication, but it's not the case for Tesla.

So, every device on the vehicle that needs something like steering angle has a parallel Ethernet coms connection?

Assuming that the CANbus chips can’t be reprogrammed to pull 1 byte of data off of 1 ID message strong and then another byte off another message string to combine the form the full data piece, you would still have sequential data. For example, lets say 0x104 bytes 3 and 4 represent rear motor amps. Can that data be encrypted and still understood by the CANbus ICs due to the hex code numbers coming through on those bytes on that message ID in a non sequential manner? Meaning, 80 00 may no longer be 0 amps, but 30 amps, yet 80 01 will be -50 amps instead of 0.1 amps? Can the error checking mechanisms built into the data layer handle that. And would that data be statically encrypted? Meaning that it would always be same encryption keys such that someone with a Hioki meter could measure the current during driving and compare that back to the transmitted CAN values and decrypt the data, and that decrypted lookup table would always hold true?
 
So, every device on the vehicle that needs something like steering angle has a parallel Ethernet coms connection?

Assuming that the CANbus chips can’t be reprogrammed to pull 1 byte of data off of 1 ID message strong and then another byte off another message string to combine the form the full data piece, you would still have sequential data. For example, lets say 0x104 bytes 3 and 4 represent rear motor amps. Can that data be encrypted and still understood by the CANbus ICs due to the hex code numbers coming through on those bytes on that message ID in a non sequential manner? Meaning, 80 00 may no longer be 0 amps, but 30 amps, yet 80 01 will be -50 amps instead of 0.1 amps? Can the error checking mechanisms built into the data layer handle that. And would that data be statically encrypted? Meaning that it would always be same encryption keys such that someone with a Hioki meter could measure the current during driving and compare that back to the transmitted CAN values and decrypt the data, and that decrypted lookup table would always hold true?
Yes, everything in the car is connected by ethernet. And that communication is all encrypted and strong signed. So the point is that they can all agree on doing whatever they want and change CAN encryption or obfuscation on the fly. And so whatever you put in the middle of the CAN bus is doomed to be disrupted.

And I don't care about those performance hacks, but I need logs. And the only reason Tesla would turn on the encryption is to put those CAN hacks out of business.
 
  • Informative
Reactions: jjrandorin
Yes, everything in the car is connected by ethernet. And that communication is all encrypted and strong signed. So the point is that they can all agree on doing whatever they want and change CAN encryption or obfuscation on the fly. And so whatever you put in the middle of the CAN bus is doomed to be disrupted.

And I don't care about those performance hacks, but I need logs. And the only reason Tesla would turn on the encryption is to put those CAN hacks out of business.

So, the 2-wire CANbus and 1-wire LIN physical layers connecting a bunch of different components on the vehicles are completely redundant and/or useless?
 
Just a little update here on MY experience with Ghost:

I have already taken my car into Tesla service for warranty work and had no issues. Needed the front upper control arms replaced due to a defect in the suspension (appears to be well documented on older 3's). I removed the mod, dropped the car off, had the arms replaced under warranty, reconnected with Ingenext - got the mod re-installed and the module updated so that future updates do not require Ingenext involvement to remotely re-program. Everything is fine.

There is now a setting in the Ingenext app that you disallow updates so any attempts to update the car will fail. If a Tesla update becomes available - you simply check with Ingenext to confirm the update is safe as they have a page dedicated for that. Then you just toggle the feature on and enable it. This is also documented on page 20 of the Ghost manual.

They've added some other features in their app as well so you can see battery pack degradation and 0-60 time, etc.

I can say going back and forth between the Ghost and AWD+, that low end power on tap at less throttle is just so much more satisfying.

Cheers

Screenshot_20201202-125932.png
 
reconnected with Ingenext - got the mod re-installed and the module updated so that future updates do not require Ingenext involvement to remotely re-program. Everything is fine.
This is great news. I missed the black Friday/Monday sale. Didn't see this in time. I'm hoping there is an easy process to uninstall and reinstall under the glove box. So, once you install the module under the glove box you don't need to connect the laptop any longer?
I really want to do this. Need to wait until after the holidays. It's exciting to have the 980 motor. I really don't think Tesla dialed out all the performance though. Ran the Y at the track and it did a surprising 12.9sec at 111mph. Can't wait to give it another go after the ghost update.