Good day all,
With all the hubub about airport security screening your phone I'm interested in an 'airport app'. Namely, as opposed to full encryption (meh good if needed, but I don't really want to trade battery life for security) or the hassle of backing up an image, flashing a virgin phone image for travel, and then restoring the image after travel..
Why not create a 'sandbox' app of sorts. Start it, it simulates virgin or near virgin status, have an advanced unlock sequence to close it. The only issue, I see, would be if the phone was restarted while in 'airport mode' could it be triggered to restart in said mode.
After typing out my whole idea, I'm thinking the backup and flash of virgin rom might be a lot simpler. But I'm interested if any other world travelers, or US travelers would be interested in something like this.
So I guess the question is, anyone else thought about this, anyone know of something similar out already? Anyone want to develop something like this?
~HattZ
Screening in X-rays? What does it have to do with anything?
Or some other screening (don't believe it's technically possible - too many phones)? Can you point to your info source?
I don't understand the point of this, it is not like they take your phone and play with it when you go through security. In fact, mine has never been removed from my carry on when passing through security.
Maybe you have some evidence to support your theory that our phones data is at risk when passing through security checkpoints... but I doubt it.
Are you in the US? 'cause 1) that never happened, and 2) that would be illegal (to search the content of your phone), unless they had reasonable suspicion that your phone contained data that showed evidence of criminal activity.
They might 'touch' some phones to make sure they are real (as in really work vs being a bomb or something), but they wouldn't search the content of your phone.
pconwell said:
Are you in the US? 'cause 1) that never happened, and 2) that would be illegal (to search the content of your phone), unless they had reasonable suspicion that your phone contained data that showed evidence of criminal activity.
They might 'touch' some phones to make sure they are real (as in really work vs being a bomb or something), but they wouldn't search the content of your phone.
Click to expand...
Click to collapse
Sorry, wrong answer, it is the US, most national travel is not submitted to this type of search. All international (incoming) travel can be.
Lots of interesting talk on it: http://yro.slashdot.org/story/10/11...r-Moxie-Marlinspikes-Laptop-Cellphones-Seized
Legal explanation: http://caselaw.lp.findlaw.com/data/constitution/amendment04/04.html
pertinent excerpt: "Border Searches .--''That searches made at the border, pursuant to the longstanding right of the sovereign to protect itself by stopping and examining persons and property crossing into this country, are reasonable simply by virtue of the fact that they occur at the border, should, by now, require no extended demonstration.'' 87 Authorized by the First Congress, 88 the customs search in these circumstances requires no warrant, no probable cause, not even the showing of some degree of suspicion that accompanies even investigatory stops."
A google search for "international travel us border checking laptops and phones" give about a million other examples, I'll throw a few below.
from Feb 12, 2008 (this isn't a new phenomenon, just getting more press)
http://www.pcworld.com/article/142429/five_things_to_know_about_us_border_laptop_searches.html
from 21 September 2009
http://www.mondaq.com/unitedstates/article.asp?articleid=86010
Don't like it? neither do I.
http://www.aclunc.org/issues/technology/blog/checking_your_privacy_at_the_border.shtml
ACLU excerpt (it's liberal, and slanted but a valid presentation of the worst case scenario): "Originally announced in July 2008, the current policy permits border agents to search electronic devices “absent individualized suspicion.” Agents may hold on to devices “for a reasonable period of time” to “review and analyze information.” In other words, border agents are legally able to take travelers’ information whenever they want at security checkpoints at airports or along the border, and hold on to it for as they long as they want. Agents may also copy information and send it off-site to be analyzed. The policy applies to all electronic devices, including computers, disks, hard drives, cell phones and cameras. Travelers have to be concerned about more than the possibility of security agents rifling through their belongings. Their private data might be compromised, erased, or kept indefinitely, and they don’t know how that data might be used."
Best I can say is nandroid + ext backup to your home computer, wipe phone before coming back into country, then recovery nandroid once you're back at home.
MaximReapage said:
Best I can say is nandroid + ext backup to your home computer, wipe phone before coming back into country, then recovery nandroid once you're back at home.
Click to expand...
Click to collapse
Yeah, sorta realized that or something similar would be the most efficient. I'm thinking even a step lazier, nandroid backup to SD, restore a stock rom / clear sim card, remove SD, maybe even backup to laptop (truecrypt FDE - custom error message at boot saying master boot record is corrupt)
walk out of security, pop in SD, start nandroid restore...
sigh.. a sandbox app would be sorta fun though.
If they have a right to detain your laptop, clone your HD and you have to submit all your passwords - it's kinda useless to try and protect the data somewhere on the computer, and it's better just to back it up on microSD hidden in the suitcase - no way it'll be detained.
Definitely keep a copy of it on your computer at home, though.
airplanemode anyone?
Or turn of your phone.
I know what will make it a quick transition through airport security when flying international..
Put some heavy encryption on my phone, obfuscate my data, and then pass it off with a flimsy cover program to make it look like there is nothing there. That way if they do find it, it's GITMO TIME.
Jack_R1 said:
If they have a right to detain your laptop, clone your HD and you have to submit all your passwords - it's kinda useless to try and protect the data somewhere on the computer, and it's better just to back it up on microSD hidden in the suitcase - no way it'll be detained.
Click to expand...
Click to collapse
meh, at the lower tier of airport security a custom boot message from a full disk encrypted truecrypt volume. "please insert windows disk" "cannot find master boot record" or similar.. and a sob story about how your laptop stopped working on vacation and when you get home you have a friend that you hope can fix it..
gets by most, it's not NSA at every checkpoint. it's just over min wage, uneducated, folks..
so backing it up to laptop, and tossing micro SD card in the bottom of a bag or in a jacket pocket.. will work just fine.
Hi, everyone.
Some time ago I've been working on getting mainline linux to work on our device.
I was mostly interested in running desktop GNU/Linux, not Android, not in chroot.
I used it in Uni for occasional coding, in order not to carry laptop with me.
I'm not sure if I'll continue to actively develop and maintain it, so I decided to share my work with whoever might be interested in it.
However if there would be community interest, I might continue to improve support.
Or maybe someone would like to help me with this undertaking.
The code is not based on amazon kernel, and don't use legacy board files, but is Device Tree based.
Most of the basic hardware works, however, some don't, and would be nice if someone smarter or more stubborn than me helps to troubleshoot it.
What works:
It boots)
Serial console - needs device disassembly, convenient for debugging
eMMC
Display panel with backlight - 18bit mode, without dithering.
HDMI display (hotplug, modeswitching)
USB device - works as usb cdc, handy for SSH access and configuration.
Charging - uses driver from stock kernel
Battery monitoring - doesn't strictly match android measurements, but works.
WiFi - uses brcmfmac driver, needs firmware, haven't tested it outside of regular client mode, not shure if either hotspot or p2p works.
Bluetooth - needs firmware uploaded from userspace, however may be rewriten with serdev interface.
Touchscreen - uses driver from stock kernel.
Vvolume gpio keys
Power button - connected to power management chip
Vivante gc320 - gives a nice speedup for X11 and Xv scaling.
Hall sensor (protective cover (lid) sensor)
Case thermal sensor
Audio codec - headphones, speakers, microphones not tested
LTE modem - can be used for data and SMS but not calling (unless you figure out how to ). Not sure about positioning (if it is available on this modem)
What doesn't work:
Sound - codec works, but I failed to make it properly communicate with omap, am I missing something obvious? works now: mclk pinmux was misconfigured
Camera - not really interested in it anyway.
RPROC - see notes below
[*] DSP - seems to be not used on stock andoid at all;
[*] IPU - required for camera and video encoding/decoding acceleration
[*] IVA-HD - part of VPU.
GNSS - provided by the same chip as Bluetooth, but communicates via some obscure protocol from userspace.
PoverVR gpu.
What could be brought up with small effort (supposedly):
Various sensors:
IMU: accelerometer, gyroscope, compass.
Hall sensor - protective cover lid
ambient light sensor
various thermal sensors.
LTE (might actually have GPS in it, or call functionality, who knows...)
Bugs:
Bluetooth needs to be enabled in android prior to (hot) reboot to linux, I'm obviously missing some port configuraion.
USB host technically works, but is disabled since it needs some work. (And it makes high pitched noise while 5v booster is on though)
Suspend/resume mighth not work Should work :silly: (proper power management needs newer u-boot).
Charging sometimes get's limited to 500mA -- smb347 driver needs some debugging.
CPU Idle is disabled, not really shure what's wrong with it.
Frequency scaling is not perfect (since omap4470 is not really supported in mainline kernel).
HDMI DDC - EDID reading corrupted, looks like some issues with ddc pullup/esd protection chip, sometimes it might even work. If someone with osciloscope is interested in debugging, you are welcome. And one more thing: after you reboot back to android hdmi wouldn't work here for some time, untill it gets back to normal. Resolved.
Remoteproc functionality (DSP, IPU) for omap chips is not really present in mainline. It IS in TI kernel, I was able to build firmware for ducati, and run it.
But was unable to make it properly communicate with userspace.
Someone experienced with it might help.
What is unlikely to EVER work:
SGX544sc has no userspace drivers, so unless you have some contacts at TI who would bother to compile it, this gpu won't work.
Camera requires some code running on IPU, which, AFAIK, was never opensourced.
Boot process:
The kernel is booted directly via second bootloader.
For now without initramfs, so it needs a separate partition on eMMC for rootfs.
With initramfs, on the other hand, one may put rootfs on the regular `data` partition, either as file or in directory.
Works nicely along with regular Android: with a small tweak to bootloader you can boot either via volume key combination.
The bootloader is configured to boot from `dkernel` partition if both volume buttons are pressed.
Dkernel partition initially contains kernel for factory device check and is not used in regular device operation. Still, you may wish to back it up if you feel like you may need it at some point.
You may choose whichever linux distribution you like, I'm using archlinuxarm for now.
I'll provide a more detailed manual, and flashable binaries, alongside with rootfs later,
But for now, if you know what you are doing, here are some sources:
kernel (current working branch is `integration-4.18`, use omap4jem_defconfig)
u-boot (will upload source code later, for binary build see attachment)
Basic outline of required steps are:
replace secondary bootloader in your main boot partition
rebuild dkernel, with zImage build from sources and flash it.
shrink your 'data' partition
add new partition on your eMMC for your rootfs and format it to ext4 or f2fs
unpack your rootfs onto it
mount and chroot into it to make basic configuration
boot.
A video demo:
https://www.youtube.com/watch?v=mpjwL4VRS-E
Have a nice day!
ipipipipip said:
...
Click to expand...
Click to collapse
Sorry for jumping on the bandwagon a little late here. Seems like a promising project. If you managed to get mainline 4.18 to at least boot (which sounds hard in and of itself), how would it work out if it booted nicely on Android? that wouldn't be too bad of a prospect. Complicated, yes, but maybe remotely possible. I'd be willing to test drive it on my non-lte jem - after I give this project a spin, of course.
A quick update:
Bluetooth now neither require to be powered on prior reboot (there was a clock that I forgot to enable that prevented bcm module from starting), nor a user-space firmware upload.
It now uses serdev bus and kernel-space driver to upload firmware, that removes the hassle of adding system daemon that will properly initiate bluetooth with the correct tty.
There is no proper way for now to check what version of jem/jemlte device you are using so you have to rebuild the kernel with the correct firmware in "firmware/brcm/BCM2076B1_26MHZ.hcd". The default firmware is for lte version, so if you use non-LTE version please replace the file "firmware/brcm/BCM2076B1_26MHZ.hcd" with the 20MHZ one from the same directory (just remove the 26MHZ one, and change 20MHZ to 26MHZ in file name).
WiFi no longer causes issues on resume, and device suspends and resumes properly (more or less), I haven't measured battery drain)
Bad news:
I've bricked my device and not sure if I still can revive it, looks like eMMC is almost dead. Or another case of crappy samsung moviNand firmware.
It is detected over USB as OMAP4470 device and it looks like cpu does not detect emmc.
After about 5 minutes (some kind of watchdog??) it manages to boot u-boot aka fastboot. Any other action that tries to modify content on emmc causes the flash controller lockup and communication with it is no longer possible.
Soldering wires directly to pcb pads doesn't help much, the card is not detected by card-reader.
The main idea for now is to use vendor command 62, as mentioned in one of #Hashcode's posts to wipe all the content of the chip. The problem is that I have wiped linux partition and can't boot into any kind of working linux system on the device. (Recovery tries to mount some partitions rw and thus makes flash chip inaccessible). Guess it's time to make an NFS rootfs and boot the device over USB network.... Or maybe someone knows how to prevent TWRP from accessing partitions on device?
In the worst case scenario I'll have to replace emmc chip (if it's not glued too hard in place), curious if some 128GB will work
Or maybe someone has a spare PCB, or a broken device that they no longer need and may donate?
monster1612 said:
Sorry for jumping on the bandwagon a little late here. Seems like a promising project. If you managed to get mainline 4.18 to at least boot (which sounds hard in and of itself), how would it work out if it booted nicely on Android? that wouldn't be too bad of a prospect. Complicated, yes, but maybe remotely possible. I'd be willing to test drive it on my non-lte jem - after I give this project a spin, of course.
Click to expand...
Click to collapse
There will be no GPU or video decoding acceleration, which might be a problem with modern apps, if you wish, go on and try, might be interesting to have a look, I don't have much experience in building android ROM's.
Sup, have some news on the progress of the project
An eMMC on my tablet died completely, thus I had to replace it with another one. My initial intent was to place some 64gig SanDisk emmc 5.1 from ebay, but I was not sure if it'll work with omap4 and that I won't fry it in the process of replacement. So I've bought some similar scrapped 16gig variant from a local reseller for a couple of pennies. After recovering partition layout and bootloaders the tablet came back to life, thus it's pretty safe to put whatever eMMC chip you have on your hands in your tablet) (it's time to order a larger capacity flash now, 16 gig is rather scarce for both android, arch and some content). The trusty old stock kernel, on the other hand, needed a tiny patch to let kernel understand a flash from the future. The driver checks for known emmc protocol version and unloads flash driver if the revision is too high.
Now feeling more confident in unbrickability of my tablet, I've gone an extra mile of porting mainline U-Boot bootloader to the tablet.
The port is pretty minimal, just support for serial port, usb/fastboot, and framebuffer console. Since pinmuxing and HW initialization is done via stock bl, nothing much to do. But it adds ability to freely manipulate boot sources, kernels, ramdisks, supports dtbs and overlays, environment save/restore, and external boot scrips on a FAT boot partition ). For some reason bootloader font is corrupted and hard to read, bit it should be easy to fix.
The good parts:
kernel version is bumped up to the latest 5.0.0
enabled mpu6050 IMU sensor
enabled tmp103 temperature sensor, supposedly case temperature...
enabled hall sensor that is triggered by a case lid magnet, It's mapped as a SW_LID key
some cleanups for display panel code
resolved HDMI edid issue: two part problem of wrong DDC pin mux sequence and wrong HDMI vdda supply regulator match string
Regressions:
Somewhere in the process it lost the ability to resume from suspend, have to find what caused that.
New bootloader does not handle IDME tags, therefore for the stock os I had to hardcode serial and MAC addresses in stock kernel idme driver. But since there is plenty of place to put different bootloaders on our tablets you may use one for stock rom, and another for development.
A second part of the update is coming soon...
Hi there,
This is very exciting work - how is the tablet doing a year on? I'm wondering how much of your work is applicable to the 7 inch equivalent, seeing as the board is common, just with a few minor hardware differences.
Thanks,
Jack
Jack_Kekzoz said:
Hi there,
This is very exciting work - how is the tablet doing a year on? I'm wondering how much of your work is applicable to the 7 inch equivalent, seeing as the board is common, just with a few minor hardware differences.
Thanks,
Jack
Click to expand...
Click to collapse
Hi Jack, since last update I got some additional pieces working. Specifically: sound (and that was a brain-teaser for a long time) and LTE modem are working now. UEFI boot with u-boot implementation is functional.
Indeed 7-inch tablet may be brought-up with quite a low effort: lcd panel is slightly different, but there is a driver for it already in kernel, touch screen is also different. Apart from that rest of the stuff should work quite the same, that is usb, uart, wifi, bt, audio, backlight, keys, emmc, hdmi, with minor DeviceTree adjustments.
Same for u-boot: for basic functionality only a few pin-assignment changes are needed.
Hi,
For a relative arch Linux beginner, what resources would you point one to to be able to implement this on an OG kindle fire HD 8.9?
I'm decently comfortable on the command line, but once it starts getting deep in the kernel, I am a little more cautious..
Many thanks,
Jeff
Joonatnoon said:
Hi,
For a relative arch Linux beginner, what resources would you point one to to be able to implement this on an OG kindle fire HD 8.9?
I'm decently comfortable on the command line, but once it starts getting deep in the kernel, I am a little more cautious..
Many thanks,
Jeff
Click to expand...
Click to collapse
It depends on what you want to achieve. This kernel will happily work on any kindle fire 8.9 2012. LTE version just has an additional board with a modem on it, (and needs another Bluetooth firmware).
At some point, I created a bit more user-friendly image of Manjaro with LXQt suitable for dual-boot, but without hardware acceleration, it was too sluggish for any real use.
If you want to have some fun and do something useful at the same time, I'd suggest adding support for this device in postmarket os project.
The starting point is here https://wiki.postmarketos.org/wiki/Porting_to_a_new_device
If you encounter any difficulties, feel free to ask
ipipipipip said:
Hi Jack, since last update I got some additional pieces working. Specifically: sound (and that was a brain-teaser for a long time) and LTE modem are working now. UEFI boot with u-boot implementation is functional.
Indeed 7-inch tablet may be brought-up with quite a low effort: lcd panel is slightly different, but there is a driver for it already in kernel, touch screen is also different. Apart from that rest of the stuff should work quite the same, that is usb, uart, wifi, bt, audio, backlight, keys, emmc, hdmi, with minor DeviceTree adjustments.
Same for u-boot: for basic functionality only a few pin-assignment changes are needed.
Click to expand...
Click to collapse
Thanks for all this. I hope to port the 7 inch version (soho) to postmarketOS (am surprised you didn't want to get jem running it so you can have a nice touch interface).
Have you seen the attempts to get mainline drivers that interface with PowerVR SGX 5xx graphics firmware? Seems like one day there might be 3D working...
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
One more question - have all the changes you described been pulled upstream, so I can just fork from mainline, or are some important ones still not yet in, so I should fork your repo?
Thanks again for all your efforts - I am very excited as to how this will benefit soho development.
Jack_Kekzoz said:
Thanks for all this. I hope to port the 7 inch version (soho) to postmarketOS (am surprised you didn't want to get jem running it so you can have a nice touch interface).
Click to expand...
Click to collapse
I did get it run postmarket, but it was somewhat clumsy and not properly integrated into a build tree. Also, it seemed a bit clumsy to update-rebuild-flash-reboot firmware image after a change contrary to rebuilding some users-pace parts just on the device.
Have you seen the attempts to get mainline drivers that interface with PowerVR SGX 5xx graphics firmware? Seems like one day there might be 3D working...
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
Click to expand...
Click to collapse
If only there was a non-android userspace driver for sgx544sc that is in 4470, inb4: ti still uses sgx544 in their new chips, but it is different.
Would be nice to have 3d, but I'm afraid that without major testing and bug fixing (on source code driver level, which is closed) It will be buggy as hell.
One more question - have all the changes you described been pulled upstream, so I can just fork from mainline, or are some important ones still not yet in, so I should fork your repo?
Click to expand...
Click to collapse
Nope :angel: . Clone my repo.
Hello again,
I've been trying to get a downstream kernel postmarketOS running on soho, and had noted the bootloader refused to load my kernel (just went to fastboot) unless I hexedited some zeroes (and some other data) at the beginning of my boot image (a technique required for the one custom rom available for it), after which it bootlooped. I see jem too requires some boot image manipulation to get cm11 on it (https://github.com/LineageOS/android_device_amazon_jem/blob/cm-11.0/boot.mk) - how did you get your kernel booting? I don't know much about the boot process, but I imagine there is some sort of signature verification Amazon cooked in that the hex data added at the beginning confuses.
Can I pm you?
Thanks,
Jack
Hi, yes boot image is signed and verified, but at least on Jem there is a vulnerability in stock u-boot that allows to bypass the signature check and execute arbitrary code.
Not sure how it is done on soho, but, at a first glance, the exploit looks kinda the same (even addresses are the same).
https://github.com/TeamWin/android_device_amazon_soho/blob/cm-12.0/exploit.mk
On jem there is an image size check missing when loading boot image into ram. The boot.img header contains image size to be loaded, and thus if you load a large enough chunk you will overwrite current stack frame (and what's important - return address), thus after data is loaded bootloader will jump to user-specified address. The trick is to load your executable code (second bootloader in my case) into ram (put it somewhere at a known place in boot partition) and use that address to overwrite the stack.
One problem was that main boot partition is too small (8MiB) to contain a patch to overwrite the stack, thus initially it was placed somewhere at the beginning of system partition (with hopes and prayers that it will not corrupt ext4). But then I resized those partitions to 16MiB which is enough to fit everything.
If you don't want to bother with modifying bootloader, just retrofit those boot image creation makefiles.
Thanks - so how did you modify your boot image when you were tinkering with pmOS? Did you just replace the stock u-boot so no exploit was necessary? I thought x-loader would refuse to load any u-boot not signed with Amazon's keys? Sorry, you stated you put your second bootloader at an address in the boot partition. I'm just curious as to how exactly one does that when building pmOS.
Thanks,
Jack
Who knows, there is actually no sane way to create simply flashable boot.img without resizing boot partition first, that I highly suggest you to do. Make a backup of all partitions and gpt table, practice a bit on a spare sdcard, boot twrp, remove boot partition, and what's after it, then recreate those with sizes as need (and don't forget to restore partition names, that's important). Also would be handy to increase system partition size on the way, by sacrificing userdata size.
But, if you have working third party ROM, and don't expect to fiddle with bootloader, chances are you may get away with just dd-ing a few values and 2nd loader over boot.img postmarket builds (there is a package stage in linux-xxx target in postmarket's APKBUILD where you can put this code), and hope that magic value (stack smashing value) will not be overwritten while installing firmware
Thanks for this info. I've managed, through your help and others, to get a boot pmOS (on a downstream kernel). I'm in the process of merging my work, and the question is being asked of the boot hack, which I am hoping to get merged into postmarketos-mkinitfs package (not in an APKBUILD for soho) - are there any other devices that use a similar hack? If the answer is yes, I think it makes sense to include them in the same portion of code for future pmOS jem attempts - I know you didn't want to merge all your code, and that's ok, but could I make a request for one part of it? Please may I ask what exact shell commands you needed to run to amend jem's boot.img so that tricking the signature check takes place? For what it is worth, for soho I adapted the boot hack in the rom makefile to the below:
SOHO_HEADER_DATA='\x50\x03\x00\x00\x00\x25\xe4\x00'
SOHO_HEADER_SIZE=848
SOHO_HEADER_OFFSET=52
tempfile=$(mktemp)
dd if=/dev/zero of="${tempfile}" bs=$SOHO_HEADER_SIZE count=1
printf "%b" $SOHO_HEADER_DATA | dd of="${tempfile}" bs=$SOHO_HEADER_OFFSET seek=1 conv=notrunc
cat "${outfile/initramfs-/boot.img-}" >> "${tempfile}"
mv "${tempfile}" "${outfile/initramfs-/boot.img-}"
(I didn't need to resize my boot partition as I believe the hidden bootloader is stored in the recovery partition.) Anyway, thanks for all the help. I'm going to work a bit more on polishing my downstream port before turning my attention upstream, and copying most of your dts and relevant commits
Nice , as for other devices: fire hd 2012 7" (IIRC it is called tate) is likely using the same hack, and that's it, it was an amazons bug so no other devices affected. You may assume that the commands for jem are exactly the same.
BTW, may I have a look at a merge request for postmarketos-mkinitfs, when you create it? I dug a bit, trying to find a nice clean method of wrapping boot.img after mkinitfs creates it, but didn't found any. The closest thing that exists are a few device-specific "sign" steps, which are almost exactly what we need, except that, I don't want to add more ugly device-specific checks in build scripts. Some generic field that names the tool for signing and a separate package that does that device-specific signature would've been the best IMO.
I guess It's time to rebase jem to a latest kernel, with a cleanup, coz a few things are broken now and need additional rework.
The Kindle Fire 2 (otter2) also appears to require a similar exploit. Merge request is here: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1995
Rebasing jem sounds exciting!
I don't know if you've read the MR comments, but lead dev Ollie has just said what you said re device specific code. Time to rewrite then...
I was running a U1 XAA build of Android 10 2.0 with the
June 1 Security patch that I'd downloaded and flashed
from Sammobile.
Awhile ago I downloaded and flashed the U1 XAA 2.1 update from the same place and noticed that there
are a number of apps I can no longer deny Wifi Control
access to under the Apps Special access area:
DeviceTest
DeviceKeystring
FACM
Gear VR Service
Voice wake-up
being 5 out of the 12 I cant deny access to.
Also I am no longer able to disable Google Play Services
whereas before in 2.0 I could. I'm not even allowed to forcestop Play Services now! Its not just these two changes, there are other things I used to be able to disable but now can't. And I have *two* 'SmartThings'
apps, one is version 10.0.37.0 and the other is version
1.7.50-21 (the-21 is just how its listed.)
I know this all sounds somewhat tame and trivial but I would like to know if this is all normal and can be confirmed by anyone else.
Anyone
-----------------
**Update**
Okay, just wanted to post some info on some sort of resolution to the above, mostly for those who make honest and earnest pleas for help and ask really pertinent questions but are ignored by the knowledgable (or criminal)
peruser.
In short, I was hacked. It doesn't come as a surprise (has happened *many* times with my N9. It *does* make me wonder about that supposed military-grade Knox security)
How do you know if you're hacked?? I just used the Running Services lister under Development Tools. Look
for services that shouldn't be running as often as they do
(Last hack they had Samsung Push which is for delivering notifications related to Samsung apps?? running something as a Service (not sure what it was but as soon as I stopped it, it popped right back up) or things you never use or have deactivated showing up in the cache (ESPECIALLY Aircommand!! Disable this as a Trusted Agent immediately! And keep an eye on it, and always keep the Air Remote feature OFF).
Also, the Google Play Store app. When I flashed the July 2020 Security update I noticed the Play Store was still at the May 2020 version update. I didn't think much of it at the time, but after having to Factory Reset I noticed it now read July 1 2020. So I guess the 'worms' have the May version hacked. Sucks that villany loves working for free breaking stuff, but in order to build something up and protect it, it takes toil and coercion.
Finally (Not sure if this is actually a sign of malware or hacking, but the only reference I could find relating to it
was from a guy who was truly beleaguered by hackers)
theres a User Certificate under Biometrics & Security / Other
Security settings / User Certificates that reads as
'FindMyMobile' and purports to being necessary for VPN security and other applications. Well, I had Find My Mobile
deactivated and uninstalled via ADB and it still showed back up after being deleted numerous times and my VPN seems to work without it. It might be for the Note 9's
built-in Knox android VPN strengthening parameters, but I couldn't find nfo online about it anywhere except in the case I mentioned which seems very odd. Qualifying proof of its malicious intent for me?: After factory resetting it hasn't shown back up.
I dont think my N9 is cleaned or I should say I'll never trust a smart phone fully again, not until the outdated and hacked 40 year old SS7 protocol that runs all cellular communications is updated, not until something more reliably secure than 'somewhat' obsfucatingly complex baseband processors are present in phones and maybe something akin to a hardware firewall in the soc that can interpret and filter non-carrier invalid commands (prob only need to update that damn SS7 protocol!) I'd also love it if Google/Alphabet would dump Android and start over with a new updated mobile OS with security at the forefront (Think, updates delivered via 'Middleware', roms bought initially directly from the manufacturer that can be crytographically flashed up to three times with signed updates with each update burned and locked into the rom via fuses. Each factory reset brings you back to your last update. The roms are only updatable if a hardware dip switch is tripped which moves actual physical leads in the soc which powers the ability to flash this chip. And maybe screw AOSP, I wonder if all this open sourceness has actually given the malware creators more knowledge to
finess the software and the hardware. The so-called white-hat 'Ethical Hackers' (LOL! HOW can breaking into someone's personal space without permission outside of national defense be considered ethical?!? All hackers are criminals. If you want to be considered a 'good' hacker (*snort*) bring to light the measly exploits and software, the slime who make and distribute the same and tell how to protect against them and detect them and disable them. Criminals giving webinars and seminars about how to circumvent protections for devices that billions of people rely on for living should be outlawed FULL-STOP-PERIOD I'd rather have one slime who knows how to get into a system than having that slime be allowed to freely distribute the software and knowledge so that millions of other definately less conscionable scum can make use of his knowledge.)
hackers only care about making their fame and fortune by
beinging to light obscure and unknown exploits that no one has ever used or are likely to use than going after to exoloits that *are* in use and *do* affect those in the here and now. It must give some sense of ease not to be in contention with real criminality and the fear of any reprisals from the 'less-ethically saturated' in the tech community.
Just wanted to get that out somewhere. I know its pointless and no-one will listen. Look at what Edward Snowden sacrificed for people who were/are unworthy of *any* sacrifice by betraying everything bit by bit, battle by battle until it must one day be reclaimed (if it can be) via costly confrontation, disruption and perhaps irrevocable critical loss.
Okay, END RANT. Yeah, a slow day, corona cloud and all.
But seriuosly the Feds need to check all this electronic criminality, its gotten waaay out of hand. TO FEDS: Less hunting terrorists, MORE hunting electronic predators and anarchists!
Hi, @tamdwin,
Even though you believe your phone may have been hacked, DeviceKeystring, DeviceTest, EmergencyManagerService, FACM, IMS Service, IOTHiddenMenu, Samsung MirrorLink 1.1, Settings, Setup Wizard, Wi-Fi Direct & WlanTest are enabled on my Note9 with One UI 2.1, Security patch: 1 July 2020 (w/out Google Play Services/Google Play Store, Bixby, GearVR, DeX...only have Google Services Framework installed).
After downloading the 1 July 2020 Security update, I noticed that these services could no longer be turned off for wi-fi control.
Wish I never downloaded the update for the fancy camera features, lol.
Snowden? Have you read any of his articles on smartphone security? (you may want to throw your phone in a blender after reading...)
Some of the settings, such as disabling "Find My Mobile" from running in the background, reset/enable after you restart the phone.
Snowden? Have you read any of his articles on smartphone security? (you may want to throw your phone in a blender after reading...)
But will it blend!
https://www.youtube.com/watch?v=FN9mktgYZJ8
I am worried about these things, so I am looking at developing my own custom ROM.
Sorry for my English I Am brazillian
@P00r ROFL! The Samsung S4 Active shake looks delicious! Thank you for sharing the vid!
silvaBR said:
I am worried about these things, so I am looking at developing my own custom ROM.
Click to expand...
Click to collapse
That sounds like an excellent plan!