Ingenext Boost Modules [aftermarket]

[Mash]

It's realtime by convenience; every controller operates with it and performs critical operations over the bus. You also keep saying queue as if that is a thing within the spec. It's timing based on priority and arbitration with transmission delay. If a lower priority node sees a transmission it just waits until the next. Any small disruption to the order can compound to a lot of missed frames and disruption over the network for lower-priority nodes.

But I don't really need to rely on my understanding of the protocol as there are many sources citing CAN as realtime (even if we both agree serial multiplex is not the best implementation for that purpose!!).

Lets take VCfront for example, with a 120 MHz clockspeed max. Now that's monstrously fast for an embedded device but considering all the operations it handles (everything forward of the firewall and HV equipment), that leaves very few cycles for general computation. There is an encryption engine that connected to the memory protection unit but that appears to only be used for hardening the memory. So any encryption algorithm would have to use the general instruction set, and would need to be tailored to each module (assuming that everything on the CAN isn't using the same monster chip).

Maybe you can speak to programming an embedded device; I certainly can't. But my understanding is that it contains no fluff and coding an arbitrary encryption algo would be difficult, hence the use of engines and peripheral chips. Couple that with the minor overhead to bandwidth, it makes implementing encryption with the current hardware extremely difficult, if not practically impossible. CAN encryption is a pointless endeavor, like teaching a horse how to pilot a plane; it's a difficult, pointless addition to something that already works.

In any case, we already agreed that detection and defeat of a CAN module is arbitrarily easy. The whole encryption debacle is theoretical nonsense.

Ok, it's offtopic. But whoever calls it realtime is wrong. It can be done predictable in maximum delay, but we are talking milliseconds delays anyway. And I insist that encryption won't require any bandwidth overhead and delays anywhere close to naturally expected from CAN bus.

If you can safely and regularly exchange a symmetric key (and Tesla modules can do that) - encryption of 8 bytes (maximum length of data in CAN) is incredibly fast with just a regular arithmetic instruction set. You can just XOR it with a key and be done with it. No bandwidth loss, way below 1 microsecond delay.

 

[ph0ton]

Ok, it's offtopic. But whoever calls it realtime is wrong. It can be done predictable in maximum delay, but we are talking milliseconds delays anyway. And I insist that encryption won't require any bandwidth overhead and delays anywhere close to naturally expected from CAN bus.

A given frame can take mere microseconds to transmit. Couple that with the fact that higher priority IDs will always transmit, it doesn't seem farfetched at all that mission-critical modules operate in realtime.

On the other hand, I've been taking Tesla to their word that they are performing some next-generation stability control with the motors; using steering wheel position, speed sensors, position sensors for the driven axle, and accelerometers (which I don't see in the diagram nor could I find for parts) to precisely control the torque delivered to the wheels.

But even if the stability control is modularized between brakes and motors, the stability control system controller is still sending and receiving signals over CAN with the iBooster. I'd be very skeptical it's not winning out in arbitration and sending signals below milliseconds without delay.

If you can safely and regularly exchange a symmetric key (and Tesla modules can do that) - encryption of 8 bytes (maximum length of data in CAN) is incredibly fast with just a regular arithmetic instruction set. You can just XOR it with a key and be done with it. No bandwidth loss, way below 1 microsecond delay.

This is a great approach but then you rely on modules to be encrypted themselves, otherwise you can easily get the common key off of it either by some sort of peripheral communication or directly from the memory. That might prevent ordinary monitoring over CAN but not a 3rd party module designed to circumvent the OEM control; that's sort of their thing. Then it just becomes an arms race where the barrier is hardening every module or implementing a more onerous cryptographic service.

Again, as entertaining as it may be, why is this even a discussion? There is very little gain for Tesla to implement even the most basic encryption, as evidenced by the absence of it. Meanwhile, nothing has to change architecture-wise, and the MCU can just listen for black-listed frames to prevent a module from working.

 

[PauliePucks]

Thanks. Glad to hear they both work. Planning to do the same!

There is an update for the TRUNK software, if you are on software 2022.20.** and up.

Here’s a link to their GitHub:

GitHub - evoffer/electric-liftgate-firmware: Firmware Update for Electric Liftgate Systems (Tesla Model S/X/3/Y) from EVOffer

Firmware Update for Electric Liftgate Systems (Tesla Model S/X/3/Y) from EVOffer - evoffer/electric-liftgate-firmware

github.com

There are also install videos linked there for reference. You will need a small sized micro sd (under 32gb). I would definitely recommend updating the firmware during your install since everything will still be exposed and you can tidy up after.

The update fixes an issue where the trunk showed it was closed when it was open on the tesla UI.

I’m still on 2022.12.3.0 fsdb so I haven’t done it yet.

 

[Bizzwhizz]

FYI 24.6 been fine for days with me.

 

[TM3-Ghost]

There is an update for the TRUNK software, if you are on software 2022.20.** and up.

Here’s a link to their GitHub:

GitHub - evoffer/electric-liftgate-firmware: Firmware Update for Electric Liftgate Systems (Tesla Model S/X/3/Y) from EVOffer

Firmware Update for Electric Liftgate Systems (Tesla Model S/X/3/Y) from EVOffer - evoffer/electric-liftgate-firmware

github.com

There are also install videos linked there for reference. You will need a small sized micro sd (under 32gb). I would definitely recommend updating the firmware during your install since everything will still be exposed and you can tidy up after.

The update fixes an issue where the trunk showed it was closed when it was open on the tesla UI.

I’m still on 2022.12.3.0 fsdb so I haven’t done it yet.

I just placed the order so won’t have them in a few weeks. But I’m also on the fsd branch, so still on 2022.12.3.20 too.

But appreciate the reference to GitHub. I’ll have to figure out how to format to fat32 with a Mac.

 

[pbcsd]

Is this the right picture to look at to see if the motor is eligible for the ghost upgrade? I don’t recognize any of these numbers…

 

[ph0ton]

Is this the right picture to look at to see if the motor is eligible for the ghost upgrade? I don’t recognize any of these numbers…

You're looking at the shock. Per the ingenext video it's above it, to the right, along the metal enclosure you see in the background.

 

[PauliePucks]

You're looking at the shock. Per the ingenext video it's above it, to the right, along the metal enclosure you see in the background.

If you’re able to remove the wheel (driver side rear) it makes life a lot easier. If not, some OEM wheels are easier to see through than others. The label is not necessarily out in the open, it’s slightly obscured and it’s almost behind the shock as mentioned above.

I have a 2019 m3 sr+ with 19” sport rims and I had to do some angling to get the label just barely visible. I have a 980 motor.

When I cleaned and lubed my brakes last I realized how easy it was to see the label with the wheel off. Hope that helps! Good luck, fingers crossed you have a 980

 

[itch808]

I admire all the talk about how and if Tesla can detect this "hack." I have no doubt they probably could if they wanted to put the work into it. BUT lets face it... Tesla has bigger issues to divert resources to. They are firing people and trying to maintain gross margins. They have a Cybertruck to deliver that has been delayed many times. They are trying to open their supercharger network to everyone by the end of the year. Full self driving is the endless project. Meanwhile there are numerous manufacturers playing catch up.

I don't think they have the time and resources to allocate towards <1% of the people on this thread who use ingenext's modules. It'd be a waste of resources. /Story

 

[Knightshade]

I admire all the talk about how and if Tesla can detect this "hack." I have no doubt they probably could if they wanted to put the work into it. BUT lets face it... Tesla has bigger issues to divert resources to.

This wouldn't require "devoting resources" to at all though.

The car already measures acceleration by default.

The car already has triggers that will put it into limp mode and tell you to contact service.

You add one line of code to the existing triggers that if the detection it's already doing ever detects acceleration in excess of what the official config is capable of, it triggers.

That'd take one guy they already have 5 minutes.

 

[itch808]

This wouldn't require "devoting resources" to at all though.

The car already measures acceleration by default.

The car already has triggers that will put it into limp mode and tell you to contact service.

You add one line of code to the existing triggers that if the detection it's already doing ever detects acceleration in excess of what the official config is capable of, it triggers.

That'd take one guy they already have 5 minutes.

If it was really one line of code don't you think they would've done it by now?

They would have to account for differing gradients of incline/decline, weight of vehicle/driver (someone could strip the interior out), tailwinds/headwinds, non stock wheels/tires and sizes, coefficient of friction for differing surfaces, and with varying SOCs. All these this things could in any moment affect acceleration. ONE line of code? Yeah right.

 

[Knightshade]

If it was really one line of code don't you think they would've done it by now?

No.

We know this for a fact

Because they previously DID include the one line of code to detect it-- and then chose to ONLY display a warning- not actually put it in limp mode.

