Forgot your password?
typodupeerror
Handhelds Open Source Operating Systems Privacy Security

Replicant Hackers Find and Close Samsung Galaxy Back-door 81

Posted by timothy
from the in-their-spare-time dept.
gnujoshua writes "Paul Kocialkowski (PaulK), a developer for the Replicant project, a fully free/libre version of Android, wrote a guest blog post for the Free Software Foundation announcing that whlie hacking on the Samsung Galaxy, they "discovered that the proprietary program running on the applications processor in charge of handling the communication protocol with the modem actually implements a back-door that lets the modem perform remote file I/O operations on the file system." They then replaced the proprietary program with free software.

While it may be a while before we can have a 100% free software microcode/firmware on the the cellular hardware itself, isolating that hardware from the rest of your programming and data is a seemingly important step that we can take right now. At least to the FSF anyhow. What do others think: is a 100% free software mobile device important to you?"
This discussion has been archived. No new comments can be posted.

Replicant Hackers Find and Close Samsung Galaxy Back-door

Comments Filter:
  • Re:Dupe (Score:5, Insightful)

    by wonkey_monkey (2592601) on Thursday March 13, 2014 @09:25AM (#46472479) Homepage

    Replicant OS Developers Find Backdoor In Samsung Galaxy Devices
    Replicant Hackers Find and Close Samsung Galaxy Back-door

    Totally different story.

  • by Gaygirlie (1657131) <gaygirlie@@@hotmail...com> on Thursday March 13, 2014 @10:58AM (#46473367) Homepage

    Either this is a back door, or they are the worst software engineers ever.

    A back-door is something that was placed there with the specific intent of providing access to the system even against the system owner's wish, so that's my point: it doesn't seem like that was the intent. It just sounds like it was there for this service, but they never really fully thought out the scheme and just went with whatever they first came up with. Granted, I'm only guessing here, but for once I'm going to go with the "it's incompetence, not malicious intent" - defense.

  • by Andy Dodd (701) <[ude.llenroc] [ta] [7dta]> on Thursday March 13, 2014 @02:12PM (#46475269) Homepage

    "Never attribute to malice that which can be attributed to stupidity."

    My guess, after years of working with Samsung's poor-quality platform software and multiple runins with their utterly piss-poor configuration management processes (as in, the Korean divisions at Samsung Mobile don't seem to have any, as evidenced by numerous situations during the Superbrick fiasco):

    Samsung probably put this into the RIL library to facilitate modem debugging. e.g. the modem can read/write to /efs/root/ in order to make it easier for a developer to track state changes of the modem or whatever. (Why do this instead of using whatever debugging functions are built into the modem such as maybe JTAG? This is probably for late-stage development where they wanted to test finishing touches on the modem using final hardware and the modem's debugging functions weren't physically available.)

    Keep in mind that, based on the reverse engineering effort, Samsung *intended* this feature to only access files within /efs/root/ - the EFS partition is specifically reserved for device-specific state and calibration data (most notably the phone's IMEI is stored in the EFS partition, and with the exception of some miscellaneous other config data such as MAC addresses for wifi and BT, it's almost entirely for modem-related items. I may be wrong about the MAC data, I'm a bit rusty and haven't poked around at my EFS partitions in a long time.) It's only due to a screwup (lack of sanitization of escape sequences such as ../../ ) that someone can in theory access files outside of /efs/root

    So at some point, Samsung probably removed the corresponding components on the baseband firmware side (no one has yet to confirm anything on the modem side that sends these commands, nor has anyone caught any of these commands being issued - the behavior of the library was verified by injecting extra commands with a kernel patch in the driver between the modem and the library), but someone forgot to remove them from the RIL library on the applications processor side. Forgetting to remove dead code and/or leaving epic security holes in place (remember that in late 2012, someone realized that Samsung left a world readable/writable device node that effectively mapped all system memory to that device file - allowing anyone to read or write any part of memory. For more, do a Google search for "exynos-abuse" ) is pretty typical for Samsung.

    As to my experience here - I was one of the Cyanogenmod maintainers for the Exynos 4210 (I9100, I777, N7000) handset family, and also did some work on 4412 devices (primarily the Note 10.1 - GT-N8013) throughout 2012 and the first half of 2013. I'm 90% retired from working with Haxxinos these days and was (along with the majority of the rest of the Exynos maintainers) one of the people who left the project to start Omni after the Focal relicensing attempt fiasco.

    An interesting question is - what architecture is the XMM626x's baseband processor? Is it custom or an ARM variant making it easier to analyze the baseband firmware itself? More than two years of working with that family of devices and I never personally looked in detail at what was running on the baseband side.

Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie

Working...