Daniel sent us something that starts with a confession. He was building a call-forwarding tutorial using carrier-level codes, and it actually worked — which surprised him, because who dials star-pound-anything anymore? That led him down a rabbit hole. Here's what he wrote.
"I want to explore the world of numeric codes you can enter directly into a phone's dialer. I was using these yesterday to create a carrier-level call forwarding tutorial, and it worked remarkably well. That made me realize there's an entire ecosystem of these codes that most people never encounter. Use this as a starting point to explain the different categories. Cover the GSM supplementary service codes — the MMI codes — used to configure network features like enabling, disabling, and querying call forwarding, call waiting, caller ID, and call barring. Then contrast those with USSD codes, which are for interactive services provided by the carrier, and with the manufacturer-specific engineering and diagnostic codes that expose testing menus and hardware information. Explain how these different systems work, why they all look superficially similar despite serving different purposes, how much is standardized versus carrier or manufacturer specific, and how commands entered into the phone are interpreted by the handset and the mobile network. Finish by discussing why these capabilities remain so obscure despite being built into virtually every mobile phone."
There's a lot in there. Four distinct questions stacked inside each other.
And the call-forwarding anecdote is the perfect entry point, because it forces you to realize something most people never think about. The dialer on your phone is not just a number pad. It's a command-line interface. You've got three completely different protocol stacks listening to the same twelve keys, and they all use star and pound as delimiters. That's why everything looks like star-something-pound — but what actually happens when you hit send depends on which interpreter grabs the string first.
Three interpreters, one keypad. That's the taxonomy we should lay out right at the top.
Right. System one is MMI slash SS codes — Man-Machine Interface for Supplementary Services. These configure network features. Call forwarding, call waiting, caller ID presentation, call barring. System two is USSD — Unstructured Supplementary Service Data. That's the interactive pipe carriers use for things like balance checks, top-ups, roaming menus. System three is engineering codes. These never leave the phone. They're intercepted by the firmware and open diagnostic menus, show hardware info, run tests. Three different systems, three different destinations, one dialer.
And Daniel's core puzzle is: why do they all look like star-pound-gibberish when they do completely different things?
Because they all inherited the same design constraints from GSM in the early nineties. The star and pound keys were available — they weren't used for dialing numbers — and they needed a way to signal "this is a command, not a phone number." So star became the opening bracket and pound became the closing bracket across all three systems. But the similarity is purely cosmetic. The interpretation pipeline is completely different for each one.
It's like three different languages that all happen to use angle brackets as quotation marks. You see the brackets and think you know what you're looking at, but the grammar underneath is totally different.
And the confusion is compounded because the same twelve-key pad is the input device for all three. Imagine if your computer keyboard had only twelve keys, and three different operating systems had to share them. You'd end up with overloaded syntax too.
So let's crack open the first system — the one Daniel was actually using for his call-forwarding tutorial. MMI codes. What happens when I type star-two-one-star and then a phone number and then pound?
You've just configured unconditional call forwarding. And the way it works is elegant. Your phone does not send those raw digits to the network. The handset's firmware recognizes the pattern — star, two-digit service code, star, parameter, pound — parses it locally, and then sends a structured Supplementary Service message over the control channel to the network's Home Location Register or Visitor Location Register. The network never sees the star and pound characters at all.
So the phone is translating before it even transmits. It's like a compiler. You write in the high-level MMI syntax, and the phone compiles it down to a binary network message.
The MMI string is a local user interface convention. The actual protocol message is a binary SS request that says — in effect — "set call forwarding unconditional to this number." The standardization for this is rock solid. It's defined in three GPP technical specifications twenty-two point zero zero four and twenty-two point zero three zero. The service codes are universal. Twenty-one is call forwarding unconditional. Sixty-one is call forwarding no reply. Sixty-two is call forwarding not reachable. Sixty-seven is call forwarding busy. And the syntax pattern is consistent across all of them.
Walk me through the pattern.
Three operations. Star-code-star-parameter-pound enables the feature. Pound-code-pound disables it. Star-pound-code-pound queries the current setting. So for call forwarding unconditional, star-two-one-star, then the destination number, then pound — that sets it. Pound-two-one-pound cancels it. Star-pound-two-one-pound asks the network "what's my current forwarding number?"
And Daniel's tutorial was built on exactly this. He was telling people star-two-one-star-some-number-pound to forward calls, pound-two-one-pound to cancel.
Which works on virtually every GSM-derived network on the planet. It doesn't matter if you're on a four-G or five-G phone — the underlying SS protocol hasn't changed since the nineties. The phone still speaks MAP, the Mobile Application Part protocol, to the core network. That's the thing people don't realize. Your five-G smartphone is running a thirty-year-old signaling protocol to handle call forwarding.
Because replacing it would mean replacing every switch in every carrier's infrastructure.
And there's no business case for that. It works. Billions of phones use it every day without anyone noticing. The network doesn't care that your phone has a teraflop processor — when it comes to call forwarding, it's still a GSM phone from nineteen ninety-two. Think about that. Your phone can render real-time ray-traced graphics, but when you tell it to forward calls, it drops into a protocol designed when the cutting-edge handset was a Nokia brick with a monochrome screen.
There's something almost beautiful about that. This ancient digital dialect, still spoken perfectly by the newest hardware. It's like finding out that modern fighter jets still use some hydraulic system designed in the 1940s because it just works.
Infrastructure is full of these living fossils. And they persist precisely because they're boring. Nobody gets promoted for redesigning the call-forwarding signaling protocol. Nobody wins a product launch keynote by announcing "we've reinvented how your phone tells the network to send calls somewhere else." So MAP just keeps running, quietly, perfectly, decade after decade.
So that's MMI. The network feature configuration system. Standardized, structured, translated by the handset before transmission. Now what about USSD? Because that's the one people are more likely to have used without knowing it.
USSD is a completely different animal. The spec is GSM zero two point ninety, and it defines USSD as a session-based interactive transport. The key word there is session-based. An MMI command is fire-and-forget — you send the request, the network responds, the transaction ends. USSD opens a session. The phone sends a string like star-one-zero-zero-pound, the carrier's USSD gateway receives it, runs whatever service is mapped to that code, and returns a response — which might be a text menu, a balance display, a prompt for more input. You can have a back-and-forth conversation with the carrier's server without ever leaving the dialer.
So it's like a text-based terminal session over the control channel.
That's exactly what it is. And unlike MMI, the phone does not parse the USSD string locally. It sends the raw characters to the network. The carrier's USSD gateway interprets them. The phone is just a dumb terminal.
Which means the same star-one-zero-zero-pound might do completely different things on different carriers.
On one network it's a balance check. On another it's a data plan menu. On a third it does nothing at all. USSD is standardized as a transport layer, but the services riding on top are one hundred percent carrier-defined. There is no global registry of USSD codes. Each carrier builds their own menu tree.
So if I switch carriers and try my old balance-check code, I might get nothing — or worse, I might land in some completely unrelated service menu and not know what I'm looking at.
Or you might accidentally trigger something you didn't intend. Imagine dialing what you think is a balance inquiry and instead you've just opted into a premium service because that carrier mapped that code to something else entirely. It's unlikely but it's not impossible, because there's no central authority preventing code collisions across carriers.
And this is where the similarity to MMI codes becomes actively misleading. They look identical. Star-something-something-pound. But one is a standardized network feature command parsed by your phone, and the other is a proprietary carrier service string passed through to a server somewhere.
And the third category — engineering codes — is different again. These never leave the phone at all.
Star-pound-zero-six-pound. Everyone's done that one at least once.
The IMEI display. And it's the perfect example of an engineering code because it demonstrates the key property: the phone's firmware intercepts the string before the radio even wakes up. The dialer app sees star-pound-zero-six-pound and says "I know what this is" and displays the International Mobile Equipment Identity number directly on screen. No network transaction. No data sent. The code is handled entirely in the baseband processor or the application processor, depending on the phone architecture.
So if I put my phone in airplane mode, star-pound-zero-six-pound still works.
Try it. It absolutely does. Because it never needed the network in the first place. The IMEI is burned into the device hardware. The code just tells the firmware to read it back to you.
And Android has a much deeper engineering menu hidden behind a different code.
Star-pound-star-pound-four-six-three-six-pound-star-pound-star. That opens the testing menu on many Android phones — but not all. It shows you network information, signal strength in decibel-milliwatts, battery stats, usage statistics, Wi-Fi details. It's a diagnostic dashboard that most users never see.
I've used that menu to check what band my phone is camping on. It's genuinely useful, and it's absurd that it's hidden behind an arcane string of symbols.
And here's where the fragmentation gets wild. That four-six-three-six code works on stock Android and many devices, but Samsung has their own engineering menu with a different code. Some manufacturers disable it entirely. Others require you to enable developer options first. There is zero cross-brand standardization for engineering codes because they were never part of any spec. Each manufacturer just picked a code pattern and hard-coded it into their firmware.
It's like every car manufacturer hiding the diagnostic port in a different place under the dashboard, and some of them requiring you to turn the key three times while holding the brake pedal to access it.
That's not even an analogy. That's literally how some car diagnostic modes work, and it's the same philosophy. These are tools built by engineers for engineers, and they saw no reason to make them discoverable or consistent for end users. The IMEI code is the one exception — that one got standardized almost by accident, because regulators needed a universal way for users to find their device identifier.
So we've got three systems. MMI is heavily standardized by three GPP, with universal service codes and syntax. USSD is standardized as a transport but the services are proprietary per carrier. Engineering codes are the wild west — entirely manufacturer-specific, no standards body, no consistency.
They all use star and pound as delimiters because they were designed in the same era by engineers facing the same constraint: how do you signal "this is a command" using only the existing telephone keypad? The answer was obvious. Use the two non-numeric keys as brackets. It's the same reason command-line flags use dashes. You pick characters that don't conflict with the primary input.
The visual similarity creates a false sense that these are all the same kind of thing. And that's probably why most people find them confusing.
It gets worse when you look at the interpretation pipeline end to end. Trace a single dial from the keypad to wherever it ends up. The phone's firmware is the first gatekeeper. It checks: is this an engineering code I recognize? If yes, handle it locally and stop. If no, is this an MMI string — does it match the pattern for a supplementary service command? If yes, parse it, build an SS message, send it over the control channel to the network's HLR. If no, does it start with star and end with pound? Then it might be USSD — send the raw string to the carrier's USSD gateway and see what comes back. If none of the above, treat it as a phone number and attempt to place a call.
Three interceptors standing in a row, each checking the string against its own pattern library. And the user just sees "I dialed something and something happened."
Or didn't happen. Which is the other source of confusion. A code that works on one carrier might silently fail on another because the USSD service doesn't exist there. An MMI code might be blocked by the carrier even though the standard says it should work. An engineering code might have been removed by the OEM in a firmware update. There's no error message for most of these failures. You just get nothing.
And "nothing" is a terrible error message because it leaves you guessing. Did I type it wrong? Is my carrier blocking this? Does this phone not support it? You have no way to know.
The phone could tell you. It knows which interpreter grabbed the string and what happened. But the design philosophy across all three systems was never "inform the user." It was "execute the command." User feedback was an afterthought.
Or worse. You get something you didn't expect. The USSD attack vector.
This is the security nightmare. USSD codes can be triggered from a web page. A malicious site can embed a tel link or an iframe that attempts to dial a USSD code. On some older Android versions, certain Samsung phones, the phone would actually execute the code without user confirmation. There was a famous demonstration where a web page could trigger a factory reset by auto-dialing a Samsung engineering code. The phone would wipe itself just from visiting a URL.
That's terrifying. And it exposes a fundamental tension. These codes are powerful — they can reconfigure network settings, expose diagnostic data, even wipe the device — but they were designed in an era when the only way to dial them was to physically type them on a keypad. Nobody anticipated that a web browser would be able to inject keystrokes into the dialer.
The attack surface is the tel URI scheme. A web page can include a link like tel colon star-percent-two-three-percent-two-three-something-pound, and if the phone's dialer app doesn't show a confirmation dialog before executing, you've got remote code execution — well, remote command execution — via the dialer. Carriers and manufacturers have patched most of the egregious cases, but the fundamental design tension remains. These codes were built for a trusted local input model, and smartphones broke that assumption.
It's the same class of problem as SQL injection. You've got a system that interprets strings as commands, and you've accidentally connected it to an input source that shouldn't be trusted.
Exactly the same shape. Untrusted input reaches a command interpreter. And the fix is the same too — sanitize the input, add a confirmation step, never auto-execute. But that fix had to be retrofitted onto a system that was designed before the web existed as a threat vector.
Which brings us to Daniel's final question. Why do these capabilities remain obscure? Given that they're built into every phone, given that they're useful, why doesn't the average user know about them?
Several reasons, and they compound each other. First: no marketing incentive. Carriers don't advertise USSD codes because they'd rather you use their app, where they can track you, show you ads, and upsell you on services. A USSD balance check gives you the number and nothing else. An app gives you the number plus three offers for data add-ons.
The app is a revenue surface. The dialer code is not.
Second: fear of user error. Carriers and manufacturers are terrified of customers bricking their phones or disabling essential services by poking around in engineering menus. The safest thing to do is bury the codes and hope most people never find them.
The tech support cost of "I dialed something and now my calls don't come through" is real.
It scales. If one in a thousand users who discovers engineering codes causes a support call, and suddenly a million people discover them because some TikTok goes viral — that's a thousand support calls the carrier didn't budget for. The economics of obscurity are very straightforward.
Third reason?
Third: the rise of graphical interfaces. In the pre-smartphone era, USSD menus were the only interactive data service available on basic phones. You dialed star-one-zero-zero-pound to check your balance because there was no app, no web portal, no other way to get that information. Smartphones made USSD menus feel archaic. Why navigate a text menu with numeric responses when you can tap a button in an app?
Because it runs over the control channel, not over IP data. The control channel is always active as long as you have a signal. It's the same channel that handles call setup and SMS. USSD messages are tiny — a hundred eighty-two characters max per message — and they don't require a data connection. You can check your balance with zero bars of LTE showing, as long as you have a voice signal.
That's the hidden power layer you mentioned. These codes work at a level below the smartphone experience. They're not dependent on your data plan, your app updates, your operating system version. They're part of the network fabric.
That's why they've survived. Every generation of mobile technology — two-G, three-G, four-G, five-G — has maintained backward compatibility with the core SS and USSD protocols. Not because anyone loves them, but because replacing them would break too many things. Emergency services, roaming, carrier provisioning, prepaid top-ups in developing markets — all of these depend on USSD and SS infrastructure.
In a lot of the world, USSD is still the primary interface for mobile banking and payments.
M-Pesa in Kenya runs on USSD. Hundreds of billions of dollars move through star-something-pound codes every year. It's not obscure in those markets. It's the dominant financial interface. The obscurity is a wealthy-market phenomenon — we moved to apps while much of the world stayed on USSD because it works on any phone, smart or not.
The obscurity is cultural, not technical. These codes are hidden in plain sight because our particular ecosystem decided they weren't worth surfacing.
Because the people who understand them — network engineers, carrier operations staff, handset firmware developers — have no incentive to write user-friendly documentation. The knowledge exists in three GPP specs and OEM service manuals, not in consumer-facing help pages. If you want to know what star-pound-star-pound-four-six-three-six does, you're not going to find it in the iPhone user guide. You're going to find it on an XDA Developers forum thread from 2014, posted by someone with a username like "androidhacker42."
Even that thread is probably half dead links and arguments about whether it works on the Verizon variant.
Of course. That's the nature of unofficial documentation. It's scattered, it rots, and it's never comprehensive. Meanwhile the official documentation doesn't exist in any consumer-accessible form because the people who wrote it never imagined a consumer would want to read it.
Given all that, how do you actually use this without breaking something?
Practical cheat sheet. If a code configures a network feature — call forwarding, call waiting, caller ID, call barring — it's MMI, and the syntax is standardized. You can look up the service codes in the three GPP specs, but the common ones are twenty-one for forwarding, forty-three for call waiting, thirty-one for outgoing caller ID, thirty-three for call barring. The pattern is always the same: star to enable, pound to disable, star-pound to query.
Daniel's call-forwarding tutorial is the perfect safe starting point because you can always cancel it with pound-two-one-pound.
If a code opens an interactive menu — you dial it and get a text response asking you to reply with a number — it's USSD. These are carrier-specific. Star-one-zero-zero-pound is common for balance checks, but verify with your carrier's documentation. If a code displays hardware information or opens a testing screen, it's an engineering code. Star-pound-zero-six-pound for IMEI is universal. Beyond that, proceed with caution.
The caution is not performative. Don't dial codes you find on random forums.
Absolutely not. And be aware of the USSD auto-dial attack vector. If a website suddenly opens your dialer with a code pre-filled, do not press send. Close it. Modern phones are better about showing confirmation dialogs, but the safest rule is: never dial a code from an untrusted source, and never let a web page dial one for you.
The engineering menu is worth exploring if you know what you're doing. On many Android phones, star-pound-star-pound-four-six-three-six-pound-star-pound-star opens a testing dashboard that shows you real signal strength in dBm, which is far more useful than the bar display. It shows you what band you're on, what tower you're connected to, detailed battery stats. It's useful diagnostic information that the phone is collecting constantly but hiding from you.
That's the shame of it. These capabilities exist. They're built in. They work. But the industry decided, somewhere along the way, that users shouldn't know about them. The dialer became a dumb number pad when it used to be a power tool.
The command line got paved over with a GUI and nobody told us what we lost.
Which leaves us with an open question. As carriers move fully to VoLTE and five-G standalone — networks that are IP-native, that don't have circuit-switched fallback — what happens to these legacy codes? The SS protocol has been adapted to run over IP in IMS, the IP Multimedia Subsystem. USSD has been carried forward in the five-G core. But the trend is toward API-based provisioning, toward carrier apps, toward graphical interfaces for everything.
The codes might survive technically but become even more hidden — supported by the network but never surfaced to users, buried in firmware that no longer responds to star-pound-anything from the dialer.
Or they might persist for decades simply because the cost of removing them exceeds the cost of ignoring them. That's the story of most infrastructure. The thing that nobody designed, that nobody loves, that nobody documents — it outlasts everything else because it's too expensive to kill.
The cockroach protocol. Survives the apocalypse because nobody cares enough to exterminate it.
Every so often someone like Daniel rediscovers it and thinks, wait, this actually works. And it does. It's been working the whole time.
Our producer Hilbert Flumingtop keeps this whole operation running, and we're grateful as always.
This has been My Weird Prompts. If you want to dig deeper into how your phone quietly does things you never asked it to do, we've covered a lot of that ground. Check the archives at my weird prompts dot com.
Dial star-pound-zero-six-pound on your phone right now. See your IMEI. Feel briefly like a network engineer. We'll be back soon.
