Category Archives: Software

OTP Authentication required to unlock IMS Debugging and TCPDUMP on Samsung Sysdump tool

Reverse Engineering Samsung Sysdump Utils to Unlock IMS Debug & TCPdump on Samsung Phones

Note: This post is just about the how I reverse engineered the tool, for info on how to use it, you want this post.

While poking around the development and debugging features on Samsung handsets I found the ability to run IMS Debugging directly from the handset.

Alas, the option is only available in the commercial version, it’s just there for carriers, and requires a One Time Password to unlock.

OTP Authentication required to unlock IMS Debugging and TCPDUMP on Samsung Sysdump tool "This menu is not allowed for commercial version. You can activate this menu after OTP Authentication enabled"

When tapping on the option a challenge is generated with a key.

Interestingly I noticed that the key changes each time and can reject you even in aeroplane mode, suggesting the authentication happens client side.

This left me thinking – If the authentication happens client side, then the App has to know what the valid password for the key shown is…

Some research revealed you can pull APKs off an Android phone, so I downloaded a utility called “APK Extractor” from the Play store, and used it to extract the Samsung Sysdump utility.

So now I was armed with the APK on my local machine, the next step was to see if I could decompile the APK back into source code.

Some Googling found me an online APK decompiler, which I fed the compiled APK file and got back the source code.

I did some poking around inside the source code, and then I found an interesting directory:

Here’s a screenshot of the vanilla code that came out of the app.

Samsung OTPSecurty Source Code

I’m not a Java expert, but even I could see the “CheckOTP” function and understand that that’s what validates the One Time Passwords.

The while loop threw me a little – until I read through the rest of the code; the “key” in the popup box is actually a text string representing the current UNIX timestamp down to the minute level. The correct password is an operation done on the “key”, however the CheckOTP function doesn’t know the challenge key, but has the current time, so generates a challenge key for each timestamp back a few minutes and a few minutes into the future.

I modified the code slightly to allow me to enter the presented “key” and get the correct password back. It’s worth noting you need to act quickly, enter the “key” and enter the response within a minute or so.

In the end I’ve posted the code on an online Java compiler,

Generate OTP Response from Key (Challenge)

Replace yy182 with your challenge. I suggest you try the 0 offset and type it in quickly.

I did a write up on how to use the features this unlocks in this post.

If you’re leaning about VoLTE & IMS networks, or building your own, I’d suggest checking out my other posts on the topic.

Samsung-Sysdump-IMS-Debug-DM-View_Cropped

VoLTE/IMS Debugging on Samsung Handsets using Sysdump & Samsung IMS Logger

Samsung handsets have a feature built in to allow debugging from the handset, called Sysdump.

Entering *#9900# from the Dialing Screen will bring up the Sysdump App, from here you can dump logs from the device, and run a variety of debugging procedures.

Samsung share information about this app publicly on their website,

Sysdump App in Samsung handsets used for debugging the device

But for private LTE operators, the two most interesting options are by far the TCPDUMP START option and IMS Logger, but both are grayed out.

Tapping on them asks for a one-time password and has a challenge key.

OTP Authentication required to unlock IMS Debugging and TCPDUMP on Samsung Sysdump tool

These options are not available in the commercial version of the OS and need to be unlocked with a one time key generated by a tool Samsung for unlocking engineering firmware on handsets.

Luckily this authentication happens client side, which means we can work out the password it’s expecting.

For those interested I’ve done a write up of how I reversed the password validation algorithm to take the key given in the OTP challenge and generate a valid response.

For those who just want to unlock these features you can click here to run the tool that generates the response.

Once you’ve entered the code and successfully unlocked the IMS Debugging tool there’s a few really cool features in the hamburger menu in the top right.

DM View

This shows the SIP / IMS Messaging and the current signal strength parameters (used to determine which RAN type to use (Ie falling back from VoLTE to UMTS / Circuit Switched when the LTE signal strength drops).

Screenshot of Samsung Sysdump tool in the IMS Debug - DM View section

Tapping on the SIP messages expands them and allows you to see the contents of the SIP messages.

Viewing SIP Messaging directly from the handset

Interesting the actual nitty-gritty parameters in the SIP headers are missing, replaced with X for anything “private” or identifiable.

Luckily all this info can be found in the Pcap.

The DM View is great for getting a quick look at what’s going on, on the mobile device itself, without needing a PC.

Logging

The real power comes in the logging functions,

There’s a lot of logging options, including screen recording, TCPdump (as in Packet Captures) and Syslog logging.

From the hamburger menu we can select the logging parameters we want to change.

Settings for Samsung IMS Logger

From the Filter Options menu we can set what info we’re going to log,

Filter options used in Dump output of Samsung IMS Logger application

If you’re leaning about VoLTE & IMS networks, or building your own, I’d suggest checking out my other posts on the topic.

PLMN Identity from Wireshark in Hex Form

PLMN Identifier Calculation (MCC & MNC to PLMN)

Note: This didn’t handle 3 digit MNCs, an updated version is available here and in the code sample below.

The PLMN Identifier is used to identify the radio networks in use, it’s made up of the MCC – Mobile Country Code and MNC – Mobile Network Code.

But sadly it’s not as simple as just concatenating MCC and MNC like in the IMSI, there’s a bit more to it.

In the example above the Tracking Area Identity includes the PLMN Identity, and Wireshark has been kind enough to split it out into MCC and MNC, but how does it get that from the value 12f410?

This one took me longer to work out than I’d like to admit, and saw me looking through the GSM spec, but here goes:

PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding: according to TS GSM 04.08 [14].

If storage for fewer than the maximum possible number n is required, the excess bytes shall be set to ‘FF’. For instance, using 246 for the MCC and 81 for the MNC and if this is the first and only PLMN, the contents reads as follows: Bytes 1-3: ’42’ ‘F6′ ’18’ Bytes 4-6: ‘FF’ ‘FF’ ‘FF’ etc.

TS GSM 04.08 [14].

Making sense to you now? Me neither.

Here’s the Python code I wrote to encode MCC and MNCs to PLMN Identifiers and to decode PLMN into MCC and MNC, and then we’ll talk about what’s happening:

def Reverse(str):
    stringlength=len(str)
    slicedString=str[stringlength::-1]
    return (slicedString)    

def DecodePLMN(plmn):
    print("Decoding PLMN: " + str(plmn))
    
    if "f" in plmn:
        mcc = Reverse(plmn[0:2]) + Reverse(plmn[2:4]).replace('f', '')
        print("Decoded MCC: " + str(mcc))
        mnc = Reverse(plmn[4:6])
    else:
        mcc = Reverse(plmn[0:2]) + Reverse(plmn[2:4][1])
        print("Decoded MCC: " + str(mcc))
        mnc = Reverse(plmn[4:6]) + str(Reverse(plmn[2:4][0]))
    print("Decoded MNC: " + str(mnc))
    return mcc, mnc

def EncodePLMN(mcc, mnc):
        plmn = list('XXXXXX')
        if len(mnc) == 2:
            plmn[0] = Reverse(mcc)[1]
            plmn[1] = Reverse(mcc)[2]
            plmn[2] = "f"
            plmn[3] = Reverse(mcc)[0]
            plmn[4] = Reverse(mnc)[0]
            plmn[5] = Reverse(mnc)[1]
            plmn_list = plmn
            plmn = ''
        else:
            plmn[0] = Reverse(mcc)[1]
            plmn[1] = Reverse(mcc)[2]
            plmn[2] = Reverse(mnc)[0]
            plmn[3] = Reverse(mcc)[0]
            plmn[4] = Reverse(mnc)[1]
            plmn[5] = Reverse(mnc)[2]
            plmn_list = plmn
            plmn = ''
        for bits in plmn_list:
            plmn = plmn + bits
        print("Encoded PLMN: " + str(plmn))
        return plmn

EncodePLMN('505', '93')
EncodePLMN('310', '410')

DecodePLMN("05f539")
DecodePLMN("130014")

In the above example I take MCC 505 (Australia) and MCC 93 and generate the PLMN ID 05f539.

The first step in decoding is to take the first two bits (in our case 05 and reverse them – 50, then we take the third and fourth bits (f5) and reverse them too, and strip the letter f, now we have just 5. We join that with what we had earlier and there’s our MCC – 505.

Next we get our MNC, for this we take bytes 5 & 6 (39) and reverse them, and there’s our MNC – 93.

Together we’ve got MCC 505 and MNC 93.

The one answer I’m still looking for; why not just encode 50593? What is gained by encoding it as 05f539?

PyHSS Update – MongoDB Backend & SQN Resync

After a few quiet months I’m excited to say I’ve pushed through some improvements recently to PyHSS and it’s growing into a more usable HSS platform.

MongoDB Backend

This has a few obvious advantages – More salable, etc, but also opens up the ability to customize more of the subscriber parameters, like GBR bearers, etc, that simple flat text files just wouldn’t support, as well as the obvious issues with threading and writing to and from text files at scale.

Knock knock.

Race condition.

Who’s there?

— Threading Joke.

For now I’m using the Open5GS MongoDB schema, so the Open5Gs web UI can be used for administering the system and adding subscribers.

The CSV / text file backend is still there and still works, the MongoDB backend is only used if you enable it in the YAML file.

The documentation for setting this up is in the readme.

SQN Resync

If you’re working across multiple different HSS’ or perhaps messing with some crypto stuff on your USIM, there’s a chance you’ll get the SQN (The Sequence Number) on the USIM out of sync with what’s on the HSS.

This manifests itself as an Update Location Request being sent from the UE in response to an Authentication Information Answer and coming back with a Re-Syncronization-Info AVP in the Authentication Info AVP. I’ll talk more about how this works in another post, but in short PyHSS now looks at this value and uses it combined with the original RAND value sent in the Authentication Information Answer, to find the correct SQN value and update whichever database backend you’re using accordingly, and then send another Authentication Information Answer with authentication vectors with the correct SQN.

SQN Resync is something that’s really cryptographically difficult to implement / confusing, hence this taking so long.

What’s next? – IMS / Multimedia Auth

The next feature that’s coming soon is the Multimedia Authentication Request / Answer to allow CSCFs to query for IMS Registration and manage the Cx and Dx interfaces.

Code for this is already in place but failing some tests, not sure if that’s to do with the MAA response or something on my CSCFs,

Keep an eye on the GitLab repo!

Making use of Australian Elevation Data in Forsk Atoll

The Australian Government publishes elevation data online that’s freely available for anyone to use. There’s a catch – If you’re using Forsk Atoll, it won’t import without a fair bit of monkeying around with the data…

The data is published on a a system called ELVIS – Elevation – Foundation Spatial Data.

You draw around the area you want to download, enter your email address and you’re linked to a download of the dataset you’ve selected.

So now we download the data from the link, unzip it and we’re provided with a .tiff image with the elevation data in the pixel colour and geocoded with the positional information.

Problem is, this won’t import into Atoll – Unsupported depth.

Forsk Atoll - Unsupported Depth when importing

I found a tool called VTBuilder – A tool for messing with terrain data.

I fired it up, and imported the elevation tiff file we’d downloaded.

Selected “Elevation” waited a few seconds and presto!

We can export from here in the PNG 16 bit grayscale format Atoll takes, but there’s a catch, negative elevation values and blank data will show up as giant spikes which will totally mess with your propagation modeling.

So I found an option to remove elevation data from a set range, but it won’t deal with negative values…

So I found another option in the elevation menu to offset elevation vertically, I added 100 ft (It’s all in ft for some reason) to everything which meant my elevation data that was previously negative was now just under 100.

So if an area was -1ft before it was now 99ft.

Now I was able to use the remove range for anything from 0 100 ft (previously sea level)

Now my map only shows data above sea level

Now I offset the elevation vertically again and remove 100ft so we get back to real values

Now I was able to export the elevation data from the Elevation -> Export to menu

Atoll seems to like PNG 16 bit greyscale so that’s what we’ll feed it.

In Atoll we’ll select File -> Import and open the PNG we just generated.

Data type will be Altitude, Pixel size is 5m (as denoted in email / dataset metadata).

Next question is offset, which took me a while to work out…

The email has the Lat & Long but Atoll deals in WGS co-ordinates,

Luckily the GeoPlanner website allows you to enter the lat & long of the top corner and get the equivalent West and North values for the UTM dataum.

Enter these values as your coordinates and you’re sorted.

I can even able a Map layer and confirm it lines up:

Open5Gs Logo

Open5GS – Splitting Network Elements

Note: NextEPC the Open Source project rebranded as Open5Gs in 2019 due to a naming issue. The remaining software called NextEPC is a branch of an old version of Open5Gs. This post was written before the rebranding.

I’ve been working for some time on Private LTE networks, and wrote my own HSS (See PyHSS – Python Home Subscriber Server).

The packet core I’m using is NextEPC, it’s well written, flexible and well supported.

I joined the Open5Gs group and I’ve contributed a few bits and pieces to the project.

One of which was how to split all the network elements in NextEPC:

NextEPC Splitting Network Elements

In a production network network elements would typically not all be on the same machine, as is the default example that ships with NextEPC.

NextEPC is designed to be standards compliant, so in theory you can connect any core network element (MME, PGW, SGW, PCRF, HSS) from NextEPC or any other vendor to form a functioning network, so long as they are 3GPP compliant.

To demonstrate this we will cover isolating each network element onto it’s on machine and connect each network element to the other. For some interfaces specifying multiple interfaces is supported to allow connection to multiple

In these examples we’ll be connecting NextEPC elements together, but it could just as easily be EPC elements from a different vendor in the place of any NextEPC network element.

ServiceIPIdentity
P-GW10.0.1.121pgw.localdomain
S-GW10.0.1.122 
PCRF10.0.1.123pcrf.localdomain
MME10.0.1.124mme.localdomain
HSS10.0.1.118hss.localdomain

External P-GW

In it’s simplest from the P-GW has 3 interfaces:

  • S5 – Connection to home network S-GW (GTP-C)
  • Gx – Connection to PCRF (Diameter)
  • Sgi – Connection to external network (Generally the Internet via standard TCP/IP)

S5 Interface Configuration

Edit /etc/nextepc/pgw.confand change the address to IP of the server running the P-GW for the listener on GTP-C and GTP-U interfaces.

pgw:
    freeDiameter: pgw.conf
    gtpc: 
      addr:
        - 10.0.1.121
     gtpu: 
      addr:
        - 10.0.1.121

Gx Interface Configuration

Edit /etc/nextepc/freeDiameter/pgwd.conf

Update ListenOn address to IP of the server running the P-GW:

ListenOn = "10.0.1.121";

Update ConnectPeer to connect to the PCRF on it’s IP.

ConnectPeer = "pcrf.localdomain" { ConnectTo = "10.0.1.123"; No_TLS; };

Restart Services

Restart NextEPC PGW Daemon:

$ sudo systemctl restart nextepc-pgwd

External S-GW

In it’s simplest form the S-GW has 2 interfaces:

  • S11 – Connection to MME (GTP-C)
  • S5 – Connection to the home network P-GW (GTP-C)

S5 Interface Configuration

Edit /etc/nextepc/sgw.confand change the address to IP of the server running the S-GW for the listener on GTP-C interface.

sgw:
    freeDiameter: pgw.conf
    gtpc: 
      addr:
        - 10.0.1.122

Restart NextEPC SGW Daemon:

$ sudo systemctl restart nextepc-sgwd

External PCRF

In it’s simplest from the PCRF has 1 network interface:

  • Gx – Connection to P-GW (Diameter)

Gx Interface Configuration

Edit /etc/nextepc/freeDiameter/hss.conf

Update ListenOn address to IP of the server running the HSS on it’s IP:

ListenOn = "10.0.1.123";

Update ConnectPeer to connect to the MME.

ConnectPeer = "pgw.localdomain" { ConnectTo = "10.0.1.121"; No_TLS; };

MongoDB Interface Configuration (NextEPC HSS only)

Edit /etc/nextepc/freeDiameter/hss.conf and change the db_uri: to point at the HSS: db_uri: mongodb://10.0.1.118/nextepc

Restart NextEPC PCRF Daemon:

$ sudo systemctl restart nextepc-pcrfd

External HSS

In it’s simplest form the HSS has 1 network interface:

  • S6a – Connection to MME (Diameter)

S6a Interface Configuration

Edit /etc/nextepc/freeDiameter/hss.conf

Update ListenOn address to IP of the server running the HSS on it’s IP:

ListenOn = "10.0.1.118";

Update ConnectPeer to connect to the MME.

ConnectPeer = "mme.localdomain" { ConnectTo = "10.0.1.124"; No_TLS; };

Restart NextEPC HSS Daemon:

$ sudo systemctl restart nextepc-hssd

MongoDB Interface Configuration (NextEPC specific)

If you are using NextEPC’s HSS you may need to enable MongoDB access from the PCRF. This is done by editing ‘‘/etc/mongodb.conf’’ and changing the bind IP to: bind_ip = 0.0.0.0

Restart MongoDB for changes to take effect.

$ /etc/init.d/mongodb restart

External MME

In it’s simplest form the MME has 3 interfaces:

  • S1AP – Connections from eNodeBs
  • S6a – Connection to HSS (Diameter)
  • S11 – Connection to S-GW (GTP-C)

S11 Interface Configuration

Edit /etc/nextepc/mme.conf, filling the IP address of the S-GW and P-GW servers.

sgw:
    gtpc:
      addr: 10.0.1.122

pgw:
    gtpc:
      addr:
        - 10.0.1.121

S6a Interface Configuration

Edit /etc/nextepc/freeDiameter/mme.conf

Update ListenOn address to IP of the server running the MME:

ListenOn = "10.0.1.124";

Update ConnectPeer to connect to the PCRF on it’s IP.

ConnectPeer = "hss.localdomain" { ConnectTo = "10.0.1.118"; No_TLS; };

Restart Services

Restart NextEPC MME Daemon:

$ sudo systemctl restart nextepc-mmed

Building Android APN / Carrier Config

As anyone who’s setup a private LTE network can generally attest, APNs can be a real headache.

SIM/USIM cards, don’t store any APN details. In this past you may remember having to plug all these settings into your new phone when you upgraded so you could get online again.

Today when you insert a USIM belonging to a commercial operator, you generally don’t need to put APN settings in, this is because Android OS has its own index of APNs. When the USIM is inserted into the baseband module, the handset’s OS looks at the MCC & MNC in the IMSI and gets the APN settings automatically from Android’s database of APN details.

There is an option for the network to send the connectivity details to the UE in a special type of SMS, but we won’t go into that.

All this info is stored on the Android OS in apns-full-conf.xml which for non-rooted (stock) devices is not editable.

Instead the devices get updates through the OS updates which pull the latest copy of this file from Google’s Android Open Source Git repo, you can view the current master file here.

This file can override the user’s APN configuration, which can lead to some really confusing times as your EPC rejects the connection due to an unrecognized APN which is not what you have configured on the UE’s operating system, but it instead uses APN details from it’s database.

The only way around this is to change the apns-full-conf.xml file, either by modifying it per handset or submitting a push request to Android Open Source with your updated settings.

(I’ve only tried the former with rooted devices)

The XML file itself is fairly self explanatory, taking the MCC and MNC and the APN details for your network:

<apn carrier="CarrierXYZ"
      mcc="123"
      mnc="123"
      apn="carrierxyz"
      type="default,supl,mms,ims,cbs"
      mmsc="http://mms.carrierxyz.com"
      mmsproxy="0.0.0.0"
      mmsport="80"
      bearer_bitmask="4|5|6|7|8|12"
/>

Once you’ve added yours to the file, inserting the USIM, rebooting the handset or restarting the carrier app is all that’s required for it to be re-read and auto provision APN settings from the XML file.

Further reading

APN and CarrierConfig | Android Open Source Project

Carrier Configuration | Android Open Source Project

UICC Carrier Privileges | Android Open Source Project

/etc/apns-full-conf.xml – Master Branch

Kamailio Bytes – Geoip2

GeoIP2 allows simple Geo IP location parsing using mmdb files, to allow us to map IP addresses to geographic locations in standardized format.

Getting the GeoIP Data

MaxMind provide GeoIP2 formatted data ready for use, albeit with limited accuracy.

We need to download them from MaxMind and extract them for use, so let’s download the file:

#> wget https://geolite.maxmind.com/download/geoip/database/GeoLite2-City.tar.gz

Next we’ll extract the data:

#> tar -xzvf GeoLite2-City.tar.gz

Next we’ll add the below to our Kamailio config (replace the path to the GeoLite2-City.mmdb to your directory).

loadmodule "geoip2.so"
modparam("geoip2", "path", "/home/ubuntu/GeoLite2-City_20190709/GeoLite2-City.mmdb");

If you’re planning on using this in production you probably want to automate the pulling of this data on a regular basis and keep it in a different directory.

I’ve made a very simple example Kamailio config that shows off some of the features of GeoIP2’s logic and what can be shown, so let’s look at the basics of the module:

if(geoip2_match("$si", "src")){
                xlog("Packet received from IP $si");
                xlog("Country is: $gip2(src=>cc)\n");
}

If we put this at the top of our request_route block every time we recieve a new request we can see the country from which the packet came from.

Let’s take a look at the output of syslog (with my IP removed):

#> tail -f /var/log/syslog
ERROR: <script>: Packet received from IP 203.###.###.###
ERROR: <script>: Country is: AU
ERROR: <script>: City is:  Melbourne
ERROR: <script>: ZIP is:  3004
ERROR: <script>: Regc is:  VIC
ERROR: <script>: Regn is:  Victoria
ERROR: <script>: Metro Code is:  <null>

We can add a bunch more smarts to this and get back a bunch more variables, including city, ZIP code, Lat & Long (Approx), timezone, etc.

        if(geoip2_match("$si", "src")){
                xlog("Packet received from IP $si");
                xlog("Country is: $gip2(src=>cc)\n");
                xlog("City is:  $gip2(src=>city)");
                xlog("ZIP is:  $gip2(src=>zip)");
                xlog("Regc is:  $gip2(src=>regc)");
                xlog("Regn is:  $gip2(src=>regn)");
                xlog("Metro Code is:  $gip2(src=>metro)");

                if($gip2(src=>cc)=="AU"){
                        xlog("Traffic is from Australia");
                }
        }else{
                xlog("No GeoIP Match for  $si");
        }
#> tail -f /var/log/syslog
ERROR: <script>: Packet received from IP ###.###.###.###
ERROR: <script>: Country is: AU
ERROR: <script>: City is:  Melbourne
ERROR: <script>: ZIP is:  3004
ERROR: <script>: Regc is:  VIC
ERROR: <script>: Regn is:  Victoria
ERROR: <script>: Metro Code is:  <null>

Using GeoIP2 you could use different rate limits for domestic users vs overseas users, guess the dialling rules based on the location of the caller and generate alerts if accounts are used outside their standard areas.

We’ll touch upon this again in our next post on RTPengine where we’ll use an RTPengine closes to the area in which the traffic originates.

Full example config on GitHub here.

RF Planning with Forsk Atoll - Importing environmental data

Forsk Atoll – WMS Map Tiles

A hack I found useful to add Google Maps / Google Satelite View / Bing Maps / Bing Arial / Open Street Maps in Forsk Atoll.

Close Atoll,

Go to C -> Program Files -> Atoll

Edit the file named atoll.ini

Paste the following into it:

[OnlineMaps]
Name1 = OpenStreetMap Standard Map
URL1 = http://a.tile.openstreetmap.org/%z/%x/%y.png
Name2 = MapQuest Open Aerial
URL2 = http://otile1.mqcdn.com/tiles/1.0.0/sat/%z/%x/%y.jpg
Name3 = 2Gis
URL3 = http://static.maps.api.2gis.ru/1.0?c...z&size=256,256
Name4 = 2Gis without logo
URL4 = http://tile2.maps.2gis.com/tiles?x=%x&y=%y&z=%z&v=37 
Name5 = Bing Aerial
URL5 = http://ecn.t3.tiles.virtualearth.net.../a%q.jpg?g=392
Name6 = Bing Hybrid
URL6 = http://ecn.t3.tiles.virtualearth.net.../h%q.jpg?g=392
Name7 = Bing Road
URL7 = http://ecn.t3.tiles.virtualearth.net.../r%q.jpg?g=392
Name8 = Yandex Road
URL8 = http://static-maps.yandex.ru/1.x/?ll...=%z&l=map&key=
Name9 = Yandex Aerial
URL9 = http://static-maps.yandex.ru/1.x/?ll...=%z&l=sat&key=
Name10 = Yandex Hybrid
URL10 = http://static-maps.yandex.ru/1.x/?ll...l=sat,skl&key=
Name11 = ArcGIS
URL11 = http://services.arcgisonline.com/Arc...e/%z/%y/%x.png
Name12 = opencyclemap
URL12 = http://tile.opencyclemap.org/cycle/%z/%x/%y.png
Name13 = Google Terrain
URL13 = http://mt.google.com/vt/lyrs=t&hl=en&x=%x&y=%y&z=%z
Name14 = Google Map
URL14 = http://mt.google.com/vt/lyrs=m&hl=en&x=%x&y=%y&z=%z
Name15 = Google Hybrid (Map + Terrain)
URL15 = http://mt.google.com/vt/lyrs=p&hl=en&x=%x&y=%y&z=%z
Name16 = Google Hybrid (Map + Satellite)
URL16 = http://mt.google.com/vt/lyrs=y&hl=en&x=%x&y=%y&z=%z
Name17 = Google Satellite
URL17 = http://mt.google.com/vt/lyrs=m&hl=en&x=%x&y=%y&z=%z
Name18 = Google Scheme
URL18 = http://mt.google.com/vt/lyrs=h&hl=en&x=%x&y=%y&z=%z
Name19 = Google Scheme2 
URL19 = http://mt.google.com/vt/lyrs=r&hl=en&x=%x&y=%y&z=%z

Save and open Atoll,

Open the Geo Tab,

Right click on Online Maps, click “New”

Select the map source (In this example I’m using OSM) & hit Ok.

Enable the Online Map layer by ticking the layer.

Bam, done.

RF Planning with Forsk Atoll - Laying out environmental data

Magma – Facebook’s Open Source LTE / 4G EPC/OSS Platform

In February Facebook announced they’d open sourced their Magma project,

Magma provides a software-centric distributed mobile packet core and tools for automating network management.

Open-sourcing Magma to extend mobile networks

Magma’s modular software based architecture means you can scale up extra resources as needed, with no need to have physical hardware to run your EPC.

(Cisco’s Ultra Packet Core does have a virtualisation option, but it’s not cheap)

I got pretty excited by this, so I’ve ordered myself an eNodeB (Just a Picocell), a pile of USIMs, programmer and started installing an environment.

In the past I’ve used srsEPC and NextEPC and software-defined radio hardware (BladeRF) to run LTE stuff, so I’m looking forward to seeing if I can implement parts of them into Magma, and also eventually use Kamailio’s IMS modules to implement an IMS core and run VoLTE.

So let’s install Magma, explore it and lurk on the Discord, all while we kill time waiting for hardware to arrive!

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm

All About IMS Authentication (AKAv1-MD5) in VoLTE Networks

I recently began integrating IMS Authentication functions into PyHSS, and thought I’d share my notes / research into the authentication used by IMS networks & served by a IMS capable HSS.

There’s very little useful info online on AKAv1-MD5 algorithm, but it’s actually fairly simple to understand.

RFC 2617 introduces two authentication methods for HTTP, one is Plain Text and is as it sounds – the password sent over the wire, the other is using Digest scheme authentication. This is the authentication used in standard SIP MD5 auth which I covered ages back in this post.

Authentication and Key Agreement (AKA) is a method for authentication and key distribution in a EUTRAN network. AKA is challenge-response based using symmetric cryptography. AKA runs on the ISIM function of a USIM card.

I’ve covered the AKA process in my post on USIM/HSS authentication.

The Nonce field is the Base64 encoded version of the RAND value and concatenated with the AUTN token from our AKA response. (Often called the Authentication Vectors).

That’s it!

It’s put in the SIP 401 response by the S-CSCF and sent to the UE. (Note, the Cyperhing Key & Integrity Keys are removed by the P-CSCF and used for IPsec SA establishment.

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm
Click for Full Size version of this image