Oval Elephant UG802 with RK3066 CPU

I picked up a UG802 from Oval Elephant a week or so ago, this is one of a number of so called Android Mini PCs, such as the MK802, that have appeared out of China in the last few months. These devices are based on low/mid end Android cellphone hardware, with the screen replaced with an HDMI connector and no battery. The intended application for these devices is to add internet (smart) functionality to TV sets. The UG802 is notable in that it uses a more modern Cortex A9 dual core processor. On the whole I've found the device to be quite usable, especially after rooting and changing the default launcher.

From looking around I'm confident that the UG802 hardware is also sold under a bunch of other name/model combinations, so if you have a similar device with a RK3066 chip in, its likely the same or very similar hardware.

I looked around and couldn't find any decent pictures of the internals of the device, so I decided to take it apart and make a few board scans. Also, the pictures on OvalElephant lead me to believe there were likely a number of test points around the CPU worth investigating -- more on that later.

Disassembling the device is a pain in the butt, as its held together with a number of rather fragile plastic clips. For anyone looking to take theirs apart, the clips extend from the smaller of the two halves. I worked from near the sides of the HDMI port out, using hotel key cards as pry bars and shims. A technique I've proved effective a number of times in the past, worked reasonably well here. However, I required a bit of screw driver prying as the case is quite snug.

Huge versions can be found here, front and back.

For an inexpensive device I was rather impressed with the finish on the boards. The soldering is clean and and the component placement well done. The only issue I observed was a poor routing on the antenna cable, which caused it to be pinched by the case. Mine was severed, but the insulation and some of the shielding was cut. I suspect if people are having issues with WiFi reception, this is a likely cause.

While I had the device open, I grabbed the oscilloscope and checked out the test pads around the CPU. I was able to locate a serial boot console, which could be useful for development and anti-bricking purposes.

The color coding for the pins is as follows:

• Green = Ground
• Blue = Serial TxD
• Red = Serial RxD
• White = No signal
• Yellow = 3.3V
• Magenta = 2.5V

The serial connection is the expected 3.3V at 115,200bps. A log from the boot process is available here. Regrettably, I didn't take the time to see if the bootloader had an interactive mode. I'll make a dump of the bootloader and examine it, see if there is anything interesting or useful there.

I'm guessing the unpopulated TO92 package is intended to be an IR receiver, but that's only a guess.

The use of the other pins is less clear, I'm guessing that by either pulling some set high or low, the device can be placed in a factory flash/recovery mode, however more time with the CPU datasheet and experimentation required to figure this out.

Moving forward...

My next plans for looking at republic wireless involve peering into the HTTPS connection it makes to their SSL server.

Depending on how they have things configured this will likely involve some DNS redirection on my local network. Basically I'll take update.republicwireless.com and redirect it to a local machine. I'll use the local machine to man-in-the-middle the data. Either just displaying it, or altering it along the way.

Depending on how their software is setup, this may require me to modify the handset to trust some extra SSL certificates. Only time will tell.

Doing this should at least enable me to figure out how they're doing text messages over WiFi and probably yield some other interesting results.

I've also been pondering how they're handling 911 calls. I've got three theories, in order of likelihood:

1. If the user dials 911 force the call to occur on the cellular network. This enables them to rely on Sprint's already existing, federally mandated, E911 support. -- In this instance, I wonder which number (cellular directory number or republic VoIP number) the 911 processing center sees..?
2. If the user is on WiFi determine the phones position using GPS, WiFi, and/or cell site positioning. Then send that data to their backend -- probably a bit like I think they do text messaging. Use this information to determine which 911 center to route to and provide them with the position.
3. They don't handle 911 calls. Given that they're a VoIP service they may or may not be required by law to handle 911 calling at all. Some services are able to avoid this by putting some language in their user agreements.

Like I said, my money is on the first option. This would be a hard one to test without running afoul in the law. So I'll just leave it as a thought experiment -- unless someone from republic wants to explain?

More as it occurs to me and I've time to look into it.

WiFi Security & republic

In response to David Wright:

The concern that I'd like to address is air gap security. While I agree, Hotspot 2.0/802.11u will likely help to address this issue -- its not in the installed hardware/software base which is going to persist for a long time. Granted it could be added with a software update, but vendors tend to not support legacy hardware for very long. In my lexicon, legacy is anything older than roughly one year. Also, I'm not really aware of wide support for the standard in currently available hardware. Give that the standard is less than a year old (ratified 25 Feb 2011) this isn't at all surprising. All of that is beside the point, though.

There is a contextual difference between republic and typical wire line VoIP. I dove in to it a little here. But I want to drill into it a bit deeper, so here goes...

