Android Smartphone Secret Codes: Revealed
by J. J. Styles
Hello, 2600 readers of the world.
In this article, I will divulge how to retrieve "secret codes" from your very own personal Android smartphone. No longer will you need to look up up secret codes or, even worse, beg others to provide them for you.
Most people are already somewhat familiar with so-called secret codes.
The code *ADD or *233 is well known for adding minutes to an account.
The code *#06# is also well known for presenting various identification numbers, or strings, pertaining to a unique personal smartphone.
I believe this information should appeal to a wide audience of 2600 readers because it involves a little bit of computer hacking, reverse engineering, and a bit of telephone phreaking. The difficulty level is low in my opinion, meaning that most anyone with a personal computer and an Android smartphone should be able to do everything discussed within this article. I discovered this technique all on my own one day when attempting to unlock my phone in order to switch to another provider.
I noticed that it was difficult to obtain this information for lesser known models of smartphones and decided to just poke around the phone using my computer programmer and system administrator skills. Hopefully this information is not too widely known already.
In order to do this, we will need:
- Android Debug Bridge (ADB) drivers.
- dex2jar
- JD-GUI
- Linux system tools: grep and/or strings.
First, install ADB drivers.
There are various ways to do this. Drivers exist for Windows, Mac, and Linux. I will discuss doing this on Windows for simplicity. It should be easy enough to figure this information out by searching/Googling for "adb drivers download install". Most people reference this article: www.xda-developers.com/install-adb-windows-macos-linux
In order to utilize these drivers, "Developer" mode must be enabled on the smartphone. This is done by going into the "Settings" menu/app of the Android smartphone, then the "System" and/or "About" settings page, and pressing/clicking/spamming the "Build number" option/button until it begins a "Developer mode" countdown.
Once this procedure has been completed, a new option called "Developer options" will be available.
In "Developer options," we will need to switch them "On' and also enable "USB debugging" and exit back to the main menu of the smartphone.
Now we should be able to begin our journey into ADB interfacing. When a new computer system is used/connected via USB to an Android smartphone, authorizations must be made. All this requires is checking a checkbox on the phone and accepting the authorization/connection.
Hopefully I have provided enough information about this "Developer mode" "ADB" procedure.
Please excuse my brevity/ briefness, but my goal is not to fill 2600 pages with rudimentary, easy-to-obtain information.
Oh, also, the necessary phone drivers must be installed on the computer system as well, in order for the phone to be recognized as a device. Typically, this can be automatically handled by the operating system "plug and play" but if not, please consult your phone manufacturer. I know, for example, that Samsung smartphones often require drivers to be obtained/downloaded.
If you are already able to transfer Photos/Music/Movies/Files/etc. between your smartphone and PC, then it is safe to say the drivers are already installed/loaded.
When a smartphone is connected via USB in Media Transfer Protocol (MTP) mode, you may have noticed that there is a simple file system that appears, containing folders such as "Android," "data," "DCIM," "Music," etc.
What you may not know is that there is a UNIX/Linux file system that is not usually revealed.
If you have "rooted" your smartphone before and used a file manager such as "ES File Manager," you may have noticed the Linux file system, common directories, like /bin, /dev, /etc, and /root.
The directory we will focus on is the /system/priv-app one. This directory contains apps/programs/APKs that come preinstalled with your smartphone.
One of these programs is going to be the Dialer app that we use to make phone calls. Sometimes this app is called "Dialer," "GoogleDialerGo," or "LGTeleService." We will find out by grep'ingg.
Now it's time for the juicy stuff.
When we installed the ADB drivers, an application called adb should have been installed to a directory called platform-tools on the PC.
When we open a DOS/UNIX/Terminal command prompt and navigate to that directory, we can type in commands such as adb devices which will display the connected devices.
If nothing is listed, the drivers are not correctly installed and you will need to retrace your steps to complete the process in order to proceed with this article.
Once we have determined the smartphone device is connected and registered, we can use the adb shell command to open an actual UNIX shell terminal on the device.
This is similar to running the Google Play store apps "Termux" or "Terminal Emulator."
If the whole ADB procedure is too much for you, you can attempt to extract secret codes just by using the aforementioned apps, but in order to truly reverse engineer the Dialer app, we will need to transfer files utilizing the adb pull command.
With that said, after issuing the adb shell command, we should have a "shell" user (UID 2000) access level command prompt in the root (/) directory.
Depending on the file system permissions, we may be able to issue the ls command to take a peek at what is available. This is irrelevant, because I want you to type: cd /system/priv-app/ and press the Enter key.
You can type: ls -la to list all files/folders in long format and see a bunch of directories.
While in the /system/priv-app directory, we can type:
and find out which binary contains the secret codes.
You will get back a message like "Binary file Dialer/Dialer.apk matches."
From here you could type:
and get some secret codes spit back at you.
grep "##" would spit some other codes back.
At this point, you could consider yourself done, poke these codes into your dialer app, and figure out what each one does. But this is not the 2600 way. We hopefully want true and total understanding of how these codes operate. For that, we will need to reverse engineer some Java code.
The binary APK file obviously contains secret codes, but reversing the APK is not so straightforward. No. But! We can get the actual Java source code from the DEX/ODEX/VDEX files associated with that APK.
Continue to look around the particular Dialer directory for your smartphone; you may find a directory called oat and/or arm, or the DEX files may be contained in the root of the Dialer directory itself.
We can grep those files as well for *#06#, and determine that they too obviously contain secret codes. I use the *#06# code as an example, because it seems to be a universal secret code that exists on all smartphones (to my knowledge). We can type in pwd (Enter) to get the present working directory, ls to get the filename, and put them together to get something like: /system/priv-app/Dialer/oat/arm/Dialer.dex
We must make note of the pertinent file locations because now we will be copying them to our local PC for reverse engineering purposes.
Type exit to exit the shell.
We should be back at our local system prompt in the platform-tools directory.
If we type, for example:
that should copy the file Dialer.dex from the smartphone to our current working directory.
You could replace the . part of the command with whatever directory you wish to store the file.
Once we have copied over all the files that contain secret codes, we can begin reversing them. I found instructions for this technique on: onlytrikss.blogspot.com/2012/12/how-to-get-source-code-from-apk-file.html
We obtain a program called dex2jar: github.com/pxb1988/dex2jar
We run: d2j-dex2jar.bat Dialer.dex
This will create a file called: Dialer-dex2jar.jar
If we only had access to an ODEX file, an extra step is required.
We will also need SmaliEx: github.com/testwhat/SmaliEx
And we will need to create a DEX file by running: java -jar oat2dex.jar Dialer.odex boot.oat
Then we will have a legit DEX file to run dex2jar on as previously stated.
Then we obtain Java Decompiler: github.com/java-decompiler/jd-gui
When we load Dialer-dex2jar.jar in Java Decompiler, guess what we get? The entire source code for the Dialer! Including all the methods/functions for the available secret codes.
We are done.
This method should basically work on every Android phone ever made, and you will never need to beg for a secret code again. Hooray! You may find codes like ##DEBUG# (or ##33284# rather) and many other phun thingz.
Of course, this article would not be complete if I did not explain how to obtain the MSL/SPC for your smartphone (Master Subsidy Lock/Service Programming Code).
Sometimes secret codes will only be available for use after the MSL/SPC has been entered. This code can sometimes be obtained from the cell service provider, but the point of this article is doing it ourselves, not begging for "CoDeZ."
There's a great little script known to the world as "GETMSL.BAT."
Basically, what is does is grep for keywords that pertain to the MSL/SPC.
What does it grep exactly? It looks for the logcat command. logcat is one of the built-in busybox/funbox/Linux system commands on Android systems.
So if we run: adb shell and then run logcat it runs a continuous system log of Android events.
When an invalid MSL/SPC gets entered, a log entry gets made that basically says "The code entered does not match XXXXXX" where XXXXXX is the actual MSL/SPC. Brilliant security design, right? Not! Anyway, here is the code most people use:
While that code runs on your PC, enter a secret code that prompts you for the MSL/SPC, enter a bad code: 000000, 123456, etc.
The script should now have the six-digit code, allowing you to get into the menu that you desire.
I hope that you have enjoyed this article.
Good luck, or rather, godspeed in your H/P/V/A/C adventures!
Code: GETMSL.BAT