WebView is a component that allows you to display web pages as part of your Android app layout. It is an extension of the View class and does not have any features of a fully developed web browser, such as navigation controls or an address bar. You can use WebView to show online documents, such as user agreements or guides, or to load web pages that are tailored for Android devices.

WebView is very flexible and powerful, as it supports various web standards, such as HTML, CSS, JavaScript, and more. You can also bind JavaScript code to Android code, enabling communication between your web page and your app. For example, you can call a JavaScript function from your Android code, or vice versa.
How to use WebView in your Android app
There are two ways to add a WebView to your app: either by including the <WebView> element in your activity layout XML file, or by creating a WebView object programmatically in your activity’s onCreate() method.
To add a WebView in your layout XML file, use the following code:
<WebView
android:id="@+id/webview"
android:layout_width="match_parent"
android:layout_height="match_parent" />
To load a web page in the WebView, use the loadUrl() method. For example:
val myWebView: WebView = findViewById(R.id.webview)
myWebView.loadUrl("[http://www.example.com](http://www.example.com/)")
To add a WebView in your onCreate() method, use the following code:
val myWebView = WebView(activityContext)
setContentView(myWebView)
Then load the web page with:
myWebView.loadUrl("[http://www.example.com](http://www.example.com/)")
You can also load HTML content from a string using the loadData() or loadDataWithBaseURL() methods. For example:
// Create an unencoded HTML string
// then convert the unencoded HTML string into bytes, encode
// it with Base64, and load the data.
val unencodedHtml = "<html><body>'%23' is the percent code for ‘#‘ </body></html>"
val encodedHtml = Base64.encodeToString(unencodedHtml.toByteArray(), Base64.NO_PADDING)
myWebView.loadData(encodedHtml, "text/html", "base64")
You can also use these methods to load inline HTML:
val htmlString = "data:text/html,<html><p>Hello :)</p></html>"
myWebView.loadUrl(htmlString)
Loading Local Files with WebView
webView.loadUrl("file:///android_asset/test.html", null)
JavaScript Interface For Communication
fun javaInterface(){
class JsObject(){
@JavascriptInterface
fun logger(res: String){
Log.v("JsObjectResult", res)
}
}
myWebView.addJavascriptInterface(JsObject(), "JsObject")
myWebView.webViewClient = object : WebViewClient(){
override fun onPageFinished(view: WebView?, url: String?) {
super.onPageFinished(view, url)
myWebView.evaluateJavascript("JsObject.logger(document.domain)", null)
}
}
myWebView.settings.javaScriptEnabled = true
myWebView.loadUrl("https://ifconfig.io/")
}
Post Message (Sending Message From Java to JavaScript)
What is Post Message?
postMessage is used to transfer data between two different origins.
myWebView.settings.javaScriptEnabled = true
myWebView.webViewClient = object : WebViewClient(){
override fun onPageFinished(view: WebView?, url: String?) {
super.onPageFinished(view, url)
myWebView.evaluateJavascript(
"window.addEventListener(\"message\", (event) => {\n" +
" alert(`Received message: \${event.data}`);\n" +
"});\n", null
)
myWebView.postWebMessage(WebMessage("I'm from JAVA :)"),
Uri.parse("https://example.com"))
}
}
myWebView.loadUrl("https://example.com/")
Post Message (Sending Message From JavaScript to Java)
myWebView.settings.javaScriptEnabled = true
// Creating Web Message Port to make JavaScript able to response back to Java
val channelPorts = myWebView.createWebMessageChannel()
channelPorts[0].setWebMessageCallback(
object : WebMessageCallback() {
override fun onMessage(port: WebMessagePort?, message: WebMessage?) {
message.let {
Log.v("postMessageDemo2", "[+] Data: ${it?.data}")
}
}
}
)
myWebView.webViewClient = object : WebViewClient(){
override fun onPageFinished(view: WebView?, url: String?) {
super.onPageFinished(view, url)
myWebView.evaluateJavascript(
"window.addEventListener(\"message\", (e) => {\n" +
" alert(`Received message: \${e.data}`);\n" +
" var port = e.ports[0]\n" +
" port.onmessage = function(e2){\n" +
" alert(e2.data)\n" +
" port.postMessage('im JavaScript :)')\n" +
" }\n" +
"});\n", null
)
// Sending first message to establish the communication channel
myWebView.postWebMessage(
WebMessage("I'm Java. Let's Talk together.", arrayOf(channelPorts[1])),
Uri.parse("https://example.com/")
)
// Now we can send all other messages with this channel
channelPorts[0].postMessage(
WebMessage("I'm Java. Let's Talk together."))
}
}
myWebView.loadUrl("https://example.com/")
Cloaking
What is cloaking in Android malware?
Cloaking is a technique used by some Android malware to evade detection and analysis by security solutions or users. On other words, its process of using multiple techniques to making certain in-app behaviors dependent on specific conditions in order to avoid the detection or witness of those behavior.
Why understanding clocking is important for malware analyzers
- Most of malwares show different behaviors when running in virtual machine. Therefore if you don’t know this point you probably missing a lot.
- Due to referrer cloaking the source of the app installation matters downloading from VT(Virus Total) can cause a much different experience than installing from an in-the-wild source.
- Malware developers expect you to look at their app during a relatively short time-window, during deep-dive investigations try to run the malware for at least 72 hours to see the full picture.
Universal Cloaking Techniques
Even across multiple platforms campaigns successfully utilizing cloaking usually include most of the following elements:
- Setting up a C2 infrastructure to invoke specific behaviors based on network responses. Your C2 controller say to agent what and when to do some works
- Gathering client-side data about the system resulting in a fingerprint that can be reproduceable across install attempts, generally results in a persistent device identifier either provided system or unique to the campaign itself
- The unique device identifier is often accompanied by a one time installation ID allowing the camping to track number of attempts per persistent device identifier. For example if C2 controller sees a device installed the app more than four times in 24-hours is potential analyst not going target them.
- Ensuring network requests aren’t coming from blocked ASN such as a cloud provider, VPN-provider, or a known AV vendor. Most of AV vendors register net-blocks and malware C2 controller can find them.
- Server-side systems in place to block behaviors for certain device IDs.
Common Android Device Checks
Checking the CameraInfo interface
Registering a sensor event listener
Checking the kernel version and build name
- Automated analysis systems usually deploy kernel level hooks and are likely to have a custom build name or version number
Reading the /proc/cpuinfo or /proc/tty/drivers
- Checking for X86 —> ARM translation
- Checking for GOLDFISH drivers common to Android Emulators
Parsing of Android.OS.Build class
Build | Android Developers
Time Based
- Malware developers knows our time is limited, therefore they wait for 24-houres or more to ensure you’re a real user
App Based
- Apps may check for extremely common apps like Facebook and grow suspicious of users that don’t have them.
Referrer Based
- Checking the source of malware installation
Some Other Cloaking Techniques
Time Delay
Time delays are likely the most common approach to avoid sandbox detection. Also time delays have other benefits too. For example monetizing a user aggressively only after the user has had the app installed for more than 72 hours makes it less likely the user suspicious the malware
Dynamic code loading
One of the most common ways of cloaking Android malware is to use dynamic code loading, which means that parts of the malicious code are not embedded in the app itself, but are downloaded from a remote server at runtime. This makes it harder for static analysis tools to detect the malware, since they only see the initial app code, not the malicious payload that is executed later.
For example, toll fraud malware, which subscribes users to premium services without their consent, often uses dynamic code loading to fetch the premium service offers and initiate the subscriptions. This way, the malware can adapt to different network operators and regions, and avoid being flagged by Google Play Store policies that prohibit apps from sending SMS or making calls to premium numbers.
Screen recording
Another way of cloaking Android malware is to use screen recording, which means that the malware captures the screen of the infected device and sends it to a remote server. This allows the attacker to see what the user is doing on their device, such as entering credentials or OTPs for banking or cryptocurrency apps.
For example, Vultur malware, which steals login information from more than 100 banking and cryptocurrency apps, uses screen recording to monitor when the user opens a targeted app and then records their screen. The malware uses a real implementation of the VNC screen-sharing application to mirror the screen of the infected device to an attacker-controlled server.
Anti-Analysis
This is the process of detecting and avoiding security software or researchers that try to analyze the malware. Anti-analysis techniques can be based on environmental checks, such as checking for emulators, debuggers, sandboxes, or antivirus apps, or on behavioral checks, such as checking for network connections, user interactions, or sensor data. If the malware detects any signs of analysis, it can change its behavior, terminate itself, delete itself, or trigger a malicious payload.
Obfuscation
This is the process of transforming the code or data of the malware into a form that is difficult to understand or reverse engineer. Obfuscation can be applied at different levels, such as source code, bytecode, or native code. Some common obfuscation techniques include renaming variables and methods, using encryption or compression, inserting junk code or dead code, or using reflection or dynamic loading.
Abusing accessibility services
Another way of cloaking Android malware is to abuse accessibility services, which are designed to help users with disabilities interact with their devices. Accessibility services can perform actions such as clicking buttons, filling forms, or reading notifications on behalf of the user. However, some malware apps request accessibility permissions to perform malicious actions without the user’s knowledge or consent.
For example, Cloak & Dagger malware, which can perform phishing attacks or steal sensitive information from other apps, abuses accessibility services to overlay fake UI elements on top of legitimate apps or system settings. The malware also uses accessibility services to prevent its uninstallation by automatically clicking the back button when the user tries to access the app details screen in the Android settings.
Mitigating cloaking in Android malware
Cloaking in Android malware poses a serious threat to users’ privacy and security, as it can bypass traditional detection methods and perform fraudulent activities on their devices. However, there are some ways to mitigate this threat, such as:
- Using mobile security solutions that can detect dynamic code loading, screen recording, or accessibility abuse by analyzing the app behavior at runtime.
- Updating Android devices to the latest version, as newer versions have introduced restrictions or warnings for apps that use dynamic code loading, screen recording, or accessibility services.
- Being careful when granting permissions to apps, especially accessibility permissions, and checking if they are necessary for the app functionality.