TurboSlipNot

My car is finally off of a locked-out cyvecs and on a proper motec setup running the 12inj flex-fueled 4L. Its night and day in terms of both normal driving and getting into the boost/RPMs but given the whole "ZF locked even Porsche out of the transmission" thing, the interaction between ECU and TCM is still a bit of an approximation which produces unpleasant traction control pushback under some conditions or outright spark cut when it should just give me a bit of rotation around the middle. PSM is far more than TC and i'm not sure how the interactions with all of those parts play out and i'm wondering if anyone is.
I've started outreach to the various commercial entities in this space, but with a background in infosec going back to the 90s i can be a bit more proactive than the average person waiting for a proper solution.

The technology being called "AI" in the market is actually just a deeply nested set of reentrant pattern encoders and decoders which "looks" like pattern recognition/awareness when nested and complex enough... techniques which can be used to analyze the IO between a Porsche ECU and ZF TCM to either assist in the actual reverse-engineering of function or just precisely approximate the outputs produced by inputs observed (and as many other conditions recorded from adjacent systems as possible). Since ZF really don't want anyone's pillaging their IP, they decided to encrypt the communications on the bus between the TCM and ECU. Encryption however requires either storing or deriving key materiel for the session which can either be dumped from endpoint memory or extracted by similar analyses of the initial key exchange/negotiation and internal state of each side.

I'm not quite at the point of being able to procure a test mule for something like this, so wondering if anyone else is working the problem set and might have IO intermediation/intercept capability to capture the traffic between TCM and a factory ECU (putting a factory one in my car isn't feasible at this level) or made headway on the decryption of the datapath/understanding the protocols involved "out in the open" (vs behind commercially-closed doors which preclude collaboration). It might be feasible to actually extract and decompile the TCM firmware but that seems like an ethical boundary i'd rather not cross - however we do have a right to repair our own vehicles as we see fit, so at least having the ability to communicate with ZFs TCM seems like a prerequisite for building fully informed maps to take advantage of all of the car's capabilities when replacing factory parts with (improved) aftermarket ones.

worf928

I wish.

B Russ

Holey Fuch, What did he just say

arkadyzv

I have no idea what you're actually trying to accomplish... but I can safely say no one in the 991 world thats not a legit shop nor tuner is trying to unlock the ZF software privately if thats what you're hinting at. The only Motec players in the 991 world that have any results that would lead me to believe they know what they are doing are Wayne Potts, Cicio and Fasil from Xperformance , I dont see any of them sharing their secret sauce just because.


Why?

TurboSlipNot

Not sharing of secret sauces is one thing - base interface semantics and peer unit logic is another. Without those common curves and comms protocols, all IO between components and aftermarket ones ends up being an approximation of the correct "language and grammar" between them (Zapf Brannagan style). Its the original GPL license argument of making systems software available to all for standardized use and common improvement while application software is sold for profit. Builders who perform full builds from a strengthened block on up have their own specific nuances for things like managing case pressure, blow-by, ethanol condensate, and more commonly for non megacar stuff the optimal timing/gapping/compression/fuel atomization/combustion temps/clearances/top ends/porting/so on; all of which play into the way they map AFRs and a thousand other parameters to optimize for those factors... I don't think youd have much luck running an ESMotors map on a motor built by someone else entirely since they optimize for VE in physical components and dimensions differently.

Most practicing hackers aren't buying these yet and ones who do are often burnt the hell out too much to dig into the guts especially given that the factory car is way too fast already for anyone with a shred of sanity left. That said, I can't be the only one here so I'm hoping some curious minds with electrical and digital skills roger up. My outfit has our own analysis and modeling capacity, but we lack the raw data between modules to parse out and assess

​​​​​

akrapovic

that’s engineer for i’m smarter than you😂😂😂

CodyzWorld

interesting. Ihave slight comprehension but wow..........

B Russ

I was a hacker in 1999 but this Not sure what they hope to accomplish, thats what Im really trying to understand

worf928

@TurboSlipNot wants to reverse-engineer the control algorithms between the engine and PDK by doing black-box analysis where “black-box” means that the functionality can only be inferred by presenting inputs in various combinations and observing system behavior. To do this, first the communication protocol must be determined, then encryption (if any) must be broken, and then, only, can the real work be done.

This involves - to start - putting a protocol analyzer (Or IOWs, a digital oscilloscope with data/signal storage capability) in between the PDK and engine to capture data on the bus (AFAIK, FlexRay, now an ISO bus standard) which is then subsequently analyzed.

It’s a tall order, but I proffer best wishes and luck.

The 928 community has accomplished similar goals, but we can pull EPROMs, read them out, decompile “by hand” and figure out what’s what. It’s about 1000 times more complicated to do that with modern stuff that’s also encrypted on-chip. Luckily tools have also progressed so maybe it’s only 10 or 50 times as hard.

worf928

Now that I think about it, the easiest way to do this would be to run a Lolita Conn on a Porsche Motorsports software engineer, get credentials, hack the system and exfiltrate the source and encryption keys.

I hope TurboSlipNot looks good in a little black dress…

TurboSlipNot

Fields of engineering have progressed into full-fledged rabbit holes - pretty much every SME sounds like that in their domain . Decent chance most people who've made it to the point of owning these cars know quite a bit about their field i dont.

Exactly, thanks for the disambiguation; and while the on-chip approach is far easier there's an ethical concern involved in my field since that would actually involve coming into contact what is proprietary "special sauce" which we would have to carefully separate from the IO stack. The more gray area involved in how we get the final outcome the harder it will be to build on that foundation. We're friendly with the firmware security companies and have one of their former RE engineers on our team which is part of the "capabilities puzzle" to getting this sort of work done.

That said, we do need to figure out how to get detailed contextual logging from a more or less factory car and i'm wondering if the piggyback users/vendors around here might have any insight into that part of the game.

Porsche engineers do not have the credentials per se - there are individually negotiated encryption keys setup during the pairing of the transmission and ECU. Motec and Cyvecs have to have already solved for that just to be able to commune with these things but the specifics of that communication are approximations of function likely done by old-school oscilloscope analysis methods as opposed to feeding inhuman amounts of data into a machine learning model (full-bore debug logs of all the systems on board since chassis information has bearing on how PSM handles power delivery) or otherwise deriving the requisite adjustment of outputs from the ECU to the TCM to achieve smoother operation under all the varying operating conditions, allow the TC to understand delivering the result of a thousand lbft multiplied by low gear ratios from a stand-still while turning out into traffic, and so on.

I look good in whatever avoids detection by the adversary, damned good at that, thankyouverymuch.

B Russ

Wow this is bringing me back to my old Eprom days, great brain exercises here

TurboSlipNot

The closed loop nature of systems interop here means static analysis of one systems logic won't give us the whole picture. Dynamic analysis of input dependent outputs (which actuate functions downstream) and feedback between all the components is (hopefully) how we fill in all the blanks.

B Russ

Understanding communication, k

Angryinch

How about just hold that traction control button down for 5 seconds and turn it off?

It was never designed to work with massive power and how fast that wheel spin and shifts will happen. It might not even have the speed to keep up.