# lsusb 
Bus 001 Device 038: ID 04e8:689a Samsung Electronics Co., Ltd LTE Storage Driver [CMC2xx]
Bus 002 Device 002: ID 05ca:18c2 Ricoh Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

The command line for the usb_modswitch would be:

usb_modeswitch -W -v 0x04e8 -p 0x689a -I -M '55534243785634120100000080000601000000000000000000000000000000' 

Here is an output log:

# usb_modeswitch -W -v 0x04e8 -p 0x689a -I -M '55534243785634120100000080000601000000000000000000000000000000' 
Taking all parameters from the command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.2.3 (C) Josua Dietze 2012
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x04e8
DefaultProduct= 0x689a
TargetVendor=   not set
TargetProduct=  not set
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint=  not set
MessageContent="55534243785634120100000080000601000000000000000000000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check disabled
System integration mode disabled

usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 006
usb_os_find_busses: Found 005
usb_os_find_busses: Found 004
usb_os_find_busses: Found 003
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_devices: Found 001 on 006
skipping descriptor 0x30
skipped 1 class/vendor specific endpoint descriptors
usb_os_find_devices: Found 001 on 005
usb_os_find_devices: Found 001 on 004
usb_os_find_devices: Found 001 on 003
usb_os_find_devices: Found 002 on 002
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 18 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 038 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
Looking for default devices ...
  searching devices, found USB ID 1d6b:0003
  searching devices, found USB ID 1d6b:0002
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 05ca:18c2
  searching devices, found USB ID 1d6b:0002
  searching devices, found USB ID 04e8:689a
   found matching vendor ID
   found matching product ID
   adding device
  searching devices, found USB ID 1d6b:0002
 Found device in default mode, class or configuration (1)
Accessing device 038 on bus 001 ...
Getting the current device configuration ...
USB error: error sending control message: Connection timed out
Error getting the current configuration (error -110). Assuming configuration 1.
Using first interface: 0x00
Using endpoints 0x06 (out) and 0x85 (in)

USB description data (for identification)
-------------------------
Manufacturer: not provided
     Product: not provided
  Serial No.: not provided
-------------------------
Looking for active driver ...
 OK, driver found ("usb-storage")
 OK, driver "usb-storage" detached
Setting up communication with interface 0
Using endpoint 0x06 for message sending ...
Trying to send message 1 to endpoint 0x06 ...
 OK, message successfully sent
Resetting response endpoint 0x85
USB error: could not clear/halt ep 133: Connection timed out
 Could not reset endpoint (probably harmless): -110
Resetting message endpoint 0x06
-> Run lsusb to note any changes. Bye.

So after that, a new lsusb would show us:

# lsusb 
Bus 001 Device 040: ID 04e8:6889 Samsung Electronics Co., Ltd GT-B3730 Composite LTE device (Commercial)
Bus 002 Device 002: ID 05ca:18c2 Ricoh Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

In order to have a device descriptor for the stick, we need to modify the linux driver already available.

https://github.com/mkotsbak/linux-2.6/blob/Samsung_kalmia_driver-3.0/drivers/net/usb/kalmia.c

The new file kalmia.c is present HERE
. (Special thx to Xavier Martin for his this)
and I added the Makefile that let me compile it

obj-m += kalmia.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Now 2 new devices are present:

	/dev/ttyUSB0
	/dev/c2xx

Now the /dev/c2xx device will give us all the debug packet, including NAS and RRC, so we could look at them with wireshark.
In order to do that, we need a wireshark dissector that: packet-c2xx.c
As seen on the following picture, the dissector takes a packet that we named c2xx.

This packet is itself composed of a header, a HDLC flag, and a frame.

Packet containing NAS are then visible

Samsung LTE USB dongles codename Kalmia

I acquired a couple of GT-B3740 800Mhz LTE Dongle, and decided to open one of them to find out what the chipset was used in it.

The very surprizing part was to see that it had a JTAG connector there and it was written JTAG !
So after looking for some documentations about it, another interesting thing came. Googling a bit let me find the Service Manual of the device !

Even more surprizing, there was a schematic in there, with the JTAG pinout description!

After some investigation, I found the connector DATASHEET: http://www3.panasonic.biz/ac/e_download/control/connector/base-fpc/catalog/con_eng_f4s.pdf?via=ok It is in fact a PANASONIC AXT512124.

One can find those at Digikey or Mouser.
So THE problem with those connector is the size. In fact, any soldering iron would melt the connector before being able to soler anything to it. So there is no other way than finding the Female connector and extending it. My first attemp was a failure. In fact, I tried to do it with a flex based copper sheet and PNPBlue. here is the result

In fact, the clearance is so low that it could only be done in a factory with a pick and place.
Looking here and there, I found on Alibaba a multiple JTAG cable that looked quite similar.

http://www.aliexpress.com/store/product/JTAG-JPin-JIG-Pinouts-by-RIFF-ORT-JPR-MEDUSA-BOX/927318_922669231.html

So I decided to buy one to give it a test. The thing is that you have to buy the whole set. At the time I’m writing, it’s price was $68.

As one can see, the result is shown here under

The interesting part about this cable is that the little adapter they give respects the JTAG pinout standard of the ARM, therefor, I could easily connect it with a Board to Board connector to a Amontek Jtag-Mini. So it was time to play with OpenOCD !
Here is the configuration file used.

telnet_port 4444
#gdb_port 0
#tcl_port 0

jtag_khz    100000000
adapter_khz 100000000
#jtag_speed 3

reset_config trst_and_srst

jtag_nsrst_delay 400
jtag_ntrst_delay 400

if { [info exists CHIPNAME] } {
  set _CHIPNAME $CHIPNAME
} else {
  set _CHIPNAME cmc220
}

#reset_config none

if { [info exists CPU_TAPID ] } {
  set _CPU_TAPID $CPU_TAPID
} else {
  set _CPU_TAPID 0x4ba00477
}
jtag newtap $_CHIPNAME tap -irlen 4 -ircapture 0x1 -irmask 0x3 -expected-id $_CPU_TAPID

set _TARGETNAME $_CHIPNAME

target create $_TARGETNAME cortex_r4 -endian little -chain-position $_TARGETNAME.tap

So I managed to dump the Memory of the chip. And I got the firmware extracted. A couple of strings on the file shows that the file is REALLY verbose. All the debug symbols are there. All the printf are still there… It’s time to play with IDA pro !
One interesting part is that I was able to tell IDA pro that the GDB Server is in fact OpenOCD. so IDA pro would go into debug mode and be able to step in the running code. Most of the time that would generate an interrupt tho. But that is quite good enough with some scripting to see what part of the Firmware is Code segment or Datasegment..

And as said earlyer, the amount of Strings debug is really big. Worth digging into it.

In the meantime, I decided to get myself some GT-B3730 that does the 2.6Ghz LTE band as well as 2.75G and 3G. Hoping that they are similar.

So Opening it showed me that it’s based on the same chip, which is connected to another chip in charge of the 2/3 G.

2 different Firmware are written in this one. mode A and B. A is LTE, B = 2/3 G. Therefor, in order to switch, it needs to reboot on its new firmware.