Database Develop

[Q] How to mod XAP files.

I have LUMIA 620 dev unlocked via dream spark.
I downloaded XAP file from marketplace and it seams to be encrypted so they are not installing via DEV tools to my device.
But i searched around some apps which can be installed via DEV tool because the are modified and i want to know what are the changes that are need to be made in XAP files:good:
One thing i have noticed that those XAP files which can be installed on device via DEV can be opend via any archive software like winrar etc...
but those XAP that are not able to install on device via DEV cannot be open with any archive software.

prashantvrm said:
One thing i have noticed that those XAP files which can be installed on device via DEV can be opend via any archive software like winrar etc...
but those XAP that are not able to install on device via DEV cannot be open with any archive software.
Click to expand...
Click to collapse
The XAP files from the store are encrypted. Unless someone figures out a way to break the encryption, it cannot be done.
The XAP files you found are probably home-made apps, which can be sideloaded, because they're deployed by developer tools in an unencrypted format, or WP7 apps. The encryption is applied after you submit the XAP to the store.
There is no known workaround to sideload store XAPs without an SD card, at the moment.

TheGoldrocker said:
The XAP files from the store are encrypted. Unless someone figures out a way to break the encryption, it cannot be done.
The XAP files you found are probably home-made apps, which can be sideloaded, because they're deployed by developer tools in an unencrypted format, or WP7 apps. The encryption is applied after you submit the XAP to the store.
There is no known workaround to sideload store XAPs without an SD card, at the moment.
Click to expand...
Click to collapse
You are correct sir. It sucks that you can't even sideload Xaps that were downloaded manually due to the app being removed from the WP store on a non-SD device. I'm trying to see if I can make a workaround for this though. It would be nice if it worked. In terms of modifying the encrypted XAP, it'll be a while before one of us figures out how to decrypt, but at the same time that opens a whole new can of worms regarding to piracy.

I've looked at the encrypted XAPs a bit myself; they're basically a PlayReady wrapper around the ZIP archive (XAPs are just renamed ZIP files; I usually use 7-Zip to open them). Unfortunately, I don't think anybody has broken PlayReady yet. The various programs which claim to strip PlayReady (usually from music or video) all appear to work by running the file through the decoder built into various programs like Zune and Windows Media Player, and re-capturing the content that comes out of the decoder. That won't work for these files.
We might be able to do something similar if we can get the XAP decoder out of the phone ROM and use that, though it will be ARM code (I don't know if the x86 "emulator" image includes the DRM decoder) and therefore somewhat tricky to work with. It will also probably be obfuscated to deter reverse engineering, and may be difficult to make work independently. A kernel debugger on the phone may be needed to figure it out.

GoodDayToDie said:
I've looked at the encrypted XAPs a bit myself; they're basically a PlayReady wrapper around the ZIP archive (XAPs are just renamed ZIP files; I usually use 7-Zip to open them). Unfortunately, I don't think anybody has broken PlayReady yet. The various programs which claim to strip PlayReady (usually from music or video) all appear to work by running the file through the decoder built into various programs like Zune and Windows Media Player, and re-capturing the content that comes out of the decoder. That won't work for these files.
We might be able to do something similar if we can get the XAP decoder out of the phone ROM and use that, though it will be ARM code (I don't know if the x86 "emulator" image includes the DRM decoder) and therefore somewhat tricky to work with. It will also probably be obfuscated to deter reverse engineering, and may be difficult to make work independently. A kernel debugger on the phone may be needed to figure it out.
Click to expand...
Click to collapse
It would be nice to be able to put one on the emulator itself and see what was going on..

I offer up my Programs folder dumped from my Lumia 928 if it is any help. Devs do with it as you will At the very least under common files you will find the xaps installed on my device which do open with 7zip and include the license xml. As far as installing or side loading I did throw a few xaps at the various emulators with mixed results. Have at it guys!!!
http://sdrv.ms/13tlc0F

tonbonz said:
I offer up my Programs folder dumped from my Lumia 928 if it is any help. Devs do with it as you will At the very least under common files you will find the xaps installed on my device which do open with 7zip and include the license xml. As far as installing or side loading I did throw a few xaps at the various emulators with mixed results. Have at it guys!!!
http://sdrv.ms/13tlc0F
Click to expand...
Click to collapse
Xaps within the Programs directory from a ROM are unencrypted. These will help out a lot though!
Edit: Ohhh... Something interesting. CommonFiles\Xaps\SyncUi.xap is the Verizon Backup Assistant. This has some code to intercept SMS..
<Extensions>
<!-- Email & Accounts UX Integration -->
<Extension ExtensionName="Accounts_Extension_Standard" ConsumerID="{47998C28-3D90-11E1-8E07-8B2B4924019B}" TaskID="_default" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="SMS_INTERCEPT_STANDARD" ConsumerID="{55DB4873-5CDF-43B0-82B4-87EB13E9BF6B}" TaskID="SmsInterceptAppExtension" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="Service_Agent_Application" ConsumerID="{208558CC-4407-40F8-83AE-AE3D567126B3}" TaskID="BackgroundTask" />
</Extensions>

snickler said:
Xaps within the Programs directory from a ROM are unencrypted. These will help out a lot though!
Edit: Ohhh... Something interesting. CommonFiles\Xaps\SyncUi.xap is the Verizon Backup Assistant. This has some code to intercept SMS..
<Extensions>
<!-- Email & Accounts UX Integration -->
<Extension ExtensionName="Accounts_Extension_Standard" ConsumerID="{47998C28-3D90-11E1-8E07-8B2B4924019B}" TaskID="_default" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="SMS_INTERCEPT_STANDARD" ConsumerID="{55DB4873-5CDF-43B0-82B4-87EB13E9BF6B}" TaskID="SmsInterceptAppExtension" ExtraFile="Extensions\Extras.xml" />
<Extension ExtensionName="Service_Agent_Application" ConsumerID="{208558CC-4407-40F8-83AE-AE3D567126B3}" TaskID="BackgroundTask" />
</Extensions>
Click to expand...
Click to collapse
I don't like the sound of that The app is part of the settings on my device but when opened says there is a problem with my account and contact Verizon.

@tonbonz: Thanks for the dump! That could be really handy. I'll explore and see if I can find anything useful. Any direct applications will likely be Nokia-specific (which among other things means I can't test them) but lots of people have Nokia phones, and I may find something more generally useful too.

GoodDayToDie said:
@tonbonz: Thanks for the dump! That could be really handy. I'll explore and see if I can find anything useful. Any direct applications will likely be Nokia-specific (which among other things means I can't test them) but lots of people have Nokia phones, and I may find something more generally useful too.
Click to expand...
Click to collapse
I've enjoyed the benefits of all the devs and their hard work here at XDA since my HTC Trophy. Glad to give back in any way I can. If any other files or folders are needed I would be happy to oblige...and... I thank you sir!!!

Oh what the h*** Rest of the dump files currently uploading. Dump 1, three 7z files altogether, is the Programs folder from earlier post. Left out maps data from Data/shared data folder as it was huge and of no consequence as to what we are trying to accomplish. Also, to be clear, this is a dump from the Lumia 928 variant package not my actual device. Have fun!!!
http://sdrv.ms/13tlc0F
@djtonka Thank you for your tutorial on Nokia Care Suite on wimdowsmania.pl. 
 @AnDim Extra thanks for ImgMount Tool which was used to dump these files!!!

