Restricting the user agent for Chromium does not work #825
Comments
|
@BlueMax can you please confirm if this version can restrict the user agent on KitKat: http://d-h.st/vHJ |
|
Yep, gimme a minute... |
|
Doesn't work... Also, the user-agent permissions are not present anymore. There are only two right now. There used to be 6 or so... |
|
About the restrictions: that is correct, getSettings has replace the previous present functions. Did you reboot your device after installing the test version of XPrivacy? |
|
The screenshot shows getSettings was actually called. |
|
Yep, i did reboot. I/XPrivacy/XWebView( 1927): android: hooked android.webkit.WebView.getSettings/view (1) |
|
@BlueMax can you please try if this version works: http://d-h.st/EvR |
|
Still no go... I/XPrivacy/XWebView( 1928): android: hooked android.webkit.WebView.constructor/view (4) |
|
Wait, wait, wait.... It works. something is cached. If i change the user-agent (switch to desktop version) it shows faked data. I will try previous version v1.10.28.1. |
|
Could you capture a log like this: start just before you run the browser, but reboot first, so I can see the initial hooking too. |
|
It just works when i switch to 'desktop' user-agent. And now even the 'WebView.constructor' permission is lit. But when i switch back to normal/mobile user-agent its back to unfaked state. Correction: It just works for one time (right after switching user agent in browser - no matter what user agent). Reloading the page resets to original state. Switching the user-agent in the browser gives another one-time fake. |
|
Can you provide me with a logcat for the switch? |
|
Sure... What has been done:
|
|
Another test version: http://d-h.st/rES (sorry, I cannot test myself, since I don't have a device that can run KitKat yet) If it not works, please make a new logcat: |
|
Indeed.. :) I/XPrivacy/XWebView( 1927): android: hooked android.webkit.WebView.constructor/view (4) |
|
Another test version: http://d-h.st/Pll |
|
Still only for one time... I/XPrivacy/XWebView( 6757): Queue usage data=10027/view/WebView.constructor=true size=1 |
|
:-( |
|
Unfortunately I am out of ideas how to fix this at the moment. |
|
Also does not work in version 4.12 |
|
@gdmzyejian : |
|
On KitKat its the following scenario: Its probably somewhat related to the new tabs. I created several stack traces, forced all Set-/GetUserAgent, parent/child methods and linked lists/hashtables with constants but there's still an alternative runtime path. I couldn't find a proper target. The browser uses an internal counter for custom user agents (overriding system static string from framework-res.apk). If that value is '0' system static settings are in effect. I traced it back and forth into several system parts browser.apk/framework-res.apk/WebviewChromium.jar and also stumbled upon native methods but whatever i touched the original user agent always came through. The shared/static system settings are kinda hard to trace offline. They use exceptions and abstract methods to sync the settings and i don't have a proper debug chain installed. My theory is that the browser omits filling the user agent value on purpose so that the system fills it up with static system values. But i couldn't test it yet... |
|
@BlueMax good work! Maybe getUserAgent(String) needs to be hooked to fix this. Did you find useful class/method names to look into? |
|
Didn't you already hooked getUserAgentString? It's present in the pastebin log above. |
|
@BlueMax could you please try if this version fixes your problem: http://d-h.st/4Wc Please capture a log (whether it works or not). |
|
Please try this newer version: http://d-h.st/IIe |
|
Still no go... Log: I/XPrivacy/XWebView( 1928): android: hooked android.webkit.WebView.constructor/view (4) |
|
:-( |
|
I've traced the string some more. The one in framework.res (strings.xml) seems to be obsolete/outdated: The real user agent string is: Note the 534.30 <> 537.36. Probably legacy string from old engine not needed in new chromium engine anymore. I just started analyzing the native chromium libraries (20MB monster). It seems it does contain the real user-agent string mask (Mozilla/5.0 (%s) AppleWebKit/%d.%d (KHTML, like Gecko) %s Safari/%d.%d). I've hooked some native methods already leading to nothing (same partial leak) but there must be another bit/flag/switch/setting/whatever that leads to different runtime path (ignoring all setUserAgentString methods). I will cross reference the string mask to see whats involved. |
|
@BlueMax again thanks for looking into this! I guess the old Android browser is present next to Chromium, explaining two user agent strings. |
|
They just started implementing chromium. Several things are still buggy like saving passwords, incognito mode and some dialogs/TextViews (like the one that pops up when you want to change the theme on XDA forum). Logcat shows crash due to "Not implemented yet". :-) |
|
Can you try hooking Landroid.webkit.WebView.loadUrl? Its an 'abstract method' that leads to Chromium for KitKat and into Webkit(?) for others. If this works all other user-agent related hooks for all systems should be obsolete. The class holds two methods. Both are used in Android Browser. 1st argument is URL, 2nd is additional http header parameters including user-agent. XPrivacy could force-jump 1st method into 2nd one and 2nd method could be hooked with (static) faked 2nd argument holding the user-agent. If that's not possible, unreasonable or doesn't work we can still tackle Chromium directly by enforcing something like the below runtime path as a last resort. Its probably not as "code evolution resistant" as the loadUrl method above though. java.lang.Throwable: stack dump setOverrideUserAgent is integer, held '2' as i logged and is only called when fake was successful. Probably involved in enabling honoring setUserAgentString internally. Somewhere there i expect the target. Haven't looked all too thoroughly into this yet. I hope we don't need it... |
|
Test version with loadUrl hooked: http://d-h.st/j4E |
|
Still no go... These two 'open new tab' scenarios show different runtime paths. The stable one shows 'setUserAgentString' and 'LoadUrl'. The unstable one only has 'setUserAgentString'. I've disabled hooking 'LoadUrl' and it doesn't show any difference so its probably not of any use. I will inject more stack dumps and watch variables to analyze the two scenarios. There's still enough left i haven't looked into... getUserAgentLocked |
|
Thanks for testing. |
|
In the Android 4.12, MIUIv5, MIUI browser can fake UA, but others do not work. |
|
Xprivicy 1.10.37 |
|
Its a bug in the chromium engine (native code). The chromium internal child tabs do not properly inherit parent properties delivered from Android/Java code. The built-in custom user-agents (Android browser) are affected as well. Most user actions ("open in new tab") result in a new (parent) WebView instance (thus unaffected) compared to clicked links that create new tabs automatically (as child). Unless we can hook native code i'm out of ideas at the moment. |
|
@BlueMax thanks for your research! I guess we have to wait until this Chromium bug is fixed. |
|
Just for reference:
|
|
Thanks again for your research!
|
CM11 (24.11.2013)
Galaxy SIII - I9300
XPrivacy 1.10.27
Xposed 2.4 beta 1
The text was updated successfully, but these errors were encountered: