Related
So the signature is encoded over the update.zip right so all we need to do is steal the difference between signed and unsigned update files they have to be the same file but uziping and reziping does so. All that needs to be done from there in my thought is calculate each offsets difference and bam signature. Now create a new update.zip with all rooted files. Clockwork and s-off being all we need. Make the update the same size exactly and add the difference we obtained to it and bam rooted it is
Sent from my T-Mobile G2 using XDA App
public key cryptography 101 says it wont work.
Why won't it work if I may ask.
Sent from my T-Mobile G2 using XDA App
What you are proposing sounds acurate in my head, but everything says it doesn't work that way. I guess some things I will never understand..... Women is another one.
Ill do it on my own and test it when I get home again. MORE COFFEEE!!!
Sent from my T-Mobile G2 using XDA App
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Yayy for phone insurance claims then
Sent from my T-Mobile G2 using XDA App
More power to you then my friend, go nuts, maybe youll get something out of it that helps with the perm root.
Dom18 said:
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Click to expand...
Click to collapse
I highly doubt that will happen. Look at all the failed updates due to the whole goggles thing.
Quick question though how does one set s-off in the image so I can try this. And to clarify I'm using a hex editor to re-add the diff from the signed and unsigned updates so the calculating will be a headache :/
Sent from my T-Mobile G2 using XDA App
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Just incorrect in every way imaginable. That's not how signature verification works. If cryptography could be circumvented that easily no one would use it. I am not going to explain asymmetric encryption in this thread, there are plenty of resources for that. Let's just say what you're proposing here has no chance of working whatsoever.
Start here: http://en.wikipedia.org/wiki/Public-key_cryptography
and here: http://en.wikipedia.org/wiki/Digital_signature
Unless HTC put an idiot in charge of their crypto, what you are proposing won't work.
Yeah, if you are lucky, they will have put jdkoreclipse in charge of that. I think that is the only way the encryption could be done as poorly as you are suggesting.
funkadesi said:
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Click to expand...
Click to collapse
I forget where I suggested this... but I was thinking someone could write one of the [email protected] or bovine (for those who remember) type application, where the client can run on anyone's machine that tries to crack the key by connecting with a central server in a coordinated effort. All of us G2 owners could run the client on 1 or multiple machines 24/7 and we may get lucky and find the real key.
I'm willing to install it on every machine at work if someone will write that client program ;-)
reference: http://www.distributed.net/RC5/en
To the best of my knowledge unzipping and rezipping it wouldn't break the signature...
I don't want to be insulting but if you do not understand PPK cryptography and how cryptographic signatures work please do not try and "break" something that has been evaluated and probed by numerous security experts in an attempt to find vulnerabilities.
It might be possible to crack ppk based signatures but it is not a simple matter of a diff between pre and post signature files. Again, I don't want to hurt anyones feelings but people A LOT brighter than you who actually understand the mathematics involved are not able to do it.
Put simply I will give you 2 documents, a signature for one of the documents, and a public key to verify the signature. If you can derive the key from which the signature is made or a way to create a valid signature for the second without the key you will be famous overnight since you will have found a vulnerability in one of the cornerstones of modern cryptography. Again it is possible but the chance of success without knowledge of the mathematics involved is monumentally small. Even with knowledge of the mathematics such a crack has not been found by people dedicated to researching such vulnerabilities.
Sorry for the rant but voodoo mechanics is a sore subject for me.
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
flarbear said:
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
Click to expand...
Click to collapse
I wanna add that most of that process is known because of AOSP and how we sign with the test keys. The only piece missing is google's/t-mobile's/htc's private key (because...who knows who really made the one for the G2?).
my 2 cents
Awaiting OPs response
Archos 101 has a problem that all the fonts are blurred, including text in 3-rd party apps. It looks just awfull. On windows I have an option to turn that off. Loking for some method to do the same on Android.
There are many apps for font changing
but you need root your device for this
Maybe there is an option like this in that apps, just try it
One could recompile the skia library.
arpruss said:
One could recompile the skia library.
Click to expand...
Click to collapse
Can that library be relpaced in current Android installation without rewriting full Android image?
sarge425 said:
Can that library be relpaced in current Android installation without rewriting full Android image?
Click to expand...
Click to collapse
I would think so, unless Archos has customized the stock library and the 2.2 source code doesn't match it. I'll try a recompile and see what happens.
That sounds interesting...
Looking into sourcecode of AOS, i noticed that "freetype" library included too. May be it involved in font decoding?
I compiled libskia from the 2.2 sources, making only one change (enable bytecode interpreter in FreeType). Zygote doesn't start up.
Maybe Archos has made some modifications to the stock code.
It might also be worth checking if FreeType reads some config files. Normally, FreeType works with fontconfig, and fontconfig has some configuration files.
I found exact places where text rendering is done. It is in file trunk/src/ports/SkFontHost_FreeType.cpp
Most work done via calls to freetype library, however some "subpixel rendering" attempts can be noticed in the source.
sarge425 said:
I found exact places where text rendering is done. It is in file trunk/src/ports/SkFontHost_FreeType.cpp
Most work done via calls to freetype library, however some "subpixel rendering" attempts can be noticed in the source.
Click to expand...
Click to collapse
Right. I don't think the subpixel rendering is currently implemented. People say that subpixel rendering doesn't work vertically, and these tablets are often used vertically. I couldn't find anywhere in the code where the font code would have access to the current screen orientation, which would be crucial to subpixel rendering.
In any case, it would be easy to disable all antialiasing, in SkFontHost or in FreeType (libskia.so includes FreeType, I think--at least there is no separate libfreetype or libft2 or the like on the device). But since I can't get Android to start up on my archos when I install my compile of libskia.so, that's moot.
By the way, did you notice that the skia library includes PDF rendering? One could make a very lightweight pdf viewer if one hooked into that (but it might stop working with a new release of the skia library, since this isn't an official Android API).
Things seems to be more simple. In the file SkFontHost_FreeType.cpp I found a string "FT_Render_Glyph(fFace->glyph, FT_RENDER_MODE_LCD);" and some text down. According to FreeType2 docs, parameter FT_RENDER_MODE_LCD is used for subpixel lcd rendering, and FT_RENDER_MODE_NONE means 1-bit mode (anti-aliasing off).
Another problem is that freetype uses subpixel glypth positioning, which not good.
arpruss said:
I couldn't find anywhere in the code where the font code would have access to the current screen orientation
Click to expand...
Click to collapse
I found that place in SkScalerContext_FreeType constructor.
Btw, inability to replace libskia is really bad. I have only remaining way to binary patch that lib
sarge425 said:
I found that place in SkScalerContext_FreeType constructor.
Btw, inability to replace libskia is really bad. I have only remaining way to binary patch that lib
Click to expand...
Click to collapse
Or do a pass-through patch, like ChainFire3D did for the opengl library. I don't know how to do that.
Also, I am guessing there are some hardware-dependent settings to set for the skia code that I didn't set--I just compiled the generic 2.2 code for it. Someone who understands the skia code better might be able to get it running quite easily.
I was busy that days. Now I disassembled libskia.so and fortunately it has symbols!!! I can locate all public methods, and all calls to FT2 as well. Also I found the optimal font configuration: nonchrome mode + full hinting (tested on ubuntu).
sarge425 said:
I was busy that days. Now I disassembled libskia.so and fortunately it has symbols!!! I can locate all public methods, and all calls to FT2 as well. Also I found the optimal font configuration: nonchrome mode + full hinting (tested on ubuntu).
Click to expand...
Click to collapse
Maybe you can try to figure out how it differs from the stock 2.2 source, so we can just compile the stock source with some changes?
I expect it will be a hard task. I'm not very familiar with ARM asembler, and the problem can be everywhere in that library. I found some strange calls to external modules, where functions linked with constant address. That may be the source of incompatibility. Normally all imports defined by name, not by magic address.
Doing a pass-through library might be the best way to go. Do you know how one might do that?
What means "pass-through" library? I think the key problem is the mechanism of recompiled library not working. It may be just checksum verification, but may be more complex too.
The most straight way is to change responsible bytes directly in .so file. I already have found where to patch.
Can You describe steps to be able to replace libskia with ability to return back if boot fails?
---------- Post added at 07:11 PM ---------- Previous post was at 07:00 PM ----------
Also I noticed that skia uses very strange method of drawing texts - it renders text into separete bitmap, then does alpha-blend. Obviously subpixel rendering will require 3 separate alpha-channels for alpha-blend at subpixel level. Windows GDI, for example, outputs text directly to final bitmap, and doesn't need to to store subpixel transarency values.
sarge425 said:
What means "pass-through" library?
Click to expand...
Click to collapse
ChainFire3D installs replacements for the OpenGL libraries that do a few things when called and then pass control to the stock library (which is still there, but renamed).
I think the key problem is the mechanism of recompiled library not working. It may be just checksum verification, but may be more complex too.
The most straight way is to change responsible bytes directly in .so file. I already have found where to patch.
Can You describe steps to be able to replace libskia with ability to return back if boot fails?
Click to expand...
Click to collapse
I used the Chulri's RW root, and just copied libskia.a over the original one and rebooted. When it didn't work, adb still connected just fine, and I just went to /mnt/system/unionfs/system/lib (I think) and deleted the new libskia.a there (the way the rw root works is that stuff in /mnt/system/unionfs shadows stuff in /) and rebooted.
Also I noticed that skia uses very strange method of drawing texts - it renders text into separete bitmap, then does alpha-blend. Obviously subpixel rendering will require 3 separate alpha-channels for alpha-blend at subpixel level. Windows GDI, for example, outputs text directly to final bitmap, and doesn't need to to store subpixel transarency values.
Click to expand...
Click to collapse
Interesting. And there may be another blend that's done by the surfaceflinger library.
arpruss said:
ChainFire3D installs replacements for the OpenGL libraries that do a few things when called and then pass control to the stock library (which is still there, but renamed).
Click to expand...
Click to collapse
The technical name for this is an "interposition library". You an search the web for LD_PRELOAD and interposition for a lot of information. (LD_PRELOAD itself doesn't work on Android.)
Version Alpha 0.6.0 is now available
I'm back! Not dead yet, I promise. This is actually a relatively small update in terms of user-facing features, with only one really big new thing - support for file uploading - but that's a lot bigger than it might sound. It's the first write support I've implemented in the server, and it also required some fairly massive updates to the HttpServer component (support for binary requests, for POST parameters, for MIME multipart parsing). These will be built upon in forthcoming versions to add support for things like registry editing, in-browser file viewing (possibly editing), and so on. There are also a large number of small fixes and improvements that I've made over the last two-weeks-shy-of-a-year, which should make the server faster, more robust, better able to support concurrent connections, and lighter on device resources. Finally, while the app still targets WP8.0 and should run on 8.0, it now is designed for 8.1 compatibility (especially the AllCapabilities version).
Previous update (0.5.6): This version is mostly bug fixes and UI changes. The biggest changes are: clearer display of weird registry data types, the server now consumes fewer threads (it used to spawn them with wild abandon) and does faster string compares, the app version is now shown on the phone, error pages are now better, if you launch the app without a WiFi IP address it'll offer to take you to the WiFi settings page, connections are no longer closed as soon as the app starts sending a response, and the server now defaults to using the Connection: keep-alive header, with a two-minute timeout. The last change, combined with the second-to-last, should hopefully both do away with the tendency to have the app fail to display a page. However, I shouldn't have *needed* to switch it to "keep-alive" - using "close" should have worked - but it still veeeery occasionally would kill the connection early. Agh. Anyhow, this is better in the meantime.
DevDB offers me a support / Q&A thread. Please use that thread to ask questions; don't PM me unless it needs to be kept private for some reason!
ISSUES ON WP8.1:
It *should* work to deploy the app with "Application Deployment", but if you have a problem try deploying with "Windows Phone Application Deployment 8.1" instead.
Problems have been reported in the past when the app is installed to the SD card. It's small, though; putting it on internal storage shouldn't be a problem.
RESOLVED The AllCapabilities version included a few capabilities that were present in 8.0 but removed in 8.1. Those capabilities have been removed; the AllCapabilities version now deploys and runs on capability-unlocked WP8.1 phones.
IN CASE OF OTHER ISSUES: Please provide a *detailed* error report - what phone and OS version you have, what hacks you've installed, what Webserver version you're running, what you do to get the error to occur, and exactly *what* occurs - and I'll fix it as soon as I can! There's a DevDB section for posting bug reports, and you can also use CodePlex if you want.
I finally implemented file upload! I'll work on getting more stuff like that (file delete, possibly file rename/move/copy, various registry edits), hopefully soon! I also hope to add support for different areas, like an "Applications" path, a "Processes" path, a "Services" path... eventually. Many of those are really hard without good privileges. I'm also looking at moving the server to a background process and making the app just a control UI for it, adding support for authentication and/or HTTPS, adding some stylesheets to the web UI, adding caching, and much more. I did finally implement Connection header support.
Once again, the XAP is published twice. One is a fairly standard XAP that any phone can sideload, and the second has many exotic capabilities to enable viewing of (and writing to) slightly more of the file system and registry. The standard XAP has had its list of capabilities expanded to pretty much all of them that can be used without interop-unlock. The high-capability variant requires not just interop-unlock, but the additional capability-unlock hack available in the interop-unlock thread. The AllCapabilities version now works with WP8.1; sorry for the long delay on that!
An item of note: the AllCapabilities version (or either version, on WP8.1) can open other drives in the file system. On phones with an SD card, it is mounted at D: and you can browse it as normal. Credit to @hjc4869 for this discovery!
DESCRIPTION: This is a simple webserver app which can enumerate those files that are in folders readable from the sandbox, can download and upload (access permitting) files, can browse the registry, and can display the contents of registry values of any type. It runs on WP8.x (not yet tested on W10M). It is a spiritual successor to the Functional Webserver / WebServer (Mango) projects from WP7. This version is still missing a lot of functionality as I decided to implement it from scratch, but it is advancing swiftly. Note that there's no access controls implemented; use it on a public network only at your own risk!
Instructions are simple: sideload the XAP, connect to WiFi (required), run the app (called "WebServer Native Access"), point a web browser (on a PC or phone that is also on that local network) to the URL that the app displays. You should get a basic index page. Click on a Filesystem or Registry link to begin browsing the phone. There's a textbox near the top of all filesystem pages, type in a path there (for example, "C:windows" with no quotes) and hit Enter or click Get Files. You'll see a list of the contents of that folder. Click on a file to download it or a directory to open it. There's also a box for uploading files, one at a time, to the current directory. Navigating the registry is similar, except you'll need to specify the registry hive and then the path from that hive (or no path, to access the root of the hive).
As of v0.6.0, uploading files is finally supported! Other modifications (editing files, creating, deleting, or changing registry keys or values) are currently not supported. They will be "soon" although my personal testing suggests that basically the whole registry, and most of the file system, is off-limits for writing unless you use restricted capabilities.
You might see an error code (error 5 is "ACCESS_DENIED", you'll see it a lot; I should replace it with an appropriate 403 or whatever). Or you might see a status 500 message because of an exception in the server. Or the server may just crash (hopefully not so often anymore...). I'm making it more resilient, but there are still bugs. Please report any previously-unreported issues you find, including how to reproduce them, and I'll fix them if possible.
Also feel free to request features or changes; I'll implement them if reasonably possible. The app is a mixture of C++ and C# code; I could probably have done it all in one or the other but wanted to have a C++ component in case I ran into something that wasn't available in C#, and although it probably would have saved some time, I decided that hacking up a web server in C++ was maybe not the best idea.
The source code is on Codeplex, at the following projects: https://wp8webserver.codeplex.com/ for the server and the app (C#) and https://wp8nativeaccess.codeplex.com/ for the native access wrappers (C++). You may have to fix up the reference paths to get the C# component to see the C++ component correctly. The code is reasonably well documented, but let me know if you have any questions. Permission to re-use the code or components is granted under the MS-PL (Microsoft Permissive License) as posted on Codeplex.
Go forth and find cool stuff!
Version history (see the git commit logs for more detail:
07 July 2013 - 0.2.0: Initial release, FS only, 920 downloads (source: 652 downloads)
14 July 2013 - 0.3.2: initial registry, HTTP server and web app encapsulation, source on Codeplex, 225 downloads
0.3.3: bugfixes, 454 downloads
0.4.2: basic registry values display, 86 downloads
0.4.3: bugfixes, 326 downloads
0.4.6: multistring registry values, bugfixes, updated libraries, first AllCapabilities version (950 downloads), 453 downloads
25 Oct 2013 - 0.4.8: binary and long registry values, formatting and bugfixes, 451 downloads AllCaps, 201 normal
22 Dec 2013 - 0.4.9: all registry value types, better threading, proper resume, remembers port, 97 downloads AllCaps, 53 normal
24 Dec 2013 - 0.5.0: background operation using Location APIs. Downloads: 1011 AllCaps, 963 Normal
20 Jul 2014 - 0.5.1: More capabilities, better navigation. Downloads: 358 AllCaps, 352 normal
07 Aug 2014 - 0.5.3: .REG export, better traversal, bugfixes. Downloads as of 0.5.5 release: 260 AllCaps, 164 normal
10 Oct 2014 - 0.5.5: Bugfixes and back-end work. Downloads as of 0.6.0 release: 140 AllCaps, 113 normal
25 Oct 2014 - 0.5.6: Bugfixes and UI tweaks. Downloads as of 0.6.0 release: 1720 AllCaps, 1334 normal
12 Oct 2015 - 0.6.0: Binary requests, file uploads, bugfixes.
XDA:DevDB Information
WebServer Native Access, Tool/Utility for the Windows Phone 8 General
Contributors
GoodDayToDie
Source Code: https://wp8webserver.codeplex.com/
Version Information
Status: Alpha
Created 2014-10-17
Last Updated 2015-10-12
I'm going to use this space to mention something that's pretty cool:
J. Arturo of http://www.komodosoft.net is using a modified version of the HTTP server that powers this app in the ShareFolder app (http://www.windowsphone.com/s?appid=e2b9c82e-eaa1-4a3b-9d4a-8a2933a8bdb4) to support opening video files directly from Windows network shares! This was done to work around a limitation of the WP8 media control: it can only source from an isolated storage file or a HTTP URL. By running a server in the background and streaming the video file through it, and pointing the video player control at the localhost URL, it becomes possible to play the file on the phone without first copying it to the app's isolated storage. A very cool way to solve the problem! Also, reviewing the changes that were made to the network code of the server pointed me toward those threading fixes I made that have hopefully much improved version 0.4.9.
Please note that the updated version of ShareFolder with this feature may not yet be available, although it should be soon. It is a commercial (paid) app, but the author sought and received permission to use my code (although the license does not require such permission be received).
What exactly is the problem with sockets? I am battling myself with sockets atm too, maybe we can share knowledge?
Strictly speaking, the problem was with the phone's limited subset of the Sockets API forcing me to access it through functions I wouldn't normally use (asynchronous everything, SocketAsyncEventArgs and lambdas and AutoResetEvents and so on everywhere...) but I've got a pretty good handle on it now, at least for the System.Net.Sockets.Socket and its friends. The new .NET 4.x ones (using the async keyword and all) are in a different namespace; I didn't mess with them. They are more abstracted from the Bekeley sockets interface that I'm used to from C, but they are also (supposedly) more user-friendly, especially if you don't feel like writing all your own thread management code (and in fairness, I should re-write the webserver's threading to use threadpools; they're better for this type of work).
If you want to ask questions about the topic, I suggest starting a new thread (possibly in the Q&A subforum, although it's also dev related...) and I'll answer if I can.
GoodDayToDie, just an idea: how about sharing your source code via CodePlex or GitHub?
Oh man, this is pretty nice! GoodDayToDie does it again!
So far, I can read \Windows, the current install folder which you access just by typing "." with no quotes and the current application folder by typing ".." I can access the .dlls, .winmd and AppManifest.xml from the current install, but from everywhere else, it goes boom. This is a great step towards something awesome though!
EDIT:
I was wrong. For some reason, when you click on a folder it's trying to "download" it, rather than chdir. I can get pretty far into the Windows directory.
THAT's what you meant by "Click on a file (note: there's no current way to tell the difference between files and folders) to download it.
You might see an error code (error 5 is "ACCESS_DENIED", you'll see it a lot). Or you might see a status 500 message because of an exception in the server. It's getting a lot more resilient but there are surely still some bugs. ".
If you see a folder, just type the full path to it instead of clicking on it and you will be able to read the contents.
ANOTHER EDIT:
I just found a file inside of the \Windows\System32 directory named [guid].devicemetadata-ms (It's easier to just search for "devicemetadata-ms"). It's a cab file with some metadata about WP8 with a sign.cat and packagesign.cat file in the archive. I don't know what these files could potentially be useful for.
New version in a day or two (busy tonight). Features I plan to implement (not necessarily in the next version or at any particular time):
File upload (IsoStore and, of all crazy things, install directory are writable. I think I'll put a flag on each FS page that says whether the current dir is writable...).
File deletion (where possible, of course).
File and Directory distinction in the listing (clicking a dir should open it, not error out).
Filesystem index page with links to folders that can be accessed successfully (since the root isn't readable).
Some more file info (size, probably attributes, possibly permissions).
Possibly an option to preview a file (as plain text) without downloading it.
Some kind of background mode (the server uses minimal resources when not actively servicing a request, so I'll see if I can get it to work in the background, perhaps by abusing the music transfer agent...)
Some kind of offline mode (at least basic file browsing within the app, as an alternative to using the web interface, though I might just make a second app for that).
Source code changes: separate the server code from the webapp / phone app code (move it into its own project).
Source code changes: move to a hosted version control service, probably CodePlex (good suggestion sensboston).
Maybe add an icon and such...
Any other suggestions?
I also want to try experimenting with various non-standard capabilities and see if I can get access to more of the system . I've already added the ability to access removable storage, but I've also found a bunch of really weird and frequently undocumented capabilities in the OS's policy configuration files, and I need to look into those... The interesting (and possibly the uninteresting) ones are probably blocked for unsigned sideloaded apps, but it's worth checking on anyhow.
Yeah sorry, I should have been more explicit about clicking on dirs. not working in 0.2.0. Also, it's "unofficial" but if you check the URL bar you'll see a URL parameter called something like "pattern" (by default, it's *) and if you change that, you can filter the results. For example, "foo*.exe" (note: no quotes!) will search for EXE files whose names start with "foo". Among other uses, this makes it a lot faster to load large dirs like System32. This will be added to the UI at some point. Also note that URL decoding is applied correctly to querystring parameters (Probably already noticed with the path sometimes written using %5C for \) so you can add special characters that way if needed, though currently any of them but \ will probably just cause an exception.
...
Actually, does this filesystem support Alternate Data Streams? If so, you should be able to download them by appending a : and the ADS name to the filename in the download URL...
OK, so that was a new version in five days. Sorry, stuff takes time.
The source code is now on Codeplex. The native access portion is at https://wp8nativeaccess.codeplex.com/, and the web server portion is at https://wp8webserver.codeplex.com/. Both are licensed MS-PL and use Git for version control. The full XAP is also available for download from the Webserver project on Codeplex.
GoodDayToDie said:
OK, so that was a new version in five days. Sorry, stuff takes time.
The source code is now on Codeplex. The native access portion is at https://wp8nativeaccess.codeplex.com/, and the web server portion is at https://wp8webserver.codeplex.com/. Both are licensed MS-PL and use Git for version control. The full XAP is also available for download from the Webserver project on Codeplex.
Click to expand...
Click to collapse
You are a god. I'll be sure to post my findings .
Hmm. When I first load up WebServer File Access then access from my laptop, I get the main page then the program crashes on my phone. It seems to hold a lock on to the socket as i can no longer access port 9999 from any other device when re-opening the app. I can access it again when I reboot, but the same thing happens.
EDIT: I think it may be due to the WiFi at work... it's junky. I'll try again when I get home. I was just able to browse some directories.
Wow, that's completely unexpected... I can beef up the error chacking and handling around the listener port though. That part of the code is really straightforward, so I actually haven't hardened it very much. I can also put in a Finally block to close the socket and/or mark the socket as re-usable so that other apps (or the same one again) can listen on it in the future.
I also plan to add support for setting your own port, but that doesn't solve the underlying problem. I'll put in more error reporting as well, to enable better debugging. Thanks for the report! Always good to have users report problems so I know where to prioritize fixes.
GoodDayToDie said:
Wow, that's completely unexpected... I can beef up the error chacking and handling around the listener port though. That part of the code is really straightforward, so I actually haven't hardened it very much. I can also put in a Finally block to close the socket and/or mark the socket as re-usable so that other apps (or the same one again) can listen on it in the future.
I also plan to add support for setting your own port, but that doesn't solve the underlying problem. I'll put in more error reporting as well, to enable better debugging. Thanks for the report! Always good to have users report problems so I know where to prioritize fixes.
Click to expand...
Click to collapse
I tried the app at home and it DOES crash on the first hit of the home page, but I'm able to open it up again and it works fine.
The new version 0.3.3 should be more rebust; try it and let me know if you still have issues. If you do, let me know what the exception message is (and any other info you can provide) and I'll try to track it down.
Downloading really big files should also work now. The app will read and push files in smaller chunks (the code to do this existed in the NativeAccess library before, but wasn't used).
a simple SDK?
Dear Sir
Will it be possible for you to make some sort of SDK from this so other developers can integrate this into their apps and enable browsing isolatedstorage?
Sorry if it is a stupid question.
Bruce_X_Lee said:
Dear Sir
Will it be possible for you to make some sort of SDK from this so other developers can integrate this into their apps and enable browsing isolatedstorage?
Sorry if it is a stupid question.
Click to expand...
Click to collapse
With the restrictions in permissions, this app only allows browsing of the app's isolatedstorage locally. You are able to use the IsolatedStorage API within your app to browse files and directories already.
snickler said:
With the restrictions in permissions, this app only allows browsing of the app's isolatedstorage locally. You are able to use the IsolatedStorage API within your app to browse files and directories already.
Click to expand...
Click to collapse
That's right. What I want is to allow the end user to be able to browse the isolatedstorage. Imagine I have a video download app, I want the user to be able to transfer those downloaded videos from the app's isolated storage to, say, a PC.
One can do this by integrating the webserver code into the said app.
Bruce_X_Lee said:
That's right. What I want is to allow the end user to be able to browse the isolatedstorage. Imagine I have a video download app, I want the user to be able to transfer those downloaded videos from the app's isolated storage to, say, a PC.
One can do this by integrating the webserver code into the said app.
Click to expand...
Click to collapse
Ahh I see what you mean now. That sounds like a pretty nice idea. I think more research needs to be done to see whether it would even be allowed in the marketplace.
The webserver portion is stand-alone (builds to its own .NET DLL with no dependencies on the other parts) and has a pretty clean interface. You'd need to implement the web application portion of it yourself - the thing that generates the response pages for a given request - but the HttpResponse class in the server does a lot of the work of that for you; you basically just specify the content you want to send (as a String or byte array) and it sends it.
Is it possible to create an application that would hook all api calls to windows and be able to accept or deny the call? How trivial would this be?
All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...
Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,
GoodDayToDie said:
All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...
Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,
Click to expand...
Click to collapse
Due to recent program vulnerabilities *cough cough* IE exploit, I want to create a program to minimize and effectively stop the exploits, by blocking reading api calls from programs that have the vulnerability and determining if the call should be made or not.
There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.
GoodDayToDie said:
There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.
Click to expand...
Click to collapse
For educational purposes and further knowledge could you show me what I would have to do to hook one api call from a process? it does not have to be a global hook.
There's a handful of possible approaches.
If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.
If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.
If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.
Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.
With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).
GoodDayToDie said:
There's a handful of possible approaches.
If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.
If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.
If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.
Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.
With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).
Click to expand...
Click to collapse
I want to write open sourced code that will be like super user and permissions for windows so you can have the open feeling of windows but a secure feeling as well with little to no anti-virus's. This would not be like windows rt's locks, you can run any program you like.
You're not the first person to have this idea, but I don't think you understand the magnitude of what you're asking for. Even if such a system were created, it would be a lot of work to create all the rule sets for every program you want to protect. Besides, you'd still be vulnerable to malicious code that runs as Admin (i.e. most installers, etc.) since they could unload or modify your driver.
Hi,
Like I mentioned in "my" Joying PX5 review thread, I was (and still am) happy with the Joying PX5 and the nicely functioning split-screen on Android 8 like I mentioned in my video review on youtube.
What I didn't like at all was that the FYT/Joying apps lack the split-screen functionality (see here), which is so easy to accomplish, like I explain a little later.
It only requires one line in the AndroidManifest.xml.
I also mentioned that the Joying/FYT apks are signed which made it impossible to hack them because a changed AndroidManifest makes the signing invalid, which is why I can't do this..
Wrong!
By completely internally renaming them inside every smali file (for example from com.syu.bt to com.syu.btss -> ss for splitscreen), recompiling them and giving them a completely different signing it works. It took me only 15-20 minutes per apk. Of course I used some linux commands to do this for me. On Windows this would have taken much longer.
See images attached. I hacked the radio app and the BT app.
I'm the first to admit that in their current state they look horrible as the layout is not designed for split-screen, but that is not the point. Android also gives you easy options for your layout.xml files on how to behave in splitscreen mode: almost automatically.
Anyway: Making them ready for split-screen was the easy part. Reworking the layout files to adapt automatically to split-screen will take more time, which I don't have at the moment but it is a nice target to go for.
Nice!
I am looking forward to the day when this mod is incorporated into JET.