I'll let you know. Just for curiosity's sake, how are you extracting those files? Is it from a working device, or a ROM image?
EDIT: Just saw your message, thanks for the info!
Initial results are a mix of cautious hope, disappointment, and speculation.
1) The OEM apps use a ton of restricted capabilities (among the most tame, for example, is "ID_CAP_MEDIALIB_PHOTO_FULL", which gives direct access to the image folders and has visibility "public" according to the policy XML files from the Windows directory).
2) The OEM apps can be sideloaded, but you have to remove the PlayReady header and all the restricted capabilities. They aren't very exciting at that point; they may not even start up.
3) Speculation: The so-called "public" restricted capabilities require a (Store-?)signed app when used on a standard phone. It *may* be possible to sign the apps ourselves, install that cert on the phone, and then sideload them, but I doubt it.
4) More speculation: These new, high-privilege capabilities seem to have largely replaced ID_CAP_INTEROPSERVICES. Although the error when trying to sideload them on an interop-locked phone is different than it is for INTEROPSERVICES, it may be that an interop-unlock would allow sideloading apps that use those capabilities anyhow.
5) The OEM apps include WPInteropManifest.xml. It's exactly the same near-empty file as on WP7. However, they don't use COM but instead use the same native-CLR interop as the official SDK advocates (.winmd files that bridge managed code to C++ DLLs). Its presence does not impede sideloading.
6) Speculation: The WPInteropManifest may be needed for apps which intend to use the "raw" win32 API (as opposed to WinRT) in C++. This theory is supported by the presence of things like DLLs that read and write to the registry directly (not through a driver, which would need INTEROPSERVICES), using APIs such as RegCreateKeyW.
7) More speculation: Since we can extract the system libraries from our phones, it should be possible to use the DLL-to-LIB tools to create .LIB files (the official WP8 SDK is extremely short on these) that we can then use to link to the native Win32 API. Although we would still be (cripplingly) limited by the sandbox's low permissions, we could probably do things like write a basic registry browser.
8) The provxml commands to install apps are very simple, but I don't understand all the parameters. Nonetheless, whenever we have an app, its license, and a tool which can process AppInstall provxmls, we should be able to install those apps on any reasonably compatible phone.
9) Speculation: Due to the use of OS-based capabilities rather than OEM drivers, an app that is installed on any given phone *should* work on other OEMs' phones even if it accesses the registry or does similarly privileged operations.
10) There may yet be a vulnerable app which we could exploit (possibly by using a provxml-injection attack?) to write to the registry / move files / do similar stuff. However, it would probably have very limited permissions even so; unlike on WP7, most things which can write to *some* of the registry can't write to *most* of it.

Extreme Debloating

Hello guys!
I've rooted my Z without unlocking the bootloader, so I cannot install a custom recovery. This left me with just the choice to debloat the hell out of the stock rom LP 5.1.1.
So far I've managed to lower the number of system apps form 274 to 70!
I've been looking into the system and found two folders:
- odex.app folder
- odex.priv-app folder
Please note that both folders have the odex. extension, so I'm not talking about the folders without it.
Whenever I try to delete files or folders inside these I get the error that it's a read-only file. I've mounted the system partition to rw in terminal and adb, but I still get the same error.
Are those folders read-only all the time or I'm doing something wrong?
On another level, is there a way of completely disabling some hardware components that I never use like Bluetooth, radio, NFC, DLNA, GPS, camera?
The closest thing I got was a code to disable the GPS from booting in build.prop, but I was looking for something more permanent.
I was hoping there may be a command similar to "pm hide" or "pm disable" for hardware features.

xzdualrecovery - twrp on locked bootldr

[Q] Xposed for nougat to read prefs ith fbe or without

as xposed for nougat is already arrived officially many modules are not working
there is either File Based Encryption in data partition or by wiping data partition from twrp removes it
anybody able to read shared_prefs either with FBE or without it successfully so that it works properly,if that so please let us know how so that other module developers can fix their modules as well

the issue is that you can not read Preferences like used to before
HTML:
pref = new XSharedPreferences(BuildConfig.APPLICATION_ID);
so any values saved in shared_prefs can not be read by xposed at the moment on nougat atleast on galaxy s7 930F
i am looking for workaround,i tried putting prefs in /data/here it works but not so stable

This seems to work OK for me:
https://developer.android.com/refer...xt.html#createDeviceProtectedStorageContext()
https://developer.android.com/refer...renceManager.html#setStorageDeviceProtected()
I adjusted one of my modules to use Device Protected Storage and it seems to initialize preferences fine on FBE devices.

