ZTE MF823 autoswitch

Markus Gothe nietzsche at lysator.liu.se
Mon Sep 12 11:29:21 UTC 2016


So this is how ZTE implements Microsofts "identity mophing" as described here: https://msdn.microsoft.com/windows/hardware/drivers/network/mb-identity-morphing

The software waits for the OS to send an MS properitary "OS descriptor‎" to detect if the OS supports MBIM or not.


Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Markus Gothe
Sent: söndagen den 11:e september 2016 15:48
To: Björn Mork
Cc: libmbim List; Gareth Lowe
Subject: Re: ZTE MF823 autoswitch

Yeah, I guess Gareth used http://vve.su/files/misc patches as I did in april last year.

Telling customers to buying a new device is not a friendly way of doing business, right? ;-)

AFAIK the MF823 is much more stable than the MF831 (in QMI-mode) and would allow people to bridge their devices and
get around double-NAT issues if we can emulate Win 8.

The one I got for the day is the K5008-Z branded one for Australian market,
so I guess Gareth and those whirlpool enthusiasts would be interested in the progress.

//M

On 11 Sep 2016, at 13:43 , Bjørn Mork <bjorn at mork.no> wrote:

> 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

//Markus - The panama-hat hacker



More information about the libmbim-devel mailing list