Hide Riru

[kotori2]

We all know that riru can be easily detected by parsing /proc/self/maps. Is there any possibility that we hide Riru with following modifications:

1. Copy implementation of libmemtrack.so to riru, to prevent producing libmemtrack_old.so
2. Create metadata in some place like /data/adband load riru modules with random name and random export table
3. For symbols in .text segment, i don't have idea for now, maybe use some protection and encrypt plaintext strings, to prevent memory searching

[tianyah]

What do you suggest

[tianyah]

Parse /proc/self/maps for detection ，What can't be detected

[kotori2]

@tianyah That's why we need random ELF names

[tianyah]

please parse /proc/self/maps， According to what features can riru be detected?

[kotori2]

@tianyah

OnePlus7Pro:/proc/7181 # cat maps |grep riru
f0501000-f0531000 r-xp 00000000 fc:02 9444869                            /system/lib/libriru_storage_redirect.so
f0531000-f0534000 r--p 0002f000 fc:02 9444869                            /system/lib/libriru_storage_redirect.so
f0534000-f0535000 rw-p 00032000 fc:02 9444869                            /system/lib/libriru_storage_redirect.so
f0700000-f077c000 r-xp 00000000 fc:02 9445053                            /system/lib/libriru_edxp.so
f077c000-f0781000 r--p 0007b000 fc:02 9445053                            /system/lib/libriru_edxp.so
f0781000-f0782000 rw-p 00080000 fc:02 9445053                            /system/lib/libriru_edxp.so
f07d7000-f07f1000 r-xp 00000000 fc:02 9175162                            /system/lib/libriru_location_report_enabler.so
f07f2000-f07f4000 r--p 0001a000 fc:02 9175162                            /system/lib/libriru_location_report_enabler.so
f07f4000-f07f5000 rw-p 0001c000 fc:02 9175162                            /system/lib/libriru_location_report_enabler.so

[tianyah]

Yes, obviously

[kotori2]

@tianyah obviously i didn't get what you mean

[tianyah]

I mean the features are obvious

[upthekhyber]

I have an app that is apparently able to detect Riru (Riru Core is the only installed Magisk module). As soon as I remove the Riru Core module, the app runs fine.

Is there a way to find out if the changes proposed by @kotori2 would help in this case?

[RikkaW]

First, It's possible to detect if a file is added/replaced by Magisk modules, so any randomization is meaningless (not many people know for now). Also in the future, SafetyNet may enforce locked bootloader (apps can achieve this without SafetyNet if they want). We can do something to "hide" for now (if they haven't used those methods), but in the long run, play this cat-and-mouse game is not fun and we have already lost.

[kotori2]

1. I think it is a Magisk side issue, and someone mentioned that in your group
2. Not much apps check SafetyNet for now, especially for phone manufacturers in China. Users can't access SafetyNet API as well. Anyway I don't think it is meaningless to add hide functionality, at least they will make native hooks lives longer.

[MlgmXyysd]

First, It's possible to detect if a file is added/replaced by Magisk modules, so any randomization is meaningless (not many people know for now).

But don’t know what these random names mean, and some people did not use Magisk to install riru

At present, if there is no other test like symbols in .text segment, random names are valid and feasible

Also in the future, SafetyNet may enforce locked bootloader (apps can achieve this without SafetyNet if they want).

Most software does not use SafetyNet to verify

My plan is to remove the prefix of riru_ for the riru module, and randomly name the original libmemtrack.so for the riru core, and then replace the so binary of riru with a random name

Edit: There are some software that can detect Storage Redirect and make corresponding countermeasures (钱钱飞走了