i need tester for this
because i am unable to boot if i flash magisk or supersu without formating data partition ,so i format /data partition and rooted which eventually remove encryption from /data partition so unable to test
i saw your commit but would be fine if i got tested with encrypted /data partition to test

C3C076 said:
This seems to work OK for me:
https://developer.android.com/refer...xt.html#createDeviceProtectedStorageContext()
https://developer.android.com/refer...renceManager.html#setStorageDeviceProtected()
I adjusted one of my modules to use Device Protected Storage and it seems to initialize preferences fine on FBE devices.
Click to expand...
Click to collapse
I have the same issue. To fix it, actually, we don't need to touch device protected storage. But we do need to set up the package folder permission and the preference file permission.
I set the folder to 711, and the file to 644. Then the preference works well. XSharedPreference.makeWorldReadable should set the file permission. And you may need to set up the folder permission manually with setExecutable(true, false).

guangyu.zhou said:
I have the same issue. To fix it, actually, we don't need to touch device protected storage. But we do need to set up the package folder permission and the preference file permission.
I set the folder to 711, and the file to 644. Then the preference works well. XSharedPreference.makeWorldReadable should set the file permission. And you may need to set up the folder permission manually with setExecutable(true, false).
Click to expand...
Click to collapse
The thing is OS automatically changes permissions of preference files back and removes readable flags. This happens when preferences are committed to the filesystem.
To work around this I had to implement a solution that tracks those changes and adjusts permissions as necessary.
https://github.com/GravityBox/Gravi...o/nougat/gravitybox/SettingsManager.java#L371
https://github.com/GravityBox/Gravi...ougat/gravitybox/WorldReadablePrefs.java#L157

C3C076 said:
The thing is OS automatically changes permissions of preference files back and removes readable flags. This happens when preferences are committed to the filesystem.
To work around this I had to implement a solution that tracks those changes and adjusts permissions as necessary.
https://github.com/GravityBox/Gravi...o/nougat/gravitybox/SettingsManager.java#L371
https://github.com/GravityBox/Gravi...ougat/gravitybox/WorldReadablePrefs.java#L157
Click to expand...
Click to collapse
Yeah, you're right. So we need to proactively set it readable to work around it.
By the way, Gravity Box is a great project. It helps me a lot on the exposed development.

Hello, Can i help me.
Android 7.1.1 (Nougat) can not be used XSharedPreference can not read the contents of the file,How to solve this problem?Thank you

Root Explorer & AutoRun Receiver modification How to? (Going from SuperSu to Magisk)

Root Explorer & AutoRun Receiver modification How to? (Going from SuperSu to Magisk)
I'm old school, using SuperSu, looking at a new phone will have to use Magisk. I understand it is systemless still unsure if i can do what I did prior with SuperSu like running root explorer and making changes to the system partition files does not appear to be as simple as it was with SuperSu. A thread mentioned that a module is needed. Can someone explain to me in detail what is required to make a change to a system file and if my understanding is correct I can't just fire up Root Explorer and make the changes on the fly?
This also ties to other apps like AutoRun which I use to manage all the receivers for all the apps and system apps. How can this be achieved with Magisk which is systemless root?

SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).

..

Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot

Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.

arf8 said:
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot
Click to expand...
Click to collapse
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.

Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Didgeridoohan said:
Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.
Click to expand...
Click to collapse
Thanks again, very useful information.
The edits will be to XML files to tweak and mod the usual CSC open up hidden features, etc so hopefully that does not trigger SafetyNet.
I did read a little about Q on and Pixel 3. I believe he achieved root on Pixel 2. If this is the case it is a sad day for those of us who like to do mods the old fashion way.
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks

arf8 said:
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks
Click to expand...
Click to collapse
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:

