Bypassing adb detection is not perfect

[Young-Lord]

如题，Ruru中有通过读取prop进行检测的部分，建议加入对这部分检测的拦截

[xfqwdsj]

它似乎使用了 XposedDetector，可以检测 Xposed 并清除钩子（GitHub 地址目前为 404），我认为马上针对它作出改进不太值得。如果你想试一试，可以提交 PR 或者自行修改测试（可以的话，建议模仿原有的样子为每一条检测项设置一个开关）；如果不行，我也会找时间完善这些功能，只是可能没这么快罢了。

[daiaji]

Thanks to Pine now we can hook Java methods + JNI methods + C code + patch instructions.

https://xdaforums.com/t/spoof-locked-bootloader-bypass-tee-check.4586251/post-88652491

Pine可能管用.

[daiaji]

https://github.com/chiteroman/BootloaderSpoofer/issues/1#issuecomment-1875583280 按他们的说法，停用LSP的日志后，没再检测到hook。了。 但让本模块使能后，momo还是能检测到adb启用。

[Verequies]

I believe we can fix some of the issues if we add in hiding the settings props development_settings_enabled=1, adb_enabled=1 and adb_wifi_enabled=1. Obviously making the app think they are set to 0. I used settings list global'to see these options.

Snapchat detects USB debugging, and as soon as you turn it off, it lets you login. Don't even have to clear the app data or close the app, just switch to Developer Options, turn off USB Debugging, switch back to Snapchat, login. Then you can switch back and enable it again. I can only assume its checking the above props on login.

[xfqwdsj]

@Verequies The module already do this.

https://github.com/xfqwdsj/IAmNotADeveloper/blob/6e27a2fe4c45b2089857a2659d8e25822d3721a4/app/src/main/java/xyz/xfqlittlefan/notdeveloper/xposed/Hook.kt#L45-L81

[Verequies]

@xfqwdsj Apologies, you are correct, that is working. Confirmed with Ruru. I have narrowed it down.

It seems the way we are intercepting init.svc.adbd is not always working. Snapchat is looking for this value - I figured it out by manually manipulating the values via terminal. It allows login when the prop isn't running. Setting it to stopped or an empty string via terminal and attempting to login allows you to login successfully. So it appears it is just checking it isn't running.

Is there another way we can intercept this request and return stopped or an empty string?

[xfqwdsj]

@Verequies We also already considered it:

https://github.com/xfqwdsj/IAmNotADeveloper/blob/6e27a2fe4c45b2089857a2659d8e25822d3721a4/app/src/main/java/xyz/xfqlittlefan/notdeveloper/xposed/Hook.kt#L115-L166

The problem is, we do not implement an effective method to intercept it yet. (use a subprocess?)

For now, you can check https://github.com/xfqwdsj/IAmNotADeveloper/pull/31#issuecomment-1776551251.

[Verequies]

Yeah, that is what I mean. It seems the code that you have written does intercept some app checks but not all apps check in that way.

Maybe we could detect when adb is enabled and just set that property to stopped? Not sure if that would muck up anthying else. Adb seemed to work fine when I cleared the init.svc.adbd setting.

[xfqwdsj]

The magisk module I mentioned uses a simple and brute force approach to do this 😂:

https://github.com/rushiranpise/Hide-Debugging/blob/8c09cc248598586abf17bc581f895c82220e35c0/service.sh#L8

But right now I'm temporarily unavailable to maintain this project, PR is welcome.

[Verequies]

Yup that would do it haha. Surely there must be a way to subscribe to an onchange event for a specific prop. That way we can detect if it is changed without polling it.

[Verequies]

So I have done quite a bit of playing around and reverse engineering. It seems that a lot of apps including Snapchat load a native library which then invokes the __system_property_get function. We can't easily hook into this via the usual Xposed hooks. Looks like we need to implement an Xposed Native Hook: https://github.com/LSPosed/LSPosed/wiki/Native-Hook

Have you done any native hooks before? I've only just started researching Xposed so not too familiar yet.

[xfqwdsj]

Interesting. But I haven't gotten into native reverse engineering. Anyway, I can learn native hook since I have a little C (or Rust? 😂 hahaha) basement.

But to get started with native hooks to tamper with properties, we should clearify something. Is this function also be used by getprop command? If so or not, what module scope should we use? The LSPosed's native hooks should be studied in depth.

[Verequies]

I also do have a little experience in C/C++ and Rust. Only problem is I have only started getting familiar with the Xposed framework and Android system in general. I reckon between the both of us we can cover up the developer/ADB status completely haha.

I believe the getprop command - which is actually symlinked to the toolbox command - does in fact use the system call __system_property_get. Not entirely sure what scope the module should be but I suppose we should only apply it to those apps that we have selected in LSPosed?

[xfqwdsj]

https://github.com/LSPosed/LSPosed/wiki/Native-Hook#:~:text=Whenever%20a%20new%20native%20library%20loaded

What library does the function from and who load it? 🤔

[Verequies]

The library is dynamic as its unique per app. We will have to hook into every library that the app loads. Snapchat in particular loads libscplugin.so.

[xfqwdsj]

Oh I mean detection using getprop because this is a common way to do this.

Furthermore, we may need to hook __system_property_get so that we can make the most compatibility. It comes from libc.so. But native hooks seem that cannot hook the result of getprop for specific app, maybe we should do more research.

[Verequies]

I did look into this, if we want to hook the getprop command we will have to hook any Runtime.exec calls. __system_property_get can be called from any native lib, not just libc.so. I have started looking at implementing a quick native lib that does a __system_property_get call in order to to make it easier for us to make a native hook.

Snapchat don't use Runtime.exec however. We definitely need to hook the __system_property_get in order to bypass that check. I used Frida in order to do some reverse engineering as well as some rudimentary APK decompilation and string checks on the binaries.

[xfqwdsj]

Uhmm, maybe the native hook is to intercept a function itself and we should hook libc.so?

But I have no time to verify it at this point...