Qin F25 USA?

ars18 · April 7, 2026, 1:14pm

The new f21 also has many mentions of US carriers that’s why I originally got excited.

Interesting though that you’re connected to Verizon at all though.

Zvi_Wolf · April 7, 2026, 2:52pm

They did it with the new f21s, and so far it’s unbreakable, so why would it be a risk with the f25

I believe he has contacts with the sellers on aliexpress

flipphoneguy · April 7, 2026, 5:47pm

I don’t know what they did with the qin but didn’t they use a different chipset for the new one?

flipphoneguy · April 7, 2026, 5:49pm

@ars18 @Nooch can I know exactly where you got stuck on the f21? I wanna confirm if it’s the same exact with the f25.

BenTorah · April 7, 2026, 6:51pm

It’s not simple as flipping a bit to enable the bands. That’s assuming we can determine the bitmask or other config mechanism to start. There are FDD and TDD, LTE and not, etc.

MAUI has an nvram editor, but it’s not enough. The modem firmware needs to support it.
Yes, it is a software lock. The SoC supports much. But the modem needs the tuning and radio calibrations that are specific to the device.
That is why the F21 US flash trick works; because the “F30” manufacturer worked with vendor to obtain the configs.

I’ve only gotten as far as requesting the MTK Engineering mode apk elsewhere. I’d start there (manually) and explore.
AI can help with localized analysis, but you’ll need to do research into modem tech before going in blindly. That’s my evidence-based advice.
Try to gain AT command execution. I think it’s what EM does - that or there are some native APIs, but without the apk I can’t know for sure. There may be a dev port exposing a modem interface.

flipphoneguy · April 7, 2026, 8:10pm

Thanks so much for clarifying.

So here’s the thing. The em app is already installed. Tons of options there including at execution. I used summer at command to conclude to the conclusions I got to (not sbp but rather baked into firmware) and as you said the only way to fix it will be to modify the firmware which you say isn’t easy. Not sure what configs you’re talking about btw. But would it be possible to take from another random phone with the same modem with us support and flash it on this device?

If you want I’ll post the em app here.

Here’s the config file (which creates available at commands in the app) generated by Claude after inspecting the md1img image

Modem Info
 modem_version
  AT+EMDVER?
 modem_id_imei
  AT+EGMR=0,7
 modem_capabilities
  AT+EGMC=0,"rf_cal_info"
 modem_type
  AT+EGTYPE?
 radio_status
  AT+CFUN?
Band Query
 query_supported_bands
  AT+EPBSE=?
 query_current_bands
  AT+EPBSE?
 query_supported_nr_bands
  AT+EPBSEH=?
 query_current_nr_bands
  AT+EPBSEH?
 query_cdma_bands
  AT+ECBANDCFG?
 query_serving_cell
  AT+ECELLINFO?
 query_lte_bw_info
  AT+ELTEBWINFO?
 query_network_info
  AT+ENWINFO?
 query_network_config_info
  AT+ENWCFGINFO?
 query_registration_info
  AT+EREGINFO?
 query_eslband
  AT+ESLBAND?
SBP Query
 query_sbp_full
  AT+ESBP?
 query_sbp_id
  AT+ESBPID?
 query_dynamic_sbp
  AT+EDSBP?
 sbp_band_disable_by_plmn
  AT+ESBP=7,"SBP_DISABLE_LTE_BAND_BY_PLMN"
 sbp_custom_band_disable
  AT+ESBP=7,"SBP_CUSTOM_BAND_DISABLE_FOR_PLMN"
 sbp_disable_band_sim_plmn
  AT+ESBP=7,"SBP_DISABLE_BAND_BY_SIM_PLMN"
 sbp_lte_custom_disable
  AT+ESBP=7,"SBP_LTE_CUSTOM_DISABLE_BAND_BY_PLMN"
 sbp_disable_b41
  AT+ESBP=7,"SBP_DISABLE_LTE_B41"
 sbp_visible_sim_disable
  AT+ESBP=7,"SBP_DISABLE_BANDS_IF_SIM_IS_VISIBLE_SIM"
 sbp_hpue
  AT+ESBP=7,"SBP_HPUE"
 sbp_dsda
  AT+ESBP=7,"SBP_DSDA"
RF Diagnostics
 rf_index_query
  AT+ERFIDX=?
 rf_index_current
  AT+ERFIDX?
 rx_path_query
  AT+ERXPATH?
 antenna_info
  AT+ETXANT?
 ca_combo_info
  AT+ECACOMB?
 ca_info
  AT+ECAINFO?
 ca_switch
  AT+ECASW?
