Hacking old Galaxy Tabs for better living

How I helped my high-rise neighbors to actually own their smart homes

Similar projects worth following
My apartment came with a "black box" smart home setup with no technical documentation. In this project I go from manually rooting and exploring my apartment's wall-mounted Galaxy Tab 3 10.1 P5210 tablet to testing vulnerabilities to develop an easy to use multi-tool app to share with my neighbors.

When I moved in to my brand new apartment in a newly constructed high-rise, I was intrigued - it was designed with smart home functionality in mind and every light, power socket, window blind was remote controlled in addition to push-buttons placed around the rooms. Also all HVAC and bathroom floor heating functions were interfaced as well. Besides the DIN-rail mounted relays and PLCs the heart of the user interface was a wall-mounted tablet: every one of the 128 apartments had a Galaxy Tab 3 10.1 P5210 configured with Android apps for smart home control, apartment doorbell and IP intercom. We were given a basic user interface manual but no technical docs, so I set out on figuring how it all works.

Including example usage snippets for getting the WiFi password, disable packages and reboot the tablet

Java Source File - 2.50 kB - 09/12/2021 at 11:27



List of bloatware package names to be disabled (combined list for OS 4.2.2 and 4.4.2)

XML - Extensible Markup Language - 5.71 kB - 09/12/2021 at 11:18


  • A sense of accomplishment

    Neighborino09/12/2021 at 10:19 0 comments

    💡💡 PROTIP: To experience this exciting story of self-discovery and why I hated chocolate at some point, read through the project logs starting with the oldest:

    With my toolkit app every apartment can now:

    • Backup the previously undisclosed WiFi password - I advised everyone to do it ASAP before the 8 years old tablets fail completely
    • Considerably speed up their aging tablets by removing everything except for the smart control apps
    • For good measure, one can schedule an automatic tablet reboot to keep it in shape - using these two methods the aging tablets will be able to work for a bit longer
    • With the WiFi password for each apartment now revealed to its owners, one can go and get a new tablet model and reinstall all the smart home apps on it when they choose to do so - I upgraded mine to the Galaxy Tab A7 Wi-Fi SM-T500.

    And all that with a simple APK sideload via internal network. No changes were made to it and every homeowner can decide whether to use my app. Getting limited root access happens within seconds after the first app launch and is completely automated in the background and doesn't even require a reboot or removing the tablet from its wall mount.

    There have been no reports of issues and it feels great knowing I could share my enthusiast hobby findings with others.

  • WiFi Password Revealer becomes an all-in-one toolkit!

    Neighborino09/12/2021 at 09:45 0 comments

    All through this project I was "forced" to use the sluggish Galaxy Tab 3 a lot and was really fed up with how slow it was. Besides mounting a consumer grade tablet with a degradable battery to the wall and expecting it to last for the lifetime of the apartment this is another caveat - the tablet came preloaded with so much stuff that any additional apps, even if lightweight, were constantly getting killed while in the background and after a few weeks of uptime the tablets would become so slow regular reboots were needed. If only the smart home supplier would have disabled at least some of them on each tablet before installing them... but some of the apps could not be removed or disabled by the user and one could not expect a supplier to go so far as to root the tablets anyway, right?

    I added a reboot scheduler to my app with a suggested frequency of 1 week.

    But the one thing that made the most impact was when I decided to disable all packages except for the essentials. To my app I added a Debloat and Rebloat options and painstakingly compiled a blacklist of package names which could be safely disabled:

    • First on the list were all the applications and games which came preinstalled - I just made my way through the application list in the Settings app.
    • Then I came for Google and Samsung services. There were a lot and they were completely unnecessary as the tablet did not have internet access or was ever meant to be used beyond the smart home apps anyway.
    • I left the core system packages alone, also of course did not disable FactoryTest.apk and just left the File manager, Samsung Browser and smart home apps.

    After doing the umpteenth TWRP backup restore to get to the baseline and executing the Debloat command and rebooting, the tablet booted up much quicker than never before! And the RAM consumption has shown a dramatic incerase of free resources as well:

    Apps blacklisted: 114 (see bloat.xml in this project's files), tablet boot time reduced from 45 seconds to 25! Free memory increased from 350 MB to 450+ MB.

    The app was now ready. The neat thing about the high-rise internal network was that even though it was mainly used for IP intercom/weather forecast communication, I could configure up my WiFi access point/router so that port 80 went through to a Raspberry Pi web server connected to it. That way my neighbors just had to open the Browser app on their tablets, enter my apartment's local IP address and sideload the toolkit APK. I even made a step-by-step guide with screenshots.

  • Look ma, no reboot

    Neighborino09/12/2021 at 09:29 0 comments

    I was free to code the new FactoryTestBroadcastReceiver receiver (you can find the code in this project's files) as I pleased and I decided on a generic approach - that way I could supply a payload in the form of shell commands which would then be executed in onReceive() and the output would be sent back to my app in a form of another Broadcast. That way I could issue a "cat /data/misc/wifi/wpa_supplicant.conf" to read the contents of the file or "pm disable" to get rid of the preinstalled app bloat.

    I compiled this class into a Dalvik cache compatible .odex on both OS versions: 4.2.2 and 4.4.2 and packaged it into my app together with the dirtycow binary which I XOR'd so that would not upset any of my more curious neighbors - I was not trying to hack them, after all. In any case, I disclosed how the app works in my instructions page so it was all good.

    My first 2.0 app asked the user to reboot so that the new Dalvik cache would be used (since it was in-use and running in the background at the time), but since the tablet was trapped in a wall mount with difficult access to the reset button and the only other way (which I discovered too late in any case) was to enable a on-screen accessibility menu, I was glad to think of the weird free-for-all KILL_BACKGROUND_PROCESSES permission which can be used with killBackgroundProcesses("com.sec.factory") to kill the system app without any special permissions. Then I could dirtycow (which is now a verb I guess) the .dex and the next Broadcast would make the Android OS wake up the app and luckily for me it would load the new code now - no reboot needed!

    I was very happy with the results and preparing to share my app with my neighbors.

  • All thanks to Samsung and SwiftKey partnership

    Neighborino09/12/2021 at 09:19 0 comments

    I was trying all kinds of stuff to get the hidden code do my bidding but even though there was some promise, I just could not get the foot in the door to pry it wide open. I did more research and found...

    Remote Code Execution as System User on Samsung Phones by NowSecure

    It was a fun read. It turns out some versions of the preinstalled keyboard software got updates via ZIP files served via http (that can be MITM'd) which were then promptly extracted to the filesystem. The nasty thing is how ZIP files can contain relative paths which leads to path traversal which in turn means arbitrary writes.

    But I hear you say, don't you already have dirtycow for that? Indeed I do - I don't need to abuse SwiftKey at all. But the author of the research paper was not done yet - they decided to attack the Dalvik cache and more specifically, the DeviceTest app which I was already looking into myself.

    It's pure genius: we prepare a replacement Dalvik cache .odex for the com.sec.factory.entry.FactoryTestBroadcastReceiver class which can be triggered with an unprotected MEDIA_SCANNER_FINISHED broadcast and all the new Java code will execute in the system context!

    Dirty cow is well up to the task of messing with the /data/dalvik-cache/system@priv-app@DeviceTest.apk@classes.dex file and for a bonus it is not on a read-only partition which means no chance of file corruption. It can be easily reverted to the original, too.

    The missing part of info which I was happy to learn was how to trick Android into thinking the new cached .dex was valid - because the OS will otherwise generate a new one upon reboot (during the "Optimizing apps" phase): one simply needs to copy the old CRC32 and date from the file header and inject it into the newly compiled .dex.


    Now I had everything I need and it was time for some app development!

  • The things you find in production builds

    Neighborino09/12/2021 at 09:03 0 comments

    It became apparent that there was no low hanging fruit or indeed any fruit that I could reach from the Android vulnerability tree that would get me the access I needed. At least not something that would cover both OS 4.2.2 and 4.4.2. I then focused my efforts into the specific OS build Samsung made for their tablet with all the bloat and hidden apps.

    It's amazing how much stuff is running in the background of the tablet and it explains why it lags even after factory reset - there's Google stuff split into several apps, Samsung first party apps and all the partnership preloaded stuff that keeps growing in size with each new device and makes me feel like us users are the product.

    I investigated all the preinstalled APKs focusing on keywords such as test, factory, debug,... and found a potential target: app with package name com.sec.factory deployed from DeviceTest.apk. It had system level permissions and its AndroidManifest.xml showed A LOT of potential entry points. It was the equivalent of chmod 777 * -R. It seems that Samsung engineers figured that some kind of root access was needed during device/OS development and testing and why not keep it in production builds, too, but protected by a custom Android permission? And best of all - a very similar app was present on both Jelly Bean and KitKat OS images.

    The code quality was bad. It looked quickly put together with many complex relationships with other hidden preloaded apps in the form of private Activities, BroadcastReceivers and Services. Some of the test/debug features can be triggered through a special code entered in the Calculator app. I was overwhelmed but excited - I knew that they have forgotten something somewhere that would give me access!

    A great paper on this:

  • Let's sacrifice Wi-Fi Direct

    Neighborino09/11/2021 at 15:41 0 comments

    I investigated the tablet filesystem a bit further and found out that wpa_supplicant was not the only binary that had access to WiFi config - there was another! p2p_supplicant could be abused to the same effect but even if it became corrupt, it wouldn't matter because the Wi-Fi Direct features it provided would fail silently and were never used on this tablet.

    I was ready with my 1.1 app now!

    I sent it to an eager beta tester/neighbor and awaited results.

    ... and then I got foiled by chocolate.

    It turned out of all the neighbors I could have sent my WiFi password revealer app to, the one that volunteered had a tablet running not Jelly Bean but Android OS 4.4.2 KitKat which was the last officially supported OS on the Galaxy Tab 3 10.1.


    I coded my app so it would show a "Device unsupported" warning and it triggered, preventing my neighbor from experiencing my awesome app.

    I needed to take a break and regroup.

  • Fantastic cows and where to find them

    Neighborino09/11/2021 at 15:31 0 comments

    It turns out the dirtycow exploit is a complex thing with many possible implementations:

    I tried them all out and was excited by the supposedly "memory-only" PoC but realized it still needs to do modifications to in order to work. That's way too risky and offers no benefits to my original implementation - imagine having bricked half of my neighbors' tablets? I would have to take the stairs instead of the elevator just to avoid meeting the angry mob :)


    vDSO? Never heard of it! It turns out it's a Linux execution optimization feature that features a virtual that dirtycow can overwrite (and can't do any permanent damage to) but on the specific x86 Linux kernel build my tablet uses it does not expose enough stuff to work :( :( I learned some x86 assembly and managed to get it to reboot my tablet on command, but no filesystem calls worked and though it had great potential to safely read a read-protected file, it turned out it didn't want to.

  • So close, yet so far

    Neighborino09/11/2021 at 15:17 0 comments

    The kernel version marked 3.4.34-2545684 on the 4.2.2 tablets was ripe for some dirtycow-ing.

    The PoC at compiled great for x86 Android and just like that I had root access. Unfortunately some targets such as /system/bin/run-as could only be touched via adb with the tablet "tethered" to the PC which was once again not what I had in mind - one had to be able to execute the privilege escalation from inside an app running on the device.

    I then made a breakthrough when I considered which binaries actually had access to the wpa_supplicant.conf - would you know it, it was actually the wpa_supplicant program itself!

    High-rise wall-mounted tablet WiFi password revealer 1.0!

    Having made a successful exit from our mobile app startup some years prior, I no longer had Android Studio installed (taking an extended vacation from gradle did me a lot of good!) and after getting back into it, I developed an app which would:

    1. Disable WiFi so wpa_supplicant would finish running - any app can do this with sufficient permissions.
    2. Make a backup of it and use the dirtycow exploit to overwrite it with a simple program that upon execution makes a copy of wpa_supplicant.conf to /sdcard
    3. Enable WiFi which executes my program with elevated privileges. Then wait a moment for the WiFi state machine to settle and once again disable WiFi.
    4. Put back the original wpa_supplicant binary and re-enable WiFi. It was as if nothing has happened.

    Now I can parse the .conf and display the WiFi password to the end-user.

    I then realized a dirty secret of dirtycow and how it affects read-only file systems:


    This means that steps 1-3 worked but getting the file back to original failed or rather, it seemed to take, but after rebooting the tablet, the file contents would get scrambled/corrupt and no amount of dirtycowing would fix it. Even a factory reset won't help because there is no backup copy of the /system partition. Only restoring a TWRP backup or flashing the stock firmware via ODIN would help.

    What good is a WiFi password if the cost is ruining WiFi connectivity of the smart home tablet?!

  • Biting into the Swiss cheese

    Neighborino09/11/2021 at 15:02 0 comments

    Note that at this point I believed every tablet ran Android OS 4.2.2 Jelly Bean.

    I found a great vulnerability resource at and in the end reviewed and tried out proof-of-concepts for every supported vulnerability listed.

    Besides the generic Android OS vulnerabilities it quickly became apparent that once the Android source went through the hands of Samsung developers and their product managers it gained many preinstalled user-facing and "hidden" apps together with a scary amount of new vulnerabilities, which will later turn out to be a blessing in disguise.

    I never before went down the rabbit hole of specific CVEs and it was an exciting and educational journey for me, a Java-focused Android developer with moderate C/Linux knowledge. I felt humbled by the security researchers and disturbed by the amount of attack vectors - in such complex systems it seems you can only do damage-control, you can never be fully secure, especially when considering the competition on the smartphone/tablet market, where companies have to innovate to stay on top and under-the-hood code security counts for much less than the newest buzzwords and product marketing requirements.

    Going back to, here's what I found out:

    • libperf_event, TowelRoot/futex_requeue, ping_unhash
      Was not able to find a working PoC for my Intel tablet or compile a PoC from GitHub that would trigger this. It also seemed the Linux kernel Samsung chose for this tablet was different from what contemporary ARM Androids run on.
    • Fake ID
      I had great fun with this - I found scripts to make an APK that could impersonate the Flash Player plugin and get executed from any WebView context but there was no way to read the wpa_supplicant.conf file from there.
    • Stagefright, ObjectInputStream deserializable
      A family of various media file exploits I'm sure it could be used to do anything to the tablet but required the knowledge of assembly and crafting ROP chains with few x86 examples and thus way out of my league. Same goes for CVE-2014-7911.
    • dirtyc0w
      Now we're getting somewhere! A powerful exploit in the right hands, one could overwrite any file (even on the read-only mounted /system partition) with data less than or equal in size of the target. And the Linux kernel version of my tablet was vulnerable! While ironic that the only suitable exploit only allows for write access and not actually reading the contents, this cow that rolled in the mud too much was the One.

    • The WiFi password heist

      Neighborino09/11/2021 at 14:36 0 comments

      For myself, I had everything figured out - how the apps work and connected to the PLCs and internal building network using a dedicated WiFi access point and how exactly the tablet was configured from out of the retail box to the wall-mounted duty. I upgraded it to Android KitKat which seemed to speed it up a little but still I had to disable most apps to make it faster.

      But I wanted to help out my neighbors, too and 2 years ago I decided to finally document and share my knowledge. The goal at first was to focus on getting the WiFi password which could enable us to add additional devices to control the smart home and replace the aging original tablets. Also consider that if accidentally pressing "Forget this network" would require a visit from the infrastructure technician to re-establish the connection! This has happened before because some were tempted to fiddle with it.

      I had a few options to consider:

      • Everyone could take their tablets out of the wall mount, connect it via USB and after flashing a custom recovery, flash an auto root tool and then extract the WiFi password using an app that reads the wpa_supplicant.conf file... This it too complicated for anyone but enthusiasts and could brick the only device in control of the smart home, so out of the question.
      • I then explored the shady but apparently popular one-click-root apps distributed outside Google Play as risky APK downloads. They exploited known vulnerabilities to cover a wide list of devices and OS builds. However the x86 came out to bite me as no such app supported our tablet models and in any case, a complete root was overkill for what I was trying to achieve.
      • I then focused exclusively on the WiFi credentials file access - /data/misc/wifi/wpa_supplicant.conf - I would develop my own app that only forced its way through the file permissions to read back the contents of this file and display the password to the end-user.

    View all 12 project logs

    Enjoy this project?



    Arya wrote 09/15/2021 at 20:10 point

    hell yeah, this is great reading, thank you

      Are you sure? yes | no

    Similar Projects

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates