Forensics Analysis of goTenna

gotenna-banner

Intro

Two prominent conversations still exist as important considerations in the digital age: the privacy of personal information and the geographical limitations of certain commercial cell networks. This is where goTenna comes in: goTenna is an “off-the-grid” communications tool which interfaces with mobile devices via Bluetooth. GoTenna devices are able to create private cell networks and enable geolocation sharing through radio waves and relays from other nearby devices. The traffic is not stored anywhere and is transmitted using end-to-end encryption with 384-bit asymmetric key ciphering. These encryption methods are used in both private group messages and one-to-one exchanges, but other features like the Emergency option or Shouting – which sends a public conversation out to anyone connected to a goTenna network within range of the sender’s device – do not utilize it.

With a device like this now in public circulation, we must now assess the claims made by the developers. Is goTenna really 100% private? Our project team has been tasked by the LCDI to performs a forensic analysis of a series of devices that have utilized a goTenna network.

With privacy becoming a major concern in this modern age, and cell networks still unreliable in some instances. GoTenna was created with this in mind. GoTenna is a transmitter and receiver for quick text messaging communication and GPS location sharing. With the ability for the average consumer to purchase this device and create their own private network, the question of how private and what artifacts are left behind becomes apparent. For this project we set out with the goal of finding what Artifacts are left behind on the device and if possible capture transmitting data. The devices we used were the Nexus 5, and Nexus 7. How GoTenna works, is it connects to the device via Bluetooth and  then transmits to other GoTenna via radio frequencies. This data is transmitted using end to end encryption with a 384-bit elliptic public private key ciphering. This encryption method is used in both it’s  Private 1-to-1 messages and group message features. The only exception to this is the shout and emergency features which are public conversation sent out to everyone within range of you.

To gather data on these devices we synced them to the phone and then walked around with varying distances from one device to another, from half mile to one mile. From there we sent multiple messages to each device and used all the features except the Emergency one. Upon completing the task we then analyzed the data created. To achieve the secondary goal of capturing the data in transit we used an UberTooth one to intercept the data via bluetooth, and a HackRF to intercept the data over radio frequencies.

Analysis

To begin the project, the team was issued two Google phones – a Nexus 5 and a Nexus 7 – and a pair of goTenna transmitters. After syncing the devices, we walked around and communicated with each other through the new private network, using every feature besides the Emergency function. The distance between each device varied from a half mile to one  mile away from each other. We made sure to capture data in transit as well: using an UberTooth One we intercepted the Bluetooth communication between the phones and the goTennas, and we monitored the radio frequencies exchanged between the two goTennas using HackRF.

Our analysis started by processing a physical forensic image of each smartphone using Cellebrite Touch, then we examined those images in UFED Physical Analyzer. A quick inspection revealed that both devices produced almost identical findings. All the information pertaining to the GoTenna was found in the same directory: com.gotenna.gotenna.

image-1

Several files immediately stood out to us: Conversations.json, goTennaLogs.log and public_keys.json which are stored under com.gotenna.gotenna/files/ and then com.gotenna.gotenna.encryption.xml and com.gotenna.gotenna.secure.prefs.xml which are found under com.gotenna.gotenna/shared_prefs. As we began looking into each of these files, we started to notice that a lot of the data was being obfuscated. This is an example of what we found in the conversations.json file:

image-2

We ran the data through various online deobfuscation tools that would run it against ROT-13, base64, and other common obfuscation methods. Unfortunately, this did not provide any further information about what the data was.

We continued looking through the other noted files and found various strings labeled as encryption keys. These keys were found within the com.gotenna.gotenna.secure.prefs.xml file.

image-3image-4

These strings appeared to be obfuscated in a similar fashion as the data in the other files, so we ran these keys through the deobfuscation resources used earlier; however, this did not provide any useful output.  

Another interesting file we found was com.gotenna.gotenna.xml. this file included information on the time the application was installed on the phones, and where exactly they were located when the goTenna app was installed. The timestamp for the installation was in Unix so it was decoded using DCode, which revealed it was installed on Tuesday, October 25th 2016 at 5:09PM.

image-5

Next, we entered the latitude and longitude coordinates into Google Maps to pinpoint the location this data contained. Google Maps revealed that it was coordinates for the Leahy Center for Digital Investigation, which is where we installed the application. The file did not contain any coordinates for locations where data was sent or received.

image-6

Within this file, we also found the name of the user associated with the goTenna app, and a timestamp for the last time the goTenna was connected to the phones. Once again, we used DCode to decode the timestamp because it was in Unix, and found that it was last connected on Thursday, October 27th 2016 at 2:36PM. The name of the user was written in plain text and read, MrBilliams.

image-7

Hack RF & Ubertooth One

To capture the data in transit we used HackRF using GNUradio to try and capture and data over radio frequencies. While setting up and using GNUradio we ran into the issue of not knowing what frequency the GoTenna was operating on. With this issue in mind we attempting to capture the data in transit via bluetooth using Ubertooth one. After getting the Ubertooth up and running we ran into the issue of not  being able to detect the bluetooth connection between the devices. Overall we were unsuccessful in trying to capture the data transmitted.

Conclusion

At this point in our project, we have hit a brick wall due to how goTenna encrypts its data. The main problem we encountered was that we do not know how it handles encryption. Data could be encrypted on the phone before it is sent, or after when it reaches the goTenna itself. Despite this, we decided our best course of action was to try and use OpenSSL to decrypt the data using the private and public keys we found in the files from the images we took. Unfortunately, we discovered that these keys cannot be used to decrypt the data. The unusual length of the key and the errors we received from OpenSSL, led us to believe that the keys themselves were being encrypted in some way. We determined that it is likely that the keys we would need to decrypt our keys are located within the memory of the devices. Therefore we attempted to use a tool called Lime to extract the memory from the Nexus 5, but the lack of documentation on the tool made it difficult to use and we hit a dead end. Finishing this project is impossible right now due to a lack of time, and because it is beyond our skill set at the moment. Someone who has more skill and experience with encryption would be better suited to finish this project.

 

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at champforensics@gmail.com.

2 thoughts on “Forensics Analysis of goTenna

  1. Zach

    I’m not sure the conversations.json file is base64 – it contains periods(.) which isn’t a normal character for normal base64. Maybe find a tool that lets you substitute characters or use a different base method.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *