Related
Hello Everyone,
I am a avid, aspiring developer, and as such I felt it would be mutually beneficial to start this thread. The Point of this this is for you [the users] to post up ideas for programs, and some sketch-ups of designs, and in return, I will try to make, and maintain, these applications.
In doing this, I will get the experience I need, and you [the users] will get the results that you [hopefully] want.
Below is [or will be soon enough] a list of programs that are developed or in the process of consideration.
Project List:
AutoSend - Scheduled SMS Sender [V3.5][NO LONGER BEING UPDATED]
CMail - A Replacement tmail for Devs and Advanced Users[V1.0]
Export-Studio - A FREE alternative app to export Contacts and SMS[V4.0 + Command Line Version]
Appointmentor - A command-line based app for creating appointments quickly and easily [V1.5]
ContactRetriever - A command-line based app for getting info on a specific contact! [V3.5]
CDL - A Command-Line based File downloader (designed with MortScripter's in mind) [Release Delayed]
CSort - A Command-Line based List Sorter (designed with MortScripters in mind) [V2.0]
ImgResize - A Command-Line based Image Resizer (Resize + Crop) [V2.0]
All2Reg - Based off of Msg2Reg, this will export MANY things to registry [Coming Soon]
TornadoClean - A utility for deleting old files/SMS/MMS/EMAILS with certain 'traits' specified by the user [Conceptual - PsuedoCode Stage]
CBRunner - [Idea courtesy of HowdyKeith] Runs EXE's (and possibly other file types like MP3, etc.) In the background so MortScripters can do their stuff! [V1.0]
CMessageSuite - A Re-Make of AutoSend with more features! [V1.0]
*As you can see, the list is sort of pathetic now, but with your help, I can bulk it up*
UPDATE:
A command-line version of Export Studio is now posted for all you Scripters!
Appointmentor[V1.5]
This program allows scripters and devs to quickly and easily make appointments. This program features the ability to set every parameter that a user could set thru the calendar itself (I believe...)
This Program Includes:
A documentation explaining all parameters
A small cmd-line app for creating appointments.
To Install:
Just download and extract the ZIP file to anywhere on your phone, and you are done!
To use:
Follow the parameters in the documentation, but as for running it, run it like any other command-line based program.
Tips:
Not all parameters must be set, as I have preset defaults (shown in documentation).
EDIT: DOWNLOADS REUPLOADED
V1.5 Update:
In this update, you can DELETE scheduled appointments. This feature has not been thoroughly tested, so errors may occur. Will test in near future. (If users could post back successes/failures it would help).
Please test it out!
*While I coded this on my own, credit must be given to google and this forum for its constant help in everything I do. Please don't forget that while these apps are free, donations are appreciated!*
Update:
I fixed up a major issue in Appointmentor and re-uploaded it. Now it should work. All documentation is provided in the ZIP file. Please test and post results and ideas!!!!
Image Resizer [V2.0](Command-Line Utility)
This application is a command-line based app for resizing images.
All instructions are provided in the Documentation.txt
Enjoy!
V1.5 Update:
In this version of the program, Cropping is now available. Look at the docs to find out how to use it. I also fixed an issue with Naming, so now the outputted file has the ACTUAL size of the image (not what is inputted in some cases). Also, you can use PERCENTAGE to resize/crop. Lastly, you can now simply convert your file from one extension to another.
V2.0 Update:
In this version, BatchCropping and BatchResizing is now available. Look at the docs to find out how to use it. This comes in handy when dealing with many pics in a folder. Please report back any bugs that are found
DISCLAIMER::::::
I did not code this program fully by myself. For the original Image Resizing project visit:
http://blogs.msdn.com/acoat/archive/2007/05/09/resize-images-a-thumbnail-maker.aspx
All Credit for the actual Image Resizing functions of this app go to the original author:
Username on msdn blogs is : acoat
Name (?) : Andrew Coates
ContactRetriever V3.5
This application allows a scripter or dev to export a specific contact's data for easy use!
This program includes:
A simple, easy to follow documentation and functionality
A light-weight solution for getting contact info.
A SUPER EASY GUI (contacts menu) when not wanting to start it in CommandLine mode.
The ability to export specific contacts (or many) as VCF files
To Install/Use
Just unzip the ZIP file and read the documentation!
(To use the GUI, just run the app WITHOUT parameters, to use the CMD run it WITH paramteres)
Bugs:
None so far!
V3.5 Update:
In this version, you can find contacts by partial (or full) phone numbers! Read the docs for more info.
Please remember that while I did the coding on my own, help came from XDA and Google and the millions of resources on the net. Please remember that while this application is free, Donations are greatly appreciated!
Enjoy!
UPDATE:::
Export-Studio 2.5 Is now out.
2.5 Has the ability to set the NUMBER of Contacts/SMS to be exported (with a safeguard that if the number is too high or is 0, it will set it to the maximum).
Expect an upgrade to Export-Studio 3.0 Soon (ability to export to VCF, and maybe MMS implementations).
Expect a new CMail to come out (ability to send E-Mail's via commandline and maybe MMS implementations).
Contact related app...
I've been searching for an app that allows to browse the contact list (with a scrollable list of names for a GUI... similar to Outlook or any other contact manager) and retrieves a selected contact full name as a reg key (my point would be using it in conjunction with MortScript and go2contact to add a dynamic contact launcher feature to my HS++ skin... guess it would be usefull for other skinning engines too).
Would you be willing to do such an app?
frmariam said:
I've been searching for an app that allows to browse the contact list (with a scrollable list of names for a GUI... similar to Outlook or any other contact manager) and retrieves a selected contact full name as a reg key (my point would be using it in conjunction with MortScript and go2contact to add a dynamic contact launcher feature to my HS++ skin... guess it would be usefull for other skinning engines too).
Would you be willing to do such an app?
Click to expand...
Click to collapse
Sure would be! I will just implement a GUI into ContactRetriever! Expect a release in 10 minutes TOPS.
UPDATE::
Export-Studio 3.0 Now released - Can export Contacts as vCard (VCF) format!
UPDATE::
ContactRetriever 1.5 NOW released - Has a really simple GUI (same functions)!!
UPDATE::
ContactRetriever 2.0 NOW released - Ability to export as VCF, control # of contacts, and WILDCARD'ing
Thank you so much! Just tried it and this was what I was looking for.
There seems to be an issue though... I can only get stuff from the first contact in the list... Also the name will be in all caps and have an underscore before it... I can't get any other contatcs info in the reg...
how about Cdown.exe -url "http:.../file.zip" -outp ".../file-Downd.zip"
as smartphones cant do that w/mort atm...
howdykeith said:
how about Cdown.exe -url "http:.../file.zip" -outp ".../file-Downd.zip"
as smartphones cant do that w/mort atm...
Click to expand...
Click to collapse
Added to project list....WOrking on it
Thank you so much for fixing ContactRetriever
While the paint is still fresh... Any chance on creating a value for the selected contact named "LastSelectedContact" (or something else) where the contact name is the data (without the preceding underscore and case sensitive like Outlook). Would really make it a lot easier to MortScript (I really have no idea how to get just the desired part of the key and remove the underscore).
Hope I'm not abusing of your good will...
Hey, so I can't really make a key that is for "lastcontact" because the command-line users may export a whole bunch of them (as you can see, I implemented the ability to export based on Wildcards)....
As for removing the underscore and such, I put that there as a standard for users so that they know what WAS created by my program, or what was created by something else that may have used the same area (rare, but possible).
Anyways, if you want to format it, do a substring on the Key name using the indexOf the _ as the ending for the first and that + 1 for the start of the second, then bring it all to lowercase then make the first uppercase (through substringing?) I don't know the mort-commands, but I am sure you can figure it out by asking HowdyKeith or posting on the MortScript thread or reading the Manual on Mort's website.
Good Luck
Thanks for the info. I've been reading the txt manual of Mortscript and it's kind of incomplete compared to the pdf... I'll read it tomorrow (must sleep) but until now I didn't find a function that returns the reg key (because it'll be random). I'm sure the substring bit will help.
Just found my contact list got sort of messed up by some app I used (guess it's too late to find out which one...) All the names (first and last) are now stored in the first name box... I didn't notice it before so I didn't get why was there a _ before the name even when I had a last name too.
Ok.
How about CSort.exe -inp "/path/Unsorted.txt" -outp "/path/sorted.txt"
maybe the option to dump the output into a regkey:
Sorted1=Alimoney
Sorted2=Bingo
...
If we r dumping to a reg folder, why not import from a registry folder too?
So i know u got the picture taking exe.
what about calling the Camera get picture class? Like your contact retriever calls the GUI.
I have to think about it to see if that makes sense.
howdykeith said:
So i know u got the picture taking exe.
what about calling the Camera get picture class? Like your contact retriever calls the GUI.
I have to think about it to see if that makes sense.
Click to expand...
Click to collapse
I am using Managed C# code, and the most 'power' that I get in terms of taking photos is just to start up the 'dialog' with certain paramters....so in MortScript, a script can just call it, then send the "ENTER" button to start and "ENTER" to stop (if it is a video) or save (if it is a photo)....
*FYI: The Camera App I am developing is currently in Private Beta, release soon enough*
So as far as contacts posted to the reg from contact retriever.
It probly should always delete the prior searches unless you give it a command -keep
For the advanced hacker: SQL database access and posting.
Do u have a Microsoft Bluetooth stack? There is no toggler for Widcomm Bluetooth. PhoneAlarm controls the bt just fine, so it's not impossible.
Can you turn on and off the flash? Other apps do it, so that's a low priority. But if you could and u added that function to an all in one tool, that would be cool.
Make a contact from a command line.
Can u change the power profiles? Normal/Headset/Auto...
Can u get the accelerometer info? i dont have one. Detect stylus removed from a command line?
I really hope u can get the sorter to the registry, so i am holding my breath til then.
Thanks Dude.
*Anyone get the reference? Haha*
Resident Mort
The Scripter's Companion​
Current News / Status:
Resident Mort is currently Under Development
Resident Mort is planned to be a background EXE that will extend the functionality of MortScript available to developers through the usage of the "PostMessage" function.
Resident Mort is planned to extend functionality by adding extra, possibly more complex, functions or even adding in the ability for more complex GUIs.
Features (Green = Implemented, Blue = In Testing, Orange = Planned, Red = Failed):
GetProcessList - Gets a list of Running Programs
GetRecentApps - Gets a list of Recent Apps (10)
CreateScript - Creates a MortScript with the provided info
MakeFile - Makes a file of any kind with the provided info
MakeFolder - Makes a folder at the specified location
RegToEvent - Registers a File to an event​
UnRegFromEvent - Unregisters a File from an event
IsIdEventRegistered - Checks to see if a File is registered to an event.
DispImg - Displays an Image to the screen [and gets where the user Presses]
MakeForm - The Initial call for setting up an 'advanced GUI' form
FormAddObject -A Call that will add one of the predefined objects to the form being created
DeployForm - The Final call for setting up an 'advanced GUI' form, displays it to the user
This application is being made for MortScripters, to possibly make some projects easier. Since I don't use MortScript so much any more, I do rely on you the developers who use MortScript, to tell me what you want in the program.
Since I have a good deal of Functions there, I will commence work on a primary release
Saved For Future Use - Features and Screenshots
like the idea! advanced guis would be very useful
so this is a compiler? I am not sure what this is about
-sorry
No, this is a Resident App, an EXE that is always running in the background. It will have certain functions in it which can be accessed by MortScripters.
All the functions can be called with PostMessage ( I will provide documentation on how to do so, when I make a first release ). Then the results will either be written in the REGISTRY, written to a FILE, or copied to the CLIPBOARD (depending on how the scripter wants to handle the task).
Does this clarify it a bit?
Thanks for sharing!
A small update:
I am using this 'decent' planning utility, to help me keep track of my growing projects. According to this utility, the program is close to 30% complete. Then again, this is just a 'decent' utility haha. I would say, in my estimation (since some Code is "Copy + Paste"), I am close to 60% to 75% done.
A small change in my plans:
While I originally had the intentions of making this program as simple as a PostMessage in MortScript, I found out the following two Limitations:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
2) Due to #1, I made an assistant EXE, which would be run instead of calling PostMessage [this way I could do it Natively in my own control], but it is MUCH harder to transfer data between two applications that I would have thought! Due to Virtual Stacks and Memory Allocation 'rules', I couldn't EASILY do this.
So Here is my change:
In order to use Resident Mort, scripters will have to do about 3 or 4 commands to run. The only real commands that need to be used are PostMessage and RegWriteString (Did I get those right?).
In any case, my Resident Mort will read the Registry for corresponding wParam and lParam values and use those [in the future I will attempt Clipboard integration, to avoid Registry Interfacing].
When I release this program to the public, I will try to include a MortScript file that shows how to use all the functions. I don't remember much of MortScript [unfortunately], but I was thinking it could be helpful to make a "Library" of MortScript functions so a script will only have to call that function. But that is if some kind dev. would like to help out later on
Anyways, Thats that for this update. Expect a result in the coming week.
That sounds interesting for adv. gui functions.
Cyclonezephyrxz7 said:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
Click to expand...
Click to collapse
That's not MortScript's fault, it is design of whole Windows CE kernel, more here
I'd go with background EXE, that would listen to messages WM_USER+somenumber, maybe even region (for different actions, so you'd have both lParam and wParam free for another parameters). If you need help with this part, drop me PM on MSN, I had to study this a bit in the PinchToZoom project myself.
@OndraSter : Yeah, I know that Windows CE has limitations, however it is not impossible. Such an ability could be implemented in a code-update to MortScript. I did my reseach (if you look at #2, I mention that I found it much harder to transfer data between exe's that I had hoped) and found that you can transfer data via SendMessage (the Synchronous method) using a TRANSFERDATASTRUCT and WM_COPYDATA. If MortScripts interpreter could identify a SendMessage with a String value in either wParam or lParam, then it would create such a structure and transfer it, the receiving app would HAVE to take care of deleting the data though, or you have mis-used RAM.
As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID). I have it mostly covered, and I am closing in on finishing (currently with Reg data retrieval only, no Clipboard yet). I have completed 3 of the 7 Proposed Functions (MakeFile, MakeFolder, CreateScript) and I would have finished RegToEvents, but I got sorta lazy hehe. DispImg shouldn't take me more than a few minutes when I get to it, and once I get the API calls for Processes and figure out how to read the MRU reg-entry, I will have the last 3 complete!
As for Clipboard data retrieval, unless I am using the entirely wrong API calls, MortScript has an interesting way of using the Clipboard...I tried copying simple strings like "hello world" to the clipboard using MortScript, then trying to retrieve them in my Resident Mort, but the clipboard always comes up empty... Any ideas anyone?
Thats that for now I am about ready to release....any other functions you want implemented?
As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID).
Click to expand...
Click to collapse
http://msdn.microsoft.com/en-us/library/ms644947(v=VS.85).aspx
Good idea, the only downside being that it will generate the Message Numbers each time it is run... It is not assured that the Post / Send Message MsgIDs will remain constant.
Thanks for the link however
Cyclone,
Sorry about taking so long to post here...
How about, when the BT is on, this reports what is "out there" based on what the BT stack is telling you.
That is, it should read the surrounding area, then report that is saw my BT dongle. In the car, it should report that it saw my BT GPS unit.
Then, I can use that information to change my profile. That is, when it sees the BT dongle, regular phone calls. When it sees the BT GPS unit, run speaker mode, or connect to the GPS unit for phone calls.
Thanks!
--Ironhead
P.S. it would need to support the Touch Pro 2, Rhodium (my understanding is that it is Widcomm BT stack)
I"ll see what I can manage. I am really 'grid-locked' in my work on a couple of projects already So a release of this may have to wait a while....Sorry
I wish I had caught you a little sooner...
AutohotkeyCE may be a better base to work from than Mortscript...
http://www.autohotkey.net/~Micha/AutohotkeyCE/html/index.htm
In fact... AHKCE should be able to cater to all of your needs without the separate resident app
Yeah, I have seen that before. This project is really just a little challenge for myself to expand upon MortScript [because I know it is widely used].
Thank you for the link/suggestion however
I've been playing with Mortscripts for a while, I'm really thinking I can do everything I want, right from there...
EXCEPT:
Actually getting the information from the BT stack. I just need to see if there are any registered BT devices around my phone (so I can tell if I am in my car, at home, at work, etc.).
--Ironhead
Bumpity bump!
Hehe...Yeah, sorry for the lack of work on this. Check out FFP_LockScreen. I am working on a new release. I have very little time now, and I can't manage more than just one or two projects at a time. Once I release FFP_LS 3.0, I can devote some time MAYBE to this project. It all depends on how quickly the XDA-Marketplace idea takes off.
Sorry =\
I you can add a tool to make an GUI... it s must be soo cool...
Hi at all,
I would like to start coding for wp7. I already have the sdk and some knowledge about c#. However, I don't know how and where to start.
My plan is to program a vocabulary builder, that just asks a vocabulary from a database, then waits until the user has thought about the answer, then on click shows the answer and the user can say if it was right or wrong. Dependent on the answer the vocabulary's phase increases or decreases 1. There should be six phases.
No idea how to do that. I even don't know where to save the vocabularies and how to get them on the phone.
Any ideas for me?
Hi,
Depending on the size of the dictionary you could put the vocabs in one or more XML files, that will be deployed with your application. Maybe something like this:
Code:
<dictionary sourcelanguage="spanish" targetlanguage="english">
<vocab id="1" word="uno" translation="one"/>
<vocab id="2" word="dos" translation="two"/>
</dictionary>
Add the file to your project with build type content and read it e.g. with XDocument.Load("spanish.xml") => see here.
Build classes representing your XML-Structure and get a random vocabulary to display it to the user (use a public property e.g. "CurrentWord" in your ViewModel that is bound to a UI-Element in your View).
The "Show answer" button should be binded to a Command that triggers the hidden answer and the "Rate my answer" button to be shown.
To save the phases you could build up a index file that saves the IDs of the vocabularies with an integer of the phase count. This would then be saved each time the user processes words.
Hope this helps a bit.
I want to do the following:
xboxmod said:
Google
Code:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes]
"DefaultScope"="Google"
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes\Google]
"URL"="http://www.google.com/m?hl=en&gl=us&client=ms-hms-tmobile-us&q={searchTerms}"
Click to expand...
Click to collapse
I installed Registry Editor from TouchXperience on my Samsung Omnia 7. I went to:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes]
And changed DefaultScope's value to "Google" (without the quote obviously). For:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes\Google]
I need to create a new key and name it Google in SearchScopes, right?
I tried to do that, but Registry Viewer could not create the new key. I tried multiple times, but it wouldn't work. I get the following error:
Unable to create registry key "Google".
I also accidentally created a new value called "a" but when I try deleting it, I get a similar error. I get the following error:
Unable to delete registry value "a".
TouchXperience registry editor uses the COMRilClient.dll from Samsung to get access to the registry on Samsung devices. This dll only allows read/write of dword and string values. It does not allow to create/delete keys and it does not allow to delete values. It is also restricted to keys that have permissions for Elevated Privileges. It has no access to key that need TCB permissions.
At the moment I am working on "WP7 Root Tools" which allows you to read and write to the entire registry. At the moment I am using a little part of the Samsung drivers, so for now it is only suitable for Samsung devices. I will try to make it work for all devices in time. With a work-around I have access to the phone with TCB privileges.
I have been working on it for quite a time now and I am close to releasing an alpha version. It has been delayed, because last month my grandpa died and now my mother is on Intensive Care because she had an aneurism and needed brain surgery. She is recovering in very little steps and I pray she will be fully recovered after rehabilitation.
So I am not fully committed to hacking at this moment, but I promise it won't be very long before I can release a working alpha version.
Thanks for the info, though does that mean I can't even remove the "a" value that I accidentally added?
I'm sorry to hear about your family situation. I hope your mother fully recovers sooner than later.
Chaoticaa said:
Thanks for the info, though does that mean I can't even remove the "a" value that I accidentally added?
Click to expand...
Click to collapse
Yes, that's right. But it probably won't do any harm. So don't bother.
Chaoticaa said:
I'm sorry to hear about your family situation. I hope your mother fully recovers sooner than later.
Click to expand...
Click to collapse
Thanks.
Heathcliff74 said:
But it probably won't do any harm. So don't bother.
Click to expand...
Click to collapse
Yeah, it doesn't even make sense for it to have any affect unless something is looking for that value name in my registry. I'm just a neat-freak that hates that extra accidental value a lot more than the fact that I can't do what I was trying to accomplish.
Chaoticaa said:
Yeah, it doesn't even make sense for it to have any affect unless something is looking for that value name in my registry. I'm just a neat-freak that hates that extra accidental value a lot more than the fact that I can't do what I was trying to accomplish.
Click to expand...
Click to collapse
You could always hard-reset your phone
Hahaha not that bothered by it.
OK, time to give this subject its own thread. You can read about previous efforts here: http://forum.xda-developers.com/showthread.php?t=1113066. In particular, http://forum.xda-developers.com/showthread.php?t=1113066&page=11 is where I started.
Background: the policy database is essentially the Access Control List (ACL) store for WP7. ACLs are typically attached to objects (files/folders, registry keys/values, drivers/services, possibly even APIs). When a process tries to do something, the OS uses the process's security identifier (called a "Token", it identifies the account running the process and therefore the permissions that process has) and looks up the ACL specific to that operation. If the ACL authorizes that account to perform the operation, the kernel permits it. If not, it blocks the operation and indicates an error (most famously on WP7, 1260 or 0x4EC, meaning blocked by policy). For some OSes, like NT, that attachment is in the metadata which describes the object (for example, NTFS stores ACLs for each file and folder). Apparently, WP7 uses a centralized database of ACLs, stored as "policies", instead.
Why I'm doing this: the policy database is the key to fully unlocking the phone. I mean that literally; "full unlock" ROMs achieve that state by basically turning off policy enforcement. I don't necessarily want to do that - at least not phone-wide and constantly - but I want to be able to set my own policies, and possibly modify existing ones.
What can be done with it: well, one example is the subject of the thread I linked above: homebrew native EXEs require first being able to add policies for them. There are some other cool possibilities, like turning off ID_CAP_INTEROPSERVICES enforcement or allowing apps to write to the MaxUnsignedApp registry value directly. That gets around the risk of phones being re-locked and unable to interop-unlock again. Basically, it allows an app to do anything short of modify the ROM.
Purpose of this thread:
* Provide a central location of information about the policy system, policy database, and creation of custom policies.
* Collaborate on the project of understanding and modifying the policy database and policy system overall.
* Share interesting policies we've found in the database, or post custom policies that can be added to enable a cool hack.
* Discuss and share ways to preserve, going forward, our control over the policy system.
There has been concern raised that this work should not be mde public, because Microsoft will look at what we are doing and use that knowledge against us. There is some validity to that argument; if the work is done in secret, and any files posted that use the fruits of that work are heavily obfuscated, it would probably take Microsoft a little longer to block it if they decided to do so. Not terribly *much* longer though, I suspect - they have many tools at their disposal, full source code and documentation, and full understanding of the system in their engineer's minds. Any hack we find, they can reverse engineer or simply block access to whether or not they can read a thread about it here on XDA-Devs.
There's also the risk of malware. Malicious homebrew apps could abuse this knowledge to do serious damage to your phone, to steal info, and possibly even for direct financial effect (send premium SMS, for example). However, I see no real way around that problem; it's an inherent risk of unlocking a device. The simplest and best step to combat it is to not install untrasted apps, and the best way to be sure an app is trusted is to be able to analyze it. (This is one of the reasons I include the source for my apps, and encourage others to do the same.) Besides, it's already possible to do plenty of damage with existing homebrew hacks, yet somehow that problem hasn't materialized.
So, instead of secrecy, I propose openness. The best option we have to offset Microsoft's tools, knowledge, and source code is to collaborate, pooling the knowledge and effort of many hackers. If people want to keep certain things secret, by all means use email or PMs. In general, though, I think the failure to spread knowledge does more harm than good.
OK, that turned into a long enough intro that I'm going to post my first actual findings in a reply.
Policy-related files
There are actually two databases: one is for policies, and one is for accounts. They are located in \Windows\Security\ and are called policydb.vol and accountdb.vol. These files are locked (opened without sharing permitted) while the OS is running. There are two additional files in this folder: PolicyMeta.xml and PolicyCommit.xml. These files can be accessed using provxml, TouchXplorer, WP7 Root Tools, or HtcRoot Webserver.
The PolicyMeta XML file contains macros describing accounts, and metadata about the policies in the database. In particular, it contains a large number of bit masks that indicate different permissions. By itself, this file doesn't tell us much of use, but it will be a big help for understanding binary data in the the database. It's small and not commented, but easy to read.
The PolicyCommit.xml file contains the merged result of combining all the policy files on the phone. I don't know if anything actually reads this fine, but it's a nice human-readable (and searchable) view of the data that goes into the policy database. It contains a number of comments, but most are just where the various policies were merged from. It is the largest file.
The policy database file ("Volume" to use the term of the CEDB APIs) itself is large-ish (mine approaches a megabyte) and contains three CEDB databases. The first is a small single-record "database" (in SQL you'd call it a table) that appears to be used for transaction locking. The second is a single large record (several KB) that appears to be a bloom filter (Wikipedia has a pretty good article, the short version is that it is a quick and compact data structure for checking whether a given item is in a collection). The third database (named "PatternDBmultimap") is the real deal, containing thousands of policy records.
I haven't looked at the Accounts database much yet. It's smaller than the Policy database volume, but still a few hundred KB. A substantial portion of that is probably custom accounts created for each app that is installed (since each app has different permissions - specifically, each app has read and write access to a different set of folders - there must be a unique account for each).
The policies appear to come from a few sources. One of them is the many *.policy.xml files (the first part is usually a GUID) in the Windows folder. These files are locked in ROM, and define the core system policies (system accounts, permissions for system objects, etc.). The \Windows\Security\PolicyCommit.xml file (which is not in ROM, or even marked read-only) appears to be simply the result of merging all these files.
Another source of policies must be the application installer. Application-specific polices are not present in the PolicyCommit.xml merged file, but are in the database itself. It is reasonable to expect that they are created and removed by the package manager. This is a good sign for being able to modify policies ourselves.
The initial creation of the policy files appears to be up to a program, \Windows\PolicyLoader.exe. This program takes policy.xml files, merges them, and produces the merged result file and the policy database(s?). It's even possible to run it, given sufficient permissions. Unfortunately, it seems unable to modify the policies on a running device, and is believed to only run at first boot (or after a hard reset) or when an update CAB installs new policy XML files.
EDIT: Attaching the \Windows\Security\*.xml files from my phone, along with the decompiled source for PolicyLoader that was posted on the other thread.
The LG MFG app has a section for editing certain security policies. I can post the info from there, if it'd be of any help. By the way, it specifically says "Edit security policy through registry" so it might not be the same policies that you're talking about, I don't know.
EDIT: Actually, looks like those policies are a subset of the ones listed here: http://msdn.microsoft.com/en-us/library/bb416355.aspx
Analysis of the policy database
I wrote a function to dump the policy database to a text file (with inevitably some embedded binary). Each record in the database has four fields. I'll do my best to describe them below.
1) The first is a DATETIME struct (two 32-bit integers). This is the only 64-bit numerical type available except for a DOUBLE, so it might be selected just as a convenient way to store that many bits rather than because it's actually a date and time. In particular, when I converted them to actual dates and times, the years ranged from the 1970s well into future centuries... this seems an unlikely candidate for an actual set of dates.
What I think it actually is, is some kind of hash of the second field. It might be the index bits for the bloom filter, for example. The reason I think so is that, when there are multiple records with the same value in the second field, they also have the same value in this field, but even a slight difference in the value of the second field results in a very different first field.
This field is not unique, but it does appear to be the default sort order for the database. I don't know if that's ust because it's the first field, but it would make sense to have it be indexed using this field for fast lookup (binary search) after the bloom filter finds that the item is (probably) present.
2) This field is a binary BLOB struct (a size and a pointer). This field contains Unicode strings, sometimes with a bit of binary data (small, typically less than 20 bytes) tacked on the end. Strings plural; each one is NULL-character terminated.
This field appears to be the paths that indicate the object (or objects, since it can contain wildcards) that the policy applies to. If there is a policy in the XML for ResourceIri="/REGISTRY/HKLM/SOFTWARE/MICROSOFT/CAMERA/READWRITESETTINGS" then there will be a record in the database with the second field that would be written like this in C source code: L"REGISTRY\0HKLM\0SOFTWARE\0MICROSOFT\0CAMERA\0READWRITESETTINGS\0". I'm not sure what the occasional binary afterwards means, although there appears to be a specific value for a wildcard (represented in the source XML as ResourceIri=/PATH/WILDCARD/BASE/(*)", but the last part doesn't translate to Unicade the way you'd expect).
As mentioned above, I'm pretty sure that the first field is related to this one. Since the value of a bloom filter on this database would be to quickly establish "Is there a policy for this object?" it makes sense that the path (second field) is the data that gets hashed to produce the bits of the key. It's not really required to then store the key bits, but they make a reasoanble value to sort on.
3) The third field is also a binary BLOB, but the value of it is much more opaque. Typically in the range of 50-300 bytes in length, there are certain patterns that I've noticed within it (0x01 00 01/02 00 65 is a common prefix, and they typically end with 0x00 3X) but I have not yet determined what they actually represent.
Some logical possibilities are an account identifier (though that seems needlessly long for such a purpose) or possibly the permissions data directly. When the second field has a path to related objects (for example, the isolated storage of an application), the third field is often similar as well.
4) The fourth field is another DATETIME struct, but in this case is obviously not an actual date value. The high four bytes are (almost?) always 0xFFFFFFFC, and the low four bytes are typically 0x0000XXXX where the Xs can be anything. This value is not unique - there are numerous instances of 0xFFFFFFFC00000001, for example - but I'm not yet sure what it is.
The same guesses I offered for field 3 apply as well, with the caveat that it's probably not just a different representation of field 3 because two records can have the same value on field 4, and their field three values may not only differ, but be different sizes. I need to look at the XML files and see if there's a pattern between policies with the same field 4 and an equivalent data item in the XML.
I'm attaching the dump file I created of the policy database. It's best opened in a hex editor (Visual Studio does well enough) although you can also use Wordpad (Notepad won't respect the line endings). Wordpad can't show you the binary, of course, but it's a readable layout of the data.
The format is as follows:
ASCII string: "Index "
ASCII representation of an Integer for the index.
ASCII string: ": Prop0 (FILETIME): 0x"
ASCII representation of the DateTime, with a space between the high and low DWORDs.
ASCII string: " | Prop1 (BLOB, "
ASCII representation of the blob's integer size.
ASCII string: " bytes): "
Direct dump of the second field's BLOB buffer (multiple UNICODE strings).
ASCII string: " | Prop2 (BLOB, "
... and so on. I intentionally used ASCII to make the direct memory dumps, which are in UNICODE for the second field at least, stand out.
@Arktronic: Interesting. Those policies (in the registry) are a legacy holdover from WinMo, and at least some of them have been superceded by the new policy system, but the fact that LG gave them specific mention in their app suggests that they still have some relevance.
However, you're correct that those aren't the policies I was speaking of elsewhere in the thread. It may be a good idea to explore them both in parallel, though. Which ones does the LG app list?
Arktronic said:
The LG MFG app has a section for editing certain security policies. I can post the info from there, if it'd be of any help. By the way, it specifically says "Edit security policy through registry" so it might not be the same policies that you're talking about, I don't know.
EDIT: Actually, looks like those policies are a subset of the ones listed here: http://msdn.microsoft.com/en-us/library/bb416355.aspx
Click to expand...
Click to collapse
We already did some testing with those policy settings, but the ones granting more access were not available and the others could not get the app itself into an "unsafe" mode. But then again, I'm far from a professional when it comes down to these things, I just crossreferenced them all against the MSDN DB and looked for the ones that would make fileops possible, no luck.
I'm not sure if they added policies to the LG MFG app in the meanwhile (unlikely) but it might be worth it to investigate how the MFG app modifies those select policies.
GoodDayToDie said:
@Arktronic: Interesting. Those policies (in the registry) are a legacy holdover from WinMo, and at least some of them have been superceded by the new policy system, but the fact that LG gave them specific mention in their app suggests that they still have some relevance.
However, you're correct that those aren't the policies I was speaking of elsewhere in the thread. It may be a good idea to explore them both in parallel, though. Which ones does the LG app list?
Click to expand...
Click to collapse
The latest ROM's MFG app has the following policy IDs: 4104, 4105, 4108, 4109, 4110, 4111, 4113, 4119, 4120, 4121, 4124, 4131, 4132, 4141, 4142, 4143, and 4149.
The last one isn't in the MSDN doc; it calls itself "FIPS Self Test Policy" or SECPOLICY_FIPS_SELF_TESTS.
There are potentially useful things like SECPOLICY_OTAPROVISIONING (4111), which has the value of 3732 - no idea which flag(s) that represents - but if there's a way to send provisioning messages to WP7, that might open up quite a few possibilities.
I believe there's at least a chance for OTA provisioning. Sending custom SMS appears to be possible (click around from the link):
http://msdn.microsoft.com/en-us/library/ee498239.aspx
That said, it's almsot certainly either secured or disabled by default.
Hmm... does anybody want to take a shot at getting a decent decompile of lvmod.dll? I don't have the tools, though I probably should. Reading the disassembly is slow and painful.
I've found a few new things:
It's possible for two records to differ *only* on the third field, and even then the binary was more alike than not. Look at indexes 12 and 13 in the dump - they're really similar. They are built from the following policy rules (no promises on order):
Code:
<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/REGISTRY/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="TCB can do anything to all registry keys">
<Authorize>
<Match AccountId="S-1-5-112-0-0X02" AuthorizationIds="KEY_ALL_ACCESS, KEY_READ, KEY_WRITE, KEY_EXECUTE, GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL, DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER, SYNCHRONIZE, STANDARD_RIGHTS_REQUIRED, SPECIFIC_RIGHTS_ALL, ALL_ACCESS" />
</Authorize>
</Rule>
Code:
<Rule PriorityCategoryId="PRIORITY_LOW" ResourceIri="/REGISTRY/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="Catch all rule to allow Normal and above apps to read/write to all unnamed keys">
<Authorize>
<Match AccountId="S-1-5-112-0-0X23" AuthorizationIds="KEY_ALL_ACCESS, KEY_READ, KEY_WRITE, KEY_EXECUTE" />
</Authorize>
</Rule>
I would have thought that either the different permissions being granted, or the different accounts they were granted to, would result in a different fourth field... but no such luck. Time to look into this further.
The accountdb.vol file has two databases in it, GroupMemberships (1105 records on my phone) and Accounts (291 records). The latter is actually much bigger in terms of data size, though - 70KB vs 31KB for GroupMemberships. The records in GM must be very small, probably just pair mappings.
Hey GoodDayToDie,
Awesome job on sharing all this low level findings from underneat the hood of my favourite mobile OS. While i'm not capable of researching this myself due to lack of knowledge I love to read about how you (and other well known WP7 hackers as well of course!!) tackle the security and are willing to share this with the community to combine power. I think threads such as these are really necessary to get to the finish. Keep up the good work, i've got a strong feeling we will get there eventually .
THANKS
Looks to me like this is the policy database.
Here is an example set of policies that enable/disable tethering on the Arrive.
Is shows the values needed to create/add a policy to the policy database. HTClv.dll shoudl be able do set/modify these values using "LVModProvisionSecurityForApplication"
You may already know this, but figured I would share.
Also, HTC has regedit.exe and HTC uses it to provision/make registry changes.
I will attach the regedit4 file HTC uses to configure the radios.
This also defines where the key UserProcGroup defines the TCB chamber a driver runs under. see... "UserProcGroup"=dword:5 ; TCB chamber
Seems with using the registry editor, we could elevate any driver to the Kernel chamber.
See attached....
Thanks for the info Paul!
I've heard of the "LVModProvisionSecurityForApplication" API before, yes, and it might be possible to use it here (*really* depends on how it works; if it just reads the app's manifest file like the normal XAP installer does, that's not very useful). LVModAuthenticateFile, LVModRouting, and LVModAuthorize may be extremely useful, though. It also might be helpful to try reverse-engineering how it interacts with the policy database.
The weird thing is, I don't have any htclv.dll or htcpl.dll on my phone, at least not in the \Windows folder. Perhaps they were removed in an older firmware update? It certainly sounds like they would provide the APIs I need - only for HTC phones, true, but they would provide.
The policy.xml file is the standard format read by PolicyLoader.exe, but that doesn't really help unless I can convince PolicyLoader to modify the ploicy database on a running phone.
Elevating an (already installed) driver to TCB might be useful (although I'm not certain that LVMod route-to-chamber rules wouldn't interfere) but all the useful HTC drivers are already in TCB, and installing any more drivers... well, I haven't been able to make that work yet, even old versions of official drivers with the necessary changes to the DllName in the registry.
It's really too bad you can't join in on hacking this stuff though, you've got the right ideas. Do you by any chance have a NoDo restore point you could downgrade to in order to try out some stuff on the old firmware?
Dumped the account database
Turns out the account info is quite straightforward. There are four fields per record.
0) String - the SID ("S-1-5-112-0-0X10-0X00000024").
1) Int32 - 0 for accounts, 1 for groups.
2) Int32 - always 0 on my phone.
3) String - account or group name ("TCB" or "ID_CAP_FILEVIEWER:Capability for hybrid file view app such as PDF reader etc." or "Settings3.exe Chamber" or "9BFACECD-C655-4E5B-B024-1E6C2A7456AC").
Not sure why the third field is there if it's always 0, but OK. The first and last were obvious, and the second was easy to infer. The last record has no fields, and the three immediately before it are without a fourth field; not sure why. All three are groups, and their SIDs are:
S-1-5-112-700-4160
S-1-5-112-700-5132A485-ADEE-5842-9490-856FFFFF2D6D
S-1-5-112-700-A22CF327-25C3-DB2A-A8DF-7BE586F11FBD
This database contained no binary blobs, so the dump file is plain ASCII text (the strings were originally Unicode but converted to ASCII gracefully). In the interest of making it easier to analyze, I ran a quick pass over the dump with sed and produced a CSV, which is attached.
Then, there's the GroupMemberships database. I think this one is probably less important for our concerns, but I wanted to take a look anyhow. It's the simplest so far, though that's not necessarily good. Each record has two fields, and both are just 32-bit ints.
0) Ranges from 0x30000006 to 0x3F0004A6, though the the third through fifth hex digits are always 0. Includes duplicates.
1) Ranges from 0x31000008 to 0x3100007A, then from 0x32000380 to 0x3200038C. Includes duplicates.
The mappings appear to be many-to-many (each account in multiple groups, each group holding multiple accounts) as expected. I'm guessing the first column is accounts and groups, and the second is the groups that the account or group belongs to. Given that some values appear in both columns (through in different records), I'm guessing nesting of groups is allowed.
I dumped and CSV-d this database, and it is attached as well. Ideas as to what's up with it are welcome too.