Huawei MBIM tool
Bjørn Mork
bjorn at mork.no
Thu Mar 12 05:06:06 PDT 2015
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
More information about the libmbim-devel
mailing list