Huawei MBIM tool
Markus Gothe
nietzsche at lysator.liu.se
Thu Mar 12 13:45:46 PDT 2015
Thanks a lot!
This info mean much to me and others!
I never really got a grip about the DSS-thing yet... So I am very thankful for providing this PoC!
//M - Getting DSS into umbim
Den 12 mar 2015 13:06 skrev Bjørn Mork <bjorn at mork.no>:
>
> Markus Gothe <nietzsche at lysator.liu.se> writes:
>
> > There is a tool for embedding "AT over MBIM" made by Huawei for Win 8, called "MBIM tool".
> >
> > Kinda hard to get hold of... I need it to reverse engineer it in compliance with Swedish law about interoperability (making reverse engineering legal in situations like this).
> >
> > Does anyone of you guys have it at hand or can point me where I can get it free of charge?
>
> Cannot help with that, I'm afraid. But these things tend to be so
> obvious that it is possible to guess the rest. There are basically only
> two remotely sane ways to tunnel AT command interpreter access in MBIM:
> 1) as a device service session, emulating a TTY
> 2) as a vendor specific service, using the AT command as input data to a
> "set" CID, returning the AT command output
>
> The only Huawei MBIM firmware I have is so old that I don't know if it
> is relevant for newer devices (it's the modem Huawei kindly provided to
> assist the cdc_mbim driver developement), but it implements the first of
> these alternatives.
>
> The "device services" CID gives us the necessary hints:
>
> bjorn at nemi:~$ mbimcli -d /dev/cdc-wdm1 --no-close --query-device-services
> [/dev/cdc-wdm1] Device services retrieved:
> Max DSS sessions: '5'
> Services: (8)
>
> Service: 'basic-connect'
> UUID: [a289cc33-bcbb-8b4f-b6b0-133ec2aae6df]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: device-caps (1),
> subscriber-ready-status (2),
> radio-state (3),
> pin (4),
> pin-list (5),
> home-provider (6),
> visible-providers (8),
> register-state (9),
> packet-service (10),
> signal-state (11),
> connect (12),
> provisioned-contexts (13),
> ip-configuration (15),
> device-services (16),
> device-service-subscribe-list (19),
> packet-statistics (20),
> network-idle-hint (21),
> emergency-mode (22),
> ip-packet-filters (23)
>
> Service: 'sms'
> UUID: [533fbeeb-14fe-4467-9f90-33a223e56c3f]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: configuration (1),
> read (2),
> send (3),
> delete (4),
> message-store-status (5)
>
> Service: 'phonebook'
> UUID: [4bf38476-1e6a-41db-b1d8-bed289c25bdb]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: configuration (1),
> read (2),
> delete (3),
> write (4)
>
> Service: 'ussd'
> UUID: [e550a0c8-5e82-479e-82f7-10abf4c3351f]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: ussd (1)
>
> Service: 'dss'
> UUID: [c08a26dd-7718-4382-8482-6e0d583c4d0e]:
> DSS payload: 3
> Max DSS instances: 1
> CIDs: connect (1)
>
> Service: 'auth'
> UUID: [1d2b5ff7-0aa1-48b2-aa52-50f15767174e]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: aka (1),
> sim (3)
>
> Service: 'unknown'
> UUID: [3c83a6ed-801e-4340-98f0-f8dc33baa7cc]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: 1, 2
>
> Service: 'stk'
> UUID: [d8f20131-fcb5-4e17-8602-d6ed3816164c]:
> DSS payload: 0
> Max DSS instances: 0
> CIDs: pac (1),
> terminal-response (2),
> envelope (3)
> [/dev/cdc-wdm1] Session not closed:
> TRID: '3'
>
> As you can see: The 'dss' service is supported, with both TX and RX
> payload. The number of sessions and the UUID to use for DSS is a bit
> diffuse, but experiments have shown that there most likely only one
> such tunnel is supported. And the actual UUID doesn't seem to matter
> at all.
>
> Anyway, something like this will work with this modem:
>
> nemi:/tmp# ip link set wwan1 up
> nemi:/tmp# ip link add link wwan1 name wwan1.dss0 type vlan id 256
> nemi:/tmp# ip link set wwan1.dss0 up
> nemi:/tmp# socat INTERFACE:wwan1.dss0,type=2 PTY,echo=0,link=/dev/modem
>
> bjorn at nemi:~$ mbimcli -d /dev/cdc-wdm1 --no-close --no-open=3 --dss-connect=c08a26dd-7718-4382-8482-6e0d583c4d0e,0
> [/dev/cdc-wdm1] Successfully connected
> [/dev/cdc-wdm1] Session not closed:
> TRID: '4'
>
> bjorn at nemi:~$ minicom
>
> Welcome to minicom 2.7
>
> OPTIONS: I18n
> Compiled on Jan 1 2014, 09:30:18.
> Port /dev/modem, 12:23:33
>
> Press CTRL-A Z for help on special keys
>
> OK
> ati
> Manufacturer: huawei
> Model: E367
> Revision: 11.810.09.00.00
> IMEI: 353613048805199
> +GCAP: +CGSM,+DS,+ES
>
> OK
> at+cpin?
> +CPIN: SIM PIN
>
> OK
>
> ...etc. ( The first "OK" is the response to "ATE1". Echo is disabled by
> default on this channel for some reason. )
>
> There are of course more practical ways to access this channel than
> setting up a VLAN interface and using socat, as has been discussed
> before. See the DSS section in
> https://www.kernel.org/doc/Documentation/networking/cdc_mbim.txt
>
> But those tools are readily available for a simple demo, and initial
> trial and error testing, so that's why I use them for this example.
>
> Note that the implementaion is rather buggy (might be due to the early
> firmware as mentioned):
> - It will happily accept any UUID for the DSS connect
> - it does not close the session on disconnect
> - it does not even close the session after MBIM CLOSE
> - the only effect of MBIM OPEN on the DSS session is that the echo is
> turned off
> - all DSS sessions end up as session #0, regardless of the session
> number specified on connect
> - and as a consequence: only one session is supported, not 3 or 5.
>
> If the DSS approach hadn't worked, then any 'unknown' services would
> have been interesting candidates to explore. In this modem there is
> only one, with only 2 CIDs, so we can afford to look at that anyway:
>
> Doing a "get" on CID 1:
>
> 03 00 00 00 30 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 01 00 00 00 00 00 00 00 00 00 00 00
>
> returns:
>
> 03 00 00 80 4c 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 01 00 00 00 09 00 00 00 1c 00 00 00 48 55 41 57 01 00 00 00 02 00 00 00 02 00 00 00 05 00 00 00 04 00 00 00 00 00 00 00
>
> which decodes to "MBIM_STATUS_NO_DEVICE_SUPPORT", but still with an
> interesting data buffer:
> 48 55 41 57 01 00 00 00 02 00 00 00 02 00 00 00 05 00 00 00 04 00 00 00 00 00 00 00
>
> This looks a lot a 32 bit signature followed by a sequence of low 32bit
> little endian integers, which is one of the common MBIM data types. The
> signature is "HUAW" in ascii, so I guess it is safe to assume that this
> is some Huawei specific (debug?) service.
>
> CID 2 returns a similar result, but this time without the error status:
>
> 03 00 00 80 40 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 02 00 00 00 00 00 00 00 10 00 00 00 48 55 41 57 01 00 00 00 00 00 00 00 00 00 00 00
>
> Now, this would not look promising for any AT tunneling service, where
> we are looking for a CID supporting only "set". "get" doesn't make any
> sense. But we can try some combinations just in case:
>
> Trying a "set" on CID 1 with the string "AT\r\n" as data:
>
> 03 00 00 00 34 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 01 00 00 00 01 00 00 00 04 00 00 00 41 54 0d 0a
>
> returns
>
> 03 00 00 80 4c 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 01 00 00 00 1a 00 00 00 1c 00 00 00 48 55 41 57 01 00 00 00 01 00 00 00 02 00 00 00 05 00 00 00 04 00 00 00 00 00 00 00
>
> which decodes to MBIM_STATUS_PARAMETER_TOO_LONG followed by *almost* the
> same buffer as above. Interestingly enough thers is a difference in the
> second number ("1" vs "2"). But this does not look much like an AT
> interface, which most likely would expect a much longer input.
>
> likewise, a CID 2 "set" with the same input returns
>
> 03 00 00 80 40 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 3c 83 a6 ed 80 1e 43 40 98 f0 f8 dc 33 ba a7 cc 02 00 00 00 1a 00 00 00 10 00 00 00 48 55 41 57 01 00 00 00 01 00 00 00 00 00 00 00
>
> which also is MBIM_STATUS_PARAMETER_TOO_LONG followed by the same data
> buffer as the "get" except for a "0" turned into "1"
>
> I hope this gives you some ideas on how you can explore the MBIM
> services on the modem without necessarily having anything to snoop
> on. This is not rocket science :-)
>
> Bjørn
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libmbim-devel
More information about the libmbim-devel
mailing list