SIM Info
 sim_info
  AT+ESIMINFO?
 einfo
  AT+EINFO?
IMS Info
 ims_info
  AT+EIMSINFO?
 ims_call_mode
  AT+EIMSCALLMODE?
 ims_config_mode
  AT+EIMSCMODE?
Config Read (AT+ECFGGET)
 cfg_band_config
  AT+ECFGGET="band_config"
 cfg_sbp_config
  AT+ECFGGET="sbp_config"
 cfg_rf_config
  AT+ECFGGET="rf_config"
 cfg_lte_band
  AT+ECFGGET="lte_band_config"
Radio Control (CAREFUL)
 radio_off
  AT+CFUN=0
 radio_on
  AT+CFUN=1
 radio_reset
  AT+CFUN=1,1
Band Setting (CAREFUL)
 set_all_bands_max
  AT+EPBSE=255,65535,4294967295,4294967295,4294967295,4294967295,0,0,0,0
 set_us_bands_attempt
  AT+EPBSE=154,147,134813919,482,66,0,0,0,0,0
 set_original_bands
  AT+EPBSE=154,147,134742229,482,0,0,0,0,0,0
Fake SIM Identity (CAREFUL)
 fakeid_tmobile
  AT+EFAKEID="310","260","123456789"
 fakeid_att
  AT+EFAKEID="310","030","123456789"
 fakeid_verizon
  AT+EFAKEID="310","590","123456789"

BenTorah · April 7, 2026, 9:57pm

In theory it should, but I’ve tried in the past from various devices. It didn’t work IIRC

It’s difficult to find firmware dumps online that contain all the files needed (md1img, nvdata, nvram, nvcfg).
And mixing and matching md1img/nvram/nvdata files doesn’t work right. Need all to match

BenTorah · April 7, 2026, 10:32pm

I’m recalling now, I could not locate a firmware dump of the FOSSiBOT F101 non-Pro version (with MANY global bands unlocked), since it was widely superseded by the FOSSiBOT F101 Pro (P22 instead of A22 processor).
The only place I could find it for sale was here but they won’t ship to the US.

If you’d like to give it a shot and have it delivered somehow, this might work. Would have to verify the bands in EM, dump the partitions, and flash to Qin.

flipphoneguy · April 7, 2026, 10:48pm

What are you talking about? it’s a different chipset

flipphoneguy · April 7, 2026, 11:23pm

Just had a long session with Claude checking out the md1img
Here’s what it says now

Summary

Qin F25 US Band Unlock — Technical Analysis

Summary

The Qin F25 (MT6768/MT6769) modem firmware contains a 55-entry band configuration table that restricts LTE to 7 FDD + 5 TDD bands. The modem hardware supports 27+ FDD bands including US-critical B12, B13, B17, B25, B26. These bands have active RF test handlers in the firmware but are masked out of the EPBSE capability response by the band config table. The firmware image is unsigned. Patching the 55-entry table is the most viable unlock path. NVRAM does not need modification — the bitmask exists only in md1img.

B4, B66, and B71 have no handler code in the firmware and cannot be enabled by patching.

Pre-Investigation Summary

Goal: Enable US LTE bands (B2,4,12,13,17,66,71) on Chinese-market Qin F25.

Background: A US kosher version was planned but delayed. Band restriction is intentional to protect that business channel (see info.md). The predecessor F30 was successfully unlocked by the community, prompting this lockdown.

What we tested before firmware inspection:

Engineering Mode app (com.mediatek.engineermode) sends AT commands via HIDL mtkradioex service — this works
AT+EPBSE=? returns 154,147,134742229,482,0,0,0,0,0,0 — only CN/global bands
All SBP band-disable features return 0 — SBP is NOT blocking bands
AT+EPBSE= with US band bits returns GENERIC_FAILURE — modem rejects unknown bands
AT+EPBSE= with all-max (0xFFFFFFFF) returns OK but masks back to same supported set

Conclusion from AT testing: The block is at the firmware level, not SBP policy.

Firmware Image Analysis

Image: /dev/block/by-name/md1img_a → /dev/block/mmcblk0p18, 128MB
Backup slot: /dev/block/by-name/md1img_b → /dev/block/mmcblk0p33
Format: Raw binary with MTK GFH header (magic 0x58881688, name md1rom)
Signing: None detected. End of image is zero-padded. No signature block, no dm-verity.

Structure 1: EPBSE Response Format String

Location: 0x011881A4
Content: +EPBSE: %u,%u,%u,%u,%u,%u,%u,%u,%u,%u
Proof: xxd -s 0x11881A0 -l 48 md1img.bin
Significance: Confirms the 10-integer EPBSE format. The function that uses this format string reads band capability from Structure 3 below.

Structure 2: RF Test Band Handler Table

Location: 0x011E92F8
Source file: ul1tst/ul1tst_main.c (string at 0x11E92D0)
Format: Array of 8-byte entries: [uint32 band_index] [uint32 function_pointer]
Default/stub pointer: 0x90F233D9 (= band not supported)
Proof: xxd -s 0x11E92F8 -l 512 md1img.bin — sequential indices 0x00-0x3B with interleaved pointers.

Bands with unique handler pointers (not the stub):

Band	Pointer	US-relevant?
B1	0x90F252D5
B2	0x90F251D9	Yes — 1900MHz
B3	0x90F2515D
B6	0x90F22965
B7	0x90F22929
B9	0x90F25141
B18	0x90F23B91
B19	0x90F2339D
B21	0x90F23355
B24	0x90F232DD
B26	0x90F2329D	Yes — 850MHz extended
B27	0x90F23261
B28	0x90F250F5
B29	0x90F23C09	Yes — AT&T SDL
B30	0x90F250A9	Yes — AT&T WCS
B31	0x90F2505D
B33	0x90F23A7D
B34	0x90F23219
B35	0x90F231DD
B36	0x90F231A5
B37	0x90F228ED
B39	0x90F23219
B40	0x90F23161
B41	0x90F22779
B43	0x90F23139
B45	0x90F24179
B46	0x90F25001
B47	0x90F24FB5
B48	0x90F241BD

Bands with NO handler (stub pointer only): B4, B5, B8, B10-B17, B20, B22-B25, B32, B38, B42, B44, B49+

Note: B5, B8, B20 appear in EPBSE but have stub pointers here. This table is for RF testing (ul1tst), not the main radio stack. The main stack uses a different code path for those bands.

Structure 3: Band Configuration Table (EPBSE Source)

Location: 0x012113FC
Entries: 55
Stride: 36 bytes per entry
Format per entry:

Offset  Size  Description
+0      4     LTE FDD bitmask (bands 1-32)
+4      4     LTE TDD bitmask (bands 33-64)
+8      4     LTE extended mask 1
+12     4     LTE extended mask 2
+16     4     LTE extended mask 3
+20     4     LTE extended mask 4
+24     4     LTE extended mask 5
+28     4     LTE extended mask 6
+32     4     Pointer (incrementing, not band data)

Proof:

grep -c -P '\xd5\x00\x08\x08' md1img.bin finds 0 hits outside this table
Python scan for 0x080800D5 finds exactly 55 occurrences, all in this table
All 55 entries share FDD mask 0x080800D5 = B1,3,5,7,8,20,28
Decoded: python3 -c "v=0x080800D5; [print(f'B{i+1}') for i in range(32) if v&(1<<i)]" → B1,B3,B5,B7,B8,B20,B28

Current FDD value: 0x080800D5 = 134742229

Bit 0  (B1)  = 1    Bit 16 (B17) = 0
Bit 1  (B2)  = 0    Bit 17 (B18) = 0
Bit 2  (B3)  = 1    Bit 18 (B19) = 0
Bit 3  (B4)  = 0    Bit 19 (B20) = 1
Bit 4  (B5)  = 1    Bit 20 (B21) = 0
Bit 5  (B6)  = 0    Bit 21-26    = 0
Bit 6  (B7)  = 1    Bit 27 (B28) = 1
Bit 7  (B8)  = 1    Bit 28-31    = 0

TDD values vary by entry (some have 0x100, 0x120, 0x180, 0x1A0, 0x380). This represents different carrier aggregation scenarios.

Structure 4: SBP Band Disable Strings

Locations:

0x01181FE8: SBP_DISABLE_LTE_BAND_BY_PLMN
0x01183748: SBP_DISABLE_L1_GSM_BAND_MASK
0x011831A4: SBP_LTE_CUSTOM_DISABLE_BAND_BY_PLMN
0x01185098: SBP_CUSTOM_BAND_DISABLE_FOR_PLMN

