Shizuku Privileged API

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Shizuku ni huduma ya chanzo wazi inayofungua mchakato wa Java mwenye ruhusa kwa kutumia app_process na kuonyesha API zilizochaguliwa za mfumo wa Android kupitia Binder. Kwa sababu mchakato unaendesha na uwezo sawa wa UID wa shell ambao ADB hutumia, app ambayo imeidhinishwa wazi na mtumiaji inaweza kupitisha simu za Binder kwa huduma za mfumo bila ku-root kifaa.

Kwa vitendo, hili linamaanisha app iliyo na Shizuku mara nyingi inaweza kutumia primitives sawa na adb shell: package management, appops, settings, cmd connectivity, ukusanyaji wa logi, na miamala mingine mingi ya Binder inayoruhusiwa kwa shell. Bado si root na bado imezuiliwa na idhinisho za Android, ukaguzi za UID za Linux, sera ya SELinux, toleo la Android, na vikwazo maalum vya OEM.

Matumizi ya kawaida:

  • Ukaguzi wa usalama kutoka kifaa bila root
  • Usimamizi wa packages kwenye kifaa, debloating na ufungaji wa split-APK
  • Ukusanyaji wa logi, metadata za package na hali ya mtandao/mchakato inayoonekana kwa shell
  • Kujenga PoCs au zana za msaada zinazohitaji ADB-grade access lakini si mlolongo kamili wa root

1. Starting the privileged service

moe.shizuku.privileged.api inaweza kuanzishwa kwa njia tatu tofauti. Kiolesura cha Binder kinachoonyeshwa kwa apps za mteja ni sawa, lakini ruhusa halisi inategemea kama backend ni ADB/shell au root.

1.1 Wireless ADB (Android 11+)

  1. Enable Developer Options -> Wireless debugging and pair the device.
  2. Inside the Shizuku app select “Start via Wireless debugging”.
  3. The session survives until reboot unless the OEM ROM kills wireless debugging or revokes the debugging authorisation.

1.2 USB / local ADB one-liner

adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

Skripti ileile inaweza kutekelezwa kupitia muunganisho wa mtandao ADB (adb connect <IP>:5555).

1.3 Rooted devices

Ikiwa kifaa tayari kime-rooted, endesha:

su -c sh /data/adb/shizuku/start.sh

1.4 OEM quirks that matter during testing

  • MIUI / HyperOS mara nyingi inahitaji USB debugging (Security settings) pamoja na swichi ya kawaida ya USB debugging.
  • ColorOS / OxygenOS kwa kawaida inahitaji kuzima Permission monitoring au vifuniko vingine vya usalama vinavyofanana.
  • Kwenye Android 11+, Disable adb authorization timeout hupunguza kupoteza kwa nasibu kwa Shizuku wakati wa vikao virefu vya majaribio.
  • Ikiwa kuanzishwa kwa wireless kunaendelea kushindikana, ruhusu Shizuku ikimbie katika background; ROM kadhaa za OEM husitisha local-network discovery wakati programu iko backgrounded.

1.5 Kuthibitisha kuwa inakimbia

adb shell dumpsys activity service moe.shizuku.privileged.api | head
adb shell service list | grep shizuku

Kuanza kwa mafanikio hurudisha huduma inayokimbia na inafichua huduma ya Binder inayohusiana na moe.shizuku.privileged.api.

2. Kufunga kutoka kwenye app

App iliyowezeshwa na Shizuku sio inatumia raw Binder iliyorejeshwa na Shizuku kana kwamba ilikuwa IPackageManager. Mtiririko wa kawaida ni:

  1. ongeza ruhusa ya Shizuku API na ShizukuProvider,
  2. subiri Binder ya Shizuku ionekane,
  3. omba idhinisho la mtindo wa runtime la Shizuku kutoka kwa mtumiaji,
  4. funika Binder ya huduma ya mfumo lengwa kwa ShizukuBinderWrapper.

Mahitaji ya Manifest:

<uses-permission android:name="moe.shizuku.manager.permission.API"/>

<provider
android:name="rikka.shizuku.ShizukuProvider"
android:authorities="${applicationId}.shizuku"
android:multiprocess="false"
android:enabled="true"
android:exported="true"
android:permission="android.permission.INTERACT_ACROSS_USERS_FULL" />

Mfano mdogo wa Binder-wrapper:

Shizuku.addBinderReceivedListenerSticky(() -> {
if (Shizuku.checkSelfPermission() != PackageManager.PERMISSION_GRANTED) {
Shizuku.requestPermission(1000);
return;
}

IPackageManager pm = IPackageManager.Stub.asInterface(
new ShizukuBinderWrapper(SystemServiceHelper.getSystemService("package"))
);
});

Wrapper hiyo ndiyo inayosababisha muamala za Binder kupitishwa na mchakato wa huduma wa Shizuku badala ya kutekelezwa kwa UID ya kawaida ya programu inayoitisha.

2.1 UserService: unapohitaji zaidi ya wito mmoja wa Binder

Kwa chochote kilicho ngumu zaidi kuliko muamala za Binder za moja kwa moja, maendeleo ya kisasa ya Shizuku yanapendelea UserService badala ya msaidizi wa zamani newProcess. UserService inaendesha your own Java/JNI code katika mchakato tofauti kama UID 2000 (shell) wakati Shizuku ilianzishwa kupitia ADB au UID 0 wakati imeungwa mkono na root.

Shizuku.UserServiceArgs args = new Shizuku.UserServiceArgs(
new ComponentName(this, AuditService.class))
.daemon(false)
.version(1)
.processNameSuffix("audit");

Shizuku.bindUserService(args, conn);

This is useful for offensive tooling that needs long-lived state, JNI helpers, or repeated Binder operations without paying the cost of spawning shell commands over and over. Kumbuka kwamba service ni not a normal app process: baadhi ya Context methods hazitendeki kama zilivyo ndani ya regular Android application.

2.2 Mipaka ambayo bado inatumika

  • ADB/shell and root are different privilege levels. Shizuku.getUid() inarudisha 2000 kwa shell-backed sessions na 0 kwa root-backed sessions.
  • Shell permissions change between Android releases na zinaweza pia kupunguzwa na OEMs.
  • Shell bado haiwezi kusoma moja kwa moja sandbox binafsi ya app nyingine kama /data/user/0/<package>.
  • Vikwazo vya hidden API bado vinafanya kazi kwa code inayotumia normal app process; ikiwa unahitaji non-SDK interfaces kwa wingi, hamisha logic kwenye UserService au tumia dedicated hidden-API bypass.

3. Rish - shell iliyoinuliwa ndani ya Termux

The Shizuku settings screen exposes “Use Shizuku in terminal apps”. Kuwawezesha hupakua rish, ambayo hufungua remote privileged shell inayoungwa mkono na Shizuku.

pkg install wget
wget https://rikka.app/rish/latest -O rish && chmod +x rish

# start elevated shell (inherits the binder connection)
./rish
whoami   # -> shell
id       # uid=2000(shell) gid=2000(shell) groups=... context=u:r:shell:s0

Maelezo muhimu kwa workflows zinazoendeshwa sana na Termux: wakati Shizuku inapoendeshwa kama ADB/shell, rish kwa makusudi huepuka kuhifadhi mazingira ya Termux kwa default kwa sababu shell user kawaida hawezi kupita kwenye Termux-private paths.

3.1 Amri muhimu kutoka kwa rish shell

  • Orodhesha mchakato unaoendesha wa package fulani:
ps -A | grep com.facebook.katana
  • Orodhesha sockets zinazolisikiliza na kuzipanga kwa packages:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Tandika log zote za application zinazoonyeshwa kwa shell:
logcat -d | grep -iE "(error|exception)"
  • Bulk debloat (mfano):
pm uninstall --user 0 com.miui.weather2
  • Kagua watumiaji na muundo wa profile kabla ya matumizi mbaya ya multi-user:
pm list users
dumpsys user

3.2 Mifumo ya kisasa ya utumiaji mbaya inayowezeshwa na Shizuku inayoungwa mkono na shell

AppOps na kuingilia ruhusa maalum

Manaja zilizo na Shizuku kama App Ops au App Manager kwa ufanisi zinafunga antari za appops zilizoidhinishwa na shell na Binder calls za package-manager. Kutoka kwa rish, primitive ile ile inaweza kutumika moja kwa moja:

cmd appops get com.target.app
cmd appops set --uid com.target.app RUN_IN_BACKGROUND ignore
cmd appops set com.target.app SYSTEM_ALERT_WINDOW allow

Hii ni muhimu wakati wa pentests ili kuthibitisha ikiwa app au MDM agent kwa kweli inavumilia mabadiliko makali ya AppOps bila kuhitaji root.

Kutengwa kwa mtandao kwa kila app bila VPN au root

Zana za hivi karibuni zinazotegemea Shizuku kama ShizuWall zinatumia huduma ya connectivity na udhibiti wa chain-3 kuzuia networking kwa packages zilizochaguliwa:

cmd connectivity set-chain3-enabled true
cmd connectivity set-package-networking-enabled false com.example.agent
cmd connectivity set-package-networking-enabled true com.example.agent

Kwa tathmini, hili linakupa njia ya haraka kujaribu jinsi app lengwa inavyofanya kazi wakati kifurushi cha usalama, telemetry au usimamizi kinachoshindana kinavyokatwa kwa uteuzi kutoka kwenye mtandao huku sehemu nyingine za kifaa zikiwa mtandaoni. Hali inafutwa kwenye kuanzisha upya.

Kwenye kifaa usakinishaji wa juu na split APK workflows

Wasakinishaji wa kisasa wa Shizuku kama InstallWithOptions au InstallerX-Revived hutumia upatikanaji wa shell-backed PackageInstaller kufanya shughuli ambazo vinginevyo ni ngumu kwa app ya kawaida: split APK installs, test-only packages, batch installs, na baadhi ya Android 14 package-install flags.

Kutoka kwa mtazamo wa offensive-testing, sehemu muhimu si GUI bali primitive: Shizuku inarudisha ufungaji wa package kuwa kitendo kilichoidhinishwa na shell kwenye kifaa, ambacho ni muhimu kwa majaribio ya persistence, downgrade checks na uwasilishaji wa haraka wa helper payloads kwenye handset isiyo-rooted.

Work-profile and secondary-user boundaries

Shell-backed Shizuku bado inategemea vikwazo vya watumiaji vya Android. Katika managed profiles mara nyingi utakutana na makosa kama:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

Ikiwa unachunguza hasa work-profile bypasses au required-app replacement, weka nyenzo hiyo katika ukurasa uliotengwa badala ya kuirudia hapa: Android Enterprise Work Profile Required-App Replacement

4. Mambo ya usalama / utambuzi

  1. Shizuku inahitaji kwanza ADB debugging au root, kwa hivyo Developer Options -> USB/Wireless debugging lazima iwe imewezeshwa kwenye vifaa visivyo na root.
  2. Huduma inajisajili chini ya jina moe.shizuku.privileged.api. adb shell service list | grep shizuku na adb shell dumpsys activity service moe.shizuku.privileged.api ni ukaguzi wa haraka wa kuaminika.
  3. Uwezo unakadiriwa kulingana na kile backend ya sasa inachomiliki. Katika vikao vinavyotegemea ADB, hiyo inamaanisha uso wa mashambulizi unaoonekana ni ule unaotolewa kwa com.android.shell kwenye build hiyo ya Android, pamoja na kile ambacho SELinux kinachoruhusu.
  4. Vikao havidumu baada ya reboot isipokuwa kifaa kina root na Shizuku imewekwa kama daemon ya kuanza.
  5. Tabaka za “security” za OEM mara nyingi huvunjika au hupunguza kimya kimya utendakazi wa Shizuku. Ikiwa amri inafanya kazi kupitia adb shell ya moja kwa moja lakini inashindwa kupitia Shizuku, linganisha UID ya backend ya sasa (Shizuku.getUid()), viboreshaji vya OEM debugging, na kama kifaa kimepunguza ruhusa za shell.

5. Kupunguza hatari

  • Zima USB/Wireless debugging kwenye vifaa vya uzalishaji.
  • Fuatilia Binder services zinazoonyesha moe.shizuku.privileged.api.
  • Watekeleze vikwazo vya work-profile au MDM vinavyoondoa vipengele vya debugging kwa watumiaji wanaosimamiwa.
  • Tathmini Shizuku-compatible tooling kama ADB-equivalent wakati wa threat modelling; ni post-exploitation force multiplier hata kama kifaa hakina root.

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks