Android - what process to kill?

[DeskJockey]

Disclaimer: techy, possibly boring.

TL;DR: Nixplay are being a cunch of bunts. Tech hivemind I need your help (insert bat-signal-style projection of a nerd onto the nearest cloud).

So... we've had a Nixplay Seed 10 for years. And until fairly recently it has run through a connected Google Photos album of some 2300 pictures without any issues. Nixplay, in their infinite stupidity, decided that you now need a subscription to access the features you bought and paid for once already, even those that don't cost them anything. There's no opt out, grace period or anything else. Just more e-waste. The frames are suddenly limited to 500Mb of pictures stored "locally" (Nixplay's S3 bucket(s) I think), that's it.

I'm not the only one that's angry about it and there are people actively hacking the various models to run other software on them. It is just an Android tablet underneath the fancy frame. Some of them come with USB debugging enabled from the start, but sadly mine doesn't.

Thus to the tech.

I've got ADB and Vysor running and know both work as I can connect fine to an old tablet. The picture frame, not so much. There is only one point at which I get the "USB connecting" sound, followed fairly quickly by the disconnection sound, and that is when it is doing a factory reset.

Someone else mentions being able to kill the relevant process which then doesn't disable the USB debugging, but I can't see that the process they mention is running on mine. I managed to get a process list before it disconnected and was wondering if any of you knew which one to kill in the gap I have available (10ish seconds)

USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 1704 464 ep_poll 0006f8a8 S /init
root 2 0 0 0 kthreadd 00000000 S kthreadd
root 3 2 0 0 smpboot_th 00000000 S ksoftirqd/0
root 4 2 0 0 worker_thr 00000000 S kworker/0:0
root 5 2 0 0 worker_thr 00000000 S kworker/0:0H
root 6 2 0 0 worker_thr 00000000 S kworker/u8:0
root 7 2 0 0 smpboot_th 00000000 S migration/0
root 8 2 0 0 rcu_gp_kth 00000000 S rcu_preempt
root 9 2 0 0 rcu_gp_kth 00000000 S rcu_bh
root 10 2 0 0 rcu_gp_kth 00000000 S rcu_sched
root 11 2 0 0 smpboot_th 00000000 S watchdog/0
root 12 2 0 0 smpboot_th 00000000 S watchdog/1
root 13 2 0 0 smpboot_th 00000000 S migration/1
root 14 2 0 0 smpboot_th 00000000 S ksoftirqd/1
root 15 2 0 0 worker_thr 00000000 S kworker/1:0
root 16 2 0 0 worker_thr 00000000 S kworker/1:0H
root 17 2 0 0 smpboot_th 00000000 S watchdog/2
root 18 2 0 0 smpboot_th 00000000 S migration/2
root 19 2 0 0 smpboot_th 00000000 S ksoftirqd/2
root 20 2 0 0 worker_thr 00000000 S kworker/2:0
root 21 2 0 0 worker_thr 00000000 S kworker/2:0H
root 22 2 0 0 smpboot_th 00000000 S watchdog/3
root 23 2 0 0 smpboot_th 00000000 S migration/3
root 24 2 0 0 smpboot_th 00000000 S ksoftirqd/3
root 25 2 0 0 worker_thr 00000000 S kworker/3:0
root 26 2 0 0 worker_thr 00000000 S kworker/3:0H
root 27 2 0 0 rescuer_th 00000000 S khelper
root 28 2 0 0 devtmpfsd 00000000 S kdevtmpfs
root 29 2 0 0 rescuer_th 00000000 S netns
root 30 2 0 0 worker_thr 00000000 S kworker/0:1
root 31 2 0 0 worker_thr 00000000 S kworker/2:1
root 32 2 0 0 worker_thr 00000000 S kworker/3:1
root 33 2 0 0 worker_thr 00000000 S kworker/1:1
root 34 2 0 0 console_th 00000000 S kconsole
root 35 2 0 0 rescuer_th 00000000 S writeback
root 36 2 0 0 rescuer_th 00000000 S bioset
root 37 2 0 0 rescuer_th 00000000 S crypto
root 38 2 0 0 worker_thr 00000000 S kworker/u9:0
root 39 2 0 0 rescuer_th 00000000 S kblockd
root 40 2 0 0 hub_thread 00000000 S khubd
root 41 2 0 0 worker_thr 00000000 S kworker/u8:1
root 54 2 0 0 ion_heap_d 00000000 S vmalloc
root 55 2 0 0 rescuer_th 00000000 S cfg80211
root 56 2 0 0 irq_thread 00000000 S irq/160-rk818
root 57 2 0 0 irq_thread 00000000 S irq/76-rga
root 58 2 0 0 rk_fb_wait 00000000 S fb-vsync
root 59 2 0 0 kthread_wo 00000000 S rk-fb
root 60 2 0 0 cpufreq_in 00000000 S cfinteractive
root 61 2 0 0 rescuer_th 00000000 S rpciod
root 62 2 0 0 rescuer_th 00000000 S rk818-bat-monit
root 63 2 0 0 rescuer_th 00000000 S rk818-bat-charg
root 64 2 0 0 irq_thread 00000000 S irq/163-rk818_d
root 80 2 0 0 irq_thread 00000000 S irq/38-10106000
root 81 2 0 0 irq_thread 00000000 S irq/39-10106000
root 82 2 0 0 irq_thread 00000000 S irq/98-10104000
root 83 2 0 0 watchdog 00000000 S khungtaskd
root 84 2 0 0 kswapd_try 00000000 S kswapd0
root 85 2 0 0 ksm_scan_t 00000000 S ksmd
root 86 2 0 0 fsnotify_m 00000000 S fsnotify_mark
root 87 2 0 0 rescuer_th 00000000 S nfsiod
root 88 2 0 0 rescuer_th 00000000 S cifsiod
root 109 2 0 0 irq_thread 00000000 S irq/80-10108000
root 110 2 0 0 rescuer_th 00000000 S dwc_otg
root 111 2 0 0 rescuer_th 00000000 S uether
root 112 2 0 0 rescuer_th 00000000 S kpsmoused
root 113 2 0 0 ir_raw_eve 00000000 S rc0
root 114 2 0 0 rescuer_th 00000000 S dm_bufio_cache
root 115 2 0 0 rescuer_th 00000000 S dw-mci-card
root 116 2 0 0 rescuer_th 00000000 S dw-mci-card
root 117 2 0 0 mmc_queue_ 00000000 S mmcqd/0
root 118 2 0 0 mmc_queue_ 00000000 S mmcqd/0rpmb
root 119 2 0 0 rescuer_th 00000000 S binder
root 120 2 0 0 rescuer_th 00000000 S rk312x-codec
root 121 2 0 0 worker_thr 00000000 S kworker/u8:2
root 122 2 0 0 worker_thr 00000000 S kworker/u8:3
root 123 2 0 0 rfcomm_run 00000000 S krfcommd
root 124 2 0 0 worker_thr 00000000 S kworker/1:2
root 125 2 0 0 ddrfreq_ta 00000000 S ddrfreqd
root 126 2 0 0 rescuer_th 00000000 S dvfs
root 127 2 0 0 worker_thr 00000000 S kworker/0:1H
root 128 2 0 0 rescuer_th 00000000 S deferwq
root 129 2 0 0 rescuer_th 00000000 S f_mtp
root 130 2 0 0 sleep_thre 00000000 S file-storage
root 131 2 0 0 rescuer_th 00000000 S oo
root 132 1 1960 408 poll_sched 000668a4 S /sbin/ueventd
root 133 1 1456 304 ep_poll 00037940 S /sbin/healthd
root 134 1 206668 190268 pipe_wait 0008d8a4 S /sbin/recovery
root 135 1 6052 384 poll_sched 0002ae44 S /sbin/adbd
root 136 2 0 0 worker_thr 00000000 S kworker/u9:1
root 137 2 0 0 kjournald2 00000000 S jbd2/mmcblk0p10
root 138 2 0 0 rescuer_th 00000000 S ext4-dio-unwrit
root 186 134 219636 183896 0 00017e7c R /tmp/update_binary
root 189 2 0 0 kjournald2 00000000 S jbd2/mmcblk0p13
root 190 2 0 0 rescuer_th 00000000 S ext4-dio-unwrit
root 346 135 2724 1024 0 b6e9ec94 R ps