Status: All return 0 via AT+ESBP=7,"...". Confirmed inactive.

Structure 5: Band Support Logging

Location: 0x011FBC28
Content: custom_get_supported_bands(), L1D_GetBandSupport_PCore(): 0x%x
Significance: This is the debug log line from the function that computes band support. The function custom_get_supported_bands() returns a bitmask. It likely reads from Structure 3 and possibly applies SBP filtering.

NVRAM Analysis

Partitions checked:

nvram (/dev/block/mmcblk0p31) — raw NVRAM, no band bitmask found
nvdata (/dev/block/mmcblk0p14) → mounted at /mnt/vendor/nvdata — ext4 filesystem
nvcfg (/dev/block/mmcblk0p13) → mounted at /mnt/vendor/nvcfg — ext4 filesystem

Band-relevant files found:

/mnt/vendor/nvdata/APCFG/APRDCL/MD_SBP — 26 bytes, contains SBP slot config, no band masks
/mnt/vendor/nvdata/md/NVRAM/NVD_DATA/LTEB_032 — 536 bytes, LDI header, RF calibration data per band (not enable flags)
LTEA_006, LTEF_005, LTEG_001, LTEH_001 — similar RF calibration records

Proof NVRAM doesn’t contain the bitmask:

dd if=/dev/block/mmcblk0p31 bs=1M count=4 | grep -c -P '\xd5\x00\x08\x08'  → 0
dd if=/dev/block/mmcblk0p13 bs=1M count=4 | grep -c -P '\xd5\x00\x08\x08'  → 0
find /mnt/vendor/nvdata -type f -exec grep -lP '\xd5\x00\x08\x08' {} +     → nothing

Conclusion: NVRAM modification is NOT required. The band capability bitmask lives exclusively in md1img. NVRAM contains RF calibration data that should remain untouched.

What Can Be Unlocked

Band	In EPBSE	Has RF Handler	In HW Table	Unlockable?
B2	No	Yes (0x90F251D9)	Uncertain	Likely yes
B4	No	No (stub)	No	No
B12	No	No (stub in ul1tst)	Yes*	Possibly
B13	No	No (stub in ul1tst)	Yes*	Possibly
B17	No	No (stub in ul1tst)	Yes*	Possibly
B25	No	No (stub in ul1tst)	Yes*	Possibly
B26	No	Yes (0x90F2329D)	Yes*	Likely yes
B29	No	Yes (0x90F23C09)	No	Uncertain
B30	No	Yes (0x90F250A9)	No	Uncertain
B66	No	No (stub)	No	No
B71	No	No (stub)	No	No

*The hardware table at 0x018A1291 shows these as capable, but that table’s reliability is uncertain — it may be a coincidental byte pattern match rather than a definitive capability flag array.

Best case realistic unlock: B2, B26 (confirmed handler code exists).
Possible but uncertain: B12, B13, B17 (no test handler, but may use shared handler via main stack).
Not possible: B4, B66, B71 (no code path in firmware at all).

Patch Plan

Target: Change FDD bitmask in all 55 entries of the band config table.

Location: 55 entries starting at 0x012113FC, stride 36 bytes.
Current value at each entry offset +0: D5 00 08 08 (little-endian 0x080800D5)

To add B2 (bit 1) and B26 (bit 25):
New value: 0x080800D5 | 0x02 | 0x02000000 = 0x0A0800D7
New bytes: D7 00 08 0A

To add B12 (bit 11), B13 (bit 12), B17 (bit 16) as well:
New value: 0x0A0918D7
New bytes: D7 18 09 0A

Safety:

Backup: sudo dd if=/dev/block/mmcblk0p18 of=/sdcard/md1img_backup.bin bs=1M
B slot untouched: md1img_b on mmcblk0p33 remains original
Worst case: modem won’t boot → no cellular, Android still works → restore via dd or SP Flash Tool
Cannot hard-brick: MTK BootROM (BROM) mode is hardware-level, always accessible

Files

File	Description
`README.md`	This document
`usa.md`	Session 1 investigation notes
`info.md`	Kosher phone community intel
`quickref.txt`	Command cheatsheet for EM app, partitions, backups
`config.txt`	AT command config for EM CommandTool (deploy to /sdcard/)
`md1img.bin`	Modem firmware dump (128MB)
`EngineerMode.apk`	Extracted MTK Engineering Mode app
`em_decompiled/`	Jadx decompilation of Engineering Mode

Analysis conducted April 7, 2026 on-device via Termux with root.

Gut yt to be continued

BenTorah · April 10, 2026, 1:05am

Please, re-read my message.

Claude is hallucinating most things band related. How did it analyze the md1img.bin?
Ask it for concrete proof of the findings, it’s confidence level, and it’s uncertainties. It will not admit it doesn’t know unless confronted; and even then, with another confident guess.

NVRAM modification is NOT required

This is false. It needs to match with whatever RF data to accompany the enabled bands.

NVRAM contains RF calibration data that should remain untouched.

flipphoneguy · April 10, 2026, 1:56am

Sorry but I’m still not sure I understand. It sounds like you’re talking about a different phone you tried flashing since the qin f25 is g85. Not a22. But then I don’t get what you mean by

Anyway, I believe you about Claude hallucinating. (I usually don’t blindly use AI like that. I just got Claude in my terminal for the first time and I don’t know these stuff well enough so I just gave it a shot)

I guess I’ll have to

Just 1 thing, to clarify, you said

Does that mean that if I find a rootable phone with the same SoC as the f25 with all US bands supported I can just dd it out and flash? (I’m not looking for %100 success rate. Just a big enough chance)

Anyway thanks a ton for the help! If you or anyone finds leads, (rootable phones same chipset with US bands support or has any tips) please let me know. I’m sharing the images here in case anyone knows how to reverse engineer binary and understands these modern terms and binary.

Here’s a link to download the modem firmware:

https://files.flipphoneguy.duckdns.org/browse/Jtech/f25_modem_firmware.zip

BenTorah · April 10, 2026, 2:16am

Got it. My efforts were on the F21. Different phone we’re talking about, my mistake.

Possibly. Doesn’t even have to be rootable. That chipset is still vulnerable to the bootrom exploit employed by mtkclient. Just dump and flash.

For your F25, try an unbrick image of the Fossibot F106 Pro. Same chipset, more popular (available online), and global.

flipphoneguy · April 10, 2026, 2:30am

Thanks for the lead. I’ll try. By unbrick you mean all partitions? Isn’t that extremely risky? (Wrong drivers for different hardware) Wouldn’t it be enough to flash just md1img nvram nvdata and nvcnfg?

BenTorah · April 10, 2026, 3:41am

Yes, I mean just the md1img nvram nvdata and nvcfg for flashing
Unbrick images typically contain a dump of all partitions (whereas OTA or others will ship without the ones you need)

flipphoneguy · April 10, 2026, 3:54am

Can’t find a unbrick image. If you or anyone finds please let me know. I’ll continue searching meanwhile.

BenTorah · April 10, 2026, 4:17am

Quick find: https://azrom.net/product/fossibot-f106-pro-mode-f-v09-20250327-dump-full-backup-unlocktool/
Sketchy, but $4. It has everything you need. You can download the ZIP to explore, but they’ll probably give you the pw with payment
Use privacy.com or temp card

anonymousfliphones · April 10, 2026, 5:40am

looks like your not the only one who says sketchy

Dev-in-the-BM_2.0 · April 10, 2026, 6:50am

Googled a bit, the site doesn’t sound too trustworthy.

flipphoneguy · April 10, 2026, 7:29am

I researched a bit, paid with PayPal and success on getting that firmware. Flashed from there and got tons of bands that were previously disabled to be enabled including all critical us bands. BUT 0 bars… Didn’t even find any network. Probably rf issues. Possibly different rf hardware. Also, I asked Claude to find differences in firmwares and it said:

Important: Modem Version Mismatch

Your Qin F25: MOLY.LR12A.R3.MP.V315.3.P2
Fossibot dump: MOLY.LR12A.R3.MP.V306.4.P3

Same MOLY branch, but your Qin has a newer version (V315 vs
V306). This means:

Flashing the Fossibot md1img would be a modem downgrade
The band config table is at a different offset than your
README documents (the bytes at 0x012113FC in the Fossibot
image don’t match the same table structure)

It claimed if I flash all nv partitions it shouldn’t matter. But apparently flashing all doesn’t pick up any signal.

@BenTorah what would you say can be done from here?

I assume that even if all this is correct, once we have both of these 2 devices firmwares, it’s probably more likely to be possible to manually modify either the qins md1img or the fossibots nv partitions to get the right rf…

If anyone’s interested in helping, I’ll upload the firmware from the fossibot.