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.

P1 Telecom Monitor (PTM) is an Intrusion Detection System (IDS) specifically designed for SS7 and SIGTRAN networks. It is composed of a realtime detection framework and a reporting and monitoring user interface. PTM’s design allows it to be easily scaled from a single network tap to large-scale deployments throughout the network to be protected. The network traffic is filtered and processed in a decentralized manner while alerts are collected in a central datastore.

PTM offers a realtime extensible monitoring framework for time-correlated network events.

The PTM detection framework’s modular design allows us to quickly adapt and extend it to new attack types. Detectors are implemented as independent modules exposing a simple callback interface invoked by the detector framework upon interception of new traffic.

Attacks can often not be discerned from normal traffic by analyzing single packets, PTM also allows time-correlated events to be detected.

We believe that even the best IDS will be of little value if the detected events are not quickly translated into alerts and a response from the operations team. This is why PTM also offers a comprehensive web-based monitoring interface. On the one hand, a simple dashboard allows the engineer to gain a quick overview of the current status of the network and the most important threats. Aggregate statistics and real-time charts expose network activity and top attacks. On the other hand, detailed tabular reports allow the operator to understand and reconstruct events precisely and to react in the most appropriate fashion.

PTM’s user interface offers both a simple event dashboard showing the current network status and highlighting current events, as well as a detailed tabular event report. A sample report generated from real anonymized data can be viewed here.

The combination of a scalable realtime traffic monitor, an extensible event-detector framework and simple yet powerful interface position P1 Telecom Monitor at the forefront of intrusion detection systems in the telecommunications sector.

Primary usage of wireshark is to visualize packets coming from traditional IP traffic, that is why default wireshark settings provides a relatively good overview of IP packets for most of the use cases.

The problem is that this configuration is not at all suitable for specific needs of Telecom traffic analysis, and does not give you a quick vision when you are working on an SS7 Pcap.

Here is an example of SS7 traffic using default wireshark settings:

(click on image to enlarge)

With default wireshark configuration:

• You cannot see the interesting addresses in packet list view due to different addressing in SS7 and multiple layers involved.
• You see only one color for all different SS7 traffic types, because wireshark pre-configures coloring only for standard protocols.

Why SS7 traffic is more complex to analyze

First, SS7 Addressing is more complex than IP :
Instead of only IP + port tuples to represent endpoints of IP communication, in SS7 you use Global Titles (GT), Point Codes (PC or SPC) and Sub-System Numbers (SSN), that can be used as follow:

• Global Title (GT)
• Global Title + Sub-System Number (GT + SSN)
• Point Code (PC)
• Point Code + Sub-System Number (PC + SSN)
• Sub-System Number (SSN)

Secondly, their are much more network layers involved in Telecom traffic than on usual IP only traffic. On typical SS7 traffic you face in order:

• Ethernet
• Multiprotocol Label Switching (MPLS)
• Internet Protocol (IP)
• Stream Control Transmission Protocol (SCTP)
• MTP Level 3 (MTP3) User Adaptation Layer (M3UA)
• Signalling Connection Control Part (SCCP)
• Transaction Capabilities Application Part (TCAP)
• Mobile Application Part (MAP)

Each of these layer contains more parameters compared to IP.

Besides, many small packet flags are critically important, such as M3UA Network Indicator (Coded on 1 Byte, it represents the type of SS7 link : Internal, National or International).

Customize your wireshark

Customize Wireshark columns

You can customize the display columns of Wireshark to show GT and SSN in the packet list view, and do this in a separate profile to have different views on your packet depending of your activity.

(click on image to enlarge)

How to configure column display (wireshark >= 1.8.0)

1. Create a new profile : Go to “Edit > Configuration Profiles”, click on Add and call it “SS7″.
2. Add a column: Right click on the packet list view column titles and go in “Column Preferences”. In this window, click on “Add” to add a column, and set it’s name by clicking on it in the columns list.
3. Set the field type in the “Field Type” of your new column, select “Custom”. Now you can enter your wireshark expression in “Field Name”, for example sccp.calling.digits or sccp.called.ssn.
4. Click on “Apply”: you will have your new column in your Wireshark packet list view.

NOTE: This can be generalized to any Wireshark expression, so you can display any data you want from the pcap in the columns view.

(click on image to enlarge)

Exporting / Importing columns setting

The following file stores the configuration for your Wireshark profile:

/home/user/.wireshark./profiles/SS7/preferences

Example:

[...]
# Packet list column format.
# Each pair of strings consists of a column title and its format.
gui.column.format:
	"No.", "%m",
	"Time", "%t",
	"cgGT", "%Cus:sccp.calling.digits:0:R",
	"cgSSN", "%Cus:sccp.calling.ssn:0:R",
	"cdGT", "%Cus:sccp.called.digits:0:R",
	"cdSSN", "%Cus:sccp.called.ssn:0:R",
	"Protocol", "%p",
	"Length", "%L",
	"Info", "%i"
[...]

Customize Wireshark coloring rules

To get a better overview of the SS7 traffic and identify types of messages just by looking quickly at them, you can customize wireshark coloring rules. Each rule is defined by one filter (using the same syntax as usual wireshark display filters), and a set of 2 colors (foreground and background colors).

Here is an overview of 4 basic coloring rules applied on typical SS7 traffic:

(click on image to enlarge)

On the above screenshot, MAP layer is identified by yellow or green background color, whether the message is a MAP invoke (request) or MAP returnResultLast (answer).TCAP Abort (cancellation of TCAP dialog due to error) has a pink background, and TCAP Begin (initialization of TCAP dialog) has a light blue background (Not visible on the screenshot).

How to configure coloring rules (wireshark >= 1.8.0)

1. Go to “View > Coloring Rules”.
2. Click on “New” to add a new rule.
3. Enter a wireshark display filter in “String:” text box. For example, to match MAP invoke messages you can use the filter “gsm_map.old.Component == 1″.
4. Choose one foreground and one background color for this filter, then click “OK”

NOTE: coloring rules will be tried in order until one filter matches, top filter having the highest priority.

(click on image to enlarge)

Exporting / Importing coloring rules

1. Go to “View > Coloring Rules”.
2. Optional: select one or more filtering rules to export by clicking on them. (Ctrl + Click to select multiple filters).
3. Click on “Export”.
4. Choose an output filename and optionally check the box “Export only selected filters”.

You will get a file like this one:

# DO NOT EDIT THIS FILE!  It was created by Wireshark
@MAP ReturnResultLast@gsm_map.old.Component == 2@[61023,65535,29648][0,0,0]
@MAP Invoke@gsm_map.old.Component == 1@[37006,53439,22070][0,0,0]
@TCAP abort@tcap.abort@[65535,52907,60113][0,0,0]
@TCAP begin@tcap.begin@[36382,59634,65535][0,0,0]

This file can then be used to import coloring rules on another host.

That’s it ! Don’t hesitate to comment with you’re own Wireshark tricks.

In a future blogpost, we’ll see how to use Wireshark to edit a PCAP, in order to forge packets or anonimize a PCAP file.