Most VoIP providers assume that their device (likely an ATA) is on a wired network, at a fixed premises. The assumption is that the user of the device controls the location its installed at, and thereby has some assumption of network security. By which I mean, the user would notice if someone had plugged in a monitoring device.

Its generally assumed that the networks you traverse outside the user premises are secure and unmonitored. Or at least comparably to POTS wire line service. While I don't agree with this assumption, lets just accept it for the sake of argument.

This brings me back to a question of context. Cell phones travel everywhere with us. We use them in a wide variety of locations, some of which are more secure than others. republic's business model is based on heavily incentivizing its customer base to use WiFi. The customer also has an incentive to connect to public WiFi, as in many places the quality of service (speed, latency, etc) is significantly better on WiFi than over the cellular network.

This means, that a customer sitting at an airport or in a hotel is very likely to connect their device to the location's WiFi.  This WiFi is almost certainly not encrypted. The moment they do that, republic's software will automatically attempt to negotiate a SIP connection to their service.

Anyone within wireless range, with the appropriate hardware -- pretty much every wireless card supports monitor mode these days, software -- readily available, and knowledge -- still a pretty low bar, can intercept their SIP credentials, monitor who they call (inbound and outbound calling numbers), and listen in on their voice traffic. This is a huge privacy and security concern. Granted, as I already observed, the SIP creds are being sent digest, meaning immediate SIP password recovery isn't possible.

Returning to context for another moment. A cell phone call is generally assumed to be moderately secure. While again I don't agree with this assumption, lets just accept it for the sake of argument as well. Why people talk about deeply private issues in public places is beyond me, but in this instance the person has to be within hearing range -- maybe 10-20 feet depending on noise level and they only hear half of the conversation.

In the case of WiFi interception the listener can be a up to a few hundred feet, hear both sides and actually know who was called / called the user.

When we combine the points I've already detailed the scenario isn't a sunny one. To recap:

• republic heavily incentivizies WiFi use
• People are already incentivized to use unsecure WiFi in public places, and do so often and without considering it
• Most people assume their cellphone calls are secure
• republic automatically sets up an unsecure SIP session the moment it connects to a wireless network
• Interception of wireless traffic is relatively trivial, and surprisingly common.

At the bare minimum shouldn't the device throw up a huge warning if its on unsecure WiFi prior to starting a SIP session, forcing the user to agree what they're about to do is a Bad Idea? Or as I suggested previously, just refuse negotiate a SIP connection if on unsecure WiFi?

I understand that TLS and STRP aren't great solutions and that's why no one really uses them, but for an application like this -- a hybrid WiFi-cellphone -- not having any form of encryption is a recipe for failure. A laughable one at that.

TLS and STRP also aren't the only VoIP security options...

Suggesting VPNs are a solution is equally laughable. The vast majority of people haven't heard of them at all and those that have only know them as something they need to "run it before they connect to their work stuff". They're not going to have the foggiest idea how to set one up, maintain it or use it. To say nothing of the fact that republic will still automatically connect immediately on joining a WiFi network...

I bring all of this up because republic is still in beta and is actively soliciting input to improve its service. As a result can and should fix these things now, before they have a huge public roll out and end up looking silly or being culpable for some disaster. 

SIP Credentials

In response to Zanthexter: SIP isn't my my most fluent protocol, but I did a bit of looking at the captures. Its using MD5 digest authentication, so I see the usernames, nonces, etc. I don't see the password being sent plain text, but I only did a cursory glance. Whenever I make it back from work I'll take a deeper look at it.

While yes, VPN is certainly an option, so is turning on SIP-TLS and SRTP or other security options, which is something that republic/phonebooth could easily do -- and should in my opinion.

Republic Captures

Some data from my Wireshark captures...

TCP Endpoints*:
Address,Port,Packets,Bytes,Tx Packets,Tx Bytes,Rx Packets,Rx Bytes
65.39.128.135,http,114,8604,0,0,114,8604
74.125.225.81,http,60,6608,0,0,60,6608
74.125.225.81,https,46,8310,0,0,46,8310
87.106.50.181,http,30,3408,0,0,30,3408
184.73.34.202,https,44,5540,0,0,44,5540
184.73.154.58,https,96,11444,0,0,96,11444
209.85.145.188,hpvroom,132,13172,0,0,132,13172
216.74.41.14,https,24,2670,0,0,24,2670


UDP Enpoints*:
Address,Port,Packets,Bytes,Tx Packets,Tx Bytes,Rx Packets,Rx Bytes
65.39.128.135,ntp,4,360,0,0,4,360
107.20.70.166,5090,150,76578,8,4720,142,71858
184.73.104.92,12882,354,76092,12,2904,342,73188
184.73.104.92,9988,338,72612,10,2420,328,70192
184.73.104.92,18172,344,74400,28,6776,316,67624

*Omitted all LAN IP addresses.

DNS queries of interest:
xtra1.gpsonextra.net
xtra3.gpsonextra.net
p19proxy-pro-aws01.phonebooth.net
update.republicwireless.com

Repulbic Security...

Well a quick look at some packet captures doesn't give me the warm fuzzies about republic's VoIP over WiFi implementation. Or maybe thats unfair, its just that its exactly as I feared, VoIP over WiFi with pretty much no security.

All of their SIP packets seem to go in the clear, same with the RTP (voice transport). I see some SSL traffic to EC2 instances.

Checking the IPs for most of the DNS resolves in the capture, shows that most (all) of the republic stuff is in EC2.

For reference they're using G.711 PCMU for voice.

I haven't quite figured out SMSes, at I think they're going through SSL (based on the timing)..

They're using their phonebooth.net service for all of the SIP stuff -- also in EC2.

The device does a DNS query for update.republicwireless.com -- all of the HTTPS traffic appears associated with the IPs this resolves to.


Short answer: Don't use WiFI calling on public, or unencrypted WiFi, as people can really easily sniff your traffic -- yes, I mean listen to your calls, steal your SIP creds, etc. 

WEP does not count as encryption in my book, use WPA2/AES.

A suggestion to the republic folks? Enable cyrpto or disable WiFi calling when on unencrypted networks. I'd sooner the former than the latter.

I'd post my captures, but I really don't feel like hanging that kind of data about me out there.

Sorry guys.

Republic Wireless

I've been watching republic wireless since their mysterious web page appeared a month or two ago promising unlimited usage -- calling, texting and data -- for $19 a month. They promised to accomplish this feat by using hybrid calling. Effectively making the phone a totally VoIP device while in WiFi rage and providing feedback on a users cellular consumption in an attempt to prevent it from becoming prohibitively expensive. republic is acting as an MVNO on the Sprint network, however that didn't answer the question of how their hybrid calling worked. Curious, I signed up for their beta program, forked over $100, and was lucky enough to actually get a device.

But that's the sales crap and really I was interested in doing some reversing on the tech. Sooo...

Here is what I have so far. The device has a pair of numbers (this is somewhat of a lie, but sufficient for now). The one republic assigns you, located in your geographic region and tied into their VoIP service and a second cellular number which is not normally visible. Based on this we can conclude that the republic infrastructure works roughly as follows for an incoming call:

1. The call arrives at republic's VoIP switch. 
2. The VoIP switch checks to see if you've registered recently. If you have it attempts to negotiate a VoIP connection. 
3. If you haven't, or negotiation fails, it forwards the call to the phones cellular number.

Should be similar for incoming text messages. Out going stuff is actually easier, as if you're on WiFi everything just gets sent there. If you're not, its just a matter of forging the outbound number to match your republic one and ... well actually that's it.

Interestingly, the cellular number can be called and texted directly if you retrieve it from the phone's baseband.

I do wonder about how republic is going to do accounting for their CUI stuff -- I'd posit they'll do it with their VoIP call router. This does make me wonder if one could pull shenanigans by bypassing it using the cell number directly. While this would work in the short term, sooner or later republic will get a bill for the usage from Sprint and probably notice.

For data accounting, I'd guess they're probably using either their own PDSN or a private gateway. I'll verify this sooner or later...

Both of these are really a question of how close a relationship republic has with Sprint. Can't say I've looked to see if any of them are Sprint alumn yet, so its hard to say.

If I were them, I'd probably ask Sprint to block direct access to the cellular number from the outside (just a suggestion).

Another interesting side note, while poking around in the dialer interface I noticed this:

I wonder if either they hired one or more of the XDA folks (who I hold in high regard) or appropriated their app..? Realistically if I were looking for quality phone hackers, XDA is probably where I'd start looking.

Next up I'll probably bust out WireShark and take a look at what their VoIP protocol over WiFi  looks like. That should be entertaining... I'll be very interested in knowing if they've implemented anything that resembles security.

---

If you don't understand any of the following, don't do it. You can very easily screw up your phone.

For those that are curious, the second number can be examined by using either Qualcomm Phone Service Tools (which you really shouldn't have) or CDMA-Workshop. Roughly speaking, you need to retrieve the phones SPL, once you have that then read back the service programming. With the service programming data, you can check the directory number for the device (AKA, the cellular number). While not particularly organized, or entirely applicable, bits of this are described here. Use the "old technique" to get the SPL and ignore the part about updating the PRL.

Assuming you're using CDMA-Workship, enter the SPL you just retrieved in the window next to the baud rate and press the read button.

Also interesting is the fact that the MIN, directory number and MDN are all different. For my device the dial number has a local area code, the directory number is  240-469-XXXX, and the MIN is 301-205-XXXX. The latter two being MD area codes.

The MIN returns a number not valid when trying to call it...