Related
I need (or in fact, we all need...) someone that can read and write to the registry and send SMS messages in C++. (A code example for sending SMS is here)
The objective here is to create a program which we can include in the ROMkitchen and which will allow for theft-protection of the device. Basically when you select this option, you enter the GSM number of a friend and your name at the time you create the ROM. The device regularly checks whether your name still appears in the Owner Information. If not, it sends an SMS to your friend, including the new owner info, and then it is silent until the Owner Information changes again.
More formally:
Code:
Loop forever
SLEEP 1 hour
IF reg-key '\HKEY_CURRENT_USER\ControlPanel\Owner'
value 'Owner' != reg-key '\HKEY_CURRENT_USER\
Software\XDA-developers\IIWPO' value 'LastOwner'
THEN
COPY 'Owner' to 'LastOwner' (See above)
IF value 'Owner' doesn't contain the string
held in '\HKEY_CURRENT_USER\Software\
XDA-developers\IIWPO' value 'Name' THEN
Send data from Owner field above
via SMS to number held in '[...]IIWPO'
value 'Number' (REG_SZ)
Only slightly complicating factor is that the 'Owner' field is a binary field holding unicode, and that I'd like the 'Name' field in our own entry to be REG_SZ because ROMkitchen does that without hassle. But otherwise this is all pretty straightforward.
Because our IIWPO (which, by the way, stands for 'Interesting Interaction With Previous Owner') program is meant to be in 'Startup', it would be nice if memory footprint was as small as possible. Since it's going to sleep most of the time, performance should be unaffected no matter what.
The sleep is at the beginning so that you have one hour after a cold boot to set your name before it starts sending the SMS.
Ofcourse everyone that has read this could change the registry. We're assuming for a moment that it's much more likely that your phone will be stolen by someone that didn't read this. A little Security By Obscurity never hurt anyone.
I just wonder
very interesting concept, very...
I can code this feature easy, but I just wonder: what to say, if your stoles device will stay hundreds kilometers away from you a few days later? ask the new owner to mail it to you?
hmmm? maybe it is worth?
improve the concept
I have an idea to improve the above concept:
1. we can save the original owner and "sms to send" number in the random generated register key, encrypted binary - it will be hard to find and delete for most of users
2. we provide a shortcut to the application allows the oroginal user to run it and type the name and the above number and save
3. after the above point 2 happen once, the shortcut and even the application are deleting completely, so nobody can do that again
the quextion is:
the execute part of the application: to check the current name and eventually send the sms, have to be placed in the Startup folder to run after the reset. How to hide this shortcut?
Re: improve the concept
JGUI said:
1. we can save the original owner and "sms to send" number in the random generated register key, encrypted binary - it will be hard to find and delete for most of users
Click to expand...
Click to collapse
Nice idea: but any thief that knows about this danger will just cook themselves a new ROM and install it.
2. we provide a shortcut to the application allows the original user to run it and type the name and the above number and save
Click to expand...
Click to collapse
Why not just do it in the ROMkitchen?
And besides, it already done: a kind gentleman by the name of Charles Warner has written the app, and it'll be in the ROMkitchen later today, hopefully...
When loading user setting from a file, it stores the values to 3 arrays within the "io profiles" class. the command that loads the data from the file is run through the command "public void Load(int profile)" in the same classes as the 3 arrays. In the LoadScreen form, there is a for loop which collects profiles form the txt file, make a new sealed class, retrieves data from the "io profiles" class, stores the information in the newly made class, and finally stores the class to a block in the hashtable. through each loop, there is a int PIndex which increments and is used as the key for the hashtable.
my problem is that through each loop after it loads the specific profile and leaves the scope of the "io profile" class, it changes the same variable name in all the hashtable items. there is 6 items in the class that is stored to the hashtable and its always the same variable that gets changed "string[] DateTime". i tried making it a int[] like the others, but the same problem was there. stepping through the code didn't show the problem ether. i was recommended by a friend to use Dictionary<K,V> instead, but the same problem existed.
looking online doesn't seem to mention anything about the problem and I'm VERY tempted to complain to microsoft. this isn't the first glitch ive had with the program. I'm using 32bit Visual Studio 2008 on XP: Media Center SP2. im very unsure if its a problem with the program. the problems seem to be specifically related to certain things which are un-related
if you would like to try to code yourself or see cliplets of the code, reply saying you could help and wish to see the code. any help is welcomed
Hi all.
This is a little collection of things that i have been noticing while testing hacking issues on the phone.
Remember that those are "non-useful" (not to jailbreak) the phone, and just curiousity as topic.
Easy Hidden Menu Call
Do you need a search on the net to remember the hidden menu code? No more!. Test this phone-number string instead:
(Edited now): ##PROGRAMNITT
Max size for an app name/web favorite
Seems to be no max per se, but after doing some test, where i created title as: "chunk1chunk2chunk......chunkN" i was able to load a 1691124 characters title. Further than that, the browser seems to crash.
That's about a 3MB text string, just for the title. Would work well, when testing if several of them pinned reduce our 8gb storage(use storage) or doesn't (uses other).
Btw, you can pip up to 67 apps, (51 new) so... that's a max anyway,
Application Menu "About:blank" hack
Test this in the browser bar as direction: "about:blank". Kin IE will yell that it's not a supported protocol. Yeah, that's right. Let's dev a page on a local webserver with:
PHP:
<html>
<head>
<title>Mad redirection!</title>
</head>
<body>
<h3>Mad redirection tool!</h3>
<p> Testing: <div id="testTab"></div></p>
<p> Errors:
<div id="errorsTab"></div>
</p>
<script type="text/javascript">
var urlToTest = "about:blank";
try {
var test = document.getElementById("testTab");
test.innerHTML = urlToTest;
window.location=urlToTest;
}
catch (error) {
var err = document.getElementById("errorsTab");
err.innerHTML = "Error going to " +urlToTest+"<br/>"+error.message;
}
</script>
</body>
</html>
Browse it with the kin and you will land in the about:blank page, with the ability to be pinned on the application menu. Of course it will work, having the App link on the App menu, with a non working link (Kin still yells if you use it from menu).
Useless, but weird...
I do know that this is pure thread necromancy and that those are old news but:
a) if you are able to do the trick (using the sample html i posted) you can see that indeed it comes to about:blank and is shown as that on the title: "ABOUT:BLANK".
b) if you are so smart to change it to "about:lame" it goes there but shows a "Action canceled" webpage, where it suggest you to press the "refresh" button or use menu opcion "File -> work offline".
Like if you could.. rofl.
That means:
1) "about:" protocol is supported (at least about:blank) to be navigated BUT is nerfed from the direction bar. So other protocols could work. For example, smtp and ftp does trigger a popup from the IE, but res:// file:// and rtsp:// do not (even if they crash later, and rtsp opening zune for streaming).
2) This is a pure IE (with file menu,hopefully )
3) some other things can be tested, and every person can!
I upgraded the posted code, so it outputs an error when the redirection doesnt work (almost allways).
If you try it, remember not to end your url with \ (backslash) as it interferes with the doublequotes.
I've just completed testing a couple of things.
First, I successfully tested the "about:blank".
I also tried "about:", "about:about", "about:cache", and "about:home". These each resulted in the action canceled page described above.
I also tried the "file://" protocol, with the address "file://localhost/c:/" and received the following:
Errors:
Error going to file://localhost/c:/
Could not complete the operation due to error 80070005.
[edit] It seems that error 80070005 is given when you do not permission. The solution? Log on with administrator privileges... (see link)
Upon further testing:
about:desktopitemnavigationfailure works and displays "navigation cancelled" page.
about:navigationcanceled works and displays "navigation cancelled" page.
about:navigationfailure works and displays "navigation cancelled" page.
about:noadd-ons displays "navigation cancelled" page.
about: offlineinformation works and informs the user that the current page can not be viewed off line.
about: postnotcached works and informs the user that to refresh the current page, information entered in a form will have to be re-posted.
about:securityrisk displays "navigation cancelled" page.
about:tabs (unsuprisingly) displays "navigation cancelled" page.
I read that about:mozilla works in older versions of IE. However, it displayed the "navigation cancelled" page. You can also supposedly access the about:mozilla page using the following URL: res://mshtml.dll/about.moz
However, while this "res" protocol appears to be supported, I received the same permissions error as referenced in the above post.
I tested the mms protocol on a couple of working mms streams, but received the notification that the protocol is not supported.
I tried view-source://(random web address) and unsuprisingly was told that the protocol isn't supported. While this protocol works with some browsers, it doesn't seem to work on internet explorer even on a regular computer.
I tried the javascript protocol and it seems to work, but is different than about:, http:, etc. Mainly, it processes the javascript without leaving the script "address" in the address bar like we see with about: and http:
I was a little disappointed in this one, hoping to bookmark a javascript to test the videohamster flash video viewer for ipods, or itransmogrify for other flash files.
very nice work here. I like what you have done with this.
I'm glad that other than about:blank works (apart of the "action cancelled").
I took my time to install a wm6.5 emulator and test where do this "Action cancelled" come from in the pocket IE url bar.
They are from " res://.....navcancl.dll ".
Maybe there's a way to bypass the restrictions (the permission error) by calling some parameter in the "about:XXXX", but i can't bet on it.
Edit:
about:version seems to work (it auto-says "cannot find server", although my python custom-made-for-exploits server says that it delivered my html). But it keeps loading after the javascript redirection happens.... lol, so random .
One thought I had, that I have not had time to experiment with yet, is how deep the permissions restrictions go. For example, at times I have been logged on to a windows-based computer and have access to certain user-specific files but not to system files or to files or folders closer to the root. So for instance, we may be able to access the WinCE equivalent of "C:\Documents and Settings\<UserName>" using the file:// or res:// protocols even though we don't have permission to access "C:\".
Here's another potential avenue for information related to the "res" protocol. Apparently, it can be used to enumerate the software on a machine by identifying certain executables or dlls. (see here).
Unfortunately, the example cited in the article is not available so I can't view the code on how it was done. However, the results can be viewed here, where incidentally you can see the software installed on the computer that crawled this webpage.
Luckily, a manual or how-to paper is available here. I will try to check it out and see if I can figure out something useful.
i checked, it doesnt yell at you if you use a res:// but either if using ftp:// so the big problem is that you must pre-know the res:// uri before testing.
And in the best case, you will just get an image shown, ad js cannot give you the binary data.
anyway, i'm interested in this things....
Here's a couple other likely non-useful tidbits.
The browser will attempt to open the following filetypes with the Zune player:
.avi
.3gp
.mov
.fli
.mp4
.wmv
.wmx
When you open a VBScript in the browser, the script isn't executed, but it is displayed.
The mailto: protocol works from the browser and opens up the email dialog.
The following script causes the browser to hang (and deleting temporary files does not resolve the problem--but restarting the Kin does):
HTML:
<html><body onLoad=Demo()><script>
// MoBB Demonstration
function Demo() {
var a = new ActiveXObject("Internet.HHCtrl.1");
var b = unescape("XXXX");
while (b.length < 256) b += b;
for (var i=0; i<4096; i++) {
a['Image'] = b + "";
}
}
</script>
</body></html>
I haven't played around with the logs at all, but would this provide an error that gives some useful log output?
After some further testing, I discovered the Kin does not yell about the following protocols as being unsupported (in other words, they seem to be supported):
gopher://
nntp://
telnet://
news://
snews://
windowsmail.url.mailto://
windowsmail.url.news://
windowsmail.url.nntp://
windowsmail.url.snews://
johnkussack said:
Maybe there's a way to bypass the restrictions (the permission error) by calling some parameter in the "about:XXXX", but i can't bet on it.
Click to expand...
Click to collapse
I tried playing around with about:____, such as with the following types of addresses:
about:<input%20type=file>
about:<a%20href=C:\windows\>Click-Here</a>
but without luck.
I also tried the shell handler "Shell:" which seems to be another supported protocol, but again without luck. I tried the following Shell commands:
Shellrofile
ShellrogramFiles
Shell:System
Shell:ControlPanelFolder
Shell:Windows
Shell:::{21EC2020 shell:::{21EC2020-3AEA 3AEA-1069 1069-A2DD A2DD-08002B30309D}
Here are a couple more that I found other people sometimes try that I haven't tried (at least not yet):
shell:ControlPanelFolder
shell:::{35786D3C-B075-49b9-88DD-029876E11C01}
shell:::{208D2C60-3AEA-1069-A2D7-08002B30309D}
shell:::{7007ACC7-3202-11D1-AAD2-00805FC1270E}
shell:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
shell:::{450D8FBA-AD25-11D0-98A8-0800361B1103}
shell:::{E17D4FC0-5564-11D1-83F2-00A0C90DC849}
Ok, so this will be my last post in this thread tonight . For some unknown reason, you can access your emotes when in camera mode.... It doesn't do anything if you try to use one though.
great to hear about the shell::XXXX thing.
Does it trigger something? like about:blank or the other trigger a blank or a "cannot go" page.
btw, a real path on the phone (granted by the logs) is:
\Windows\eri.bin
That's assured , with the start backslash ("\\" if used on js code)
these hacks arent nonuseful
you should have called these hacks something other than non useful because we can use these little tips and tricks in combination with others to actually create an in browser jailbreak using the unrestricted protocols.
shell commands
try the net user admin <username> <password> console command in the shell protocol and see if you an bypass restrictions. theres no reason why console commands shouldnt work even though i havent tried this myself.
X-15D9W8491 said:
try the net user admin <username> <password> console command in the shell protocol and see if you an bypass restrictions. theres no reason why console commands shouldnt work even though i havent tried this myself.
Click to expand...
Click to collapse
Sorry, I'm not sure where you mean to do this. Unless I completely missed the revelation, so far, nobody has been able to get any type of shell/console access (as it doesn't really exist on a Windows Mobile OS anyway).
i called them as is, cause in first place, they were non useful, lol.
Although now, it could be a good try to get some "jailbreak" procedure.
as we dunno what windows mobile i6 can do, i guess we should/must try into a real mobile device (maybe my old pda too), or a win mobile 6.5 emulator, to test procedures (less restrictions), and then repeat on the kin (restricted).
I always though that the browser was the weakest part anyway
if you do tel: in the browser, and write anything after that it opens it up in a bubble....it lets you call letters, although it gives an error in the phone app
When using the TRACERT (Trace Route) in the programnitt menu I found a quirk.
Using 127.0.0.1 to Trace replies: WindowsCE
...that's obvious but interesting.
Using 127.0.0.0 to Trace replies: * 87 (30 times, hits limit and stops)
I have no idea why it would reply with the voicemail number....
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.
I have a PhoneGap application designed to work on multiple mobile platforms. I'm loading a dynamic HTML content from an external page on the Internet using jQuery Mobile. The problematic system is Windows Phone 7.
This is what I get from the external page, with the URL of the script tag already replaced to load from the phone instead of from the net to save bandwidth:
HTML:
<script type="text/javascript" charset="utf-8" src="x-wmapp1:/app/www/test.js"></script>
This works fine on Android, iPhone and even BlackBerry when I replaced the x-wmapp1: part by a respective counterpart (e.g. file:///android_asset/www/ on Android). However, on Windows Phone 7 it doesn't seem to work at all.
When I try to load the same URL via $.getScript function, it always returns a 404 eror, even if I try and load it with a relative path only.
Any suggestions?
First of all, this type of question may be better suited to the Software Development or Apps and Games sub-forums, as a lot of the people who hang out here are more familiar with homebrew hacks. I'll give it a shot, though.
First of all, what kind of path are you trying to use? I haven't tried loading scripts or images in HTML or JS, but to dynamically load content within the app itself typically requires some care with regard to the path. For example, is the JS file being built into the assembly (as a resource) or included alongside it (as content)? How about the HTML page?
This is a kind of lame approach, but one option that's sure to work is just inlining the scripts in the page, directly. That won't increase the total app size or load time at all, although it might make maintaining the app take a little bit more effort.
Thanks for the reply, I will try to post this into the more appropriate forum.
With regards to paths - you can see the path in the HTML snippet I provided in the original question. It's all a bit specific and we cannot afford to load JS directly from page, since that does increase the size of the resulting HTML, sent from an external PHP page, thus increasing bandwidth. This is the first reason why we chose to have all JS and CSS files directly bundled with the application and load them internally rather than from Internet.
Also, all of JS files are included alongside the application as content. I'm using the same approach for all images, since if they were included as a resource, they would not show in the application.
GoodDayToDie said:
First of all, this type of question may be better suited to the Software Development or Apps and Games sub-forums, as a lot of the people who hang out here are more familiar with homebrew hacks. I'll give it a shot, though.
First of all, what kind of path are you trying to use? I haven't tried loading scripts or images in HTML or JS, but to dynamically load content within the app itself typically requires some care with regard to the path. For example, is the JS file being built into the assembly (as a resource) or included alongside it (as content)? How about the HTML page?
This is a kind of lame approach, but one option that's sure to work is just inlining the scripts in the page, directly. That won't increase the total app size or load time at all, although it might make maintaining the app take a little bit more effort.
Click to expand...
Click to collapse
First question: have you set the IsScriptEnabled proerty on the control to True? It defaults to False, preventing scripting within the control. Also, changing it only takes effect
on navigation, so if you already loaded the page and then set this property, it still won't work.
Anyhow, I missed that your HTML was coming externally, and only the scripts and stylesheets were local. That's... interesting, and seems reasonable enough, and I can't find any info online that exactly matches your use case. The way you're structuring the script src URI looks weird to me, but I haven't messed with the WebBrowserControl very much at all.
One solution, though a bit hacky:
Use the WebBrowserControl's InvokeScript function to dynamically load scripts into your pages. To do this, you would first need to load the script file content into a .NET String object. The GetResourceStream function is probably your best friend here, combined with ReadToEnd(). Then, just invoke the eval() JS function, which should be built-in, and pass it the JS file content. That will load the JS into the web page, creating objects (including functions) and executing instructions as the files are eval()ed.
Of course, you'd need to do this on every page navigation, but you can actually automate it such that the page itself requests that the app load those scripts. In your app, bind the script-loading function to the ScriptNotify event handler, probably with some parameter such as the name of the script to load. Then, on each page served from your server to the app, instead of including standard <script src=...> tags, use <script>window.external.notify('load localscript1.js')</script> and so on; this will trigger the app's ScriptNotify function for you.
I hope that helps. I can see your use case, but somewhat surprisingly, I couldn't find anybody else online who had either run into your problem or written a tutorial on doing it your way.
Thank you for your reply, it was very informative. One question though - why do you think the way I'm structuring the SCRIPT URI is wierd? I tried to mess around with relative URIs and the such, however those would load the JavaScript file from Internet rather than from the application itself.
The problem I'm running into with your proposed solutions, however is that:
1. the project is a PhoneGap/Cordova application, using its own components, so I have no idea where I would look for IsScriptEnabled here (although this all worked on an older PhoneGap release, so I'm guessing they have it set up correctly)
2. injecting a script programmatically on each navigation would require me to rewrite much of the code we already use for other platforms, not to mention those custom Cordova components, which I don't even know if they can handle such thing
As for my user case - I was surprised to be the only guy on the internet with this methodology in place as well. So it either works for everyone else or nobody really thought of doing it my way, since it's basically an Internet application (maybe the don't want to disclose their sources, who knows).
CyberGhost636 said:
1. the project is a PhoneGap/Cordova application, using its own components, so I have no idea where I would look for IsScriptEnabled here (although this all worked on an older PhoneGap release, so I'm guessing they have it set up correctly)
Click to expand...
Click to collapse
In the WebBrowser properties.
CyberGhost636 said:
As for my user case - I was surprised to be the only guy on the internet with this methodology in place as well.
Click to expand...
Click to collapse
Of course you not "the only guy". I've tried to port/run a few HTML java-script based games on WP7 (Digger and couple more) more then year ago; they runs well with one HUGE exception - touch screen events are freezing scripts execution and make games not playable.
The "x-wmapp1:" URI scheme was what I was referring to. Not sure where that comes from, but I haven't done anything really with the WebBrowser control.
I have no knowledge of PhoneGap or Cordova; I assume they're "we write your app for you" frameworks? One would assume that such tools would know to set IsScriptEnabled, but you may have to do so manually. A bit of web searching on that direction may be fruitful - maybe earlier versions enabled scripting by default, and now it's disabled by default so you have to specify an option somewhere?
Injecting the script on navigation really doesn't require any major change to the server-side code. I mean, is sending
<script>window.external.notify('load localscript1.js')</script>
really much different from sending
<script type="text/javascript" charset="utf-8" src="x-wmapp1:/app/www/test.js"></script>
? If that's too different, you could instead send
<script src="http://yourserver.com/LoadLocalScripts.js"></script>
and put "LoadLocalScripts.js" on your server with the following code:
window.external.notify('load localscript1.js');
This has only a trivial increase in server traffic and load time, but lets you continue using external scripts instead of inline ones. Very little server-side change needed at all.
Now, the additional client-side code to support the window.external.notify and call InvokeScript... normally I'd say that's dead easy, because it is if you have any experience with the .NET framework, but in your case I get the feeling that this isn't so? I code to the framework, or to the underlying native code, and I tend to code "raw" (very little auto-generated code), so I'm not going to be able to help you solve the problems with a "make me an app" wizard unless I can see the code it generates for you.
For what it's worth, here's the approximate raw code that I'd use (it's over-simplified, but close enough):
void HandleNotify (String param) {
String[] parts = param.split(" ");
if (parts[0] == "load") LoadScript(parts[1]);
}
void LoadScript (String script) {
String content = Application.GetResourceStream(new Uri(script, UriType.Absolute)).ReadToEnd();
theBrowserControl.InvokeScript("eval", content);
}
void theBrowserControl_Loaded (...event handler args here...) {
theBrowserControl.IsScriptEnabled = true;
theBrowserControl.ScriptNotify += HandleNotify;
theBrowserControl.Navigate("http://yoursite.com");
}
the URI comes from Windows Phone itself, with this code, you can see for yourself:
var a = document.createElement('a');
a.setAttribute('href', '.');
alert(a.href);
also, I've been informed that this works in Cordova 2.0, so it might be a 1.8.1 bug... will try and see how it goes
thanks for your help so far!
Looks like it was a problem with PhoneGap 1.8.1 - after upgading to Cordova 2.0 (PhoneGap got renamed) it all works now... thanks for all the help!