Fluffy Introduction Text
I get the “What exactly do you do for a living?” question fairly often, and tend to generically toss out a canned response of “hacker” or “information security professional” or “computers” depending on the person asking and whether or not I’m being questioned by a customs official with a gun and a surly look. I thought it might be fun to blog up a example or two of what we actually do for a paycheck, as it might help explain our niche inside a niche industry and maybe illuminate where our customer’s money goes and what value we provide.
For this exploration, let us focus on 2 random devices sitting on my desk this weekend: The Samsung Galaxy Note 3 (specifically the SM-9005 variant) and the often misunderstood and slightly obscure Samsung Anyway S102.
For the Note 3, I’ll detail what a teardown looks like to me and why it matters to the customer. The device is fairly well documented on the internet, so a full and complete hardware reverse engineering analysis probably isn't worth the time. As such, I’ll just focus on the high level overview. Consider this my first couple of hours on a project, simply what I look for and what my plan of attack would be. This teardown will disregard software and the USB stack entirely, and just be a glance at the hardware.
After the SM-9005, I’ll walk through a deeper analysis of the S102. I expect this to be quite interesting and fun, though it will be a separate post that will go up within the next couple of weeks.
So, without further ado….
The Samsung Galaxy Note 3 (SM-9005) Teardown
With any common mobile platform that crosses my desk for analysis, I start with a quick perusal of iFixIt for a teardown. For the Note III, we find this: <iFixIt Link>
The device is fairly straight forward to crack open, but the public teardown doesn’t tell us much about the internals. We can fix this with a bit more time on google and quickly run into the beloved chipworks.com tear down (we will come back to this later): <ChipWorks Link>
While the overall information is nice, what we really care about here is:
- What components are being used (ChipWorks gave us a listing already)
- How was the device built
- Did the designers leave any debugging mechanisms exposed or active during production
- Are there any weak or squishy portions of the design that look easily exploitable
So with the background we have at hand, it’s time to take a screwdriver to the phone and see what’s inside for ourselves.
A GENERIC TEARDOWN PHOTO
|
TOP OF THE PCB
|
SCREEN SIDE OF THE CASE, UNDER PCB
|
Starting with the top left corner, we can see where the PCB contacts the pressure connection pads on the case that I mentioned before. I this were a real project I would eventually explore them with a multimeter to be sure, but my initial assumption is that these simply share power and ground with the screen.
Moving to the top, we can see the 4 pins that connect to the battery when the phone is assembled, and to the right of that is our main slab of RAM followed by 2 sets of RF Shielded components.
BOTTOM OF THE MAIN PCB
|
If you didn’t notice, I did a bit of “it’s magic” handwaving when locating the SoC (it’s hiding underneath the slab of RAM). We know this because we googled the device and ChipWorks already discovered this for us and they tell us it is the new Snapdragon 800 (MSM8974). Had this not ben the case, I would have to start desoldering components looking for Qualcomm silicon. While cleaning a PCB of all components gives me great joy, this phone was a present and I’d like to at least boot it once before we kill it, so we will take the ChipWorks finding as gospel for the time being.
So far, our analysis is far from special or unique. iFixIt delves to this level trying to help people fix or replace broken components on a phone and ChipWorks delves a bit deeper looking for new hardware and trends in the engineering space. At this level, we also diverge, but our path is to catalogue hardware interaction points and to explore the PCB for potential debug interfaces.
Jumping down the stack a bit
Now, before we delve much deeper, it’s probably a good idea to spin up a quick vernacular, especially if you are not experienced in hardware. First, modern PCBs are typically dense and multi-layered. As such, a simple visual inspection is not always going to grant you 100% understanding as we can’t see internal sandwiched layers from the top or bottom. Phones and high end consumer electronics are especially dense, while more esoteric hardware still tends to be dual layer (top and bottom only).
When wanting to connect a trace between layers, a via is used. These are simply the “dots” you see from visual inspection and they generally mean that a trace has jumped to another layer (though they can be use for other things as well, like pulling a reference voltage or ground signal from a different layer).
Lastly, when PCBs are being mass produced they need to be tested prior to deployment. While a multitude of options are available, the majority of devices we look at in the real world still support the concept of a “bed of nails”. <insert google image search results here>. This concept basically means that interesting or problematic areas of the board have testing points exposed on the outer layers of the PCB so that an external testing machine can quickly validate them on the production line. Furthermore, my favorite hardware designers tend to expose debug functionality with these interaction points to allow for firmware and OS flashing post production.
Now that we are loaded with a simplified lexicon, we can delve a bit deeper into some closeup photos of the SM-9005 board.
The first thing I notice upon glancing at the PCB is the bed of nails pads lying about the board (these are the copper / gold circles in the below picture). If this wasn’t a Samsung device and I had not spent countless days tracing prior hardware revisions of these pads, I would be really excited. I’d immediately start tracing the pads with a multimeter and tapping them with a logic analyzer to explore what they are exposing. Given the target though, we will wait on that task until the S102A analysis (where I expect much more interesting results).
BED OF NAILS PADS AND CABLE SEAT
|
The other thing to take note of in this picture is the wonderfully large spacing of leads off the ribbon cable seat. These pinouts, while still fairly tight and small, are spaced far enough apart that latching with a logic analyzer to watch all the data pass over the cable is an approachable task and much easier than tapping the cables directly. If we cared about PCB to Screen interactions, this would be our starting point.
While we will disregard the bed of nails pads because I’ve explored Samsung phones in the past and know better, I do see something on the board that makes me second guess that decision. Below, you will see a collection of unpopulated pads that are designed to seat standard capacitors and resistors. Seeing these gets me quite excited, especially because some of the traces end in nail pads as well.
You will rarely see PCB layouts with truly unused components, everything about physical hardware is about tradeoffs between space, cost, usability and mass production. Engineers don't simply design and produce extra unused pads as a rule, so if they are on production equipment they probably have a function.
UNPOPULATED PADS |
Aside from the logical, these pads could expose something immensely more interesting: hardware debugging and firmware manipulation. At some point in production, the device must be loaded with software and most common SoC vendors protect that functionality with a series of hardware flags controlled by resident voltages. In this case, I would start tracing the pads with a multimeter to see where the missing discrete components would effect, and what circuit they could complete if bridged.
We have seen hardware of a lower mass production scale where through hole resistors were utilized to open the SoC for firmware debugging and then simply clipped by hand before the final device closure and shipment to customers. If my target was to acquire Qualcomm firmware or debug the resident NAND, these pads would be my starting point. Further enticing me along this path is the mysterious pads exposed directly next to the SoC / RAM stack (as seen below).
PADS ALONG THE MAIN SOC / RAM |
Final Thoughts
While we’ve meandered around a bit without real focus, I do hope I’ve explained a bit about what I look for in a teardown and what excites me to see. If this were a real engagement to find security related issues on the Note 3, I would be tracing all the pins and attempting to recreate the full PCB schematic. I would then acquire spec sheets for every piece of silicon I could and start looking for debug or flashing capabilities. The main focus of this part of a hardware analysis is to plan an attack to grab the resident firmware and the Note 3 exposes a couple of paths that while probably dead ends are none the less worth running down.
We would also explore the USB side of this hardware and obviously look at the driver/os/kernel as well, but I think I’ll save those walkthroughs for an easier device and another time / blog post.
Thanks for reading,
m0nk
if you have any questions, please email us or find us on twitter @m0nk_dot / @Atredis
if you have any questions, please email us or find us on twitter @m0nk_dot / @Atredis