<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://nirajkharel.com.np/</id><title>Niraj Kharel</title><subtitle>Vulnerability Assessment, Penetration Testing, HackTheBox, HTB.</subtitle> <updated>2026-07-03T06:11:00+05:45</updated> <author> <name>Niraj Kharel</name> <uri>https://nirajkharel.com.np/</uri> </author><link rel="self" type="application/atom+xml" href="https://nirajkharel.com.np/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://nirajkharel.com.np/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Niraj Kharel </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Android - App Link autoVerify=false</title><link href="https://nirajkharel.com.np/posts/app-link-autoverify-false/" rel="alternate" type="text/html" title="Android - App Link autoVerify=false" /><published>2026-06-22T12:15:00+05:45</published> <updated>2026-06-22T12:15:00+05:45</updated> <id>https://nirajkharel.com.np/posts/app-link-autoverify-false/</id> <content src="https://nirajkharel.com.np/posts/app-link-autoverify-false/" /> <author> <name>nirajkharel</name> </author> <category term="Mobile Pentesting" /> <category term="Android" /> <summary> Android App Links let apps claim ownership of HTTPS domains so that links to those domains open directly in the app instead of showing a browser or a chooser. The claim becomes authoritative when the framework verifies it via android:autoVerify="true" against a valid assetlinks.json on the domain. Without autoVerify, the filter is advisory - any other installed app can declare the same scheme a... </summary> </entry> <entry><title>Android - Inspecting the React Native Bridge</title><link href="https://nirajkharel.com.np/posts/react-native-bridge-inspection/" rel="alternate" type="text/html" title="Android - Inspecting the React Native Bridge" /><published>2026-06-21T12:15:00+05:45</published> <updated>2026-06-21T12:15:00+05:45</updated> <id>https://nirajkharel.com.np/posts/react-native-bridge-inspection/</id> <content src="https://nirajkharel.com.np/posts/react-native-bridge-inspection/" /> <author> <name>nirajkharel</name> </author> <category term="Mobile Pentesting" /> <category term="Android" /> <summary> React Native apps have a JavaScript runtime and a native runtime, with a bridge between them. The bridge is enumerable - apps expose a collection of NativeModules that JavaScript can call. Each module has a method list you can dump, then call directly from Frida. In production builds, React Native does not expose its bridge to arbitrary cross-origin JS the way a hand-rolled @JavascriptInterface... </summary> </entry> <entry><title>Android - Janus and v1-Only APK Signing</title><link href="https://nirajkharel.com.np/posts/janus-v1-signing/" rel="alternate" type="text/html" title="Android - Janus and v1-Only APK Signing" /><published>2026-06-19T12:15:00+05:45</published> <updated>2026-06-19T12:15:00+05:45</updated> <id>https://nirajkharel.com.np/posts/janus-v1-signing/</id> <content src="https://nirajkharel.com.np/posts/janus-v1-signing/" /> <author> <name>nirajkharel</name> </author> <category term="Mobile Pentesting" /> <category term="Android" /> <summary> CVE-2017-13156 (Janus) lets an attacker prepend a malicious DEX to an APK and have the system execute the prepended DEX while the v1 signature still verifies. v1 signs files inside the ZIP, not the file as a whole - so prepended bytes before the ZIP boundary are invisible to the signature check. Android 7.0 introduced v2 signing that covers the entire file, closing this. Apps that still ship v1... </summary> </entry> <entry><title>Android - Tokens and PII in Logcat</title><link href="https://nirajkharel.com.np/posts/logging-pii-in-release/" rel="alternate" type="text/html" title="Android - Tokens and PII in Logcat" /><published>2026-06-15T12:15:00+05:45</published> <updated>2026-06-15T12:15:00+05:45</updated> <id>https://nirajkharel.com.np/posts/logging-pii-in-release/</id> <content src="https://nirajkharel.com.np/posts/logging-pii-in-release/" /> <author> <name>nirajkharel</name> </author> <category term="Mobile Pentesting" /> <category term="Android" /> <summary> Log.d, Log.v, Log.i calls in production builds dump strings to logcat. On Android 4.1+ the READ_LOGS permission is signature-only, so a regular third-party app cannot read another app’s logs. But anyone with USB debugging enabled can. Crash-reporting SDKs like Crashlytics, Sentry, and Bugsnag also capture nearby logcat output when a crash occurs and ship it off-device. If sensitive data is in a... </summary> </entry> <entry><title>Android - Class.forName from an Intent Extra</title><link href="https://nirajkharel.com.np/posts/reflection-class-loading-intent/" rel="alternate" type="text/html" title="Android - Class.forName from an Intent Extra" /><published>2026-06-14T12:15:00+05:45</published> <updated>2026-06-14T12:15:00+05:45</updated> <id>https://nirajkharel.com.np/posts/reflection-class-loading-intent/</id> <content src="https://nirajkharel.com.np/posts/reflection-class-loading-intent/" /> <author> <name>nirajkharel</name> </author> <category term="Mobile Pentesting" /> <category term="Android" /> <summary> Class.forName(intent.getStringExtra("class_name")) is one step short of the dynamic-code-loading bug. The attacker cannot supply new code, but they can pick which existing class on the app’s classpath gets instantiated and which method on it runs. In practice that is enough to reach internal initialization logic, OAuth handlers, admin utilities, or database migration runners that the developer ... </summary> </entry> </feed>