That caused ingenuity to finally remove their outright false claim the module was "undetectable" from their website and advertising.

Tesla was making it clear they can detect it if they wish- and they're currently choosing not to do anything active about it.

But also making clear they could. And trivially.

They would have to account for differing gradients of incline/decline, weight of vehicle/driver (someone could strip the interior out), tailwinds/headwinds, non stock wheels/tires and sizes, coefficient of friction for differing surfaces, and with varying SOCs. All these this things could in any moment affect acceleration. ONE line of code? Yeah right.

No, they would not.

First- they already know much of what you just listed thanks to the sensors on the vehicle already (how else do you think the outstanding traction control systems work)?

The seats have weight sensors for example.

Moreover, most of what you list isn't even relevant because most of them are things that can not improve max acceleration- and certainly not remotely to the amount these hacks do.


Tailwinds?

You think there's a tail wind that would magically make a LR-AWD accelerate like a P?

On what planet- because it's not this one.

Surface friction for another example... there is no surface friction that would let the car accelerate faster than its max stock acceleration- that's a ridiculous thing to even mention... there's certainly surfaces that'd cause it to accelerate SLOWER, but you're not looking for that anyway.

But by all means let me know what surface I can put an LR AWD car on where it magically, WITHOUT a hack, accelerates like a P.

Come on. We'll wait.

 

[pbcsd]

No.

We know this for a fact

Because they previously DID include the one line of code to detect it-- and then chose to ONLY display a warning- not actually put it in limp mode.

That caused ingenuity to finally remove their outright false claim the module was "undetectable" from their website and advertising.

Tesla was making it clear they can detect it if they wish- and they're currently choosing not to do anything active about it.

But also making clear they could. And trivially.




No, they would not.

First- they already know much of what you just listed thanks to the sensors on the vehicle already (how else do you think the outstanding traction control systems work)?

The seats have weight sensors for example.

Moreover, most of what you list isn't even relevant because most of them are things that can not improve max acceleration- and certainly not remotely to the amount these hacks do.


Tailwinds?

You think there's a tail wind that would magically make a LR-AWD accelerate like a P?

On what planet- because it's not this one.

Surface friction for another example... there is no surface friction that would let the car accelerate faster than its max stock acceleration- that's a ridiculous thing to even mention... there's certainly surfaces that'd cause it to accelerate SLOWER, but you're not looking for that anyway.

But by all means let me know what surface I can put an LR AWD car on where it magically, WITHOUT a hack, accelerates like a P.

Come on. We'll wait.

A large auto walk…like at the airports?

 

[base_two]

No.

We know this for a fact

Because they previously DID include the one line of code to detect it-- and then chose to ONLY display a warning- not actually put it in limp mode.

That caused ingenuity to finally remove their outright false claim the module was "undetectable" from their website and advertising.

Tesla was making it clear they can detect it if they wish- and they're currently choosing not to do anything active about it.

But also making clear they could. And trivially.




No, they would not.

First- they already know much of what you just listed thanks to the sensors on the vehicle already (how else do you think the outstanding traction control systems work)?

The seats have weight sensors for example.

Moreover, most of what you list isn't even relevant because most of them are things that can not improve max acceleration- and certainly not remotely to the amount these hacks do.


Tailwinds?

You think there's a tail wind that would magically make a LR-AWD accelerate like a P?

On what planet- because it's not this one.

Surface friction for another example... there is no surface friction that would let the car accelerate faster than its max stock acceleration- that's a ridiculous thing to even mention... there's certainly surfaces that'd cause it to accelerate SLOWER, but you're not looking for that anyway.

But by all means let me know what surface I can put an LR AWD car on where it magically, WITHOUT a hack, accelerates like a P.

Come on. We'll wait.

You've put a lot of effort into reasoning why Tesla could end this hack from working if they wanted to, but it's been over two years with mostly no functional issues. I'd imagine the number of users who even have this module installed is an incredibly small number of Model 3/Y owners that it wouldn't even be worth the litigation and/or back and forth Tesla would have to engage in with the modding community to block it. Arguing what Tesla could do remotely if they disapprove with how you are modifying your own car is not the most savory position to defend.

 

[Knightshade]

You've put a lot of effort into reasoning why Tesla could end this hack from working if they wanted to, but it's been over two years with mostly no functional issues