Would appreciate some thoughts on the matter as I am not clued in enough on Android/Linux to identify the right one.

Cheers!

[Beany]

First off, I think the person saying 'stop a process to allow debug mode to run!' might be talking shite - debug mode being disabled will not be being kept alive by a running process, that's just bad security practise - if the process crashes, then debug mode is enabled, which even a shitheel company like this wouldn't fall for doing.

Secondarily, that just isn't how it works. it's a linux system at heart, so it'll be a preference in a file somewhere or a process flag that gets run at boot. Apparently (as I've not done this for years) it's commonly

Code: Select all

# Enable ADB
persist.service.adb.enable=1
persist.sys.usb.config=mtp,adb

In the system build file - the one it refers to on boot, basically. Like an Autoexec.bat or config.sys if you're old enough to have messed with DOS machines.

Backing away from that, for most devices, they'll have a keypress combo or a command sent over ADB to get into fastboot/recovery mode - at that stage, you can start messing with the system a bit, although I'd expect on that, it'd be sitting for ten seconds, awaiting a specific command over the ADB to make it go into fastboot/recovery. If it doesn't get that, then it launches normally.

I've had a quick squizz around and it looks like they used different chipsets for different devices, and each chipset has it's own particular way of getting to fastboot/recovery, so I think until someone with more time on their hands, and experience, than us comes up with a working manner for your seed, you might be a bit fucked, sadly.

Still, never underestimate a hardware hacker filled with spite - it almost certainly will get cracked soon enough if people are already attacking - sorry, fixing - their other devices.

[Rich B]

https://www.apple.com/uk/iphone/?afid=p ... act-iphone

[Mito Man]

https://www.apple.com/uk/iphone/?afid=p ... act-iphone

No point Rich, the androiders are a lost cause

[IanF]

https://www.apple.com/uk/iphone/?afid=p ... act-iphone

No point Rich, the androiders are a lost cause

I was about to post an Apple.com link,.. sarcastic minds think alike?

[Matty]

Between the 3 of you, no one noticed this was about picture frames, not phones?

Probably best you all stick to the iPhones, tbh

[Beany]

Between the 3 of you, no one noticed this was about picture frames, not phones?

Probably best you all stick to the iPhones, tbh

I didn't want to say.

But then again, Apple users. Not a shock they don't understand tech.

[DeskJockey]

I just ignored them.

@Beany I get your point, but during the factory reset process USB debugging is clearly working, and then it is disabled. I guess the question should be what process in that list updates the config to disable it.

I'll continue digging around to see what happens.

[IanF]

Between the 3 of you, no one noticed this was about picture frames, not phones?

Probably best you all stick to the iPhones, tbh

That’s the great thing about iOS, it works (and connects) all devices, so we don’t have to worry about tech being made obsolete on the “free market”.. sorry

[Beany]

I just ignored them.

@Beany I get your point, but during the factory reset process USB debugging is clearly working, and then it is disabled. I guess the question should be what process in that list updates the config to disable it.

I'll continue digging around to see what happens.

I don't think it's enabled and disabled in a way you can impact - it's going through initial boot, then moving onto full boot - think bios, and HDD.

I'd imagine that the debug gets disabled after it's not had a "no, hold on, I want to fuck about" signal over ADB - that's one way of having it set up and it's fairly common on embedded/appliance style devices.

Switches and routers are often the same - thier debug modes run for five or ten seconds, then get disabled if they don't get a command that tells them to stay available and the boot sequence then continues.