# Sentinel: Automated Detection of Android Vishing Apps Using Optical Character Recognition
## 3 Background
### Vishing Apps According to Android API Levels  
The Android platform provides various APIs (e.g., TelephonyManager API, LocationManager API, etc.) that request information from the device or manipulate it directly, facilitating flexible feature development for applications. Attackers exploit these APIs to create malicious applications, such as vishing applications. Google has recognized these issues and has been consistently implementing security patches [32; 33], as well as removing APIs that were exploited by malicious apps, restricting the values that apps request from APIs, and requiring additional permission checks before app installation, among others. Specifically, Google introduced security patches in the API level 29 update to prevent the abuse of Call Redirection [34]. In this section, we introduce the alterations in Call Redirection and Display Overlay Attacks in vishing applications based on this security patch.  
**Lower API Level 29.** In Android API levels 28 and below, vishing applications implement Call Redirection using BroadcastReceiver. At this level, the Android system broadcasts NEW_OUTGOING_CALL just before an outgoing call is made. Consequently, vishing applications retrieve or modify the broadcast value in the onReceive() callback function, thus invoking getResultData() to obtain the victim's phone number and using setResultData() to redirect the call. Vishing applications involve Display Overlay to present a counterfeit screen when displaying specific call numbers. Therefore, these applications employ APIs to detect phone events and retrieve the incoming or outgoing numbers. Vishing applications utilize the onCallStateChanged() and onCallAdded() callback functions to retrieve call states and incoming number, as shown in Table 3. Specifically, onCallStateChanged() provides both incoming and outgoing phone numbers through EXTRA_INCOMING_NUMBER.  
**API Level 29 and Above.** In Android API level 29 and above, Android modified the call-related APIs and categorized the phone permissions in more detail. First, to prevent Call Redirection that altered broadcast values, Android restricted access to broadcast values and introduced the CallRedirectionService. Android modified the behavior of the BroadcastReceiver so that the setResultData() method called just before an outgoing call returned null. Furthermore, for an application to utilize the CallRedirectionService, user consent is required, and the application must be registered as the default _call redirecting app_. Second, Android restricted the APIs  
\begin{table}
\begin{tabular}{l c} \hline \hline
**Call State** & **Constant** \\ \hline
**Incoming Call** & TelephonyManager.EXTRA\_STATE\_RINGING \\ \hline
**Outgoing Call** & TelephonyManager.EXTRA\_STATE\_OFFHOOK \\ \hline
**Waiting Call** & TelephonyManager.EXTRA\_STATE\_IDLE \\ \hline \hline \end{tabular}
\end{table}
Table 3: Constants that change depending on the call state in Android.  
that provided incoming or outgoing numbers in API level 28 and below by introducing the CallScreeningService. In earlier versions, Android apps with permissions related to TelephonyManager could call APIs within callback functions to obtain call status as well as incoming or outgoing numbers. In these versions, Android added the CallScreeningService to manage call events and introduced settings for the default app for _caller ID and spam_. Therefore, for an Android app to access the call numbers, it must implement the CallScreeningService and obtain user consent to be registered as the default app. Finally, the APIs required to execute Display Overlay are available across all Android API levels.  
In this section, we present an approach for detecting malicious behavior in vishing applications running in the background. Our approach identifies malicious behaviors, including Call Redirection, Display Overlay, and Duplicated Contacts.