It's actually very little reasoning needed- we know what the sensors can tell Tesla, and from there it's incredibly simple to recognize they can detect the module any time they want- and to impact car functionality if they wished to.

The fact they have chosen NOT to impact it (even while they DID choose to tell owners of the module they know it's there doesn't change that.

. Arguing what Tesla could do remotely if they disapprove with how you are modifying your own car is not the most savory position to defend.

What's unsavory about pointing out facts?

I even mentioned there might be legal implications to them actually disabling the vehicle to point out a reason they might not act further- but I was simply correcting the folks who mistakenly think there's any technical reason they can't do it or that it would require any real effort on their part technically to do it either. It'd dead, literally one line of code, simple using data they already have.

That said- I've 0 doubt they DO note the detection on the back end, and would bring it up if it was ever relevant to a warranty claim.

As I've also mentioned I think the confluence of people for whom ALL of these are true:
Have one of the modules
Have a failure Tesla could possibly blame it for
AND are still under full warranty

Is vanishingly small, so it wouldn't surprise me at all if nobody has experienced all 3 things at once yet.

But there's a reason even Ingenext was forced to withdraw their original, false, marketing claims that the modules were undetectable. They're easily detectable.

What happens from there is a different topic.

 

[Darmie]

Anyone using Lap Mode? Last time I was doing an SCCA event, I didn't find the vehicle responding to any of the slider inputs. It just kept driving normal.

 

[itch808]

No.

We know this for a fact

Because they previously DID include the one line of code to detect it-- and then chose to ONLY display a warning- not actually put it in limp mode.

That caused ingenuity to finally remove their outright false claim the module was "undetectable" from their website and advertising.

Tesla was making it clear they can detect it if they wish- and they're currently choosing not to do anything active about it.

But also making clear they could. And trivially.




No, they would not.

First- they already know much of what you just listed thanks to the sensors on the vehicle already (how else do you think the outstanding traction control systems work)?

The seats have weight sensors for example.

Moreover, most of what you list isn't even relevant because most of them are things that can not improve max acceleration- and certainly not remotely to the amount these hacks do.


Tailwinds?

You think there's a tail wind that would magically make a LR-AWD accelerate like a P?

On what planet- because it's not this one.

Surface friction for another example... there is no surface friction that would let the car accelerate faster than its max stock acceleration- that's a ridiculous thing to even mention... there's certainly surfaces that'd cause it to accelerate SLOWER, but you're not looking for that anyway.

But by all means let me know what surface I can put an LR AWD car on where it magically, WITHOUT a hack, accelerates like a P.

Come on. We'll wait.

You're ASSuming I'm talking about a LR to P performance. I'm talking about SR+. It's only about 0.5s difference to 60mph. I guarantee you that's a margin of difference accountable with those factors either optimized or not.

 

[Knightshade]

You're ASSuming I'm talking about a LR to P performance.

No, I'm not. Same thing applies in all cases.

I'm talking about SR+. It's only about 0.5s difference to 60mph. I guarantee you that's a margin of difference accountable with those factors either optimized or not.

Prove it.

I specifically debunked a number of your suggested causes.

But if you think otherwise please cite, as examples of your claims-

What mph of tailwind will improve your 0-60 by 0.5 seconds compared to stock best in an SR Tesla?

What surface compared to the standard race track such times are normally measured, will improve your 0-60 by 0.5 seconds compared to stock best in an SR Tesla?

What tire compound, compared to the stock tires, will improve your 0-60 by 0.5 seconds compared to stock best in an SR Tesla?

What % gradients of incline/decline, compared to level, will improve your 0-60 by 0.5 seconds compared to stock best in an SR Tesla?

What % SoC will reduce your 0-60 by 0.5 seconds will improve your 0-60 by 0.5 seconds compared to stock best in an SR Tesla?

Spoiler: None of them.

Your argument is nonsensical and you can't provide any facts to support it. Or even physics to do so. Because they don't exist.


Pro tip: when you find you are in a hole- stop digging

 

[Mash]

Nobody is going to be measuring any acceleration to detect it. They have enough sensors to see that battery current is above specs. No environment changes would influence that.

 

[Destiny1701]

They honestly don’t give a sh-t. They’ve already changed the 980 motors to 990 in 2020 to prevent any further use if the ghost module. For the number of owners who actually use ingenext, it’s not worth their time.
I’m sure for every one, there are 10 buyers who bought FSD and donated tens of thousands to an absolute BS function.

Tesla focuses on revenue generation.