Related
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
I am working on TCMD equivalent for Windows Phone. It may be:
Two-panel filemanager,
SMS and Mail configurator (groups, searching, backup),
Registry editor (editing, export, import),
Taskmanager (working apps dehydrating, resuming, closing, memory increasing),
Tiles configurator (creating, grouping),
MultiMedia manager (searching, playing etc.),
Applications configurator (uninstalling, grouping),
Keyboard Shortcuts configurator (HTC 7 Pro, Gold, Prime),
and another next by plugins system.
It will use direct access for unlocked ROMs, HtcRoot project (http://forum.xda-developers.com/showthread.php?t=1453343) for full access on (dev and) InterOP unlocked devices (where it is possible), ProvXML method for incompatible devices.
There is first screenshot:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Try it, post experiences. This is designed for HTC7Pro hardware keyboard, but must be usable for touch conntrolling too. For big dirrectories (\Windows etc.) scrollbars are necessary. I want to have as far as possible biggest amount of controls on main screen. It may not be a game, it must be working tool. In long future I want integrate also simple programming IDE to this tool.
Newest version will everytime here.
Actual attached version enables for me:
To manage all files very quickly include multioperations (like TotalCmd).
To copy mp3 files to any phone directory by desktop TotalCmd, create playlist on phone and hear music.
To do the same vith movies, photos etc.
To copy e-books from my desktop and read them in phone (formats: doc, RTF - the best reading, pdf etc).
To edit all files in phone (the same formats, include binaries).
To import .reg files to Registry
From version 2.3 added 3s timeout to JPG files shell showing in built-in Pictures application (you can make simple automatic presentation from pictures, videos and sounds in sh file).
Hey man, sounds ambitiously, with the declared functionality it would be a perfect tool Good luck!
I think I will check this out
ap3rus said:
Hey man, sounds ambitiously, with the declared functionality it would be a perfect tool Good luck!
Click to expand...
Click to collapse
I will do, what free time allows me. The rest will simple for everyone, when plugin class interface will good designed (readonly properties top, bottom, size of list, manipulation properties/methods for copying, moving, deleting etc). FilePath (read/write) equivalent can be Group (ringtones, apps) or RegPath (registry), some classes will not allow any part of methods (class Task will not implemented copy and move for taskmanager etc). First I must make spotlessly this data model and user interface, becouse those are the most problematical parts of this app (too small screen, too big area of digit touch etc). My keyboard-only inspiration is very nice FileNote app from S80 Symbian (http://tech.groups.yahoo.com/group/FileNote/messages , http://my-symbian.com/s80/software/applications.php?faq=3&fldAuto=865) , but no everybody has hardware keyboard on WP7. Plugins (libraries) for unique quantities and implementing of any special behaviour (searching, comparing, sending) will secondary parts. The biggest problem is unlocking impossibility for new devices now. M.
Hi Martin,
first look i like your commander.
I will wait next version, good work
Looks *very* cool! Makes me wish my HD7 had a hardware keyboard though; this will be hard enough to use with touch on a 4.3" screen and will be a lot harder on something like the Surround or Trophy. I must admit that the inspiration (two-panel file managers, which date back to at least Midnight Commander and possibly further) appeals strongly to my nerd side.
I'll try my best to make sure that HtcRoot is available for this to use on as many phones as possible (probably all first-gen HTC, second-gen may never be possible without a new exploit).
One suggestion: just make the file lists scrollable using swipes (it's a built-in control that you put the other controls within). The scrollbars take up non-trivial screen space and are actually kind of hard to use with fingers. Also, tapping on "ext" is *way* harder than it looks like it should be; even moving in tiny increments I tend to go from tapping "FileName" to tapping "datetime" directly.
Hi GoodDayToDie. Thanks for your support. My first mind was to use standard WP7 scroll controls. But, there are two reasons to implement own control.
1. amount of files \Windows directory in WP7. I use TouchExplorer every day, but working with \Windows directory is worry in it. Then I need control, which is quicker for big lines ammount (implementable by any part of filenames reading immediatelly and pre-loading some amout to seek in scrolling time).
2. Total commander has very sofisticated file subset signing to select operation set (file can be selected/unselected or to have focus independently). Try select 10 files beginning by diffrent characters in Touchexplorer in \Windows directory and after it try copy one another file. This is operation to 10-15 minutes in TouchExplorer. I do not know, if control behaviour is simply changeable in WP7. I am planning to have one self made control with scrollbars for big directories and one inhereted from WP7 standard with simple changes (if possible) and without scrollbars for small ones. I am low-level C/C++/etc programmer, then I must study Silverlight/C# possibilities first.
i am looking for a function that auto on/off 3G had scheduled times, much like what android apps do
is this possible with yr xap??
Magpir said:
i am looking for a function that auto on/off 3G had scheduled times, much like what android apps do
is this possible with yr xap??
Click to expand...
Click to collapse
Scheduling is in the future plane. I have a lot of to do with higher priority first. I seen any "Tasks" application on MarketPlace for scheduling. Try it, may be it is able to schedule system changing.
Martin7Pro said:
Scheduling is in the future plane. I have a lot of to do with higher priority first. I seen any "Tasks" application on MarketPlace for scheduling. Try it, may be it is able to schedule system changing.
Click to expand...
Click to collapse
those apps in the marketplace only give u a reminder.
i need the app actually disable/enable things at a given time.
GoodDayToDie said:
Looks *very* cool! Makes me wish my HD7 had a hardware keyboard though; this will be hard enough to use with touch on a 4.3" screen and will be a lot harder on something like the Surround or Trophy. I must admit that the inspiration (two-panel file managers, which date back to at least Midnight Commander and possibly further) appeals strongly to my nerd side.
...
Click to expand...
Click to collapse
I have a question:
Normally, in C++, I will make basic plugin class, inheritable to 3rd plugins dlls. When interface will changed in future, I will use multiple inheriting of additional behaviour class, in reverse order for "old generation" plugins.
But, what is the best practice in phone C# ? Multiple interfacing? Or dependency injection is implemented here? I must use something very simply for easy plugins creating. M.
If I understand what you're asking about correctly, multiple interface inheritance is probably your best bet, since .NET doesn't support multiple class inheritance. This usually means you need to have some kind of external factory as well, since interfaces can't have constructors or static methods.
Implementation-wise, one way to do this is to simply wrap the older objects, and pass calls to their interfaces through to them. This isn't ideal and still requires non-trivial coding, but it does provide good encasulation and relatively good code sharing. Dependency injection using Reflection APIs is certainly also possible, but requires some work.
I am "old school" OOP Programmer, then I must study it much. Main problem is: I know interface for files, registry, tasks etc just now. But, application must accept today unknown interfaces in future by little addition only, without recompiling old generation plugins. Then I explain previous question: Are interfaces and namespaces in C# able to solve this problem? To have one interface for today plugins, new interface will added after any months and using one or second automaticly? TotalCommander solves it by different plugins extension (*.wfx , *.wcx etc), but, I mean, it is not right way in 21 century. Second problem is: Every plugin can contain more system access methods (Standard MS WP7 API, ProvXML, your HTCRoot, fiinix's CSharp_DllImport, something new...). Every this method need not be copletely implemented in all plugins, any common base may be stored in one library for each access method and plugins will prepare only parameters for them. When design will the best, old generation plugins can use future access methods too. Access methods can be sorted by priority (probably related to method speed), plugins must use highest method priority, which is allowed on device. If plugin will not know any hi priority access method itself, must automaticly hand over its pursuance to any newer library. What modern method I must study for mentioned behaviour?
Thanks man looks very good
I think that doing this is going to require the use of the Reflection APIs. In essense, these let you load assemblies (collections of classes, typically in namespaces) from .DLL files (by name), and let you load classes from within assemblies, and let you call functions of those classes.
Probably the easiest way to do it is a function pointer table. In .NET, function pointers are called "Delegates" and are technically objects (like everything, including primitive types) but they pretty much work exactly like strongly typed C++ function pointers.
When the app starts up, it looks in a known location (or possibly queries the registry, or something) for DLLs containing extensions. It then loads the assemblies from those DLLs. Each assembly should have a registration function (probably a static method o a static class) that returns a collection of delegates (and their priorities, if needed). Your app then uses those to build a function table that it uses whenever it needs to do a specific type of operation.
For example, you could have one entry in the table for "WriteFile" and might get function pointers for it from one assembly that uses the native APIs with no special permissions (works for some custom ROMs, or after using HtcRoot), one that uses isolated storage APIs (works for any ROM, but only to a specific folder), one that uses HtcFileUtility.dll (the driver that TouchXplorer uses), one that uses ntive APIs but wraps every call in an elevation call to HtcRoot, etc. It would be up to the framework (meaning up to you, if you're designing it) to define some way to indicate which one to use.
All that said, while extensibility is an excellent goal and probably necessary in the long run, you might want to just get a proof-of-concept working that is hard-coded to use a single known approach. Reflection isn't actually that difficult, but it seems like a distraction from getting a first version out the door. Release early, release often, and all that.
I must finish other important work, after any days I will continue here. I will use simpliest way, which coul not be the best, but it will quick and independent. M.
very cool
good luck
Good luck with this app. Please drop me a PM when you finish so that I can feature it on the XDA front page.
Martin7Pro said:
I am working on TCMD equivalent for Windows Phone. It may be:
Two-panel filemanager,
SMS and Mail configurator (groups, searching, backup),
Registry editor (editing, export, import),
Taskmanager (working apps dehydrating, resuming, closing, memory increasing),
Tiles configurator (creating, grouping),
MultiMedia manager (searching, playing etc.),
Applications configurator (uninstalling, grouping),
Keyboard Shortcuts configurator (HTC 7 Pro, Gold, Prime),
and another next by plugins system.
It will use direct access for unlocked ROMs, HtcRoot project (http://forum.xda-developers.com/showthread.php?t=1453343) for full access on (dev and) InterOP unlocked devices (where it is possible), ProvXML method for incompatible devices.
There is first screenshot:
There is also Pre-Alpha User Interface demo only xap.
Try it, post experiences. This is designed for HTC7Pro hardware keyboard, but must be usable for touch conntrolling too. For big dirrectories (\Windows etc.) scrollbars are necessary. I want to have as far as possible biggest amount of controls on main screen. It may not be a game, it must be working tool. In long future I want integrate also simple programming IDE to this tool.
Click to expand...
Click to collapse
Err, why are you using drive letters like C:\? We all know Windows CE doesn't use such things. I think adding artificial drive letter paths will just confuse users in the long run. If they're going to be navigating the filesystem, they might as well learn how to do it right. But if you really must do this, at least make it easily disabled.
Also, are those native Windows CE common controls in the screenshot?
@Martin7Pro: One suggestion: with the semi-imminent release of WP7 Root Tools 0.9, which will allow elevating arbitrary apps (and will support more devices than the HtcRoot project), I suggest you focus on just using native APIs and don't worry about permissions. It will already work on full-unlocked ROMs, it will work on all devices that are supported by WP7 Root Tools once it releases, and it will be easy to add support for HtcRoot if for some reason that saspect of the project is still relevant.
I've got some exciting other directions I want to go with HtcRoot, like seeing whether I can modify ROM files or do other crazy things like that (it might be possible, what with the ability to tweak driver code directly). The elevation to TCB ("Admin") and policy-engine work was (and still is) a stepping stone to get there, but with WP7 Root Tools 0.9 supporting the most important policy engine changes directly, that's less of a concern now.
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.
This was posted (not by me) on the old forums but I want to discuss it over here;
I’ve started to put together a simple widget for calendar events and bumped into the problem that #C0# might have a start date in the past (when that event is just happening). In this case, #C0S# might even be yesterday. I tried to base my script on “R” and “T” parsers, but had to face the fact that these give an absolute value.
As abs() function is available among maths features, while on the other hand generating the positive/negative sign for it with additional calculations is fairly complicated, I’ve been wondering if it would be possible to provide this data in a negative form for past dates.
If there’s a reason for the absolute value, it’d be also a great help to have a simple parser that gives -1 for past dates and 1 for future ones.
A UNIX date parser for #D…# might also come handy and could give a possible workaround, although I’d rather prefer the past-date-parser.
Click to expand...
Click to collapse
My suggestion is to get rid of the absolute value from the "R" and "T" parsers and replace it with negative & positive numbers. Feature request?
I need some help with an app I'm developing. It's a farm/ranch management app that sets notifications in your calendar to remind you to do essential tasks as well as events that should occur on that day (i.e. insert nesting box, kits due today, etc.). I plan on starting with one or two animals and adding updates later to include any animal that might be on a standard farm. I've attached some screens of what I want my design to look like that i made in photoshop below. If anyone has any recommendations as to which coding software I should use or how to implement features I would greatly appreciate it.
mikanike said:
I need some help with an app I'm developing. It's a farm/ranch management app that sets notifications in your calendar to remind you to do essential tasks as well as events that should occur on that day (i.e. insert nesting box, kits due today, etc.). I plan on starting with one or two animals and adding updates later to include any animal that might be on a standard farm. I've attached some screens of what I want my design to look like that i made in photoshop below. If anyone has any recommendations as to which coding software I should use or how to implement features I would greatly appreciate it.
Click to expand...
Click to collapse
In order to better supply an answer, it would be beneficial for me to know your background. Do you have any software development experience? Coding Languages? Etc.
mikanike said:
I need some help with an app I'm developing. It's a farm/ranch management app that sets notifications in your calendar to remind you to do essential tasks as well as events that should occur on that day (i.e. insert nesting box, kits due today, etc.). I plan on starting with one or two animals and adding updates later to include any animal that might be on a standard farm. I've attached some screens of what I want my design to look like that i made in photoshop below. If anyone has any recommendations as to which coding software I should use or how to implement features I would greatly appreciate it.
Click to expand...
Click to collapse
I work for Kinetise.com, which might be just what you need. You can make fully functional apps (including adding items to the user's calendar, which you said you needed) without writing a single line of code, and they are purely native. You can try the editor without even registering (and download an test app on your phone as well, it will just expire in 24 hours if you don't upgrade it), so give it a try.