Dear Privacy Guides community,
I am posting this to request expert triage of what I believe to be a repeated high-grade mobile compromise affecting my Android / GrapheneOS environment.
I want to be precise from the beginning: the logs alone do not allow me to identify the exact intrusion point with 100% certainty, and I understand that logcat by itself cannot conclusively prove a full device compromise. However, the events appear in a coherent chain that is highly abnormal and resembles the kind of multi-stage behavior usually associated with advanced mobile attacks.
From my direct observation as the affected user, I categorically state that three of my devices were compromised and eventually became unusable. The attacker appeared to gain access to my phone in an impressive and highly intrusive manner, including behavior consistent with active screen control. These incidents were not isolated and did not happen only once. They occurred repeatedly across my Android / GrapheneOS environment.
Importantly, after I performed a full Android reflash with GrapheneOS, the most erratic behavior stopped. This strongly suggests that the abnormal behavior was tied either to the prior software/device state, a persistent userland or system-level condition, or an exploit chain that did not survive a clean reinstall.
I am not claiming that the attacks were necessarily government-operated. My concern is that advanced non-state actors, criminal groups, mercenary actors, or private threat groups may now have access to high-level mobile exploitation tooling that is being used in the wild.
I am seeking help because this threat appears real, repeated, technically sophisticated, and potentially relevant to current mobile exploitation research.
1. Executive summary
The strongest captured incident appears to involve a Pixel device running GrapheneOS / Android 16. The most relevant sequence appears centered on WhatsApp running under Android user/profile 10.
The strongest chain in the logs is:
WhatsApp / user profile X
→ unexplained PACKAGE_CHANGED / onPackageModified event for com.whatsapp
→ GrapheneOS/TSEC blocks native execution from app-private storage
→ WhatsApp SoLoader tries to recover multiple native libraries from libs.spo
→ several native libraries fail to map with Permission denied
→ BiometricPrompt / AppAuthenticationActivity / input channel breakage
→ WhatsApp activity/process restart or replacement
→ later Wi-Fi / WifiAware / Passpoint / OSU anomalies
→ wider RIL / IMS / modem / baseband anomalies
→ eUICC / SecureElement / THALES OMAPI activity in the broader incident family
Again, I understand this does not prove the exact exploit vector. However, the sequence is coherent, time-correlated, repeated, and very similar in structure to a high-grade mobile attack chain.
2. Main concern: the logs do not reveal one clean “entry point”, but the chain is abnormal
I want to explicitly state that I cannot identify a single definitive point of intrusion from the logs. There is no single line such as:
exploit succeeded
root obtained
payload installed
spyware package added
Instead, the concern is the sequence.
The logs show a chain of events that, when viewed together, is difficult to dismiss as ordinary Android noise:
unexplained WhatsApp package-state change
→ dynamic native-code execution blocked by GrapheneOS
→ multiple WhatsApp native loader failures
→ authentication/input window failure
→ process/activity restart
→ networking anomalies
→ radio/RIL/baseband/eUICC anomalies
This pattern looks more like a partially blocked or unstable advanced mobile exploitation attempt than ordinary commodity Android malware.
3. Immediate pre-event: AOC / CHRE / nanoapp / microdroid / WhatsApp activity
Immediately before the WhatsApp native-code failure, the logs show AOC/CHRE activity, a SystemUI action involving WhatsApp, a nanoapp message, an AppsFilter block involving com.android.microdroid.empty_payload, and then a PACKAGE_CHANGED broadcast for com.whatsapp.
Relevant snippet:
05-02 02:45:46.579 root 1202 1202 D AOC : CHRE: DRAM vote count begins
05-02 02:45:46.579 root 1202 1202 D AOC : CHRE: DRAM vote count ends: 0 ms
05-02 02:45:46.579 1001000 4331 4331 I sysui_multi_action: content=[757,875,758,4,806,com.whatsapp]
05-02 02:45:46.579 1080 878 899 D CHRE : Parsed nanoapp message from host: app ID 0x476f6f676c00103b endpoint 0x8005 msgType 1 payload size 4
05-02 02:45:46.583 1000 1381 4295 I AppsFilter: interaction: PackageSetting{... com.android.microdroid.empty_payload/10173} -> PackageSetting{... com.whatsapp/10193} BLOCKED
This is not my strongest evidence by itself. However, its timing is relevant because it immediately precedes the WhatsApp package-state event and the GrapheneOS/TSEC native-code block.
4. Unexplained PACKAGE_CHANGED / onPackageModified for WhatsApp
Android then treated WhatsApp as a changed or modified package:
05-02 02:45:46.601 1000 1381 2042 D ShortcutService: received package broadcast intent: Intent { act=android.intent.action.PACKAGE_CHANGED dat=package: flg=0x5000010 (has extras) }
05-02 02:45:46.601 1000 1381 2042 D ShortcutService: changing package: com.whatsapp userId=10
05-02 02:45:46.607 radio 2390 2640 I SatelliteAppTracker: onPackageModified : com.whatsapp
05-02 02:45:46.607 radio 2390 2390 D CarrierSvcBindHelper: onPackageModified: com.whatsapp
05-02 02:45:46.608 radio 2390 2640 E SatelliteAppTracker: Exception while reading packageInfo [ com.whatsapp ] exp = com.whatsapp
05-02 02:45:46.609 1001000 4331 5073 D AppForceStopRepository: Sending broadcast to query restart status for com.whatsapp
I did not intentionally update, reinstall, downgrade, enable, disable, force-stop, or modify WhatsApp at that time.
I understand this may have a benign Android explanation. But the timing is important because it occurs immediately before GrapheneOS blocks WhatsApp native execution from app-private decompressed storage.
5. GrapheneOS/TSEC blocks WhatsApp native execution from app-private data
Seconds later, GrapheneOS/TSEC blocked WhatsApp from executing or mapping a native library from app-private storage:
05-02 02:45:48.997 1010193 5319 5319 I auditd : avc=type=1499 audit(0.0:921): TSEC_FLAG_DENY_EXECUTE_APP_DATA_FILE: op denied, uid 1010193, pid 5319, top_pid_with_same_uid 5319, comm="com.whatsapp" path="/data/user/10/com.whatsapp/files/decompressed/libs.spo/libwa_log.so" dev="dm-62" ino=2199
05-02 02:45:48.997 1010193 5319 5319 W com.whatsapp: type=1499 audit(0.0:921): TSEC_FLAG_DENY_EXECUTE_APP_DATA_FILE: op denied, uid 1010193, pid 5319, top_pid_with_same_uid 5319, path="/data/user/10/com.whatsapp/files/decompressed/libs.spo/libwa_log.so" dev="dm-62" ino=2199
05-02 02:45:49.002 1000 1381 1411 D LogdNotableMessage: uid 0, pid 0, msg audit(...): TSEC_FLAG_DENY_EXECUTE_APP_DATA_FILE: op denied, uid 1010193, pid 5319, comm="com.whatsapp" path="/data/user/10/com.whatsapp/files/decompressed/libs.spo/libwa_log.so"
WhatsApp’s SoLoader then attempted recovery:
05-02 02:45:49.002 1010193 5319 5319 W SoLoader: Running a recovery step for libwa_log.so due to com.facebook.soloader.SoLoaderULError: java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libwa_log.so" segment 2: Permission denied
05-02 02:45:49.002 1010193 5319 5319 E SoLoader: Checking /data/app missing libraries.
05-02 02:45:49.002 1010193 5319 5319 E SoLoader: Successfully recovered from /data/app disk failure.
This is one of the most important points in the case. The behavior involves native library loading, dlopen, executable mapping, app-private decompressed files, and GrapheneOS exploit-mitigation protections.
6. Multiple WhatsApp native libraries failed under libs.spo
The failure was not limited to one library. Multiple WhatsApp native libraries under:
/data/user/10/com.whatsapp/files/decompressed/libs.spo/
failed to map with Permission denied.
Examples include:
libwa_log.so
libc++_shared.so
libessential.so
libvlc.so
libcurve25519.so
libnative_utils.so
Relevant snippets:
05-02 02:45:53.047 1010193 5574 5574 W SoLoader: Running a recovery step for libwa_log.so due to com.facebook.soloader.SoLoaderULError: java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libwa_log.so" segment 2: Permission denied
05-02 02:45:53.047 1010193 5574 5574 W SoLoader: Failed to recover
05-02 02:45:53.048 1010193 5574 5574 D nativeloader: Load libwa_log.so using class loader ns clns-4 ... dlopen failed: library "libwa_log.so" not found
05-02 02:45:53.086 1010193 5574 5574 D nativeloader: Load /data/user/10/com.whatsapp/files/decompressed/libs.spo/libc++_shared.so using class loader ns clns-4 ... dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libc++_shared.so" segment 2: Permission denied
05-02 02:45:53.087 1010193 5574 5574 W SoLoader: Running a recovery step for libessential.so due to com.facebook.soloader.SoLoaderULError: java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libc++_shared.so" segment 2: Permission denied
05-02 02:45:53.102 1010193 5574 5574 W SoLoader: Loading vlc on the main thread
05-02 02:45:53.102 1010193 5574 5574 D nativeloader: Load /data/user/10/com.whatsapp/files/decompressed/libs.spo/libvlc.so using class loader ns clns-4 ... dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libvlc.so" segment 2: Permission denied
05-02 02:45:53.103 1010193 5574 5574 W SoLoader: Failed to recover
05-02 02:45:53.112 1010193 5574 5574 W SoLoader: Loading curve25519 on the main thread
05-02 02:45:53.113 1010193 5574 5574 D nativeloader: Load /data/user/10/com.whatsapp/files/decompressed/libs.spo/libcurve25519.so using class loader ns clns-4 ... dlopen failed: couldn't map "/data/user/10/com.whatsapp/files/decompressed/libs.spo/libcurve25519.so" segment 2: Permission denied
05-02 02:45:53.114 1010193 5574 5574 W SoLoader: Failed to recover
My question is whether this is known benign WhatsApp behavior on hardened Android / GrapheneOS, or whether it resembles a partially blocked native exploit path.
7. BiometricPrompt / AppAuthenticationActivity / input-channel failure
Immediately after the native-loader/TSEC sequence, the logs show abnormal behavior involving WhatsApp authentication UI, BiometricPrompt, InputMethodManagerService, InputDispatcher, and a broken WhatsApp authentication window.
Relevant snippet:
05-02 02:45:52.672 1000 1381 1734 D CoreBackPreview: Window{7f08da9 u0 BiometricPrompt}: Setting back callback ...
05-02 02:45:52.675 1000 1381 1429 I viewroot_draw_event: [window=VRI[whatsapp],event=reportDrawFinished seqId=0]
05-02 02:45:52.679 1000 1381 1432 I input_focus: [window=Focus request 7f08da9 BiometricPrompt,reason=reason=UpdateInputWindows]
05-02 02:45:52.687 1000 1381 1905 W InputMethodManagerService: A background user is requesting window. Hiding IME.
05-02 02:45:52.687 1000 1381 1905 W InputMethodManagerService: If you need to impersonate a foreground user/profile from a background user, use EditorInfo.targetInputMethodUser with INTERACT_ACROSS_USERS_FULL permission.
05-02 02:45:52.690 1000 1381 1897 W InputDispatcher: channel '895ef82 com.whatsapp/com.whatsapp.authentication.AppAuthenticationActivity' ~ Consumer closed input channel or an error occurred. events=0x9
05-02 02:45:52.690 1000 1381 1897 E InputDispatcher: channel '895ef82 com.whatsapp/com.whatsapp.authentication.AppAuthenticationActivity' ~ Channel is unrecoverably broken and will be disposed!
05-02 02:45:52.690 1000 1381 1897 I WindowManager: WINDOW DIED Window{895ef82 u10 com.whatsapp/com.whatsapp.authentication.AppAuthenticationActivity}
05-02 02:45:52.693 1000 1381 1734 E BiometricService/AuthSession: Binder died, session: State: 2, cancelled: true, isCrypto: false, PreAuthInfo: BiometricRequested: true, CredentialRequested: true
I am not claiming WhatsApp obtained cross-user privileges. But this is highly relevant because the authentication window breaks immediately adjacent to the native-code/TSEC failure sequence.
This is also consistent with my direct observation that the attacker appeared to gain unusual control over the device UI and screen behavior.
8. WhatsApp activity/process restart or replacement
After the native-loader failures, Android restarted or re-entered the WhatsApp activity:
05-02 02:45:53.125 1000 1381 1411 I wm_restart_activity: [User=10,Token=64533260,Task ID=1000014,Component Name=com.whatsapp/.home.ui.HomeActivity]
From my perspective, WhatsApp appeared to continue or recover. In the logs, the sequence looks like one WhatsApp execution path failed or broke, and then another WhatsApp activity/process path resumed almost immediately.
This is why I am concerned about a partially blocked exploit attempt, process replacement, or exploit instability.
9. Wi-Fi / WifiAware / Passpoint / OSU anomalies after the WhatsApp event
Later in the same incident family, Wi-Fi and related services show invalid scan list / Passpoint / OSU behavior:
05-02 04:32:10.191 1000 1343 4304 W ScanResultUtil:
Empty or null ScanResult list
05-02 04:32:10.192 1000 1343 1431 E WifiService:
Attempt to retrieve passpoint with invalid scanResult List
05-02 04:32:10.192 1000 1343 1431 W WifiService:
Attempt to retrieve OsuProviders with invalid scanResult List
I did not find a clean P2P-GROUP-STARTED, DIRECT-, p2p0, or hostapd line in the preserved logs for this event. However, the Wi-Fi subsystem entering invalid scan/passpoint/OSU behavior after the WhatsApp-native sequence should be reviewed because the likely initial transport was WhatsApp over Wi-Fi.
10. RIL / modem / baseband anomalies
The wider log set includes RIL/modem/baseband anomalies. I understand that invalid subscription state, no SIM, carrier problems, eSIM state, or GrapheneOS/Android telephony noise can produce confusing logs. However, these are real low-level radio/RIL events and they appear in the broader incident family.
Relevant snippet:
05-02 04:17:41.860 radio 1153 1282 D RILC-HIDL: dataCallListChangedInd_1_6
05-02 04:17:41.860 radio 1153 1282 I RILC : RIL_SOCKET_1 UNSOLICITED: UNSOL_DATA_CALL_LIST_CHANGED length:0
05-02 04:17:41.860 radio 1153 1285 D RILC-HIDL: radioStateChangedInd: radioState 0
05-02 04:17:41.860 radio 1153 1285 I RILC : RIL_SOCKET_1 UNSOLICITED: UNSOL_RESPONSE_RADIO_STATE_CHANGED length:4
05-02 04:17:41.861 radio 1153 1305 D RILC-HIDL: HidlHalSimIndication::simStatusChanged
05-02 04:17:41.861 radio 1153 1305 I RILC : RIL_SOCKET_2 UNSOLICITED: UNSOL_RESPONSE_SIM_STATUS_CHANGED length:0
05-02 04:17:41.861 radio 1153 1284 I RILC-CommandInfo: getUnsolRespInfo not found(unsolResponse=9501 halVer=00)
05-02 04:17:41.861 radio 1153 1284 E RILC : unsupported unsolicited response code 9501
05-02 04:17:41.865 radio 1153 1302 E RIL : WaitList::Find() found record error : token=0x0005
05-02 04:17:41.875 radio 1153 1306 W RIL : [ManifestQuery]getManifest SQL query failed with exit code 1 - near "country_code": syntax error!
05-02 04:17:41.877 radio 1153 1306 W RIL : [1] An empty ICCID.
Other logs show emergency-only / registration-denied states on Brazilian carriers:
VOICE_REGISTRATION_STATE
REG_DENIED_EM
RIL Missing Reg Fail Reason
registrationState=DENIED
availableServices=[EMERGENCY]
operatorNames: TIM BRA
operatorNames: Claro BRA
I am not saying these lines prove a baseband implant. But in the context of repeated attacks, WhatsApp native failures, eUICC/SecureElement activity, and direct observed screen control, I believe they deserve expert review.
11. SMS / SIM-OTA / IMS / RCS concern
I did not find a clear ordinary SMS/MMS smoking gun such as:
SMS_RECEIVED
WAP_PUSH_RECEIVED
InboundSmsHandler
RIL_UNSOL_RESPONSE_NEW_SMS
MmsService
Therefore, I am not claiming that ordinary SMS or MMS was the initial vector.
However, the wider log set includes IMS/RCS/Shannon/RIL-related components such as:
com.shannon.imsservice
com.shannon.rcsservice
RILC_REQ_AIMS_HIDDEN_MENU
Sending AddPdn Info
RCS was turned off
LibSITRil-Gps: RequestAGPS
RILC_Send
There is also one suspicious but not conclusive SMS-role/AppOps repair sequence:
05-02 04:04:30.004 1001000 12226 12226 E SmsApplication: com.android.messaging lost android:send_sms: (fixing)
05-02 04:04:30.005 1001000 12226 12226 W SmsApplication: com.android.phone does not have OP_WRITE_SMS: (fixing)
05-02 04:04:30.005 1000 1350 1861 W AppOpService: Ignored setUidMode call for runtime permission app op: uid = 1001001, code = READ_SMS, mode = allow
05-02 04:04:30.006 1000 1350 6467 W AppOpService: Ignored setUidMode call for runtime permission app op: uid = 1001001, code = RECEIVE_SMS, mode = allow
05-02 04:04:30.006 1000 1350 4318 W AppOpService: Ignored setUidMode call for runtime permission app op: uid = 1001001, code = RECEIVE_WAP_PUSH, mode = allow
05-02 04:04:30.006 1000 1350 6467 W AppOpService: Ignored setUidMode call for runtime permission app op: uid = 1001001, code = SEND_SMS, mode = allow
This may be normal Android role repair behavior. I include it only because hidden SIM-OTA, IMS/RCS, carrier signaling, or telecom-layer activity may not appear as ordinary user-visible SMS.
12. eUICC / SecureElement / THALES OMAPI activity
The broader incident family also includes eUICC / SecureElement / THALES OMAPI logical-channel activity.
Examples:
04-30 06:44:57.966 1068 2231 2489 I SecureElementService: openLogicalChannel() Success. Channel: 1
04-30 06:44:57.966 10153 2815 3060 I EuiccSupportPixel: OMAPI: Open LC then Select AID : A000000809434343444B417631
04-30 06:44:57.966 10153 2815 3060 I EuiccSupportPixel: OMAPI channel opened: aid=A000000809434343444B417631, p2=-1, channel=android.se.omapi.Channel@58d30a0
04-30 06:44:57.967 10153 2815 3060 I EuiccSupportPixel: UiccLogicalChannel, interface: c.b.c.m.b(mReaderName=eSE1)
04-30 06:44:57.979 10153 2815 3060 I EuiccSupportPixel: THALES: DKA instance version init = 0302000600 -> DKA_3_2_BUILD_006_RC1_DEFAULT
04-30 06:44:58.072 1068 2231 2489 I SecureElementService: openLogicalChannel() Success. Channel: 1
04-30 06:44:58.072 10153 2815 3060 I EuiccSupportPixel: OMAPI: Open LC then Select AID : A00000086753555300
04-30 06:44:58.072 10153 2815 3060 I EuiccSupportPixel: OMAPI channel opened: aid=A00000086753555300, p2=-1, channel=android.se.omapi.Channel@a9c2d15
04-30 06:44:58.073 10153 2815 3060 I EuiccSupportPixel: UiccLogicalChannel, interface: c.b.c.m.b(mReaderName=eSE1)
04-30 06:44:58.083 10153 2815 3060 I EuiccSupportPixel: THALES: SUSA instance version init = 0103000500 -> SUSA_1_3_BUILD_005_RC02_DEFAULT
04-30 06:44:58.095 10153 2815 3060 I EuiccSupportPixel: OMAPI channel closed: android.se.omapi.Channel@a9c2d15
I did not find a clean downloadSubscription, switchToSubscription, enableProfile, or confirmed hidden active eSIM profile. My concern is that eUICC/SecureElement/THALES activity appears in the same broader incident family and may be relevant to a follow-on surface.
13. Screen recording / active screen control behavior
One of the most alarming user-observed behaviors was that the attacker appeared to have active control or influence over the screen/UI. During one incident, I was recording the screen, and the logs show the system stopping active MediaProjection while capture was in progress:
04-01 05:51:23.109 10169 2609 3084 D MediaProjectionManager: Content Recording: stopping active projection
04-01 05:51:23.110 1000 1599 3645 D MediaProjectionManagerService: Content Recording: Stopping active projection
04-01 05:51:23.111 1000 1599 3645 D MediaProjectionManagerService: Content Recording: Stopped active MediaProjection and dispatching stop to callbacks
04-01 05:51:23.111 1000 1599 3645 D MediaProjectionMetricsLogger: logStopped: wasCaptureInProgress=true stopReason=5
04-01 05:51:23.113 10169 2609 2691 V MediaProjection: Dispatch stop to 1 callbacks.
04-01 05:51:23.113 1000 1599 1599 I VirtualDisplayAdapter: Virtual display device released because media projection stopped: Recording Display
04-01 05:51:23.115 10169 2609 2609 D ScreenMediaRecorder: The system notified about stopping the projection
04-01 05:51:23.115 10169 2609 2609 D RecordingService: Stopping recording for user 0 because the system requested the stop
This does not prove the screen was controlled by spyware. However, it matches the broader pattern I observed: the device UI behaved abnormally, and the attacker appeared to interfere with screen activity at a level far beyond ordinary app behavior.
14. What I did not find
To avoid overstating the evidence, I want to clearly state what I did not find in the preserved logs:
No single definitive exploit-success line
No clean proof of the exact initial intrusion point
No clean INSTALL_SUCCEEDED for an unknown malicious APK
No clean PACKAGE_ADDED for a spyware package
No confirmed Device Admin activation
No confirmed AccessibilityService spyware activation
No confirmed NotificationListener spyware activation
No SELinux permissive mode
No obvious Magisk/root artifacts
No clean kernel panic proving kernel exploitation
No confirmed hidden eSIM activation
No ordinary SMS_RECEIVED / WAP_PUSH_RECEIVED smoking gun
This is why I am not presenting the logs as complete proof of the exact intrusion method.
However, the absence of one obvious “smoking gun” should not hide the fact that the event chain is abnormal, repeated, and strongly resembles high-grade mobile exploitation behavior.
15. Why this deserves expert triage
The strongest defensible technical claim is:
The logs do not identify a single confirmed entry point,
but they do show a coherent and abnormal chain involving WhatsApp,
GrapheneOS exploit mitigations, native-code loading failures,
authentication/input disruption, process restart, network anomalies,
and later radio/eUICC/SecureElement activity.
My personal statement as the affected user is stronger:
I categorically allege that three devices were compromised and rendered unusable.
The attacker achieved a level of access that appeared to include active screen control.
The attacks were repeated.
The erratic behavior stopped after a full GrapheneOS reflash.
I believe this may represent an advanced mobile threat currently being used in the wild. I am asking your team to help determine whether this chain matches anything seen in spyware investigations, mercenary tooling, WhatsApp exploitation, telecom-layer abuse, SIM/eUICC attack paths, or Android/GrapheneOS bypass attempts.
16. Specific questions
Could you please advise whether this deserves deeper forensic triage?
Specific questions:
-
Is it expected for WhatsApp on hardened Android / GrapheneOS to load multiple native libraries from:
/data/user/X/com.whatsapp/files/decompressed/libs.spo/with repeated
dlopen failed: Permission deniederrors? -
Is the following combination known benign WhatsApp behavior?
PACKAGE_CHANGED / onPackageModified TSEC_FLAG_DENY_EXECUTE_APP_DATA_FILE SoLoader recovery failure multiple native library mapping failures AppAuthenticationActivity / BiometricPrompt input channel breakage immediate WhatsApp activity/process restart -
Could this be related to WhatsApp media, sticker, WebP, video, audio, call, crypto, logging, or transport parsing?
-
Are the RIL/baseband events below consistent with benign invalid-subscription/no-SIM behavior, or do they deserve telecom-layer review?
unsupported unsolicited response code 9501 WaitList::Find() found record error : token=0x0005 ManifestQuery getManifest SQL query failed near "country_code" empty ICCID REG_DENIED_EM RIL Missing Reg Fail Reason availableServices=[EMERGENCY] -
Is it possible for SIM-OTA, IMS/RCS, or carrier-signaling activity to occur without ordinary user-visible
SMS_RECEIVEDorWAP_PUSH_RECEIVEDlogcat evidence? -
Could the eUICC / SecureElement / THALES OMAPI activity be normal Pixel initialization, or could it be relevant in a post-exploit chain?
-
What artifacts should I preserve or collect next?
full Android bugreports radio logs GrapheneOS security/audit logs MVT output if applicable WhatsApp database/media timestamps carrier records SIM/eSIM profile history screen recordings screenshots device/build fingerprints timeline of UI anomalies post-reflash comparison logs
Thank you for your time and for any guidance you guys can provide.
Best regards,
