The ABCs of Global B

At Surreal Development we created Gretio for Global B (successfully) with 0 prior knowledge. The only information you can find about Global B on the internet is conjecture but nothing definitive. We want to change that, and so we are pleased to create the first definitive 100% public documentation on Global B. What it is, why it came to be, and if it is even secure or not.

Global B, or Ultifi, VIP Architecture… Is GM’s newer architecture made to replace the existing Global A system. Since 2023 it is the standard architecture on all GM Vehicles (Cadillac, GMC, Sierra, etc…).

GM’s Troubled Past with Global A Theft

A critical flaw of GM’s global a system was that most of the security was built into the BCM, or Body Control Module. The BCM is what authenticated against your key fob (or transponder in the actual keyed ignition).

If one loses all keys to their truck, then the technician must perform what is called a “90 minute relearn” which will allow new keys to be learned and the vehicle to be driven once again. The 90 minutes was in theory enough time for someone to notice a thief attempting this.

So how is it done in less time? The BCM is the central truth of Global A. It is located on the driver side footwell, so any exploit (or even just outright replacing the BCM) can cause the vehicle to be driven away instantly. While there is a pairing process to the ECM in practice it is not trustworthy and can be bypassed in milliseconds. In fact most global a vehicles can be completely unlocked with a simple 2 or 5 byte seed/key challenge response.

Was GM’s approach bad? Not necessarily. GM was just targeted because large trucks (Silverado and Sierra) in particular are high value. These exploits are nothing compared to Kia. Regardless, GM has become somewhat paranoid and that paranoia is what shaped Global B.

The KGB of Global B

The core of global b is a circle of accountability. Every module does a handshake with the central gateway module (CGM, or SGM, or SDGM). If one fails the entire system fails and the vehicle will not start.

Contrary to what you may read online this system does not rely on encrypted CAN or anything like that. In fact much of global b is neither encrypted nor signed. It just relies on the handshake with the SDGM. When a module is provisioned at the factory, or reprogrammed with SPS against what GM has historically called the “back office” (their various http apis idk why they call it that).

In other words it spans much further than just the BCM. Every significant module does this.

When a module is replaced the GM tech has to perform what GM calls a “Serial Data Authentication Configuration” (SDAC) procedure which in effect provisions the systems using GM’s back office service on an ad hoc manner. Not doing so means a no start and the illusive U1962 DTC.

$27 Access

$27 security access allows a tester to authenticate against the SDGM for privileged actions. Notably this is usually done against the SDGM and not the module directly like it was in Global A.

The tester retrieves a seed from the SDGM (which will change every time its requested). The tester then needs to authenticate against GM’s servers using their own credentials (i.e. SPS2/3). GM then responds with the key and the action can continue (programming or whatnot).

Most ‘cool’ actions (like writing DIDs, programming, etc…) are all blocked by $27. Meaning a random third party tester simply cannot access those features. Notably on Global B even things like key reprogramming are now blocked by $27 against GM’s back office. So if GM goes defunct it will be impossible to learn a simple key fob….. Yeah have fun with that knowledge.

What happens if you doctor the SDGM? Great question, but its probably not going to be easy. Even if you do get into the SDGM every single module is only going to boot off a GM signed file anyway sooo you wouldn’t gain as much access as you think.

So how does Gretio still work without $27?

Honestly I’ve been asking myself that as well. GM is very anti right to repair and all the systems just make my life harder.

I believe GM did not want to share their internal secrets with people such as Autel, SnapOn, Mitchel, etc…. And so they kept enough of their system open without needing to authenticate with the SDGM. So certain functions just dont need to authenticate with GM.

Android

Now let’s talk android. GM took a very untrusted stance on their AAOS integration… Or maybe its just legacy code hell. Android is what is known as a “Guest OS” on Global B. It is simply a VM running within some green hills software thats frankly more similar to the global a radios than global b.

This means if you broke into Android, you can’t escape the container.

And even if you did escape the container, you can’t escape the isolated subnet you are on which is composed of just you, the SDGM, and the telematics (OnStar) module…. So no one is going to be remotely causing a car to crash any time soon. Regardless it’s cool to think about ‘how’ this is all managed especially since its where things like OTA comes from.

First off the headunit is known as the Center Stack Module or CSM. The gateway is called the SDGM or CGM depending where you look (GM can never settle on a single name can they).

Side Loading

Traditional Side Loading

Won’t work, GM disables the underlying permisison in android to allow apps to install things. I’ll talk about this more when we discuss ADB.

On some versions it ‘did’ work which is interesting. So maybe you should decline those OTAs :P.

The Weird Internal Test Track Workaround

Google Play is a trusted installer on this system and if you are an internal tester on the play store you can directly install onto the headunit. It only works in the internal test track (ITT).

This is a longstanding well known workaround, and frankly its confusing why it has lasted this long. Obviously devs need ‘some way’ to test their apps but 99% of users are likely abusing this to install APKs (as is their right).

ADB

You can’t out of box enable ADB on the headunit. You can certainly enable “usb debugging” but it doesn’t quite do everything needed.

The fastest track to truly enabling it is sending this over UDS.

31 01 03 32 DD 42 10 EE
│   │   │  │   │     │ │    └─ EE = ADB value: 01=ENABLE, 00=DISABLE
│   │   │  │   │     │ └──── DATAID = 0x10 (16)
│   │   │  │   │     └─────── COMPID = 0x42 (66)
│   │   │  │   └────────── DD = Domain ID
│   │   └  ┴───────────── RID = 0x0332
│   └────────────────── sub-function = 0x01 startRoutine
└───────────────────── service = 0x31 RoutineControl
But as you guessed it! The SDGM will block you! Even if you send this message past the SDGM over ethernet, the customized adbd is only going to allow keys provisioned by GM soooooooooooooooooooo no adb. Not by any easy method anyway.

GM Auth and OTA

This is the interesting one… How does the headunit auth against GM? (we need this for OTAs).

The auth is composed of 3 (4?) configurable parts (and this relates to the actual enrollment)

  1. The id of the gateway (CGM)

  2. The id of the radio (CSM)

  3. The vehicle’s VIN

  4. Some hard coded obfuscated secrets (clientId, deviceName, oauth2 shared secret, etc…)

 

This (including the secret deobfuscation) can be found in this python code: gm_radio_cert_provision . Do with that as you please.

From this point forward the signed cert is used for all further api communications from the headunit. The car uses this cert to check for OTA ‘campaigns’. While the kickoff is done within the radio, the actual download and OTA update is performed by the telematics module.

 

TLDR

GM’s global B is bullshit. Support your local right to repair organizations.

The only path to ‘owning’ your vehicle is to meticulously open every module and hand reprogram it to only accept your own keys (or provide other work arounds). This is actually the approach HpTuners uses… But it’s expensive.

Posted in Software.

Leave a Reply