wilsonhlacerda said:
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
Click to expand...
Click to collapse
I thought based on the response from Didgeridoohan that touching some system files does not trigger safetynet?
wilsonhlacerda said:
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
.
Click to expand...
Click to collapse
Thanks this makes sense, but how does one create a module for an application that modifies countless files. I get AdAway modifies the hosts file and changing xml files is easy enough to change because you know what file changed. But for a program like AutoRun Manager which changes countless program receivers, how do you make a module out of that? The application itself modifies countless files based on the changes made in the application. I don't assume everything can be done through a Systemless module or am I wrong?
wilsonhlacerda said:
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
Click to expand...
Click to collapse
Understand on the updates if changes are done via systemless.
So if i copy a system file and place it in the specific folder of Magisk is there more required to make this a module. You will have to excuse my Magisk ignorance. I'll have to look at those modules to see how they made them and see if i can apply the same to the mods I want to do on single files but the bigger issue is on applications itself that modify multiple files like Autorun, Tasker, VPN clients etc.
wilsonhlacerda said:
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.
Click to expand...
Click to collapse
Thanks I read through the readme at Github but I had more questions than answers.

Didgeridoohan said:
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:
Click to expand...
Click to collapse
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.

arf8 said:
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
Click to expand...
Click to collapse
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.
Click to expand...
Click to collapse
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...

Didgeridoohan said:
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...
Click to expand...
Click to collapse
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk

arf8 said:
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
Click to expand...
Click to collapse
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
Click to expand...
Click to collapse
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
Click to expand...
Click to collapse
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk
Click to expand...
Click to collapse
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...

Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
Click to expand...
Click to collapse
Makes sense, i was looking for build.prop
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
Click to expand...
Click to collapse
understand
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Click to expand...
Click to collapse
This is probably the most disheartening to hear as I'm not sure what other alternative there is to make a complete snapshot. I assume TWRP but i'm not familiar enough with it and it does not work with the S10.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.

Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.

arf8 said:
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.
Click to expand...
Click to collapse
arf8 said:
Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.
Click to expand...
Click to collapse
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.

Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Didgeridoohan said:
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.
Click to expand...
Click to collapse
Thanks as usual for the confirmation.
To summarize & correct me if I'm wrong, but the take away for anyone else coming from SuperSu to Magisk who read this thread, is that you will still be able to modify the system files the same old fashion way with apps like Root Explorer, caveat pre-Q (upcoming Android OS), but you give up the ability to Hide Root, which is one the key features what Magisk is known for. Otherwise you can go the modules route which is "systemless" and maintain the ability to hide root.
Does that sound right?
For those like me who are used to the old fashion way of tweaking it will take some getting used to modules and creating them. The problem or issue becomes older style apps which can't be adopted to modules is where the issue arises for systemless conversion. I learned a lot so I appreciate your feedback. If you ask me some of this info should be sticky'd somewhere.

You've almost got it... Even with most old-fashioned system modifications you should be able to hide root. The problem arises if you do some kind of edit that apps looking for root usually look for, like installing Busybox. But that specific case shouldn't be an issue, since there's a Busybox module available in the Magisk repo.
Actually, many if the things you'd normally edit after having rooted can be done through Magisk modules already available.
Debloating - use Debloater.
Systemising apps - use App Systemizer.
Editing build.prop and other prop values- use MagiskHide Props Config.
Hosts adblocking - use the built-in systemless hosts module (Manager settings) and AdAway (or your hosts editor of choice).
Etc...

Thanks, I do have busybox installed so I will use the Module for sure and all the other modules you mentioned. The concern is applications themselves like AutoRun for example and I'm sure more. But good to know the option is there to manually make changes like the old fashion way if you are not concerned about hiding or passing safetynet. I personally don't have anything I want to hide, using this method will trip knox so samsung pay on the phone is out the door. Setting up Samsung Pay on a Gear watch is a different story so that will be beneficial.
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?

