Related
Sometimes I come across an app thats not on the Android market and you have to install it manually. Has anyone come across a virus/trojan on Android yet? Im curious how easy or hard it is to modify a legit applications and put a virus/trojan in it?
Lol have not seen one yet. Android isn't that big yet so doubt hackers would really spend time putting trojans to get stuff like your email password lol.
Take everything you know about microshaft windoze and forget it. The system architecture of android is almost completely invulnerable to viruses/worms/etc.
In a typical unix system, hacks can take one of very few possible approaches;
1) service bug targeting, i.e., if one were to discover a security vulnerability in the Apache HTTP server, one could theoretically compromise it. That particular service I mean.
2) user account targeting, i.e., one could convince a user to run something dangerous, which would infect that specific user's account, of course, this attack would limit itself to damaging that user's personal data and would not be able to take down the whole system unless it also targeted a kernel or X-server exploit.
Note specifically regarding #1, that in a well configured system, that targeting a particular service would be restricted to a specific user account just as in #2 since each service runs as its own username.
3) Targeting KERNEL defects; this is perhaps the most frightening possibility. It is also the least likely since it would also require #1 or #2. Any particular kernel attack, particularly in Linux is also very unlikely to work for long due to the open sourced nature of Linux. There are a LOT more people involved in monitoring the fundamental securities of the Linux kernel than any other OS because of its open nature. It is also a source of PRIDE for kernel HACKERS that they ALSO be responsible for openly providing the SOLUTION to any exploits that they discover. And they usually do this with their REAL NAME since it basically immortalizes them. The end result is that every time a kernel exploit is discovered, it tends to be patched within hours of its first application.
Now of course you want to know how this affects Android, since by all appearances, there is no user-level security. WRONG. The Android security level is actually on par with service level security on unix servers. EVERY SINGLE application installed is granted is own user account, which means that if any particular application is dangerous, its range of damage is restricted to that particular application's private data, as well as any permissions that the application is explicitly granted (i.e. when you install an application, it gives you the required security list). There is also the very slim possibility of a kernel exploit (though this is extremely unlikely), and it could damage the data on the sdcard (since it is an MS-crap filesystem with no security restrictions).
Of course you will note that older versions of the ADP1 system image came with an unregulated 'su' command (which you could also end up with using a "cat sh > su; chmod 4755 su" root approach) which basically can be used by any application to take over the whole system. Make sure that you don't have any such su command on your droid. Either use a password-protected su command (which will cause problems for trusted apps requesting root privileges), or the gui-supported su command. Subsequent ADP1 images came with an su command that was restricted to the debugging terminal user, which is fine.
In other words... you don't have much to worry about. Just don't do anything really stupid, like installing an untrusted application that wants a boat load of privileges that it shouldn't be asking for.
lbcoder said:
EVERY SINGLE application installed is granted is own user account, which means that if any particular application is dangerous, its range of damage is restricted to that particular application's private data, as well as any permissions that the application is explicitly granted (i.e. when you install an application, it gives you the required security list).
Click to expand...
Click to collapse
Might be worth pointing out that android apps are for the most part interpreted language apps, meaning the onus of security and stability (just from an apk standpoint) falls largely on the vm. All the lower level subsystems are pretty well protected by the Linux kernel, and these have been significantly tried in fire by decades of Linux server deployment.
lbcoder said:
The system architecture of android is almost completely invulnerable to viruses/worms/etc.
Click to expand...
Click to collapse
jashsu said:
Might be worth pointing out that android apps are for the most part interpreted language apps, meaning the onus of security and stability (just from an apk standpoint) falls largely on the vm. All the lower level subsystems are pretty well protected by the Linux kernel, and these have been significantly tried in fire by decades of Linux server deployment.
Click to expand...
Click to collapse
All the points about the protection offered from the Linux kernel and the VM are valid. Computer secuity is an ongoing battle between the software originators and the hackers trying to get in. I'm not saying it's remotely likely, particularly due to the market share, but rule one in my book is don't taunt the hackers.
lbcoder said:
Take everything you know about microshaft windoze and forget it. The system architecture of android is almost completely invulnerable to viruses/worms/etc.
Click to expand...
Click to collapse
Until the Android Dev team screw up again and lets any app run in the system process when requested (which was why cupcake was delayed in the US).
thanks for the post.
I was curious if someone could unpack a .apk file and modify a application easily, say have it send personal info to xyz server instead of the server the app was designed for or send it to both servers so the user doesnt think anything is wrong.
Are the files in the .apk editable, like an .exe is compiled for windows and the .exe cannot be edited (since its machine code).
androidmonkey said:
thanks for the post.
I was curious if someone could unpack a .apk file and modify a application easily, say have it send personal info to xyz server instead of the server the app was designed for or send it to both servers so the user doesnt think anything is wrong.
Are the files in the .apk editable, like an .exe is compiled for windows and the .exe cannot be edited (since its machine code).
Click to expand...
Click to collapse
Yes, apks are basically just zip files with cryptographic signatures. If you get your apks from Market then there is little to no risk of apks being tampered with. If you install your apks from any source other than Market, then you just have to trust the source that the apk hasn't been modified. Obviously if the apk itself doesn't ask for many permissions then it shouldn't be a problem. For example if you download a game apk from a developer's personal webpage and it asks for just permission to keep the screen alive, there's little risk to your data. However if you download an app that has read/write access to your contacts, or has root access, then you better be sure that the site you get it from is trustworthy.
jashsu said:
Yes, apks are basically just zip files with cryptographic signatures. If you get your apks from Market then there is little to no risk of apks being tampered with. If you install your apks from any source other than Market, then you just have to trust the source that the apk hasn't been modified. Obviously if the apk itself doesn't ask for many permissions then it shouldn't be a problem. For example if you download a game apk from a developer's personal webpage and it asks for just permission to keep the screen alive, there's little risk to your data. However if you download an app that has read/write access to your contacts, or has root access, then you better be sure that the site you get it from is trustworthy.
Click to expand...
Click to collapse
So the files in the .apk not executables, rather interpreted with the VM? Im curious if those files can be read and changed. For instance, can someone open the file in a Java SDK and change the code? Or are those files protected so they cant be modified? For instance, could you download soundboard app from the Market, "unzip" the .apk, and put your own sounds in it?
androidmonkey said:
So the files in the .apk not executables, rather interpreted with the VM? Im curious if those files can be read and changed. For instance, can someone open the file in a Java SDK and change the code? Or are those files protected so they cant be modified? For instance, could you download soundboard app from the Market, "unzip" the .apk, and put your own sounds in it?
Click to expand...
Click to collapse
Unless the classes are specifically performing security/sanity checks, there's nothing keeping you from replacing asset files (pngs, wavs, etc) and then resigning the apk with any key of your choosing. However, altering xmls and classes is more difficult as they are obfuscated/optimized by default.
For apps distributed officially through the Android market, the only way Google can provide assurance for the app producer against tampering is app-protected folder. Of course that assumes that root access is not provided, which is most likely a prerequsite for any phone to be branded "with Google" and have Market access. From the viewpoint of the consumer, apps are guaranteed by Google against tampering only if retrieved through Market. Once the app is on the device, it is protected via Android's use of Linux user access permission model (each app is its own user). The consumer may of course alter the file him/herself, unless it is a protected app, in which case root is required.
sounds buggy. i hope not. this reminds me of when Mozilla firefox became popular i slowly starte dto see code become available to make pop ups n my belloved browser
Virus found on Android phone...
Article 1:
NEWS
An employee at Spanish antivirus firm Panda Security received a new Android-based Vodafone HTC Magic with malware on it, according to researchers at Panda Labs.
"Today one of our colleagues received a brand new Vodafone HTC Magic with Google's Android OS," researcher Pedro Bustamante wrote on the Panda Research Blog on Monday.
"The interesting thing is that when she plugged the phone to her PC via USB, her Panda Cloud Antivirus went off, detecting both an autorun.inf and autorun.exe as malicious," he wrote. "A quick look into the phone quickly revealed it was infected and spreading the infection to any and all PCs that the phone would be plugged into."
Article 2:
Mariposa virus back on Vodafone Android smartphones
HTC Magic According to a Spanish blogger, around 3,000 memory cards supplied by Vodafone Spain were infected with the Mariposa bot client. The mobile network operator has now reportedly confirmed that these included HTC Magic Android-based smartphone models, as well as other devices. A spokesperson for the company has told CNET that it is a "local incident". Vodafone says it has identified customers that could potentially be affected and it will be sending them new memory cards. It has also offered to supply them with tools to restore the integrity of their devices.
Reports of an HTC Magic smartphone carrying the virus were first published less than two weeks ago, however the malware is not able to harm the Android smartphone itself. The bot only attempts to contact a command & control server when connected to a Windows PC. The virus should be detected by most up-to-date anti-virus solutions.
Personal take:
Interesting to note that the virus being carried on an Android phone and was used to infect PC's NOT other Android phones. It came straight from manufacturing with the virus on, so as of yet I still haven't heard of a virus that can infect an android phone.
Further more, I have seen Anti-virus software on the market place AND being offered by Norton. What do they protect against if there are no known virus threats? Do they just draw a nice pretty anti-virus logo on the screen to make you feel comfy? hehehe.
Trojans in the hacked up ROMs people are distributing
androidmonkey said:
Sometimes I come across an app thats not on the Android market and you have to install it manually. Has anyone come across a virus/trojan on Android yet? Im curious how easy or hard it is to modify a legit applications and put a virus/trojan in it?
Click to expand...
Click to collapse
I've found a trojan in at least one of the ROMs being distributed on here. Even reported directly from the developer's own file sharing site.
"Stock" ROM http://forum.xda-developers.com/showthread.php?t=2066023
Attached is a photo of the file scanned from the linked file sharing site for the KERNEL he wants you to INSTALL!!
Click the link to JB_KERNEL_3.17.841.2_EVITA_Init.d_Support_Installer.zip - 8.54 MB in that thread and see for yourself.
Be careful what you install on your device. ANDR.Trojan.GingerBreak takes full administrative control of your device and downloads more trojans to siphon out your private personal data.
Can't believe that it almost took me a day to implement a tiny rendering change in my Vexed/HTML5 port. A little backstory:
I know there's already a good Vexed port for Android, but since I needed a web version, making it compatible with Android seemed like a good idea. It's still missing a lot of details, like a menu, manual or win/lose messages, but if you want you can play it here:
http://www.tapper-ware.net/data/devel/web/games/JS.Vexed/
The buttons used to be rendered using CSS3 border-images, which work on Android (at least 2.3+, haven't tested any other versions yet), BUT they are slow as hell. Apparently it's hitting a fallback path that renders the element much like you'd do on legacy-IE with behaviors... meaning that there's also a lot of tearing since the element that you apply the border-image to basically becomes a set of 9 image elements as far as rendering is concerned.
So I decided to implement my own border-image using Canvas (you can find it at line 168 of the HTML file: HTMLImageElement.prototype.renderAsButton)... after all, drawing border-images isn't exactly rocket science.
So far so good: it was working beautifully, but somehow I couldn't get it into my CSS... after basically checking every part of the chain with manually created data urls it really didn't make any more sense, so out of pure desperation I decided to take a look at the data url returned by HTMLCanvasElement.prototype.toDataURL, which was a ... surprise. This thing is wrong on so many levels it never should have shown up in any code. Not only does it not throw and ERR_NOT_IMPLEMENTED, it even returns data to cover the fact that it's not implemented, namely "data:," which doesn't throw an error when used as an image source.
The general workaround seems to be that people use a custom toDataURL implementation that outputs a Windows BMP file... which would be great, if Android supported 32-bit RGBA BMP files. However they usually end up as if they were 24-bit RGB files.
So if I wanted RGBA, i had to create PNG files.
The PNG spec is really very readable and makes it easy to implement a PNG encoder... but there are two shortcomings:
1. The only filter method available requires a filter byte at the beginning of every row. So you can't use the return data of getImageData directly (Array.prototype.splice doesn't work on ImageData, you have to copy it first).
2. It doesn't support uncompressed data directly... and compressing in JS seems like a bad idea. Instead you are supposed to use and ZLIB stream with raw blocks
It also has CRC checks which are annoying for our purposes, but not that hard to implement (you can find my implementation at line 94: Array.prototype.crc32). Costs a bit of performance, but wouldn't be a major problem by itself.
But the reliance on ZLIB proved to be a major annoyance, because the documentation (RFC1950 & RFC1951) is lacking... to put it mildly (the relationship between those two documents is never really mentioned, meaning that you're always guessing if a header belongs to the stream or the block). The endianess is also switched from what PNG uses, meaning that you end up with two different types of integers in the same file. I ended up mostly analyzing THE GIMP's output for uncompressed PNGs (and could have finished everything much earlier if I hadn't tried to work my way through the spec first). The most important part from the spec is the definition of the ADLER32 checksum (line 85: Array.prototype.adler32), which sadly is required for each ZLIB block, meaning that creating a PNG involves calculating two different checksums for (mostly) identical data.
But my little PNG encoder is working now, and in difference to other implementations that I've found, there's no 64kb limit as my implementation splits every stream into 32k blocks correctly. However, it's not as fast as it could be and if there's interest I'll happily put the code in a project if other people want to help improve it or maybe even add proper compression.
EDIT: THE CODE IS NOW PART OF AN OSS PROJECT, SEE THE NEXT POST
I might not check this forum at the time, but you can always reach me at [email protected]
I've published the Javascript-PNG-encoder workaround over at http://code.google.com/p/todataurl-png-js/ under the GNU Affero General Public License, version 3 license in case anybody wants to join and add compression or just general optimization. Just drop me a line if you want to be added to the user directory.
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.
It took us much longer than WP7 did, but the first Interop Unlock hack for WP8 is now available. It's currently limited to SAMSUNG phones, although we're trying to extend it to other phones, of course.
WARNING: Samsung is trying to break this hack! If you take the retail upgrade to GDR3 including the Samsung firmware update, it will not work!
A brief summary, for those unfamiliar with interop-lock: Windows Phone allows a number of high-privilege app capabilities, which can be used to make changes to the OS which are normally not possible for a third-party app. The limitation on whether we can use these capabilities or not is based on what "level" of developer unlock the phone has; standard "ISV" (Independent Software Vendor) dev unlock (max 10 apps or less) is what pretty much everybody gets; OEMs, however, get a special OEM Developer Unlock (300 apps or more) which gives them the ability to use much higher-privilege app capabilities than the standard ISV unlock permits. The name comes from ID_CAP_INTEROPSERVICES, the capability which was most important in WP7. In WP8, however, there are a great many interesting capabilities. Note that Interop-unlock by itself does not enable all of these. However, at least on Samsung phones, it is now possible to enable *all* the capabilities.
Guide for Samsung's ATIV phones:
The instructions are generally well-provided in @-W_O_L_F- 's app (direct link for updated XAP). You will also need the Diagnosis app, which is included (though hidden) on every Samsung WIndows phone.
The instructions are as follows:
Developer-unlock your phone. You will need the Windows Phone Developer Registration tool for this; it comes with the SDK.
Sideload the helper app using Application Deployment (included with SDK) or WPPT. It does not work to just copy the file to your phone, or similar.
Open the Phone dialer (the built-in one) and dial ##634# to install the Diagnosis app (if you hadn't already). You can exit it afterward.
Run the Interop Unlock Helper app and read the instructions, clicking Next until you get to Step 2.
Click the button to generate the toast notification for your phone's Diagnosis app, then tap on the toast to open the hidden registry editor.
Press-and-hold the Back button, and switch back to the helper app without closing the registry editor. Click Next to go to Step 3 in the helper app.
Copy the provided registry paths and values out of the helper app, use the Back-and-hold switcher to return to Diagnosis, paste the values into the registry editor, and write them.
Don't worry if the app says a write failed! Just hit Read afterward to verify the change.
Repeat the previous steps a few times, hitting Next after each set of instructions, until the Helper app says "Finish".
Once all the registry values are written, congratulations; you are interop-unlocked!
At this point, you probably want to run the EnableAllSideloading hack below.
If you want to enable sideloading even more high-privileged apps, you'll want the following:
Install the BootstrapSamsung app attached to this post. This requires having interop-unlock already, and will not work if you have Samsung's ships-with-GDR3 firmware update unless you unblock RPC.
Run the app once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
Install the EnableAllSideloading app attached to this post. This requires the bootstrap step. However, it is not specific to Samsung (we just can't bootstrap anything else yet).
Run EnableAllSideloading once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
At this point, you will be able to sideload any capability, even the ones used for built-in apps and services. However, there appear to still be restrictions, even with a capability such as ID_CAP_BUILTIN_TCB. Multiple XDA members, including @Heathcliff74 and myself, are working to overcome these restrictions.
It may be necessary to repeat these steps after a phone update.
Capabilities which will be enabled, without further modification, by using interop-unlock:
Note: This list is *just* the ones from Interop-unlock; it does not unclude the ones from EnableAllSideloading.
ID_CAP_CALLMESSAGING_FILTER
ID_CAP_CAMERA
ID_CAP_CELL_API_COMMON
ID_CAP_CELL_API_LOCATION
ID_CAP_CELL_API_OEM_PASSTHROUGH
ID_CAP_CELL_API_UICC
ID_CAP_CELL_API_UICC_LOWLEVEL
ID_CAP_CELL_WNF
ID_CAP_CSP_FOUNDATION
ID_CAP_CSP_MAIL
ID_CAP_CSP_OEM
ID_CAP_CSP_W4_APPLICATION
ID_CAP_CSP_WIFI_HOTSPOT
ID_CAP_DEVICE_MANAGEMENT
ID_CAP_DEVICE_MANAGEMENT_ADMIN
ID_CAP_DEVICE_MANAGEMENT_BOOTSTRAP
ID_CAP_DEVICE_MANAGEMENT_SECURITY_POLICIES
ID_CAP_DU_MIGRATOR_STATUS_OEM
ID_CAP_OEM_DEPLOYMENT
ID_CAP_INTERNET_EXPLORER_FAVORITES
ID_CAP_INTERNET_EXPLORER_SEARCH_PROVIDER_KEYS_HKCU
ID_CAP_INTEROPSERVICES
ID_CAP_KIDZONE_CUSTOMIZATION
ID_CAP_MAP_WRITE
ID_CAP_MEDIALIB_PHOTO_FULL
ID_CAP_NETWORKING_ADMIN
ID_CAP_OEM_ADC
ID_CAP_OEMPUBLICDIRECTORY
ID_CAP_PEOPLE_EXTENSION
ID_CAP_PEOPLE_EXTENSION_IM
ID_CAP_PEOPLE_EXTENSION_MOBILE
ID_CAP_PERSONAL_INFORMATION_IMPORT
ID_CAP_RUNTIME_CONFIG
ID_CAP_SMS_INTERCEPT_AGENT
ID_CAP_SMS_INTERCEPT_RECIPIENT
ID_CAP_SYNC_EXTENSION
ID_CAP_VOICEMAIL
ID_CAP_WALLET_SECUREELEMENT
ID_CAP_WIFI_BASIC
One of the goals of this thread will be to explore what we can do with interop-unlock, and look for ways to achieve full permissions. I think I've found one, but it requires the ability to write registry multi-string values. Basically, if we could add a "superuser" privilege, or enable the use of ID_CAP_BUILTIN_TCB, which already has it, this would allow the creation of "root" apps.
Aside from myself, credit for this hack goes to @cpuguy for the Native Toast Launcher tool which permits accessing otherwise-unreachable code, and @-W_O_L_F- for helping put the pieces together. I'm not actually certain which one of us achieved the interop-unlock first; we were both working on it. @Heathcliff74 continues to be a help on the quest for full-unlock.
The source code for the apps below is posted at http://forum.xda-developers.com/showpost.php?p=45606584&postcount=88
Questions and Answers
Can I install WP7 interop apps using this?
They will install, but there's no point. They almost certainly won't actually work. Interop-unlock enables access to parts of the OS which third-party developers were not intended to touch; consequently, there's no backward compatibility. Even the methods used for native code on WP7 (which is different from, but nearly essential to make use of, interop-unlock) won't work on WP8. However, it should be possible to port many of those applications to WP8.
Will this work on Lumia phones / How can I get this on my Lumia / Are you working on this for Lumia phones / What about HTC, or some other OEM?
The current hack relies on a Samsung-specific component. Adding support for other phones will require new hacks. We are looking into it, rest assured; at this time, however, there is no way to gain interop-unlock on any WP8 device other than a Samsung one.
EDIT: It looks like there should soon be a Huawei W1 custom ROM with interop-unlock included. I don't deal with custom ROMs, but you may be able to use homebrew apps on that phone too.
EDIT: Lumia phones *can* be interop-unlocked via JTAG. However, this requires some extra hardware and some phone disassembly. Not an online hack, and not for the faint of heart.
But what if we installed the Diagnosis app on a Lumia phone (using Fiddler proxy or similar) and then followed this guide?
I repeat, Samsung-specific component. Nokia doesn't put the required services/drivers for Samsung's Diagnosis app into their Lumia firmware, so the app would not work!
Can I upgrade my phone to GDR3 if I have this?
Yes. However, be aware: if you install Samsung's updates that come with the retail GDR3 update, it will break your ability to re-unlock, or to use some homebrew apps! (Developer preview updates are fine, as those are purely Microsoft code and don't mess with the Samsung components.)
EDIT: There's a way to unlock the Samsung services for full access again on GDR3. You still need to interop-unlock beforehand, though.
Can I re-lock my phone if I want to?
Yes, easily. The simplest method is to use the Windows Phone Developer Registration tool (the one that comes with the SDK) to de-register the phone (you can then re-register it if you want to get your normal dev-unlock back). This doesn't remove any changes that were made using the interop-unlock, though (for example, it won't undo the EnableAllSideloading hack, not will it set back the Full FS Access hack). Apps that require interop-unlock will still be installed, but may no longer run. To manually remove interop-unlock, you can reset all the registry values that were changed by the interop-unlock hack to their original values, and remove all the apps. There still may be a great many other changes that also need reverting, though, if you want to get back to stock settings. See next question.
Can I get my phone completely back to stock settings without knowing every little thing I changed?
Yes, a hard (factory) reset will undo all changes made by interop-unlock, or any apps (including ones that require interop-unlock), and will remove all apps. If you need to send your phone in for warranty servicing and are worried that they won't take it because you interop-unlocked it, this approach will fix that (they would probably tell you to hard-reset anyhow, if it's conceivably a software problem).
Will the interop-unlock survive a hard reset?
Not using this method! Read the question above. This unlock is purely in software, not firmware; it is reset along with everything else.
Can I upgrade my phone to WP8.1 if I have this?
Tentatively, yes! We're still working on figuring out exactly what WP8.1 means for the homebrew scene. The short version is that most apps and some (but not all) of the hacks they contain seem to still work, though. However, see next question...
Can I interop-unlock my phone on WP8.1?
At this time, I don't believe this is possible (unless you can use a custom ROM). One step of the process appears to have been "fixed" and we will need to find a different way. -W_O_L_F- has indicated that he has one, possibly coming soon...
Apps which use Interop Unlock
SamWP8 Tools Currently includes a basic registry editor and some tweaking tools, including an accent color editor.
Native Access Webserver that requires full capability unlock; still read-only at this time.
PDF to Office enables browsing and moving files.
WPH Tweaks allows easy access to a number of registry tweaks.
AppData Manager allows you to back up the data of an app so you can re-install it (possibly after a hard reset) and not lose its state.
Storage Cleanup allows you to list and delete space-wasting files on your phone.
Reserved for... whatever else is needed.
Awesome!
I suggest first app to the list: my SamWP8 Tools
Upd. I'm little bit late XD
well i ve got an ascend w1 bootloader unlocked if i can help let me know
It's awesome to have my phone Interop Unlocked. I hope to see something to clear my "Other Storage" soon. Its full with faulty Windows Store installation files.. But I guess even with this it will be a lost cause.
Sent from my GT-I8750 using Tapatalk
although the Samsung registry editor will install it will not run on my phone and I believe I was able to interop unlock any idea why it wont run?
@GoodDayToDie your wor is awesome and you are the man
Good luck buddy
@FricoRico: Actually, I'm pretty sure we can clear out those files. I've got a ton of stuff on my plate at the moment, but even if none of the capabilities that work with interop-unlock will natively allow access to the relevant folder (and I wouldn't be surprised if one does; what is the folder in question?) there's a function in the Samsung driver interface to move files; we can move them to a location where we have write access, and then delete them.
@noelito: No idea. If it installs, that means you're unlocked. Make sure your phone didn't re-lock, I guess - try deploying the app again, for example - and make sure you're using the official deployment tool (some of the unofficial ones for WP7 - which may or may not work on WP8 - strip interop capabilities) and then try again. If it still doesn't work, please give a more detailed error report.
I am using the official deployment tool, and I believe the interop unlock does work because I was able to side load operamini, Samsung photo studio, supreme shortcuts and couldn't before BUT that was it they're side loaded but do not work at all ? well actually supreme shortcuts does run but when I try to use a custom shortcut such as brightness it will crash
Sent from my SGH-T899M using XDA Windows Phone 7 App
Aha, an item for the FAQ...
WP7 INTEROP APPS WILL NOT WORK! Interop-unlock lets you develop high-privilege apps, but it's very OS-specific. This is all unofficial stuff; there's no reason for Microsoft to have maintained backward compatibility, and indeed they did not. New apps will need to be developed specific to WP8. That's why there isn't already a bunch of listed apps...
ohhh ok so this interop unlock
is paving the way for future wp8 homebrew apps?
Exactly. Things which I have in mind, beyond the obvious improvements to registry and file system browsing, include options such as sounds customizations, media library access, changing certain "restricted" file/URI associations (alter the default browser?), *possibly* better task management (not sure we have the permissions for that), cleaning up wasted storage space, and as much more as we can manage. There's also a lot of potential for future research which this enables: interop-unlocking more devices, getting even higher permissions, possibly even custom ROMs or at least custom kernel drivers (which is much the same, since once you've got that you can change anything).
Can you write anywhere on the file system?
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
GoodDayToDie said:
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Click to expand...
Click to collapse
Might be able to port @Myriachan 's exploit.
Boss442 said:
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
Click to expand...
Click to collapse
Feature-wise, Test mode is heavily locked on Lumias. One has to authorize to use its the most sweet features.
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.