ZTE MF823 autoswitch

[Bjørn Mork]

Markus Gothe <nietzsche at lysator.liu.se> writes:

> Maybe we need to dump the baseband and reverse engineer it. Luckily
> I've got a device with telnet access turned on (just using a MBN file
> with the kernel won't give us the kallsyms).

I'm not exactly sure of the status of this work. I generally do not care
much about working around braindead firmware - buy something else
instead ;)

But there has been a lot of interesting results from the ROOter, DD-WRT
and usb_modeswitch communities.  I think Gareth got something going
based on modifying the scripts running on the modem.  That's not exactly
usable for the masses, but it points towards an answer somewhere in the
scripts running in the android part of the modem. So if you have telnet
or adb access, then it should be possible to just browse around and look
for suspects.  Most of it is probably a BSP from the SoC vendor. It's
usually easy to spot changes made by the SoC customer (i.e. ZTE) simply
based on the level of hackishness...

There were also some research on the other side of the USB link, looking
at the effect of the usb-storage driver initialization. I believe the
different modes with and without usb-storage, proves that this is one of
the input parameters the firmware is looking at.  Ref:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=3&t=1880&sid=44caa5d6ce5e9e3d4381e8846446bf7f&start=15

> Then we would know how the OS fingerprints are produced. However I am
> a novice when it comes to ARM‎, but I've got some clues.


I'd be suprised if this is based on some advanced fingerprinting.  It is
more likely based on observing a single difference between Windows and
Linux (or maybe between different Windows versions?)

Sorry if I missed some final result of all this.  Others, who care about
ZTE and maybe have an MF823, will probably know a lot more...



Bjørn