arf8 said:
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
Click to expand...
Click to collapse
Yup. Enable the option in the Magisk Manager and reboot. After that Adaway (the regular one from F-Droid) will not touch /system.
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?
Click to expand...
Click to collapse
I'm assuming you mean to get the Exynos version of the S10 (since you won't be able to unlock the bootloader otherwise), so: https://twrp.me/samsung/samsunggalaxys10.html
But, I'm not the right person to ask about full snapshot backups... I never do that (haven't for years), but instead make sure that any important data (photos, etc) always is backed up to the cloud. The rest is easy to set up again after a reset (and a reset is good to do once in a while).

What is the function of the "/ prism" directory in the system folder? (SM-A715F/DS)

Good day,
I recently discovered malware in the root directory under the / prism folder that installed an app called Yandex into my system and contained various hidden APKs. (and files with .sogou at the end).
These manipulated my internet browser in some way and I was only able to remove them by flashing the stock rom.
Now I get the message from TWRP that the partition / prism could not be mounted. Even so, everything seems to be working fine on the device.
Now there is no more content in the / prism directory. What is usually stored there and what is its purpose?
Do I have to rework something?
I can't find an explanation anywhere else on the Internet ...
Thank you and best regards

According to https://github.com/PrismLibrary/Prism
Prism provides an implementation of a collection of design patterns that are helpful in writing well-structured and maintainable XAML applications, including MVVM, dependency injection, commands, EventAggregator, and others.
Click to expand...
Click to collapse
In short Prism is a framework to build applications which in turn it's built on top of another framework called Xamarin (XAML for Android).
As of why it's in the root directory I suspect is part of AppCloud, Samsung's system app, that basically does remote installation of apks.
If it is correlated to AppCloud (Big IF) then:
If you are rooted and on stock OS and have that app enabled it's not far fetched to think that there is an exploit for it out there and basically anyone could remote install any APK through root privileges and the backdoor that AppCloud system app gives the.
It's could be as easy as editing a file from within the malicious app which could change the behaviour and URL from which it fetches the needed apks. Whereas installing apks from within the malicious app needs explicit OS permissions (which AppCloud has).
I too had apps installed post-upgrade by the AppCloud system app, but I don't have root to analyse this further so all the above are just speculations based on the two things you said and my previous observations.
In the end you could have contracted the malware in a million different ways. That's how it goes with root access on OS and careless root management.

I have to admit that I was too careless with root privileges and experimented with little knowledge.
Hope that helps others to deal with it more intensively beforehand.
Your explanation helped me, the problem is a bit more serious, it is probably about corrupt security certificates in the system that are administered from outside
In this case, is it even possible to reset or delete the CA certificates? I guess I fell into a spoofing trap.
Maybe flash the stick rom again through Odin?
Is that embarrassing: D

Sorry for the graveyard post but I don't see any other threads about this.
Prism is the name of the NSA surveillance program. I guess that this is exactly that.
It's hidden because you can only see that it exists with root and most people don't have root.
I have this folder too on my rooted Galaxy Fold 4. It was already in the stock ROM and I cannot remove it because the directory is mounted as read only.
If found the mounts file (which is also read-only) and it says:
Code:
/dev/block/platform/soc/1d84000.ufshc/by-name/prism /prism ext4 ro,seclabel,relatime,i_version 0 0
I tried to give me the permission to write / delete the folder but "permission denied" ... and yes I did that as root.

Nexariuss said:
Sorry for the graveyard post but I don't see any other threads about this.
Prism is the name of the NSA surveillance program. I guess that this is exactly that.
It's hidden because you can only see that it exists with root and most people don't have root.
I have this folder too on my rooted Galaxy Fold 4. It was already in the stock ROM and I cannot remove it because the directory is mounted as read only.
If found the mounts file (which is also read-only) and it says:
Code:
/dev/block/platform/soc/1d84000.ufshc/by-name/prism /prism ext4 ro,seclabel,relatime,i_version 0 0
I tried to give me the permission to write / delete the folder but "permission denied" ... and yes I did that as root.
Click to expand...
Click to collapse
did you ever find anymore about this? ive found it on two of my phones. both samsung. cant find much online about it...