Hello
When i try to modify a file in Windows 8 apps. it says "You need permission to perform this action. You require permission from Administrator to make changes in this file"
I have full admin rights. i had followed the tutorial https://www.youtube.com/watch?v=KX3Ev_MfyPM and apply anything but i can't still modify the file. i just want to change background, text and other thing in metro apps like this http://justinangel.net/BlogFiles/WindowsLiveWriter/Hacking-Windows-8-apps_947C/image_22.png
Check the file / directory permissions on the item you're trying to change. Odds are, Admin doesn't have the requisite permissions and you need to be SYSTEM or TrustedInstaller or something.
However, Admin *does* have the permissions to overwrite access controls. If nothing else, you can take ownership of the item and then you can set its permissions any way you want.
Be aware that this kind of tampering may break the app.
GoodDayToDie said:
Check the file / directory permissions on the item you're trying to change. Odds are, Admin doesn't have the requisite permissions and you need to be SYSTEM or TrustedInstaller or something.
However, Admin *does* have the permissions to overwrite access controls. If nothing else, you can take ownership of the item and then you can set its permissions any way you want.
Be aware that this kind of tampering may break the app.
Click to expand...
Click to collapse
how can i be SYSTEM and TrustedInstaller?
Related
sorry to be such an ignoramus but wth is "root"? been trying to do my research but all I come up with is a bunch of tech terms I don't really understand...basically, if anyone can explain in layman's terms what it is, what it does, and how essential it is to the g1, i would really appreciate it...thanks in advance...
root is the name of the most powerful administrative account on Unix operating system.
You may know that Unix (Linux is a Unix. G1 runs on Linux) has user based permission so that a normal user cannot modify the file of the system or of another user. (unless permissions are given)
a "root" account can do anything he wants on the system, delete or change file anywhere, access any resource of the computer.
It's important to people who want to modify their G1 because without "root" access you cannot modify the system files. For example if you want to modify the startup picture you have to replace a file on the G1 that is owned by the root. So as a normal user since you don't have the permission to modify file you cannot change your startup picture. That is why people want root.
Because root is all powerful, root is dangerous. If you are root the system will let you do anything even if it is dangerous.
thank you thank you very much....but now that I know, it's somewhat scary to have this on your phone when you can actually brick your phone if mess around with this "root" thing...
I am having a problem with the security apps on the market like "MobileDefense", "SIM Checker" and so on. They are all great apps but can be easily uninstalled through the market with a little looking around. So what I need is to know how to install the .apk in /system. So basicly I figure that I need to move the .apk to "/system/app" so it is running in the system and cannot be uninstalled via market. So what I need would be the terminal commands to do this if anyone knows. Further more I was wondering if it would also be possible to go in and rename the .apk in "/system" to something like "systemapp.apk" to confuse the person trying to uninstall the app if they happen to stumble upon the manage applications section. Any help would be appreciated!
You can uninstall system apps too.
Yes but not as easy as going into the market and uninstalling. Is there any way to do what I am talking about in the first post? Btw I love your Rom.
Just go to Settings/applications there are the systemapps too...
maxisma said:
Just go to Settings/applications there are the systemapps too...
Click to expand...
Click to collapse
Systemapps was just an example It could also be named something else How would I go about moving "MobileDefense" to /system/app using terminal commands?
maxisma said:
Just go to Settings/applications there are the systemapps too...
Click to expand...
Click to collapse
Actually the Settings application manager cannot uninstall applications in /system. /system is supposed to be read-only on stock Android builds.
Installing something into /system/app is easy. Just install the app normally from the Market, then open your adb or Terminal emulator, remount system, and cp the file from /data/app into /system/app. After, rm the original copy. The downside is you won't be able to update the app from the market.
jashsu said:
Actually the Settings application manager cannot uninstall applications in /system. /system is supposed to be read-only on stock Android builds.
Installing something into /system/app is easy. Just install the app normally from the Market, then open your adb or Terminal emulator, remount system, and cp the file from /data/app into /system/app. After, rm the original copy. The downside is you won't be able to update the app from the market.
Click to expand...
Click to collapse
IIRC, this won't work anyways since they application will be reinstalled but your settings will not? Am I wrong? A wipe will still kill the application's usefulness even if it were built into the ROM.
Is there a way to setup a program default (your settings) so that short of installing an entirely new ROM, you keep your settings???
momentarylapseofreason said:
IIRC, this won't work anyways since they application will be reinstalled but your settings will not? Am I wrong? A wipe will still kill the application's usefulness even if it were built into the ROM.
Is there a way to setup a program default (your settings) so that short of installing an entirely new ROM, you keep your settings???
Click to expand...
Click to collapse
This is a good point; I hadn't thought about the matter of the settings. I have not installed any tracking/retrieval software before so I don't know how they specifically work, but it is theoretically possible for them to work without configuring any settings. It depends on whether the software needs to log into a remote server, but from what I gather some simply act on a sms message. If the action to take is already set by default then there should be no problems. However like I said I have no experience with any actual apps of this sort.
jashsu said:
This is a good point; I hadn't thought about the matter of the settings. I have not installed any tracking/retrieval software before so I don't know how they specifically work, but it is theoretically possible for them to work without configuring any settings. It depends on whether the software needs to log into a remote server, but from what I gather some simply act on a sms message. If the action to take is already set by default then there should be no problems. However like I said I have no experience with any actual apps of this sort.
Click to expand...
Click to collapse
Even with a text message, it would need to be "set" for a default number. Mobile Defense however does use a central server to log into.
Hmm... Is there a way to pull the IMEI from the phone and use THAT as a login??? Then if it were to be incorporated with the phone's ROM, it would be pretty difficult to remove it and not have it send data to the proper people.
Just randomly throwing out ideas here, so pardon my ignorance
Hi all -
Apologies if this is a stupid question. I'm trying to create an app that has the protected 2 level DEVICE_POWER permission. Is this possible without having a full-blown Custom ROM?
Things that I have tried:
1) Move apk from data/app to system/app [in packages.xml the app is then classified as system="true" but isn't allowed to get the permission]
2) In packages.xml, manually hack the certs line to be the same as a system app that does have the DEVICE_POWER permission
3) try to hack the file in /system/etc/permissions to add another gid to DEVICE_POWER or the uid of the app that I'm running
4) tried to re-sign the framework-res.apk and the other other system apk's with the same cert with the AOSP platform key [although google does seem to sign some apps with that key, B&N seems to have done the "right" thing and not signed everything with the platform key]. Just gets caught in a bootloop
In the devicemanager.db under /data/data/com.android.providers.settings/databases, in the registry table, it does show the hash of the system's private key ... wasn't sure if I could do anything with that though.
Someone created a custom screensaver that puts the cover of the book you're reading as screensaver and modified the Settings.apk to do so. I don't quite get how he was able to do that and still have the signature remain intact?
Thanks for the help!
AFAIK you have to build a custom ROM to do this.
Yeah I think so too, apps wanting that permission need to be signed with the platform key afaik.
I don't think I have seen any mention of this idea yet. Sorry if I missed it...
In a recent thread about the 6.2.2 update and people wanting to prevent it, I thought I read that someone saw the file show up in the update directory. I'm assuming this means the same 'kindleupdates' directory you could manually drop the update into -- but if not, the idea is the same. Why not just take some step to prevent access to this directory?
The exact step to take would depend on how smart the developers were about dealing with problems in the update process
The easiest step would be to chmod 555 it. But of course if the update process is running as root it is under no requirement to honor those permissions! (My experience in the unix world tells me that about half the time, programs running as root do honor the permissions even though technically root overrides them).
Another easy step would be to delete it altogether. But they probably thought of that (if it's /mnt/sdcard/kindleupdates where someone could easily accidentally delete it) and recreate it if it's missing.
One trick that is often done is to replace the directory with a file. Some programmers do not think to check this kind of condition - they see there is something there, but they get an error opening it as a directory, and they just declare it's an error.
A more subtle trick would be to replace the directory with a symlink that points to a read-only directory (such as /system). In this case, they could open it as a directory, and just fail to write there. The programmer probably would not have thought to check whether it's a link vs. a real directory. One possible gotcha is if you point to /system, and /system is r/w, then the update could screw something up under /system. So maybe mount /system r/w, mkdir /system/kindleupdates, remount /system r/o, then link the update dir to /system/kindleupdates.
And finally, I don't know if Android has any kind of loopback filesystem capability, but loopback-mounting something read/only on that directory would certainly fake the OS into thinking there was a directory there; it would definitely be read/only, and I don't think they would ever think to check whether there is actually some filesystem mounted there! (and if there was, all you need is an app that constantly accesses some file you put there, which would make it busy so that it couldn't be unmounted).
The first method won't work because the sdcard partition is fat32 and doesn't accept unix permissions.
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
well, i just deregistered my kindle acount and i'm still in 6.2.1...
b63 said:
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
Click to expand...
Click to collapse
Ah, that makes this less practical. Still, perhaps when the next update comes out I can try a variation on this but it requires the filename to be known.
If the update is downloaded as a single file to /cache, which is named the same as the file you can manually grab, then someone who hasn't gotten 6.2.2 (and is not averse to this failing) can try this in a root shell:
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin/blah
The purpose here is to put something unremovable in the way of the file it wants to download. Most likely if the update sees something with the existing name there it would probably want to blow it away (after determining it's incomplete) - and since any update there would normally be a regular file, they probably would do nothing more complicated than a simple unlink syscall to delete it before re-downloading. However, since it's a directory with something in it, that unlink will fail. In actuality, making the subdirectory (second command above) should be unnecessary because the unlink should not work for directories; there's a special rmdir syscall for them.
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
Click to expand...
Click to collapse
I did read a lot of that last time and I don't think I actually saw a definitively successful method. If there is one it should be stickied
My interest in this is a little different from most of you guys - I have very limited satellite internet and I don't like these unscheduled 185-meg downloads so I want to be able to update only when I want mostly to control that. This kind of means looking for the least-intrusive way to accomplish this.
/cache/update-kindle-6.2.2_D01E_3205220.bin is exactly where it downloads
if you find a way to even prevent the download, that would be greatly appreciated
Unfortunately I already got the update so I can't try it this time.
at least you could try your method with a dummy file of an other name and try to overwrite it with adb - if you can't overwrite it there's a good chance
I think I'm about the only one who prevented 6.2.1. I did it by constantly checking the cache folder. Found the update by chance and deleted it before it updated. Waited over a week for it to come back. Never did. An app that watched the cache folder for the updates and then moved/deleted them would work fine
Sent from my SGH-I897 using xda premium
jcase already work a way around this automatic OTA update, so when FIREMOD is ready to replace burrito I think we will have no more problem with this OTA issue. (you can find jcase announcement in the kindle developer section)
Heres what I have done to prevent this.
1) Droidwall (white list only the apps you want to allow internet access)
2) Removed "otacerts.zip" from /system/etc/security/otacerts.zip.
3) I removed "OTASilentInstall.apk" /system/app
4) Installed this 6.2.2 based Rom http://forum.xda-developers.com/showthread.php?t=1439916
Hopefully this eliminates the OTA. I had my Fire rooted on 6.2.1 with twrp and it OTA'd on its own, broke root and twrp. So I rerooted with burritoroot2 and installed CWM based recovery.
****Moderator Note****
A thread on this topic already exists here. Links have been removed from this one.
In Samsung's TTS app, someone discovered an exploit where the app, using it's receiver capabilities, will accept just about any command or information it receives from just about anything. This exploit so far as I know has not yet been patched but does affect a significant number of existing Samsung devices up to present day including the Samsung Galaxy Note 9 (SM-N960U) and probably others. Essentially this exploit allows a user to to run commands as system user (User: 1000) which is essentially one user level below root access. I am hoping this exploit will assist us in finding a root method for this device. In the meantime, as system user, you can run any command in a shell that is available to system. Running root commands will not work. I have not yet explored the extent of this exploit's capabilities, but you can change system props, some of which persist a reboot, probably disable some applications as opposed to uninstalling them per user, have full access to the /data directory and the ability to change anything in /data/system/users/0 at the very least. You need a Windows computer in order to perform these operations. It maybe possible to do through linux, but I did not try. This will also allow Lsposed patch to be installed on the device (a variant of the xposed framework). Though I am not sure it is required this will also allow you to use the dial pad on the device to Launch pretty much every important Samsung secret code that exists. Using Google to search for Samsung secret codes you can find what you need.
NOTE: I did not create this exploit and I do not claim any authorship or ownership over it. I just got it to work on this device. For reference, further reading and additional details and installation methods, please ***Link removed*** The steps below is the easiest and most basic method.
IMPORTANT: changing some of these props and other settings may cause device instability. In some cases a general factory reset will not change these settings back to your factory settings, so if you screw something up you're going to have to download your device's stock firmware and flash your device using odin.
1. Go to the Github repository above and download the zip file and extract it to anywhere you want. If you don't have minimal ADB and fastboot installed, you can get it here. Otherwise you'll need to download Google's platform-tools for Windows.
2. Plug your Note 9 into your PC, making sure ADB is authorized on the device.
3. Navigate to the exploit's folder and open a cmd window inside the folder, or place the folder's files in the platform-tools folder and navigate there and open a cmd window. To do this, click on the folder's window, press and hold down the shift key while right-clicking your mouse and select either "open cmd window here" or "open powershell window". Use adb to push the "samsungTTSVULN2.apk" to /data/local/tmp:
Code:
adb push samsungTTSVULN2.apk /data/local/tmp
.
4. Install "komraids_POC_V1.5.apk" using adb and reboot your Note 9:
Code:
adb install komraids_POC_V1.5.apk and open the app once. Navigate to settings, apps and select the app. Turn off battery optimizations.
adb reboot
5. When your Note 9 is completely rebooted (wait a minute or two after turning it back on, before you unlock your device), return to the exploit's or platform-tools folder and run 'systemshell.exe'. When the box pops up, click on 'start shell' and wait for the process to complete. When finished, click on 'reopen running shell'. You should be user: 1000. Run 'id' in that shell and the user should return as user: 1000. If not successful, navigate to the Github repository for other means of installation. Please note you will have to run this process on your device after every reboot.
With this level of access, you can change some system props, launch hidden activities including some degbug menus in various apps, as well as other things. From the Github repository, some examples of abilities:
Access to most of /efs /efs/imei /efs/sec_efs /efs/FactoryApp - Access to most of /data /data/system /data/user/0/ANY_SYSTEM_APP - The "Insthk" bin becomes useable, - Secure Folder/Separated Apps becomes COMPLETELY compromised if you also install the POC in it (UID 150_system) - start IOTHidden Menu, DM Mode, Service Mode, Multiple Debugging and hidden menus as well as preconfig in system context- Change many protected props, such as: setprop persist.service.adb.root 1, setprop sys.hidden.otatest 1, setprop sys.hiddenmenu.enable 1, setprop persist.sys.knox.device_owner true, setprop persist.sys.usb.qxdm.debug 1, setprop persist.service.adb.enable 1, setprop persist.sys.usb.qxdm.debug 1, setprop persist.rollback.is_test true, setprop sys.oem_unlock_allowed 1.
Click to expand...
Click to collapse
Some props I was able to change which persist upon rebooting:
Code:
persist.service.adb.root 1
setprop sys.hiddenmenu.enable 1
persist.service.adb.enable 1
persist.security.ams.enforcing 0
I am hoping with this access we can figure out a way to use it to our advantage to gain root access. I have only ever had this experience once, where we had gained system level shell access through a debug app accidently left on an Amazon Fire 10 tablet. That access later progressed to root access and from my understanding it is most likely possibility if we can gain this level of access on the device than it is more than likely there is a way to also gain root access. I would very much like any feedback anybody can provide and hopefully we can get further along in this. Please post your modifications and other tricks and hacks in this thread so others can follow along.
@DragonFire1024 Please note that a thread already exists on this topic:
***LOCKED UNTIL FURTHER NOTICE*** System Shell Exploit - ALL Samsung Mobile Devices NO BL UNLOCK REQUIRED.
***MODERATOR ANNOUNCEMENT: THREAD CLOSED*** @K0mraid3 you are hereby required to provide proper credit in your OP as follows: Link the assigned CVE for this exploit as it mentions the author's blog and GitHub, OR Link the original research repo...
forum.xda-developers.com
We do not allow multiple threads on the same topic:
5. Create a thread topic or post a message only once, this includes external links & streaming media.
As a large forum, we don't need unnecessary clutter. You're free to edit your message as you like, so if you do not receive an answer, revisit your message and see if you can describe your problem better. Not everyone is online at the same time so it might take a while before you receive an answer.
You can bump your unanswered question once every 24 hours
Duplicate threads and posts will be removed
Always post in an existing thread if a topic already exists, before creating a new thread.
Use our search function to find the best forum for your device.
Links to an external source are only allowed if relevant to the topic in hand. A description must be included, no copy & pasting from the original source.
Click to expand...
Click to collapse
I am closing this thread.
If you or someone else working on the project would like to have an open thread to discuss this topic, please refer to the original. However, I expect you to read the warnings I have posted, as the exploit covered must be credited to the individual who discovered it.