Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False possitives on Huawei phones #4

Open
Shusek opened this issue Mar 11, 2019 · 12 comments
Open

False possitives on Huawei phones #4

Shusek opened this issue Mar 11, 2019 · 12 comments

Comments

@Shusek
Copy link

Shusek commented Mar 11, 2019

Randomly on Huawei phones Magisk UDS Detection Method return true even if current device is not rooted. It is really hard to detect because it looks like it is not permanent. At this moment i do not have any Huawei device but when i get it i will provide more information.

@KimChangYoun
Copy link
Owner

I have recently confirmed that some devices have a Unix Domain Socket with a default 32-character random character.

Especially, it has been confirmed on LG phone, and probably the same symptom appears on Huawei phone.

I am going to fix this problem soon.

@Stoisss
Copy link

Stoisss commented Jun 11, 2019

Are there any updates on this issue?

@arter97
Copy link

arter97 commented Jun 16, 2019

This whole idea of detecting Magisk by filtering 32-char String from /proc/net/unix is beyond ridiculous and almost irresponsible.

This issue confirms there are false-positives. You're basically promoting your clients/watchers to use unreliable methods to detect random system services and treat them as Magisk.

Magisk can easily workaround this by randomly picking any binary names from /system/bin and marking its Unix socket name to /dev/socket, and you would have no idea whether that's a legitimate system daemon or Magisk.
Or, avoid using a Unix socket altogether.

God, I really hope apps in production isn't using this horrible method.

@KimChangYoun
Copy link
Owner

KimChangYoun commented Jun 16, 2019

@arter97
If you have a better alternative to Magisk Hide detection, please let me know.

If you criticize the project itself without any alternative, do not forget that it is stupid.

This is because the project is based on the idea that Magisk Daemon and the Magisk Manager app will detect the presence of Magisk by reversing the way they communicate with each other.

Please note that the code in this project has not been optimized or upgraded.
However, if you want to use this project's Magisk detection logic in real commercial products, you need to reinforce detection logic.

This project only explains how to detect whether Magisk has a suspected unix domain socket.

If you need better detection logic, I can personally help you.
We simply do not want to underestimate this project.
Always remember that there may be areas you have not thought of.

Finally, I have confirmed that an improved version of this detection logic is being used in some commercial software.
This issue is due to the fact that on some smartphones such as Huawei and LG, there is a daemon that uses a random 32-bit unix domain socket in a similar way to Magisk,
Likewise, there are many ways to solve this issue, but I think it is right to leave this part for the developer.

Thank you.

@KimChangYoun
Copy link
Owner

@Stoisss
There are some fixed 32-character unix domain sockets used by smartphones such as Huawei and LG.

I think there will not be many such unix domain sockets.
Of course, you can work around any issue by filtering out well known unix domain socket names.

However, since the types of smartphones are very diverse at present, we hope to keep up with the issues.

@arter97
Copy link

arter97 commented Jun 17, 2019

If you criticize the project itself without any alternative, do not forget that it is stupid.

I don't have to provide an alternative to an idea which in its principle is flawed.

This is because the project is based on the idea that Magisk Daemon and the Magisk Manager app will detect the presence of Magisk by reversing the way they communicate with each other.

Magisk system daemon will always have the full access to the sandboxed Magisk Manager app, which other 3rd party apps don't. Magisk can ditch the Unix domain socket IPC altogether.
The author didn't care much until now because he automatically assumed that no production apps would actually be using this erroneous method.

Finally, I have confirmed that an improved version of this detection logic is being used in some commercial software.

Yeah, I confirmed too that your so-called "improved logic" was to just change if (len >= 32) to if (len == 32). I've managed to bypass root detection from 35 apps from 33 partners listed here just by changing Magisk socket name generation to generate a string that's 4 to 12 characters long, with nothing else changed. The master mount namespace still had /sbin/su and everything.

Is this what you call security?
Do those companies actually know what kind of security practices its apps are deploying?

There are some fixed 32-character unix domain sockets used by smartphones such as Huawei and LG.
I think there will not be many such unix domain sockets.
Of course, you can work around any issue by filtering out well known unix domain socket names.

