Huawei MBIM tool
Markus Gothe
nietzsche at lysator.liu.se
Fri Mar 13 15:07:01 PDT 2015
A pity it did not work :-(
I should try the "unkown" method during the weekend.
//M
Den 12 mar 2015 21:45 skrev Markus Gothe <nietzsche at lysator.liu.se>:
>
> 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
> _______________________________________________
> 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