Shizuku 특권 API

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

Shizuku는 app_process로 특권 Java 프로세스를 시작하고 선택된 Android 시스템 API를 Binder를 통해 노출하는 오픈 소스 서비스입니다. 이 프로세스는 ADB가 사용하는 것과 동일한 shell UID 권한으로 실행되므로, 사용자가 명시적으로 승인한 앱은 디바이스를 루팅하지 않고도 시스템 서비스에 대한 Binder 호출을 프록시할 수 있습니다.

실제로, 이는 Shizuku를 사용하는 앱이 종종 adb shell과 동일한 기본 기능을 사용할 수 있음을 의미합니다: 패키지 관리, appops, settings, cmd connectivity, 로그 수집, 그리고 많은 다른 shell에서 허용되는 Binder 트랜잭션들. 여전히 root가 아니며, 여전히 Android 권한, Linux UID 검사, SELinux 정책, Android 버전, OEM별 제한에 의해 제약됩니다.

Typical use cases:

루팅되지 않은 핸드셋에서의 보안 감사
디바이스 내 패키지 관리, 불필요한 앱 제거(debloating) 및 split-APK 설치
로그, 패키지 메타데이터 및 shell에서 보이는 네트워크/프로세스 상태 수집
완전한 root 체인이 필요하지 않지만 ADB-grade 접근이 필요한 PoCs 또는 보조 도구 제작

1. 특권 서비스 시작

moe.shizuku.privileged.api는 세 가지 방법으로 시작할 수 있습니다. 클라이언트 앱에 노출되는 Binder 인터페이스는 동일하지만, 실제 권한은 백엔드가 ADB/shell인지 root인지에 따라 달라집니다.

1.1 Wireless ADB (Android 11+)

개발자 옵션 -> 무선 디버깅을 활성화하고 기기를 페어링합니다.
Shizuku 앱에서 **“무선 디버깅으로 시작”**을 선택합니다.
세션은 OEM ROM이 무선 디버깅을 종료하거나 디버깅 권한을 취소하지 않는 한 재부팅까지 유지됩니다.

1.2 USB / 로컬 ADB 원라이너

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

동일한 스크립트는 network ADB 연결 (adb connect <IP>:5555)을 통해 실행할 수 있다.

1.3 Rooted devices

디바이스가 이미 rooted 상태라면 다음을 실행:

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

1.4 테스트 중에 중요한 OEM 특이사항

MIUI / HyperOS는 일반 USB debugging 토글 외에 **USB debugging (Security settings)**을 추가로 요구하는 경우가 많습니다.
ColorOS / OxygenOS는 일반적으로 Permission monitoring 또는 동등한 보안 래퍼를 비활성화해야 합니다.
Android 11+에서는 Disable adb authorization timeout이 긴 테스트 세션 동안 발생하는 무작위 Shizuku 연결 끊김을 줄여줍니다.
무선 시작이 계속 실패하면 Shizuku가 백그라운드에서 실행되도록 허용하십시오; 몇몇 OEM ROM은 앱이 백그라운드로 전환되면 로컬 네트워크 검색을 일시 중단합니다.

1.5 실행 중인지 확인하기

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

성공적으로 시작하면 실행 중인 서비스가 반환되고 moe.shizuku.privileged.api와 관련된 Binder 서비스가 노출됩니다.

2. 애플리케이션에서 바인딩

Shizuku가 활성화된 앱은 Shizuku가 반환한 원시 Binder를 마치 IPackageManager인 것처럼 사용하지 않습니다. 일반적인 흐름은 다음과 같습니다:

Shizuku API 권한과 ShizukuProvider를 추가한다,
Shizuku Binder가 나타날 때까지 기다린다,
사용자에게 Shizuku의 런타임 방식 권한 승인을 요청한다,
대상 시스템 서비스의 Binder를 ShizukuBinderWrapper로 래핑한다.

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" />

최소한의 Binder-wrapper 예제:

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

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

That wrapper is what causes Binder transactions to be forwarded by the Shizuku service process instead of being executed with the caller app’s normal UID.

2.1 UserService: when you need more than a single Binder call

직접적인 Binder 트랜잭션보다 더 복잡한 작업에는, 최신 Shizuku 개발에서는 오래된 newProcess 헬퍼 대신 UserService를 선호합니다. UserService는 Shizuku가 ADB로 시작되었을 때 별도의 프로세스에서 자신의 Java/JNI 코드를 UID 2000 (shell) 권한으로 실행하고, root로 구동될 때는 UID 0으로 실행됩니다.

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

Shizuku.bindUserService(args, conn);

이는 장기간 상태 유지, JNI 헬퍼, 또는 반복적인 Binder 연산을 필요로 하는 공격 툴에 유용하며, 쉘 명령을 반복해서 생성하는 비용을 지불할 필요가 없습니다. 이 서비스는 일반 앱 프로세스가 아님을 기억하세요: 일부 Context 메서드는 일반 Android 애플리케이션 내부에서처럼 동작하지 않습니다.

2.2 여전히 적용되는 제약

ADB/shell과 root는 서로 다른 권한 레벨입니다. Shizuku.getUid()는 shell-backed 세션에서 2000을, root-backed 세션에서 0을 반환합니다.
Shell 권한은 Android 릴리스마다 변경되며 OEMs에 의해 축소될 수도 있습니다.
Shell은 여전히 /data/user/0/<package> 같은 다른 앱의 개인 샌드박스를 직접 읽을 수 없습니다.
Hidden API 제한은 정상 앱 프로세스에서 실행되는 코드에도 여전히 적용됩니다; non-SDK 인터페이스를 광범위하게 사용해야 한다면 로직을 UserService로 옮기거나 전용 hidden-API 우회 기법을 사용하세요.

3. Rish - Termux 내부의 권한 상승 쉘

Shizuku 설정 화면에는 “터미널 앱에서 Shizuku 사용” 항목이 있습니다. 이를 활성화하면 rish가 다운로드되며, rish는 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

Useful detail for Termux-heavy workflows: when Shizuku runs as ADB/shell, rish intentionally avoids preserving Termux’s environment by default because the shell user usually cannot traverse Termux-private paths.

3.1 `rish` shell에서 유용한 명령

지정된 패키지의 실행 중인 프로세스 목록:

ps -A | grep com.facebook.katana

리스닝 중인 소켓을 열거하고 이를 패키지에 매핑:

netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done

shell에 노출된 모든 앱 로그 덤프:

logcat -d | grep -iE "(error|exception)"

대량 debloat (예시):

pm uninstall --user 0 com.miui.weather2

다중 사용자 악용 전에 사용자 및 프로필 레이아웃 점검:

pm list users
dumpsys user

3.2 shell 기반 Shizuku로 가능해진 최신 악용 패턴

AppOps 및 특수 권한 변조

Shizuku 지원 관리자(예: App Ops나 App Manager)는 실제로 shell 권한으로 실행되는 appops와 package-manager Binder 호출을 감싸는 역할을 합니다. rish에서 동일한 기본 기능을 직접 사용할 수 있습니다:

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

이는 pentests 중에 앱이나 MDM agent가 실제로 공격적인 AppOps 조작을 root 없이 허용하는지 검증할 때 유용하다.

VPN이나 root 없이 앱별 네트워크 격리

최근 Shizuku 기반 도구들(예: ShizuWall)은 connectivity 서비스의 chain-3 제어를 사용해 선택된 패키지의 네트워킹을 차단한다:

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

For assessments, this gives you a fast way to test how a target app behaves when a competing security, telemetry or management package is selectively cut off from the network while the rest of the device remains online. The state is cleared on reboot.

디바이스 내 고급 설치와 split APK 워크플로우

Modern Shizuku installers such as InstallWithOptions or InstallerX-Revived use shell-backed PackageInstaller access to perform operations that are otherwise awkward from a normal app: split APK installs, test-only packages, batch installs, and some Android 14 package-install flags.

워크 프로필 및 보조 사용자 경계

Shell-backed Shizuku는 여전히 Android의 사용자 제한을 받습니다. 관리 프로필에서는 종종 다음과 같은 오류가 발생합니다:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

If you are specifically testing work-profile bypasses or required-app replacement, keep that material in the dedicated page instead of duplicating it here: Android Enterprise Work Profile Required-App Replacement

4. 보안 고려사항 / 탐지

Shizuku는 먼저 ADB debugging 또는 root가 필요하므로, _Developer Options -> USB/Wireless debugging_는 비루팅 기기에서 활성화되어야 합니다.
서비스는 moe.shizuku.privileged.api라는 이름으로 등록됩니다. adb shell service list | grep shizuku 및 adb shell dumpsys activity service moe.shizuku.privileged.api는 신뢰할 수 있는 빠른 확인 방법입니다.
기능은 현재 백엔드가 가진 권한으로 제한됩니다. ADB 기반 세션에서는 이는 해당 Android 빌드에서 **com.android.shell**에 노출된 유효 공격 표면과 SELinux가 허용하는 범위가 합쳐진 것임을 의미합니다.
기기 재부팅 시 세션은 유지되지 않습니다 — 기기가 root 되어 있고 Shizuku가 시작 데몬으로 구성된 경우를 제외합니다.
OEM의 “보안” 계층은 종종 Shizuku 기능을 깨뜨리거나 은밀하게 축소합니다. 명령이 직접 adb shell에서는 동작하지만 Shizuku를 통해서는 실패한다면, 현재 백엔드 UID (Shizuku.getUid()), OEM 디버깅 토글 상태, 그리고 기기가 shell 권한을 축소했는지 여부를 비교해보세요.

5. 완화 조치

운영 기기에서는 USB/Wireless debugging을 비활성화하세요.
moe.shizuku.privileged.api를 노출하는 Binder 서비스를 모니터링하세요.
관리되는 사용자에서 디버깅 기능을 제거하도록 work-profile 또는 MDM 제약을 적용하세요.
위협 모델링 시 Shizuku 호환 도구를 ADB-equivalent로 간주하세요; 기기가 root가 아니더라도 post-exploitation에서 역량을 크게 증폭할 수 있습니다.

References

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.