I grok what you're suggesting.
What about the Sony SVO-5800? It would appear to be a "broadcast quality" sony s-vhs deck and would appear to be able to read and write regular VHS tapes. Am I missing something or is this a rare exception to your stated rule?
It appears I set it as a preference once. I hadn't bothered to change it. This better? Sorry for the horrification.
While WebM is technically a video file format, it offers many advantages over animated GIFs—namely superior image quality, support for more than 256 colors, and reduced file size. Its main disadvantage is browser compatibility, however 86% of 4chan’s visits come from browsers that include full or partial support for WebM, and plug-ins are available for those that don’t (like Internet Explorer and Safari)."
Link to Original Source
> And pardon me, but could you explain to me what the need is for a(n undocumented!) way to gain access to "certain files" on a phone by a remote person ? As far as I can tell there is nothing on a phone a remote person should have access to without the explicit say-so of the owner.
Sweet jesus. The system is not an undocumented way to allow a reomte, third party unauthenticated arbitrary access to your data. It's a system used to allow the modem firmware running on a separate DSP core to save and recall information. Yes, there exists a <b>possibility</b> that a flaw in the modem firmware could allow a third party to command the modem to make IPC requests to the device's host processor to read information and then, potentially, transmit it back. There is no evidence to suggest that such a flaw exists.
> You mean to say that as they all have got similar backdoors (do they ?) its OK ? Strange reasoning
No I don't mean to say all have any backdoors; a backdoor is a camouflaged or otherwise hidden system installed to circumvent access restrictions. This is niether camouflaged nor hidden. It's purpose is not to circumvent access controls. It is not a backdoor.
> Bottom line: A phone which has got RPC file-IO calls from the cellular into the smart part of the phone is at least questionable.
Questionable? Yes, of course. But do not attribute to malice what is adequately explained as incompetence.
I'm replying again because it occurred to me. to check the dictionary.
A backdoor is an indirect and devious system conceived for the purpose of allowing access to resources by circumventing security protections.
This is not. This is a set of IPC requests an "API" to allow the modem firmware to store non-volatile information in a specific location of the host phone's filesystem.
You're absolutely right that a backdoor is a backdoor; however, this is not a backdoor. If they'd really meant to introduce backdoors, don't you think they'd have made even a trivial effort to hide or obfuscate it? For example, D-Link's special request header “xmlset_roodkcableoj28840ybtide” that would bypass the web admin authentication. That's a backdoor. Minterpreting wrappers for read() and write() is not.
I do believe you missed the point of my comment entirely. These IPC requests for doing file I/O are there to allow the to read and write to a small subset of files constrained to a specific portion of directory hierarchy.
Yes, the modem could potentially read other files - limited by unix access controls, but it cannot read nor write from arbitrary files.
> Maybe you're right and it should be called "criminal negligence" instead.
I was growing the impression you'd authored a post with value worth contributing to the discussion until I noticed this statement. I thank you for announcing your ignorance so clearly.
Want to prevent people from destroying/modifying your IMEI using a yet-unknown-and-incredibly-unlikely-but-still-technically-possible hypothetical remote privilege escalation? Use the chmod(1) command with the argument 640 to remove the group write permissions.
Really, how is this unlike any other phone that has a cellmodem with firmware and nvram?
If you really wanted to limit what files the rild could interact with on behalf of the modem, a trivial bind mount and chroot( ) would suffice.
Unfortunately, the daemon that opens, reads, and writes files on behalf of the modem, is running as a specific unprivileged user, radio (uid 1001 on my phone.) It could only wipe out the information I have in
It's no more a backdoor than using using static functions in your compiled C. Simply because it's not documented, does not make it a backdoor.
Two things, "Even Ham radio operators?" When did they become the retards of the RF world - I thought that title belonged to CB'ers? Honestly, hams are not interested in your phone.
While, yes, technically anyone can communicate with your modem; anyone can communicate with your wifi card or your bluetooth adapter as well. And it would appear that the samsung radio interface IPC layer at least has a modicum less access to the entirety of your device than your wifi driver - which is in the kernel. People have, in the past, exploited mistakes in wifi drivers and wifi card firmware to remote exploit via wifi. (*: The specific instance I remember, was with an old intel 802.11b/g card and specially crafted management frames which could be trivially spoofed and didn't need to be encrypted to be accepted by the wireless card. The proof of concept was able to issue busmaster DMA read/writes which, ostensibly, would allow rewriting arbitrary kernel ram, etc.)
Across the scope of samsung phones I was able to check (ok, two of them), the radio interface, the android host side of this communications channel, runs as uid 1001 (radio). As far as my cursory inspection revealed, meant that the radio/modem can read/write the files in
So, yeah, as you said, "huge technological challenge." Agreed. But, the idea that a data modem may be exploitable is by no means new.
I couldn't agree more. There is no evidence to suggest that it's a malicious backdoor.
A quick strings on my samsung captivate glide's modem firmware, reveals all manner of novel debug messages and log strings:
[DUMP] FILE OPEN FAIL
[DUMP] FILE CREATE FAIL
[DUMP] Write MA Trace To
aurrcbp: discard cell due to system information read error
[Net]NV Read Fail! OEM_NVM_TESTBED
I do know that a lot of data persistence for the radio is done with dotfiles scattered around and throughout
I'm curious what functionality is affected, if any is, by rejecting any of these IPC_RFS_ I/O.
I don't think it's clearly a backdoor. But, I do believe the concern is warranted. The radio/modem's firmware blob is not auditable. Perhaps a combination of logging/auditing filesystem requests and limiting which files are accessible by the RILD? Actually, isn't the rild run as an unprivileged user, radio? (Possibly for this very reason?)