I've noticed that some update.zips include patch files. I've done quite a bit of reading up on what these patches are and how they work... I just can't find anywhere to explain how to create them. It would be extremely useful for myself and I'm sure others to make our own patch files (i.e. someapp.apk.p) to, lets say change a few graphics in several apk's in a single zip file. Anyone able to shed some light on this before i start trying to reverse engineer the applypatch code from Google?
Does anyone have any insight?
Sent from my DROIDX using Tapatalk
Do you have an example update.zip file with a patch that I could look at?
Gene Poole said:
Do you have an example update.zip file with a patch that I could look at?
Click to expand...
Click to collapse
Thanks for the reply, here is an update.zip. all of the patches I've looked at start with "IMGDIFF2" and most have some "BSDIFF4##" mixed in there as well.
http://www.megaupload.com/?d=AOFCEKLW
Here is a imgdiff.c file in which the commented section sheds a little light on it. Although i believe that after 2.1 IMGDIFF1 was replaced with IMGDIFF2.
http://www.netmite.com/android/mydroid/2.0/build/tools/applypatch/imgdiff.c
Well, thanks for providing me the info, but looking into it, it looks like this has little value beyond OEM updates and so forth where it can be guaranteed that the ROM is pristine as it seems that this does diffs directly on the flash image itself.
Thanks for taking the time to look into it for me. theoretically however, couldn't you use this for individual apk's? It appears that the directory structure in the zip would allow you to patch anything. The reason i am looking into this is to change an icon in a group of apk's and then just flash a small update.zip of patches. I know that there may be other ways of doing this but I'd like to try if for no other reason to prove to myself it can be done.
Sorry if I'm incorrect in this, just trying to learn.
My take on reading the referenced file is that this patches a raw disk image. This would only work if the image is pristine (not been added to or changed in anyway). The first paragraph reads:
/*
* This program constructs binary patches for images -- such as boot.img
* and recovery.img -- that consist primarily of large chunks of gzipped
* data interspersed with uncompressed data. [...]
I don't see anyway to patch individual files in this way, and especially in an image such as the data partition that will be completely different on users' devices.
I took that from it as well. However if that was the case the update.zip would only have one patch file for the entire image and not a separate patch file for each apk / script / img / file that is being patched, which it does. It runs the applypatch command for each file being patched.
Gene Poole said:
I don't see anyway to patch individual files in this way, and especially in an image such as the data partition that will be completely different on users' devices.
Click to expand...
Click to collapse
This method that they used in the update.zip could only update individual files because running this update only updated certain apps and no user data was lost. I realize that they could have just updated the image that /system is on. Could it be a possibility that they would break the image up on the phone patch only the files necessary then rebuild the image?
Hi Folks,
Overview
There is a mechanism in Android to override the resources and resource-id values within the framework-res.apk with "Vendor" Specified values. All of this is done transparently at runtime and leaves the original framework-res.apk intact and on the device.
CAUTION - ALWAYS HAVE A BACKUP HANDY. NORMAL OPERATION SHOULD BE FINE BUT WHILE PLAYING AROUND AND SEEING WHAT WAS POSSIBLE THE DEVICE DID CLEAR THE ACCOUNTS DATABASE A COUPLE OF TIMES
Background
While doing some research into how the resources.arsc file are handled internally on Android I came across a Document in the AOSP sources ( frameworks/native/libs/utils/README )
Along with a general overview of resource management, it contained a couple of interesting sections.
The resource overlay extension
------------------------------
The resource overlay mechanism aims to (partly) shadow and extend
existing resources with new values for defined and new configurations.
Technically, this is achieved by adding resource-only packages (called
overlay packages) to existing resource namespaces
...
The use of overlay resources is completely transparent to
applications; no additional resource identifiers are introduced, only
configuration/value pairs. Any number of overlay packages may be loaded
at a time; overlay packages are agnostic to what they target -- both
system and application resources are fair game.
The package targeted by an overlay package is called the target or
original package.
Resource overlay operates on symbolic resources names. Hence, to
override the string/str1 resources in a package, the overlay package
would include a resource also named string/str1. The end user does not
have to worry about the numeric resources IDs assigned by aapt, as this
is resolved automatically by the system.
As of this writing, the use of resource overlay has not been fully
explored. Until it has, only OEMs are trusted to use resource overlay.
For this reason, overlay packages must reside in /system/overlay.
Click to expand...
Click to collapse
What this essentially means is you can create a resource only apk which you place at /vendor/overlay/framework/framework-res.apk.
This file only needs to contain the resources you want to override, the document goes on to explain how the idmap is created in the resources-cache
Note the path is different from the readme file which suggests using /system/overlay, this is not referenced by the source and will do nothing.
Resource ID mapping
~~~~~~~~~~~~~~~~~~~
Resource identifiers must be coherent within the same namespace (i.e
PackageGroup in ResourceTypes.cpp). Calling applications will refer to
resources using the IDs defined in the original package, but there is no
guarantee aapt has assigned the same ID to the corresponding resource in
an overlay package. To translate between the two, a resource ID mapping
{original ID -> overlay ID} is created during package installation
(PackageManagerService.java) and used during resource lookup. The
mapping is stored in /data/resource-cache, with a @idmap file name
suffix.
The idmap file format is documented in a separate section, below.
Creating overlay packages
-------------------------
Overlay packages should contain no code, define (some) resources with
the same type and name as in the original package, and be compiled with
the -o flag passed to aapt.
The aapt -o flag instructs aapt to create an overlay package.
Technically, this means the package will be assigned package id 0x00.
There are no restrictions on overlay packages names, though the naming
convention <original.package.name>.overlay.<name> is recommended.
Example overlay package
~~~~~~~~~~~~~~~~~~~~~~~
To overlay the resource bool/b in package com.foo.bar, to be applied
when the display is in landscape mode, create a new package with
no source code and a single .xml file under res/values-land, with
an entry for bool/b. Compile with aapt -o and place the results in
/system/overlay by adding the following to Android.mk:
LOCAL_AAPT_FLAGS := -o com.foo.bar
LOCAL_MODULE_PATH := $(TARGET_OUT)/overlay
Click to expand...
Click to collapse
All this may sound very familiar to those who have built any AOSP Rom for a device as it is the same concept as the overlay tree which is contained in the device specified directories of the tree. Only this method executes at runtime instead of compile time. There are other differences. Mainly the runtime version only handles the drawables and resources which are included in the resources.arsc of framework-res ( at the moment ) where as the device overlay will handle any file you throw at it. You cannot unfortunately update compressed resources ( i.e the ones in the xml, raw, menu etc ).
The AOSP Tree also contained a test directory for this functionality . /frameworks/base/core/tests/overlaytests and contain an example implementation in the OverlayTestOverlay directory and a runtests.sh shell scripts which highlights that symlinking packages with custom names to framework-res is valid.
Summary
I think this will help modders out and has benefits over the currently widely used method of pulling a devices full framework-res and using apktool to unpack, making the changes and then repacking and resigning ( or using 7z replace, if you're lazy like me ) It will also help with applying/merging multiple mods from different sources as the files only need the include the very basic of the patch.
I don't know how long this functionality has existed but I have never seen it used by any oem and a search of Xda Didn't seem to show any "prior art" of the behaviour. I'd be interested on people thoughts on this, especially if you have seen a rom in the wild that uses it. It's maybe something that could be extended by "us" if google don't have any major plans for it possibly applied to other apks.
KNOWN ISSUES AND WORKAROUNDS
There is a bug in the /frameworks/base/libs/androidfw/AssetManager.cpp. It appears that a umask is set incorrectly when creating the idmap file from the overlay package, as such only the system user had access to it resulting in a failure to apply the overlayed values.
I chmod'd 666 /data/resource-cache/* and reboot to fix this. You can find further details in this google groups post. There is a patch attached the Post which I don't think will apply correctly as the source tree has been Refactored since the patch was created.
See below a workaround
Well this is fascinating. I am going to read the files this afternoon .
That is quite a cool find. Thanks for the tip.
Trevd, I gotta try this. I finally had time to read it carefully. I am going to make a simple one tomorrow. Have you had time to give it a whirl?
Oh, the Google groups link is wrong, I think. It only took me to the Google groups home page.
mateorod said:
Trevd, I gotta try this. I finally had time to read it carefully. I am going to make a simple one tomorrow. Have you had time to give it a whirl?
Oh, the Google groups link is wrong, I think. It only took me to the Google groups home page.
Click to expand...
Click to collapse
Fixed That google link for you, I'll attach some examples and try and put together some more resources on this. I'm going to test it on a couple of different devices. I can however confirm that the functionality is in the ICS code tree and I'm give it a test on CM9 on my HTC Sensations to make sure it functions as expected
Hello Again.
I've done something further research into "weaponizing" this mod so it can be used in anger. The Incorrect Permission Issue highlighted in the first post is pretty much a show-stopper if you want to use this in a flashable zip update for example.
Problem: The idmap is successfully created but cannot be used as the file the world readable file permission is not set.
Solution 1: Patch the AssetManager to create the file with the correct permissions.
This would work but results in the extra overhead of changing core android libraries and would more than likely break Stock OTA Updates because the file hashes won't match.
Solution 1a: Patch the AssetManager to create the file with the correct permissions, Submit the patch to the AOSP project so it is upstream for future releases.
The Patch in the google groups post does not seem to have been submitted as the issue is still there in the latest master branch ( 4.2.1 ) of the AOSP Project. I held off submitting it myself because it is basically someone else's work, However if no-one else is going to do it I suppose someone should . Obviously this solution is still dependent on google actually accepting the patch, carriers including it future roms and numerous other unknown factors which are out of your direct control.
Solution 2: Add a empty idmap in /data/resource-cache folder with the correct permission at the same time as adding the custom overlay.
Although a work around this does solve the issue. This is not as simple as just creating a placeholder zero byte file. The asset manager will reject the file when checking for stale cache files at startup. We need to actually create an empty idmap. Referring back to the original readme file (/frameworks/native/libs/utils/README), google explain the idmap file format
The ID map (idmap) file format
------------------------------
The idmap format is designed for lookup performance. However, leading
and trailing undefined overlay values are discarded to reduce the memory
footprint.
idmap grammar
~~~~~~~~~~~~~
All atoms (names in square brackets) are uint32_t integers. The
idmap-magic constant spells "idmp" in ASCII. Offsets are given relative
to the data_header, not to the beginning of the file.
map := header data
header := idmap-magic <crc32-original-pkg> <crc32-overlay-pkg>
idmap-magic := <0x706d6469>
data := data_header type_block+
data_header := <m> header_block{m}
header_block := <0> | <type_block_offset>
type_block := <n> <id_offset> entry{n}
entry := <resource_id_in_target_package>
Click to expand...
Click to collapse
They also go on to give an example.
idmap example
~~~~~~~~~~~~~
Given a pair of target and overlay packages with CRC sums 0x216a8fe2
and 0x6b9beaec, each defining the following resources
....
the corresponding resource map is
0x706d6469 0x216a8fe2 0x6b9beaec 0x00000003 \
0x00000004 0x00000000 0x00000009 0x00000003 \
0x00000001 0x7f010000 0x00000000 0x7f010001 \
0x00000001 0x00000000 0x7f020000
or, formatted differently
0x706d6469 # magic: all idmap files begin with this constant
0x216a8fe2 # CRC32 of the resources.arsc file in the original package
0x6b9beaec # CRC32 of the resources.arsc file in the overlay package
0x00000003 # header; three types (string, bool, integer) in the target package
0x00000004 # header_block for type 0 (string) is located at offset 4
0x00000000 # no bool type exists in overlay package -> no header_block
0x00000009 # header_block for type 2 (integer) is located at offset 9
Click to expand...
Click to collapse
Further analysis of the asset manager code suggests that although aapt won't create an empty overlay apk it is possible create an idmap file which just contains the file magic along with the original and overlay resources.arsc CRC32 which can be set at zero. Assuming little endian byte ording, these are those magic twelve bytes you need in the /data/resource-cache/[email protected]@[email protected]@idmap
Code:
69 64 6d 70 00 00 00 00 00 00 00 00
The file value will then be updated rather than created when a new overlay apk is provided.
[ EXAMPLES TO FOLLOW ]
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
What you've presented here seems like a light at the end of the tunnel. But while I'm confident in my ability to follow directions, I'm afraid I'm too much of a noob to foresee possible reasons for this not working, which is basically what I'm requesting feedback on. Here's what I have in mind, please feel free to point out the holes in my plan...
1. Create the overlay, with the config.xml containing the proper resource-id's as found in public-xml.
2. Push the overlay. It seems to me that with an unmodified framework-res.apk in place, the overlay will simply replace the values from resources.arsc with identical values, thereby having no effect on the system. Any problems at this stage, then, would be from errors on my part, and naturally I would rather weed them out before the next step...
3. Push a modded framework-res.apk and hope that with the overlay in place and doing its business, the corrupted resource-id's will be quarantined and unable to wreak havoc on the system.
It sounds easy, so I'm sure I've missed something. I appreciate any feedback, scathing or otherwise.
shockwaverider said:
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
What you've presented here seems like a light at the end of the tunnel. But while I'm confident in my ability to follow directions, I'm afraid I'm too much of a noob to foresee possible reasons for this not working, which is basically what I'm requesting feedback on. Here's what I have in mind, please feel free to point out the holes in my plan...
1. Create the overlay, with the config.xml containing the proper resource-id's as found in public-xml.
2. Push the overlay. It seems to me that with an unmodified framework-res.apk in place, the overlay will simply replace the values from resources.arsc with identical values, thereby having no effect on the system. Any problems at this stage, then, would be from errors on my part, and naturally I would rather weed them out before the next step...
3. Push a modded framework-res.apk and hope that with the overlay in place and doing its business, the corrupted resource-id's will be quarantined and unable to wreak havoc on the system.
It sounds easy, so I'm sure I've missed something. I appreciate any feedback, scathing or otherwise.
Click to expand...
Click to collapse
Hi There.
It's sound's plausible. I will say that I was attempting to implement this "trick" on a Samsung Galaxy Note 10.1 which had a TouchWiz Rom installed without any luck. In that case it wasn't retaining the correct permissions for the resource-cache directory. I didn't go as far as patching the init binary... yet!!! I think that will probably sort it out with if you have control of the device so there is still hope on that one.
I've also not tested it with anything other than settings found in the config.xml I suppose if it gets compiled into the resources.arsc it should be alright.
Have you tried recompiling the using aapt instead? I'm afraid I'm no expert on aapt and it's many switches so I'm afraid you're are on your own as far a making the apk goes if you are trying this outside of the AOSP source tree!
Good Luck
trevd said:
Hi There.
It's sound's plausible. I will say that I was attempting to implement this "trick" on a Samsung Galaxy Note 10.1 which had a TouchWiz Rom installed without any luck. In that case it wasn't retaining the correct permissions for the resource-cache directory. I didn't go as far as patching the init binary... yet!!! I think that will probably sort it out with if you have control of the device so there is still hope on that one.
I've also not tested it with anything other than settings found in the config.xml I suppose if it gets compiled into the resources.arsc it should be alright.
Have you tried recompiling the using aapt instead? I'm afraid I'm no expert on aapt and it's many switches so I'm afraid you're are on your own as far a making the apk goes if you are trying this outside of the AOSP source tree!
Good Luck
Click to expand...
Click to collapse
Thanks for the input! I haven't tried compiling using aapt, I'm afraid that I'm working way beyond my abilities here due to a mix of frustration and determination. I ended up here after somebody pointed to barrykr's thread HERE, so I suppose the first thing to do is try out his method and see what comes of it. If it's not successful, then I'll try to sort through all the big words and smart-people talk and figure out how to get it to work.
Hey mate... just noticed this thread of yours. This is awesome... I wonder why it didn't draw more attention.
Anyway... you've probably seen my mods thread over at Rootzwiki, right? I was wondering if this "overlay" thing would actually work for SystemUI too?
shockwaverider said:
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
[...]
Click to expand...
Click to collapse
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
edit. Yes it is possible with images. ****. I'm in heaven right now. Everything will be soooo much easier.
skifyr123 said:
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
Click to expand...
Click to collapse
@skifyr123 That's a pleasant surprise, I was under the belief that it had stopped working... maybe I was doing my own mod wrong ..
The example in the aosp includes images. http://androidxref.com/4.2_r1/xref/...ytests/OverlayTestOverlay/res/drawable-nodpi/ . I don't know whether you can exclude resources, however that shouldn't be an issue as you can "override" a resource that doesn't exist so won't effect anything. I suspect you probably can excluded them...... as we say in the trade "Try it yourself"
@Kookie_Monster : No , I'm fairly certain that it won't the code only handles framework-res... however there a comment in the code that is quite interesting http://androidxref.com/4.2_r1/xref/frameworks/base/libs/androidfw/AssetManager.cpp#198 Line 198. "apps are handled by the Java Package Manager", I'll have to look deeper into that one
Images worked Do you know if this is any different from Xposed engine (http://forum.xda-developers.com/showthread.php?t=1574401).. At least in this you don't have to install anything extra.
skifyr123 said:
Images worked Do you know if this is any different from Xposed engine (http://forum.xda-developers.com/showthread.php?t=1574401).. At least in this you don't have to install anything extra.
Click to expand...
Click to collapse
Hi
I keep hearing things about the Xposed engine, It's looks a very cool project although not something I'd ever use.
Yes this is completely different It's part of Android core platform source code and is implemented by the asset manager http://androidxref.com/4.2_r1/xref/frameworks/base/libs/androidfw/AssetManager.cpp I believe it's been in there since day 1 ( or close enough ). The main difference is Xposed will let you code where as this is limit to certain types of resources.
I'm GUESSING that this was the original method for vendor overlays but possibly not picked up by HTC ( and others ) in Android's early days so the Idea was abandoned, the way the README in the AOSP reads it was fully intended to extend much more than the framework-res. With all that in mind I also wouldn't be surprised if it suddenly disappeared one day because there's no oem's ( that I know of ) using it
skifyr123 said:
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
edit. Yes it is possible with images. ****. I'm in heaven right now. Everything will be soooo much easier.
Click to expand...
Click to collapse
You, sir, are my hero!! :good: :good: :good:
Thank You.
trevd said:
Hi Folks,
Overview
There is a mechanism in Android to override the resources and resource-id values within the framework-res.apk with "Vendor" Specified values. All of this is done transparently at runtime and leaves the original framework-res.apk intact and on the device.
CAUTION - ALWAYS HAVE A BACKUP HANDY. NORMAL OPERATION SHOULD BE FINE BUT WHILE PLAYING AROUND AND SEEING WHAT WAS POSSIBLE THE DEVICE DID CLEAR THE ACCOUNTS DATABASE A COUPLE OF TIMES
Background
While doing some research into how the resources.arsc file are handled internally on Android I came across a Document in the AOSP sources ( frameworks/native/libs/utils/README )
Along with a general overview of resource management, it contained a couple of interesting sections.
What this essentially means is you can create a resource only apk which you place at /vendor/overlay/framework/framework-res.apk.
This file only needs to contain the resources you want to override, the document goes on to explain how the idmap is created in the resources-cache
Note the path is different from the readme file which suggests using /system/overlay, this is not referenced by the source and will do nothing.
All this may sound very familiar to those who have built any AOSP Rom for a device as it is the same concept as the overlay tree which is contained in the device specified directories of the tree. Only this method executes at runtime instead of compile time. There are other differences. Mainly the runtime version only handles the drawables and resources which are included in the resources.arsc of framework-res ( at the moment ) where as the device overlay will handle any file you throw at it. You cannot unfortunately update compressed resources ( i.e the ones in the xml, raw, menu etc ).
The AOSP Tree also contained a test directory for this functionality . /frameworks/base/core/tests/overlaytests and contain an example implementation in the OverlayTestOverlay directory and a runtests.sh shell scripts which highlights that symlinking packages with custom names to framework-res is valid.
Summary
I think this will help modders out and has benefits over the currently widely used method of pulling a devices full framework-res and using apktool to unpack, making the changes and then repacking and resigning ( or using 7z replace, if you're lazy like me ) It will also help with applying/merging multiple mods from different sources as the files only need the include the very basic of the patch.
I don't know how long this functionality has existed but I have never seen it used by any oem and a search of Xda Didn't seem to show any "prior art" of the behaviour. I'd be interested on people thoughts on this, especially if you have seen a rom in the wild that uses it. It's maybe something that could be extended by "us" if google don't have any major plans for it possibly applied to other apks.
KNOWN ISSUES AND WORKAROUNDS
There is a bug in the /frameworks/base/libs/androidfw/AssetManager.cpp. It appears that a umask is set incorrectly when creating the idmap file from the overlay package, as such only the system user had access to it resulting in a failure to apply the overlayed values.
I chmod'd 666 /data/resource-cache/* and reboot to fix this. You can find further details in this google groups post. There is a patch attached the Post which I don't think will apply correctly as the source tree has been Refactored since the patch was created.
See below a workaround
Click to expand...
Click to collapse
is't possible to use vendor overlay to add/ change a value in build.prop file ?
Can someone solve this? I tried to make an overlays to my rom by placing the overlays to /system/vendor/overlays. It works. But when I try to changing to other themes, my overlays gone, I tried to reapply stock theme but didn't worked. Must I try another folder like /system/overlays?
Hey guys,
I am wondering, if it is possible to write to the wmappmanifest.xml file within the app.. I searched on the net,but i didnt find some anwer. The only thing i found was how to read this file: http://www.developer.nokia.com/Comm..._Manifest_(WMAppManifest.xml)_file_at_runtime
If it would be possible we could,try to implement the capability INTEROPSERVICES programmatically..
Two problems with that.
First of all, the app's install directory is read-only to the app permissions. You can't create, delete, or modify any file there from within the app (without some sort of "jailbreak" at least).
Second, and possibly more importantly, the permissions sandbox (or "appcontainer") that the phone uses to restrict an app is created at app install. Modifying the manifest is unlikely to have any benefit whatsoever (it certainly didn't help on WP7).
A good idea, though. Always glad to see people checking for such things.
GoodDayToDie said:
Two problems with that.
First of all, the app's install directory is read-only to the app permissions. You can't create, delete, or modify any file there from within the app (without some sort of "jailbreak" at least).
Second, and possibly more importantly, the permissions sandbox (or "appcontainer") that the phone uses to restrict an app is created at app install. Modifying the manifest is unlikely to have any benefit whatsoever (it certainly didn't help on WP7).
A good idea, though. Always glad to see people checking for such things.
Click to expand...
Click to collapse
I searched on the msdn network and saw that artikle:http://msdn.microsoft.com/en-us/lib...?cs-save-lang=1&cs-lang=csharp#code-snippet-2
Examples
Use the file APIs, such as Windows.Storage.StorageFolder.CreateFileAsync | createFileAsync and Windows.Storage.FileIO.WriteTextAsync | writeTextAsync, to create and update a file in the local app data store
Click to expand...
Click to collapse
Requirements
Minimum supported client
Windows 8
Minimum supported server
Windows Server 2012
Minimum supported phone
Windows Phone 8
DLL
Windows.Storage.ApplicationData.dll
Click to expand...
Click to collapse
maybe it would be possible... I tried to implement it to a sample app, but i failed at the system.io stream...
The app data store and the app install location are completely different things. The data store is a per-app read/write location that is initially empty. The install location is a read-only location that contains the contents of the XAP file (including the manifest and executable code). They are located in different parts of the file system (I could tell you the paths if you want), they have different permissions, they are accessed using different APIs, and they are not interchangable.
even in case of root access, I highly doubt WMAppManifest is ever used after app is installed.
ultrashot said:
even in case of root access, I highly doubt WMAppManifest is ever used after app is installed.
Click to expand...
Click to collapse
Yep, I did some experiments a long time ago: WMAppManifest and/or WPInteropManifest are used on deployment only.
gipfelgoas said:
Hey guys,
If it would be possible we could,try to implement the capability INTEROPSERVICES programmatically..
Click to expand...
Click to collapse
And what does this capability give? (useful for)
I did run native api calls from w8 app, but the file system and process restrictions don't allow anything useful to do (like other than own or system32/ files browsing; registry is readable only; also no useful privileges present)
p.s. 2all: is it possible somehow to install original .xap files (taken from Market) via
\Microsoft SDKs\Windows Phone\v8.0\Tools\XAP Deployment\XapDeploy.exe"
or VS (on dev unlocked device)?
ID_CAP_INTEROPSERVICES is a Windows Phone app "capability" flag that tells the OS to allow the app to access (specifically, create handles to) drivers by device name. This is useful because drivers run outside the security context of the OS, so they are not sandboxed, and thus if they offer IOCTLs (on Windows, DeviceIoControl codes) that can do useful things for us, we can use those IOCTLs to our own benefit.
This is the standard way that OEM apps do stuff which would normally not be possible, like controlling the cellular radios or accessing parts of the filesystem that are outside the app sandbox. Each OEM includes one or more drivers in their ROMs which support these operations.
On WP7, this was the way that early homebrew worked. Access to the filesystem (TouchXplorer, Advanced Explorer) and write access to the registry (Advanced Explorer, Registry Editor, Advanced Config, and others) were made possible by OEM-provided COM DLLs which in turn opened device handles and invoked IOCTLs to obtain the required access. Later, WP7 Root Tools worked by directly accessing the drivers and exploiting security vulnerabilities within them that Heathcliff74 had discovered to gain arbitrary code execution in the kernel. That will be harder on WP8 (assuming we even get that far) because of the many exploit mitigations in the NT6.2 kernel, but it's worth a shot. Even if we can't pull that off, though, there's a decent chance we could get something like the Windows RT "jailbreak" to work, and a good chance that we could get something like the old Advanced Explorer to work.
GoodDayToDie said:
ID_CAP_INTEROPSERVICES is a Windows Phone app "capability" flag that tells the OS to allow the app to access (specifically, create handles to) drivers by device name. Each OEM includes one or more drivers in their ROMs which support these operations...
were made possible by OEM-provided COM DLLs .
Click to expand...
Click to collapse
Thanks for explanations!
Basically i don't see any app using ID_CAP_INTEROPSERVICES in 820.ffu/nokia820 image(having in manifest) . Am i missing something?
As far as i understand If we don't have ID_CAP_INTEROPSERVICES we can't load or properly use OEM-provided COM DLLs? (not enough rights) Am i right?
NB: can anybody suggest such COM-DLL (name) to explore? (as example) from wp8? (as i understand there are no such dlls in WP8 x86 emulator from SDK?)
Thanks again!
smx06 said:
Thanks for explanations!
Basically i don't see any app using ID_CAP_INTEROPSERVICES in 820.ffu/nokia820 image(having in manifest) . Am i missing something?
As far as i understand If we don't have ID_CAP_INTEROPSERVICES we can't load or properly use OEM-provided COM DLLs? (not enough rights) Am i right?
NB: can anybody suggest such COM-DLL (name) to explore? (as example) from wp8? (as i understand there are no such dlls in WP8 x86 emulator from SDK?)
Thanks again!
Click to expand...
Click to collapse
If you want to see a OEM app which uses ID_CAP_INTEROPSERVICES look at this: https://rapidshare.com/files/4165178711/825962362f3144b7a1115d0bb6a3935b.xap Its a app from the Nokia RM860 with product code 059r225 in ncs. In this xap file are also used some other caps, with a "normal" developer cant access.
If we don't have this (or other) capabilities, our app runs in a sandbox and cant access to system features, such as file system ...
If you want to see a COM-DLL, download a ffu file, mount it with this and go then in the windows/system32 directory..
gipfelgoas said:
If you want to see a OEM app which uses ID_CAP_INTEROPSERVICES look at this: https://rapidshare.com/files/4165178711/825962362f3144b7a1115d0bb6a3935b.xap
If you want to see a COM-DLL, download a ffu file, mount it with this and go then in the windows/system32 directory..
Click to expand...
Click to collapse
Thanks for the xap! (if You have some researches on it, it could be also great; to start from already explored stuff)
About COM-DLL i mean not ordinary ones (which i can see in /system32/ of wp8 SDK emulator or /system32/ on my phone), but those DLLs (or +drivers?) which are used by ID_CAP_INTEROPSERVICES apps (to do somthing like reg writing; FS access, etc.)
Thanks!
On WP7, COM DLLs were needed to access the drivers (because WP7 apps couldn't use C++ directly and don't have APIs to wrap CreateFile (for getting the driver handle) or DeviceIoControl (to call IOCTLs). On WP8, COM DLLs (or something like them) may or may not be used; I think it's possible to do what needs to be done using the official C++ SDK but I haven't checked.
In any case, the COM DLLs were just wrappers around the driver IOCTLs. The drivers are the ones that do all the heavy lifting, because they're the things that have the required permissions. Also, I guarantee you that there are some high-permission drivers on the Lumias; you can't do an app like the storage checker/cleanup or whatever it is without them. That requires filesystem access well in excess of what an app is normally allowed to have.
GoodDayToDie said:
Also, I guarantee you that there are some high-permission drivers on the Lumias; you can't do an app like the storage checker/cleanup or whatever it is without them. That requires filesystem access well in excess of what an app is normally allowed to have.
Click to expand...
Click to collapse
Ok. The simplest way to check is to search such apps (with interop cap) in the registry (afair all apps are registered there with listed caps)
shall try on my 820. also the registry viewer could be useful to search somth else..
But i doubt they really are (as there were nothing similar inside the image).
p.s. and as i understand there are no chances of finding somth like this (DLL or sys) in wp8 x86 emulator (that could be much easier to review in IDA)
p.p.s. i think all people know that is possible to mount vmdk disk of wp emulator and reverse all system modules (x86).