Skip to content

re-ws.pl

ReverseEngineering WorkStation

  • Home
  • Tutorials
  • Random
  • About

Authorizing adb connections from Android command line (and making other service calls from cli)

Posted on November 15, 2024 - November 18, 2024 by Kamil (aka. v3l0c1r4pt0r)
sunmi-partner-login
Login page that appears after clicking on Debugging
adb-authorize-replacement-sumni
ADB authorization window on Sunmi V2s

I just received POS tablet, precisely Sunmi V2s. I bought it for fraction of its prize due to alleged vendor lock. Due to that I was prepared for long fight for its freedom 😀 When starting the play it turned out that it has 14-day trial period, inside which it is possible to do almost anything in the system, just like with the ordinary Android device. Obviously one of the first things to do (especially due to this trial counting down from 14 days), was to enable adb. Developer options was enabled the usual way, but then after enabling adb and trying to connect from PC, instead of well known confirmation window with computer fingerprint, such a thing popped up on the screen:

Of course, as is usual for Chinese vendors, translation is a literal translation of Chinese glyphs into English words, so I had to click both buttons to see the difference 🙂 Anyway when Debugging is clicked, login page appears for Sunmi partner. While registration is open, the name suggest, it might not be successful for me. So I need another way. And it seems another way exists. In my case rooting the device was required at first, but for now I will ignore that part. What I want to show is how in general start digging in service calls from command line (I think I have another interesting use case on other device 🙂 ). So, without boring you all, even more, let’s get started.

AIDL – Android Interface Definition Language

This guy is a key to successful usage of all services. Without in, all you can to is guesswork, or reverse engineering receiver first. But let’s focus on easy way, because for all standard Android services AIDL files should be public and be a perfect match to what you find in the wild. So to start, let’s see what services do we have by executing service list in Android shell:

V2sB12:/ $ service list
Found 232 services:
0       DockObserver: []
1       SurfaceFlinger: [android.ui.ISurfaceComposer]
2       accessibility: [android.view.accessibility.IAccessibilityManager]
3       account: [android.accounts.IAccountManager]
4       activity: [android.app.IActivityManager]
5       activity_task: [android.app.IActivityTaskManager]
6       adb: [android.debug.IAdbManager]
7       alarm: [android.app.IAlarmManager]
8       android.frameworks.stats.IStats/default: [android.frameworks.stats.IStats]
9       android.hardware.gnss.IGnss/default: [android.hardware.gnss.IGnss]
10      android.hardware.light.ILights/default: []

I cut the list obviously, as in our case we focus only on adb, so we are interested in IAdbManager interface. For that you can google for file IAdbManager.aidl, or open Android source code repository online directly. Important is to ensure that you open this interface for as similar version of Android as possible. Same major version is a must, as it is likely there will be differences from one version to another. Next step is to find number of your desired method, starting from top of the interface, where first method has number 1 (sic!). Then in my example of authorizing device to adb, I want to call this method:

void allowDebugging(boolean alwaysAllow, String publicKey);

As it is the first in the interface I will use number one as its code. Next step is to see what are the types of its arguments. You can check what are the possibilities by calling service without giving any arguments. As you can see, first argument is boolean and from documentation we see that its meaning is to allow the device permanently. As I use it as a hack to work around login page, true is what I want. In case of making automation to allow only certain devices based on some conditions, probably false would be a way to go to force the call on each connection. When comparing that to possibilities we have in service binary, i32 is the closest we have. And the last argument is public key. As documentation states it needs to be given in base64-encoded form. In case we have access to logcat the easiest way to obtain this key is to try connecting the device to PC and immediately afterwards executing this in Android terminal:

logcat | grep -i public

If successful, public key should be returned already in format that is ready to use. And for strings we can only choose s16 as type. So complete command would look more or less like this:

service call adb 1 i32 1 s16 'cHVibGljX2tleQo='

Obviously correct public key has to be given instead.

That’s it. Now you can try any adb command, like adb shell and you should now be authorized to use it.

Posted in TutorialsTagged adb, Android, hacking, Linux

Post navigation

How to recover torrent from rtorrent meta files
Plugin architecture demo for Python projects

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Tags

Android assembly busybox C CAN can-hacking cc-factory cmake compiler docker Dreamspark electronics English gcc hacking hardware JavaCard JCOP kernel KiCAD library Linux PC PCB pinout PKI polski programming Python radio Raspberry Pi Reverse Engineering RTL-SDR SDC SDM SDR smart card software tor tty UART UEFi Windows X.509 Xperia Pro

Recent Posts

  • PHP build for use bundled in Android applications
  • Running graphical apps inside Docker containers
  • Plugin architecture demo for Python projects
  • Authorizing adb connections from Android command line (and making other service calls from cli)
  • How to recover torrent from rtorrent meta files

Recent Comments

  • pomi on Playing with GF-07 GPS device
  • pomi on Playing with GF-07 GPS device
  • Hamdy Abumgata on Playing with GF-07 GPS device
  • Mousum Gogoi on Playing with GF-07 GPS device
  • Eason on Sniffing USB traffic with DSLogic logic analyzer into pcap file

Categories

  • News
  • Random
  • Reversing LKV373A
  • Setting up new v3 Hidden Service with ultimate security
  • Tutorials
  • Uncategorized
  • Understanding JCOP

Links

  • Me @ github
  • LKV373A Wiki
  • DevTomek

Archives

  • December 2024
  • November 2024
  • May 2024
  • July 2023
  • October 2022
  • August 2022
  • July 2021
  • June 2021
  • May 2021
  • December 2020
  • November 2020
  • October 2020
  • August 2020
  • December 2019
  • November 2019
  • October 2019
  • August 2019
  • July 2019
  • February 2019
  • November 2018
  • October 2018
  • June 2018
  • May 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • September 2017

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
Proudly powered by WordPress | Theme: micro, developed by DevriX.