ARE YOU SERIOUS? I’m genuinely baffled by the idea you’re suggesting right now.

If an app developer or a system OEM decides to use an Unix socket that just happens to be 32 characters long, this will trip root detection when the users didn’t do anything remotely root-related, which happened already. You simply cannot build a whitelist from every possible scenarios.

How long did it take for you to actually realize that this method will inevitably have false-positives? 6 months? And you’re still suggesting this idea? I’ve seen some root detections causing false-positives on people who don’t even have the slightest clue what “root” is, but I never imagined it would have been caused by this level of retardness.

Security researchers need to be more aware and responsible of what implications they are bringing to the ecosystem.

This method will stop working from Android Q anyways:
https://developer.android.com/preview/privacy/data-identifiers#proc-net-filesystem

You’d better come up with other method that works fundamentally different(hopefully much better than this one) or design data-sensitive softwares to be root-proof.

People who are looking into deploying this method to your app yourself, do it only when you think potential client losses from random false-positives could be justified.

@KimChangYoun
Copy link
Owner

KimChangYoun commented Jun 17, 2019

@arter97
I have read your thoughts well and now I will write my opinion.

First of all, I am reminded that this project was not released to explain the complete detection logic.
You look like someone who is just looking for elegant and cool logic.
Unfortunately, at least there is no such thing in this project.

And you have some misunderstandings.
The position of Magisk is different from that of this project.

If Magisk continues to update, you should continue to develop detection logic that can naturally catch up.
Is that fair?

Currently, up to 18 versions of Magisk Hide can be detected in this project.

I want to show that Magisk is detectable in any way.
This is just a fight between a spear and a shield.

Analyzing the source code of Magisk Daemon
I found a section that uses the unix domain socket
Based on this, we have created detection logic.
Of course, I have intentionally written only very rudimentary routines.

I would like to remind you that the more advanced logic used by commercial software does not judge the length of the unix domain socket name alone.

If I give you a hint, think about what a unix domain socket is usually and where it is used.

Also, it is a fact that you misunderstood that the Magisk Manager app is not available at all in third-party apps.

You do not understand, but the field of security is very difficult.

I just wanted to show that the detection of Magisk Hide, which was not possible before, is detectable in a very simple way.

Detection logic itself is so easy to understand?

Talking about Android Q, according to my tests, I could not look up the unix domain socket, but I could detect it in a different way.
I do not plan to reveal the detection functionality that works on Android Q yet.

The way to detect rooting is not a fashionable and elegant way to think.
This is because the rooting is already after the smartphone is contaminated, and as the Android version rises, the limitations of the app increase.
It is very difficult to implement rooting detection on commercial products,
Several issues often arise.

Detecting the newest Magisk is a separate matter.
This is because Magisk is already installed and intended to be detected by various smartphones in use.

@topjohnwu
Copy link

Yeah, there are 1 million ways to detect Magisk, and yet you choose to falsely flag all Unix sockets that are 32 bytes long. Great job 👍

@KimChangYoun
Copy link
Owner

@topjohnwu
The head of Magisk has left me a comment and it is an infinite honor for me.
I personally highly recommend Magisk for rooting.
Because it is a very nice and elegant idea.

Thank you and good luck.

@praiseqin
Copy link

看完上下文想笑

@rodbagni
Copy link

rodbagni commented Dec 1, 2023

I just would like to understand why there are so many people angrily against the project's owner and absolutely no one contributing to the project. What is you point anyway? This is so ridiculous unrespectful. Are you serious people or only a bunch of kindergarten children that love to depreciate other people? Obviously, it's second choice. The only real contribution here so far is from the project's owner and if you don't like it, don't use it and go do something more productive with your full-of-hate-life.

@rodbagni
Copy link

rodbagni commented Dec 1, 2023

Yeah, there are 1 million ways to detect Magisk, and yet you choose to falsely flag all Unix sockets that are 32 bytes long. Great job 👍
@topjohnwu
I didn't see a better one from you either. Where is it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants
@KimChangYoun @Shusek @arter97 @praiseqin @topjohnwu @rodbagni @Stoisss and others