-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Band Locking #4
Comments
Any possibility of releasing the App on TestFlight with the capability to perform the GET and POST request? Unfortunately I don't have the capability to compile the app, thanks |
You can unlock the Fuzzer tab by tapping 10 times on the "About" text on the settings page. |
Great, I am in, thanks |
Do you know what modem (X62, MediaTek, etc.) is inside the Sagemcom? |
No idea, sorry. |
Doesn't work when running the app on a Silicon Mac? |
AFAIK, carriers do not provide/ expose public APIs for selecting 5G NR bands, but do have them for network management, diagnostics, provisioning, which I believe you are already leveraging for HINT Control on the main screen (pulling LTE, 5G data). The actual selection of 5G NR bands is typically managed by the mobile gateway itself, based on the capabilities of the device and the network. TLDR below :) my 2c - The initial intent / design was for towers to hand off smoothly from one tower to next as a mobile phone moves through the network, the 5G home gateways are adding complexity with the need for a band lock since it's now stationary (mostly). During congestion, high latency the HI gateway am assuming is programmed to look for the next best available band (mm/uw, then mid-range, lower freq) and where available another 'available' tower to latch onto I've done a bunch of testing with antennas and placement/ orientation to observe how the TMo 5G HI gateway seems to latch onto n41 bands typically after a power cycle, and soon after switch to n71 when a combination of the RSRQ, SINR, RSRP etc falls below a threshold. The same gateway latches back onto the n41 band again during late night (many times with another tower), and during wee hours of the morning until congestion time, to repeat the cycle again. I have observed 4 CGIs across 3 cell towers with this behavior. All 3 towers are all in the same physical location per (cellmapper.net) and I've verified it as well - making my task easier since I dont have to move/ reorient the gateway. Short answer band locking seems to be a 'NO' for now. I'm also checking with some of my techie engineering contacts at mabell and T-Mo and will reply back in this thread if I hear anything |
Qualcomm Snapdragon X62 5G Modem-RF System scroll down about 1/3rd way and click on the Fast 5688W tab |
Right now, we have no way to lock the modems to a specific band.
The API endpoints we know about, both in the Nokia API and the shared API for Arcadyan and Sagemcom, don't provide a way to set preferred or required cellular bands. In order to add any sort of band locking feature, we need to know:
The most comprehensive way to find what we need would be firmware dumps. However, T-Mobile doesn't publish the firmware publicly for any of its modems and it doesn't seem like anyone has succeeded yet in extracting it from the devices.
Without having access to the firmware, we need to rely on forensic and fuzzing strategies.
The web UIs on all the modems list a few API endpoints in the JavaScript served to the browser. The T-Mobile Internet app itself lists even more endpoints. However, these are only the ones the T-Mobile Internet app actually uses. It doesn't include any that might exist but aren't used. With the right tooling, it's also possible to sniff the traffic between the official client and the gateway and extract requests from that. These sources are where all of the currently-known endpoints have come from.
The only thing we really have left at this point is fuzzing (guessing) URLs to find valid APIs. I've done some limited URL guessing on my Arcadyan gateway without much luck, and I don't want to push it too far in case something breaks. If you're interested in doing your own guessing, HINT Control does have a simple page to perform GET and POST requests and display the return values, but it's not currently enabled.
Uncommenting this line and compiling the app will make it show up when the side navigation bar is displayed (wide or large screens or windows).
@chainofexecution has done a bunch of work on taking the Arcadyan gateway apart and even performing some limited UART snooping.
It seems like the device is based on a MediaTek T75, which seems to be related to the Dimensity 1000.
mtkclient is able to unlock the Dimensity 1000, so it isn't out of the question that it could also work for this chipset, but UART isn't USB, and we'd probably need the T75 scatter file.
I'm hoping this issue can serve as a bit of a discussion for findings and hacking strategies. If you do any URL guessing, mention what you tried.
The text was updated successfully, but these errors were encountered: