MAUI knowledge base (MT6261 edition)
------------------------------------
This is a (not very well-structured) compilation of everything I have learned
about MAUI OS on MT6261D/MT6261M-based feature phones manufactured since
2018. Note that I'm only talking about normal phones, not watchphones with
touchscreens (they may have their own specifics).
This knowledge base is published under CC0 into public domain.
## Basics ##
MAUI on MT6261 is much less functional than on MT6260 and all the previous
MediaTek chipsets (e.g. lacking J2ME and even MRE application support etc)
but still has a lot of secrets. It usually runs on 4MB flash and 4MB RAM,
and usually it's one of the three types of firmware:
1) unencrypted, partially aliced;
2) unencrypted, fully aliced;
3) fully encrypted.
"Aliced" here means that a part of the OS is compressed with the MediaTek's
proprietary (LZMA-based but not quite) ALICE algorithm, and in case of
MT6261 it's usually ALICE_2 format. "Fully aliced" means that even the part
that usually contains secret codes is inside that compressed partition.
All MT626x devices (except Nokia-branded ones) respond to the *#mediatek#
(*#63342835#) secret code. However, since MAUI in (genuine) Nokias is
heavily modified, we won't consider them at all for the rest of this
document.
## A2DP ##
Some Bluetooth-enabled MAUI phones lack A2DP support. To check this without
having to actually test on the Bluetooth headphones, you can run the *#1234#
code to switch between various A2DP modes. If it works, A2DP is supported
here. This test is pretty much universal for all MT62xx devices.
Most MT6261M-based phones, even the ones that do have A2DP support, perform
very poorly with Bluetooth 5.0 headsets. This problem is not solved yet. For
MT6261D, the situation is better, but don't expect all the headset buttons
to work correctly.
## Wallpapers ##
Most MT6261-based phones have 240x320 or 128x160 display resolution and
support setting JPEG, BMP or GIF wallpapers. The OS also supports monochrome
WBMP (.wbm) images but they are usually not used as wallpapers. In case of
JPEG, sometimes the phone may display "Unsupported format" error even after
you have cropped the image to the correct size. In this case, you need to
strip all extra metadata from the .jpg file using, for instance, the convert
command from ImageMagick package:
convert wall-orig.jpg -strip wall-opt.jpg
You can also optimize the quality a bit:
convert wall-orig.jpg -quality 85 -strip wall-opt.jpg
## WWW/WAP browsing ##
Unless Opera Mini is installed (which is almost never the case for MT6261
phones), MAUI offers the most basic WWW/WAP browser possible. It doesn't
have any CSS or scripting support (neither JS nor WMLScript, at least I
wasn't able to get it to work properly even with the correct content types),
has no TLS 1.3 support (1.2 maximum) and only supports these SSL/TLS cipher
combos for HTTPS (looks like the internal notation is based on XySSL, which
then became PolarSSL and now Mbed TLS):
SSL_RSA_DES_168_SHA
SSL_EDH_RSA_AES_256_SHA
SSL_RSA_RC4_128_MD5
SSL_RSA_RC4_128_SHA
SSL_EDH_RSA_DES_168_SHA
SSL_RSA_AES_128_SHA
SSL_RSA_AES_256_SHA
Hence, it works e.g. with
https://mbasic.facebook.com but not with modern
websites. Most servers dropped support for RC4, MD5 and DES, so here are
your options if you want to create a feature-phone-friendly HTTPS webpage
(XySSL identifiers, numeric ids, IANA names):
SSL_EDH_RSA_AES_256_SHA (id 57, 0x39) = TLS_DHE_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_AES_128_SHA (id 47, 0x2F) = TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_AES_256_SHA (id 53, 0x35) = TLS_RSA_WITH_AES_256_CBC_SHA
For OpenSSL, these identifiers translate as:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA = DHE-RSA-AES256-SHA
TLS_RSA_WITH_AES_128_CBC_SHA = AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA = AES256-SHA
In practice though, if only the first of these is enabled, then the MAUI
browser still shows "communication error". So, either
TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_WITH_AES_256_CBC_SHA is mandatory
for HTTPS to work here.
Enabling these algorithms server-side will also make your page viewable on
Mocor-based phones as well, you just need to have a valid certificate. The
MAUI browser, however, silently accepts all self-signed, expired and revoked
certificates and certificates from untrusted roots, so if you are developing
some web app purely for these devices, you might get away with a self-signed
option, as well as putting your application behind a Traefik instance with
proper Let's Encrypt setup.
XHTML Basic 1.1 is the preferred standard of writing the documents. Here are
some HTML tags you can use in MAUI-friendly pages:
html, head, title, body, br, div, p, h1, h2, h3, h4, h5, h6, big, small,
center, b, i, u, a, img, plaintext*, input (only these types: text,
password, button, submit, reset, image, checkbox, radio, hidden), select
(+multiple), option, textarea, form, ul, ol, li, th, td, hr
All unrecognized tags seem to behave like <span>.
* doesn't actually render any newlines in the plain text part, also
recognizes the </plaintext> closing tag as valid contrary to the spec
The MAUI browser also doesn't support any CSS styling or content coloring
(even with dedicated attributes), and you most likely won't encounter
monospace font support on your devices either.
When entering URLs manually, you must enter http:// or https://, otherwise
the browser will start searching your address in Google. Also, unlike Mocor,
MAUI's browser doesn't support any non-HTTP URIs like wtai:, mailto:, sms:,
smsto:, tel: and so on. But it does support HTTP Basic and Digest auth and
downloading images from pages.
The content served with the text/plain type is automatically prompting for
download. Then you can open it with the MAUI's ebook reader (if your phone
supports it). Unfortunately, neither the browser nor the reader support
monospace fonts.
Some vendors hide the browser menu item ("Internet service") from the main
menu for some reasons but forget to remove it from the Shortcuts/Dedicated
Keys configuration. This way, you can still access it on the phone. Another
way is to use .url bookmark files (see below).
## iMelody (.imy) format ##
MAUI supports monophonic iMelody ringtones (see the full specification saved
in the LuxDocs on this server) with some MediaTek-specific extensions. For
MT6261, only 8 distinct instruments are actually used for both MIDI and
iMelody, and you can use the COMPOSER:MTK(number) field to change the
iMelody instrument:
Electric Piano: 1
Cymbals: 11
Organ: 17
Guitar: 25
Strings: 41
Trumpet: 57
Clarinet: 72 (can be 0 for iMelody)
Flute: 120
Both iMelody and MIDI are perfectly looped by the ringtone player.
## MIDI (.mid) format (draft) ##
General limit: 128 MIDI events per the entire file?
Channel 9 is used for percussion system.
Recommended software: Aria Maestosa for primary creation, MidiQuickFix (.jar)
for fine event editing.
All not working but interestring stuff is below:
New info about msgs:
#define MELODY_RTMSG_VIBRATOR_ON 0x80
#define MELODY_RTMSG_VIBRATOR_OFF 0x81
#define MELODY_RTMSG_LED_ON 0x82
#define MELODY_RTMSG_LED_OFF 0x83
#define MELODY_RTMSG_BACKLIGHT_ON 0x84
#define MELODY_RTMSG_BACKLIGHT_OFF 0x85
Supposed Backlight/LED control:
1. Bank select: MSB = 19 (0x13), LSB = 22 (0x16)
2. Patch/Instrument: 125 (Telephone Ring)
3. Control notes: D4 for backlight, G4 for vibration, C5 for LED
4. Supposed valid volume values: unknown yet
D4 and G4 on the control bank lead to MAUI crash on the incoming call, C5
also crashes on the player preview
possible troubleshooting:
- what are valid volume values?
- what if only NOTE_ON events are allowed and not NOTE_OFF?
Supposed vibra control (Nokia-style):
1. Bank select: MSB = 121 (0x79), LSB = 6
2. Patch/Instrument: 125 (Telephone Ring)
3. Pre-event: Reset All Controllers (value 127)
4. Control note: F5
5. Supposed valid volume values: 0, 100, 127
6. Using channel: 15
## Bookmark file (.url) format ##
If the phone supports Web/WAP browsing (even if the vendor says otherwise and
the browser is hidden from the menus), its file manager will be able to open
files with the .url suffix, recognizing them as saved bookmarks. This is a
way to lift the stock bookmark limit (normally up to 10 pages) by just
opening them from the file manager. However, the format of these files is
not the Windows-like "[InternetShortcut]" bookmark format, it's an old
vBookmark format "borrowed" from SonyEricssons (just like iMelody). On
opening the file, MAUI ignores all fields except the "URL" field itself.
Hence, the minimum viable format of MAUI-compatible .url file looks like
this:
BEGIN:VBKM
VERSION:1.0
URL:
http://frogfind.com
END:VBKM
All line endings must be CRLF (\r\n). The file must end with CRLF as well.
## Audio playlist file ##
Most MT6261-based phones only have a single playlist, and it's saved into the
@Playlists/audio_play_list.sal file on the SD card root. The @Playlists
folder has a "hidden" FAT attribute so it's not visible from the phone file
manager itself. There are several versions of this audio_play_list.sal file,
but the most popular (and studied) one is arranged as follows:
1) every playlist entry is a 522-byte binary chunk, and the chunks are just
placed one after another (the file contains no other sections);
2) the full file path (DOS-style, with backslashes) is placed directly at the
beginning of the chunk and specified in UCS-2 (aka UTF-16LE), strictly two
bytes per character;
3) after the file path, two null bytes follow immediately;
4) the rest of the chunk can be filled with null bytes or random garbage.
For playlist entry path, some virtual DOS drive letter is used, most commonly
it's L: but sometimes it can be different.
PoC (JS):
http://sal-pro.831337.xyz/
## Contact backup file ##
If the phone supports contacts backup and offers the corresponding menu item,
it usually creates ~vcard.vcf in the SD card root. This file isn't visible
from the phone's file manager but is visible from the PC.
The file itself is a sequence of vCard 2.1 records which, if backed up from
the SIM (like in my case), look like this (substitute <name> and <number>
with yours):
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=
<name>;;;
TEL;VOICE;CELL:<number>
END:VCARD
Again, all line endings in this file are CRLF (\r\n), the records are
separated with double-CRLF and the file ends with CRLF as well.
## Fast language switching ##
All MAUIs support switching the UI language with secret codes of the shape
*#0xxx# + Call key. The xxx part corresponds to the country code. Whether or
not the code works, depends on whether the language is actually present in
the firmware.
E.g. *#0044#[call] will switch to English, *#0380#[call] will switch to
Ukrainian and so on.
The *#0000#[call] code is reserved for the "default" language switch. In all
MAUIs I have seen it switches to English.
Some vendors may omit some languages actually present in the firmware and not
assign a shortcode to them, but that's rare.
## Version screens, engineering and test menus ##
Almost all non-Nokia MT626x devices have the following menus/screens
available via secret codes:
- software version screen;
- engineering menu;
- manual test menu (aka "Factory mode");
- automatic/sequential test menu.
Newer phones also have hardware version screens available. The codes for all
these menus can be found in the firmware dumps, but here are the most
popular options based on the analysis of real MT62xx devices:
- software version screen: *#8375#, *#66#, *#837#, *#837837#, *#1122#,
*#18375#, *#2838*#, *#111222*#, *#5566*#, *#10201#, *#121212*#, *#48266*#,
*#456#, *#1111#, *#338375#, *#32#, *#88#, *#2#, *#36#, *#1111*#;
- engineering menu: *#3646633#, *#77#, *#364463#, *#13646633#, *#7788#,
*#3365#, *#9646633#, *#8838#, *#64276#, *#1475369*#, *#84666364*#,
*#0809321*#, *#364*#, *#4466#, *#6688432#, *#446688#, *#36951#, *#4224876#,
*#2016318*#, *#6666*#;
- manual test menu: *#66*#, *#88#, *#3228#, *#5566#, *#166*#, *#66#, *#711#,
*#37#, *#37*#, *#258*#, *#2266#, *#96*#, *#15963#, *#18#, *#2233*#;
- automatic/sequential test menu: *#87#, *#87*#, *#187#, *#55#, *#2886#,
*#1122#, *#99#, *#8818#, *#15*#, *#6804#, *#2287#, *#2255*#.
## Getting to the AT command mode ##
When you connect the (powered-on) MAUI phone to the PC with a proper
(full-data) USB cable, there may be four situations:
1) the phone displays a selection menu that offers "Mass storage" and "COM
port" and displays no errors when you select "COM port";
2) the phone displays a selection menu that offers "Mass storage" and "COM
port" but displays an error when you select "COM port";
3) the phone automatically connects in the mass storage mode and exposes your
SD card and/or internal memory as USB flash drives;
4) the phone does nothing and goes into charging only mode.
In case 1, you don't need to do anything else and your phone is properly
configured to receive AT commands via the USB-serial device detected in your
system. Sometimes this is also true in case 4 but most frequently it is not.
So in all other cases, you must enable the proper UART interface to start
the USB-COM connection.
To do this, go to the _engineering_ (not "factory") menu (refer to the
previous section). There, you need to find the "Device" - "Set UART" - "UART
setting" item. There, you'll see three configuration sections: "TST-PS
config", "PS config" and "TST-L1 config" (the order might be different).
Each section allows you to configure the corresponding port ("UART 1", "UART
2", "USB port" or "None") and the speed (which, for MT6261, must be left at
115200). First, you must make sure that the "TST-PS config" and "TST-L1
config" ports are set to "None" (unless you _really_ need them for some
internal debugging). We're only interested in the "PS config" port for now.
If you set it to "USB port", then the AT command mode will work but you'll
lose the ability to connect in the mass storage mode (no popup on
connection, directly goes to the AT mode) and will have to change the UART
setting back and forth every time you need to switch the connection mode. If
your firmware doesn't support the popup at all, this is your only option.
Otherwise, you may guess one of the port settings (in case of my sample
device, it's "UART 2") which enables both modes to work correctly with this
selection menu.
After saving the UART settings (by pressing left or center soft key), the
phone will automatically turn off. After you turn it back on, the new
setting will be in effect.
## Band selection and network monitor ##
As MT6261 is a quad-band GSM chipset, the same _engineering_ menu usually has
capabilities to change operating GSM bands: "Network setting" - "Band
selection" - "SIM 1"/"SIM 2". Then the phone will ask for the confirmation
that it will turn off after this operation, and offer you the following
selections: "Auto", "850 band", "900 band", "1800 band", "1900 band",
"850/1800", "900/1800" and "850/1900". If you press "Back", the phone will
not power off. If you save the setting, it will.
The network monitor is configured in the "Network setting" - "Network info" -
"SIM 1"/"SIM 2" submenu. It has a bunch of individual screens to display. I
won't describe them all here but the most useful ones are "RR lai info",
"RR_CELL_SEL", "RR meas rep", "RR Ch Dscr", "CC chan info", "CC call info"
and "CA list info". After the necessary checkboxes are selected, you press
"Done" and then the LSK to confirm the setting. Then, in the idle mode, the
network monitor screen is going to appear from time to time. And since you
have 17 screens to scroll through (with up/down arrow keys) anyway, you can
check all the boxes to get maximum information (you can omit the last five
though). To me, screens 1, 2, 4, 7, 9 and 10 are the most important. Note
that during a call, you can only exit the netmonitor with LSK, as the End
key hangs up the call itself.
To turn off the netmonitor, uncheck all the boxes in the network info setting
and save the changes.
## Interesting AT commands ##
Modern MT6261-based phones have a very limited command set (so-called "ULC
AT" in MediaTek terms), even much more limited than the MT6261-based phones
from 2015 to 2017. Even ATI, ATZ and AT+CIMI don't work. Nevertheless, some
notable AT commands remain functional and very important.
The biggest of them is probably AT+EGMR that has the following syntax:
AT+EGMR=<op>,<field>[,"<value>"] where <op> can be 0 (read) or 1 (write) and
the <value> field (quotes around it are mandatory!) is only required for
write operation. The field list is as follows:
- 0: (read only) Chipset ("MT6261")
- 1: (read only) DSP code ("2000.00.00")
- 2: (read only) DSP patch ("1.0")
- 3: (read only) Firmware version string
- 4: (read only) Hardware/board revision string
- 5: (read/write*) Internal serial number string
- 6: (read only) melody revision (doesn't work in MT626x)
- 7: (read/write**) SIM1 IMEI
- 8: (read only) MMI resource version (returns all "0" for all fields in
MT626x)
- 9: (read/write) IMEISV string (2 digits)
- 10: (read/write**) SIM2 IMEI (if SIM2 slot is present)
- 11: (read/write**) SIM3 IMEI (if SIM3 slot is present)
- 12: (read/write**) SIM4 IMEI (if SIM4 slot is present)
* changing the length of internal SN field even via AT+EGMR can lead to
"phone uncalibrated" message on boot and mess up some other settings in
NVRAM, so you must keep its length intact, whatever it may be
** for IMEIs, write operation only works if secure boot is not set and NVRAM
is not locked
IMEI-related AT+EGMR write operations require to reboot your handset in order
to take effect.
Now, we can also emulate keypresses on the handset in real time with
AT+CKPD="<seq>"[,<time>[,<pause>]], where <time> is the overall amount of
1/10ths of a second you "keep" each key pressed, and <pause> is the amount
of 1/10ths of a second between each press. The <time> and <pause> values are
both optional and can be from 0 to 255. The <seq> parameter is the keypress
sequence that can contain usual digit keys from 0 to 9, * and # keys, but
also the following characters (case-insensitive) for special keys on the
handset:
[ - left softkey
m - center softkey/menu key
] - right softkey
^ - arrow up
v - arrow down
< - arrow left
> - arrow right
s - call key
e - end key
u - volume up key
d - volume down key
f - function/camera key
These emulated keys work even if they are not physically present on the
device.
Here are some other important commands. For some commands mentioned below,
you need to set the operating SIM card first if the phone supports multiple
SIMs. This is done with the AT+ESUO=<simid> command, where <simid> can be 4,
5, 6 or 7 for SIM1, SIM2, SIM3 and SIM4 respectively. The data transfer mode
(AT+ESUO=3) is not supported by MT626x phones at all.
When an incoming call is registered on the SIM selected with AT+ESUO, the
terminal, in addition to normal "RING" messages, will also emit unsolicited
+EAIC: messages. In the ULC AT command set, the AT+EAIC command doesn't work
(so you can only use ATA/ATH to answer/hangup), but these messages contain
some useful information and have the following format:
+EAIC: <call_id>, "<number>", <type>, <call_mode>, <seq_no>
where <call_id> can be used for further call manipulation, <number> is local
or international phone number, <type> is the number format (145 for
international, 129 for local), <call_mode> is 0 for voice and 1 for data and
>1 for mixed modes, and <seq_no> is the ordinal number of this incoming call
since the phone power-on.
The usefulness of the +EAIC: message is that it is displayed on the terminal
even when a blacklisted number (or a number not in the contact list in case
the "Block unknown numbers" option is turned on) is calling, right before
rejecting the call.
Here's the list of some other useful AT commands that work in these limited
MAUI environments.
- Display full version + build string: AT+GMR or AT+CGMR
- Display current carrier: AT+COPS?
- Scan for all available carriers: AT+COPS=?
- Voice call: ATD<num>; (the ";" is required)
- Data call: ATD<num> (without ";", requires CSD channel support from your
carrier)
- Answer the incoming call: ATA
- Hangup the active call: ATH or AT+CHUP
- SIM check: AT+ESIMS? (returns 0 if there is no SIM in the slot selected
with AT+ESUO, 1 if the SIM is detected)
- Display incoming call infomation in the terminal (SIM-agnostic): AT+CLIP=1
- Display enhanced incoming call information and overall call progress in the
terminal (SIM-specific): AT+ECPI=3
- Send DTMF digit* during the voice call: AT+VTS=<digit> (where <digit> can
be 0-9, *, #, A, B, C, D)
- Call forwarding control: AT+CCFC (see manuals)
- Call waiting control: AT+CCWA (see manuals)
- Call hold control: AT+CHLD (see manuals)
- Active call list: AT+CLCC (see manuals)
- Disable current SIM: AT+CFUN=0
- Enable current SIM: AT+CFUN=1
- Enable SIM1 only: AT+EFUN=1
- Enable SIM2 only: AT+EFUN=2
- Enable both SIMs**: AT+EFUN=3
- Flight mode (disable both SIMs): AT+CFUN=4 or AT+EFUN=0
- Get signal RSSI: AT+CSQ (0 is 113 dBm or less, 1 is 111 dBm, 2..30 is
109..53 dBm, 31 is 51 dBm or greater, 99 means "not known or not detectable")
* contrary to MediaTek's docs, only a single digit can be sent at a time, no
semicolon-separated +VTS sequences are allowed
** sorry, I couldn't find any information about AT+EFUN syntax for 3-SIM or
4-SIM devices, and I don't have such a device to test this myself
Modern MT6261 phones also report AT+CSCS and AT+CMGW commands as available
and working, but to this day I haven't been able to create a single SMS
draft with them (will update this section if I succeed). All other SMS and
phonebook related AT commands are fully missing in the current generation.
## PC-less IMEI editing ##
The majority of non-Nokia phones running MAUI (around 70%) support editing
IMEIs directly from the keypad. See the "Featurephone IMEI editor codes"
document on this server for the full list of known codes, and the "Firmware
analysis" section of the current document to see how to find your own if you
are lucky. If you are extremely lucky then one of the following top 10 codes
will get you to the IMEI editor: *#5353#, *#0066#, *#066#, *#0160#, *#1263#
(usually works on watchphones), *#4634#, *#4634*#, *#09#, *#2018*# and
*#0606*#. These codes occur most frequently on MT6261 devices specifically.
The remaining 30% though doesn't have this ability and requires the use of
AT+EGMR command to edit IMEIs, as well as all simlocks lifted and secure
boot disabled.
## Dumping ##
Turn the phone on in the BROM mode (usually connecting the cable without
battery or just connecting while pressing the device-specific boot key —
usually Center or Call or # or 0 or 9 or 3). After the usb-serial device
appears in your OS (/dev/ttyUSB*, /dev/ttyACM*, /dev/tty.usbmodem* etc), you
have about half a second to start the handshake.
The handshake is done by sending bytes 0xA0 0x0A 0x50 0x05 until the phone
responds with 0x5F 0xF5 0xAF 0xFA (the inversion of the sent bytes). A good
practice is to keep sending 0xA0 until the phone responds with 0x5F, then
send the remaining three bytes and check the response. You have entered the
"BROM download" mode. Now you can manipulate phone's virtual RAM.
Every BROM DL command body has the following structure: a single byte command
ID and 16- or 32-bit packed (all big-endian) parameters. After sending the
command body, the phone sends it back, and only then it sends the execution
results. If the command body you've received does not match the command body
you sent, then something is wrong.
For dumping purposes, we're only interested in four operations:
- read16(addr, size): 0xA2 [32-bit addr] [32-bit size in 16-bit words] - read
[size] 16-bit words from RAM address [addr];
- read32(addr, size): 0xD1 [32-bit addr] [32-bit size in 32-bit words] - read
[size] 32-bit words from RAM address [addr] (framed with a 16-bit word at
the beginning and the end - must skip them);
- write16(addr, size, chunk): 0xD2 [32-bit addr] [32-bit size in 16-bit
words] [chunk] - write the [chunk] of [size] 16-bit words to RAM address
[addr];
- write32(addr, size, chunk): 0xD4 [32-bit addr] [32-bit size in 32-bit
words] [chunk] - write the [chunk] of [size] 32-bit words to RAM address
[addr].
The write16 and write32 operations return the sequence 0x00 0x01 twice if
everything is successful: first after writing the address and size, then
after writing the chunk itself. So it's advisable to read the command output
twice (before and after data transmission) to not send the chunk if there's
an error.
Now, how do we dump the firmware using only these four operations, with no DA
or anything? Well, almost all MT62xx chipsets support (read-only, as far as
I understand) flash mapping onto one of the RAM regions. The most stable way
to map it is to the start of RAM. This is done by writing the value 2 to the
register 0xA0510000 using the write32 operation. Afterwards, the entire
flash contents is mapped in LITTLE-endian 32-bit chunks, word by word,
starting from the location 0. The slowest but most reliable way is to read
the contents word by word with the read32 operation, flipping the byte order
and concatenating them to the output buffer.
It is also recommended to perform the following operations _before_ remapping
the RAM and starting the dump process:
1. Read the chipset type: read16(0x80000008, 1) - must return 0x62 0x61 in
case of MT6261, if it's not working then something is definitely wrong with
your connection or the chipset itself;
2. Disable system watchdog: write16(0xA0030000, 0x2200);
3. Disable battery watchdog: write16(0xA0700A24, 2);
4. Enable USB download mode: write16(0xA0700A28, 0x8000).
PoC (Python):
https://gitlab.com/suborg/mtreader/-/blob/master/mtreader.py
## Unalicing ##
I haven't studied the process myself but there already is a Python-based tool
to do that. See
https://github.com/donnm/mtk_fw_tools for all details.
## Flashing ##
Still have to research the correct way of doing this (previous attempt
resulted in bricking a Maxcom device).
## Firmware analysis ##
After you have the firmware dump binary and (optionally) the unaliced
partition, you can inspect them with a hex editor/viewer or run through the
strings utility. You can do this to find suspicious numbers/URLs or secret
codes. To find secret codes that almost always start with *#, the simplest
way to do this is:
strings dump.bin | grep '*#' | sort -u
You can optionally look for the codes that start with "#*", although that's
very rare for MAUI devices:
strings dump.bin | grep '#\*' | sort -u
Some codes are always present in MAUI firmware but never work (at least on
MT626x). These include: *#28144#, *#3366*#, *#5566183# and *#0086# (unless
the phone actually has Mandarin Chinese language installed). The purpose of
the first 3 codes and the correct way to invoke them is still unknown.
Also, NEVER test the *#6810# code if you see it in the dump (and even if you
don't): it's rumored to permanently disable engineering and test codes until
full firmware restoration (factory reset won't help).
--- Luxferre ---
