-
Notifications
You must be signed in to change notification settings - Fork 30
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
Limit frequency bands to those supported by the spoofed IMEI's phone model #1
Comments
In the AT Commands Manual V1.2 and V1.3, the
(emphasis mine) Doesn't this beg the question whether the router might in some circumstances actually still use frequency bands that were excluded using the command? Perhaps this should be explicitly tested? |
If you think there are enough EP-06E/A's you could just use the TACs for them. To do this replace the imei_prefix values in imei_generate.py with each of the following: If you want it to match the many Iphone/Samsung phones around. Another option is to wait for the GL-E750V2 which replaces the EP06-E with the EM060K. The EM060K supports LTE global bands which aligns with most modern phones. You could then use a lot of TACs from many modern phones. This option requires the software to be updated to work with v2, and of course for v2 to be released which is still TBD. |
As discussed on page 9 of the Documentation, a fingerprinting risk emerges when
blue-merle
generates an IMEI with a TAC of a phone model not supporting LTE frequency bands the Mudi router supports, namely B1, B3, B5, B7, B8, B20, B28, B32, B38, B40 and B41. When a blue merle Mudi uses a frequency band that does not match the TAC’s specification, an observer can deduce that the IMEI is spoofed.As limiting the frequency bands might impact service quality and availability, the feature should be optional.
The command to limit the baseband to specific bands is
AT+QCFG=$band
See AT Commands Manual (alternative public link) for details.
The text was updated successfully, but these errors were encountered: