I am performing Android app reverse engineering (decompilation and further analysis). I wish to analyse the package dependencies between different packages inside the same apk file. Is there any tool which does this? Else, how can I deduce package dependency in apk files?
I wish to analyse the package dependencies between different packages inside the same apk file. Please let me know if there is any tool which does this
A tool called Dexter is available to find out all the packages present in an apk. Also, if there is a program dependency among any 2 packages, Dexter show it with an edge. It could be noted that the edges do not have any weight to indicate the strength of the dependency.
The only dependencies that I have run into with apk files are with the framework from the device. If you are dealing with a standard app available from the Play, then it generally contains everything that it needs inside its own package.
Some of the custom builds like Amazon Kindle Fire, Barns & Noble Nook, etc have built custom launchers and other services which then offer other functions through their frameworks.
The framework-res.apk is typically stored in the /system/framework location. You can extract that from your device and place it in your apktool folder of your %userprofile%/~. Apktool (I am assuming that is one of the tools you are using) will then reference it when it does the work.
Related
A couple of basic questions regarding MSIX packages and their manifest files:
A MSIX package can contain multiple Applications. What identifies something as an "Application", rather than just an executable? An executable that is a component by itself? Has its own shortcut/uninstall?
Does the manifest file dominates what the package does or does not install/deploy? For example, suppose I have an MSIX package that contains and installs 2 Applications. If I change nothing else, but simply remove one of the Applications from the manifest file, re-sign the package, will the package now install only the other Application?
Appreciate the help.
An MSIX package can contain multiple applications, but applications in MSIX reffer to "shortcuts" if you want to think of them like this. Applications are the shortcuts that appear in start menu.
Of course, you can capture multiple applications in your MSIX package (vlc, notepad, etc) and create one big MSIX package, but i don't recommend that.
Yes, everything that happens on the system is defined in the AppxManifest, but you can't specify what to install/deploy. If you capture 2 applications (vlc and notepad) you cannot chose during installation that you want only VLC installed. There are no such options. Of course you can leave all the files in the package, delete the Application entry in the manifest, and the user will only see VLC for example, but the MSIX will install the files for both Notepad++ and VLC on the machine, which again i don't recommend. Keep in mind that almost everything is stored in the AppxManifest file: startuptasks, FTAs, services, app alias, app extensions, firewall rules, etc.
Think of it like this, if you recapture VLC Media Player, it has 3 shortcuts. Each shortcut represents an Application: an application to VLC.exe, and two other applications to VLC.exe and additional arguments.
While working on a number of Aurelia applications we reached the point that we need to share code between these applications.
The code to be shared is not something we (actually our customer) would like to be open sourced. So we were thinking of creating private jspm packages so we can easily reuse our modules when needed. This idea is inspired on this blogpost
Jspm does support linking packages as well so that is something we would really like to use during development, as the code to be reused is not yet stable enough.
Workflow with linked jspm packages
So our intended workflow is to create different number of projects/modules with ES2016 code and create jspm packages from these projects. These packages will then be installed and linked in our applications.
Transpiling
As far as we know jspm packages need to be transpiled before you install it into your project. So we always need to transpile code if there is any change.
According to this systemjs/babel-plugin documentation there will be support for on the fly transpiling in version 0.17 (which is in beta at this point). Currently we're using jspm version 0.16.32 which does not support on the fly transpiling with babel 6.
Somehow this workflow feels over-engineered, so we consider on the fly transpiling in our applications, though we fear a performance penalty.
How would you approach sharing es2016 code between different Aurelia applications?
Is there anyway to achieve code reuse without using jspm packages?
I personally would publish the packages to an internal npm feed of some sort. Set up the internal feed to mirror the public npm feed, then set your .npmrc to point to the private feed. Then just
jspm install npm:my-private-package
I am using Visual Studio 2013 and TFS for source control. My solution contains json files with the translations for my app made with the mvvmcross framework. The mvvmcross JsonLocalisation plugin recommends to link the translation files from a commen location to the different projects needing them.
When trying to shelve or check-in these changes, TFS complains about the translation files not being available in the platform projects.... Do any of you guys have a nice solution to that (one that doesn't include branching)?
I'd really like to avoid branching because I then need to merge the files to all my platform projects on every change I make.
How do you solve that using TFS?
I am now certain branch/merge is the best option in TFS. File linking is NOT supported by TFS. I ended up putting my json translation in a resource folder outside the platform specific projects (Droid, Windows Phone and WPF). Then I branched that directory to mentioned projects.
The process for changes are now as follows. Changes made to translation files in i.e. Droid projects must be;
Checked-in in Droid project
Merged from Droid to CommonResource
Checked-in in CommonResource
Merged from CommonResource to WindowsPhone and WPF
Checked*in in Phone & WPF
It makes it a bit more cumbersome compared to File-linking but it'll work...
Best regards
You should package your files for distribution as a NuGet package.
If you create a nuget package you can automate the update and control of the files while making them an external dependency. You then publish your nuget package to a repository (UNC or ProGet) and reference from VS.
If you edit the files you create a new versions package and deploy then update the solutions. You can automate this by having a CI build that created your nuget from the files automatically and publishing.
Look at how the Node, Angular, and other JavaScript nuget packages are composed.
I'm having trouble understanding why the Newtonsoft JSON parser has to be device specific under Xamarin. I cannot seem to find any way to have the parser exist in a common, shared library. I'm using the Tasky Pro sample app. I can get the JSON.Net DLLs from the Xamarin store to work in the Android and iOS projects, however that makes no architecural sense. E.g., the SQLite stuff is all in a shared lib, as you'd expect - as one set of c# source files.
Ideally I'd like to just add some kind of reference to "Tasky.Core" and be able to serialize/deserialize JSON.
Is there any way to get JSON.Net to work in a shared library (across droid/ios/wp8)? The source is pretty huge to try to manage as linked files, if that's even possible...
If not, is there some alternative way of managing JSON that will work in this way?
You should be able to use the JSon.NET NuGet Package for this. The implementation is actually platform-specific [1], but NuGet will transparently take care of that for you and pick the correct one for you.
Note that you need Mono 3.2.6 and Xamarin.iOS 7.0.6 for this, which just hit the alpha channel this week, I have just fixed some critical bugs in this area. You should also upgrade the NuGet Add-In in Xamarin Studio to the latest version (0.8), which contains several PCL-related bug fixes.
Simply add the NuGet Add-In to Xamarin Studio if you have not done so already, then search for "JSon.NET", the add-in will automatically install the package and add the required library references for you.
[1] The NuGet package contains different .dll's for different target frameworks and then picks and references the best one for your project - so your application will only contain a single implementation, but an iOS app may use a different one than a desktop application.
Update 01/14/14:
NuGet packages usually contain different implementations - unfortunately, not all of them will work with Xamarin.iOS due to APIs such as Reflection.Emit or Full DLR that are not available on iOS.
If you look into the packages/Newtonsoft.Json.5.0.8/lib/ directory, you'll see different sub-directories - each of these contain a different implementation and NuGet will use the one that best fits the current target framework. Unfortunately, NuGet does not always pick the right one :-(
For Newtonsoft.Json.5.0.8, the "portable-net45+wp80+win8" implementation uses DLR features that are not available on iOS, the "portable-net40+sl4+wp7+win8" one is ok. So if you add the NuGet package to a PCL that's targeting for instance Profile136, you'll get the correct implementation.
There is no GUI to choose another implementation, but you can edit the .csproj file. Replace
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net45+wp80+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
with
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
and it should work.
In general, when you're getting an error message about missing types after adding a new NuGet package, go to the corresponding package directory and grep -r for that symbol - chances are that there's a different implementation which does not use this type.
Hopefully, a more elegant solution will be available in the future, but that needs coordination with the NuGet team and package authors, so it'll take some time.
Just add it to Shared Library via NuGet. Actually, all your request/response tasks should be done in library. You should use JSON.Net to parse response.
Windows 8.1 introduced a new feature in the packaging section of the manifest called "Generate app bundle". It says that "Consider generating an app bundle if your app contains language-specific resources, a variety of image scales, or resources that apply to specific versions of DirectX. If you don't generate one, your app will run just fine, but users will have to download a larger app. For more information about app bundles, see App Packaging."
But users can change their language or run the app on a variety of different monitors at any time without reinstalling the app. So how does this feature work, what is it doing?
Basically, the App Package is split up into modular chunks. Each library that you use is split up into its component dll's. The language resources are also split up into a different chunk for each language.
This does a few things. For instance, let's say you have two games, BlackJack and Spades. Both of them use the same base engine, with the same images and base game logic. All of these are included in your 'BaseCardGame' library. In the bundle, it will keep a log of the BaseCardGame library and include it in the bundle. Now, let's say you have a user who downloads both of these apps (as you hope they would). The bundle says "I need the BaseCardGame library with XXXXX signature." Your system says "I already have that, so bundle me up the rest of the stuff that I don't have." So your users only have to download that package once.
The same thing is true for the language resources. If they have only added to their system French and Italian, then it's unlikely they're going to need the Ukrainian language information. So, they don't have to download that. Note: It does not have to be the language they have currently set, only the languages they have added to their system. If they then add a new language, the system will go and get the language packages for the apps that have them.
This is all at a high level, but describes the basics of the bundling system. Channel 9 has quite a few good videos on it.