Related
Hi,
There seems to be a lot on the wiki regarding the handsets, but there doesn't seem to be a lot of information on software for the handsets.
There's the "Must have tools" page, but I personally would appreciate a page listing software by category.
I am therefore proposing to produce a page called "Software" with a list of categories such as
Diary/Calendar
Contacts
File Managers
Games
GUI Enhancement
Instant Messaging/Chat
System Tools
Today
etc.....
Then, each of these pages would have a list of sub categories with software titles listed underneath, so for example "Instant Messaging" would have IM+, Skype, Pocket IRC etc... under it and each of these would then have it's own page on which to include features, details of compatibility with handsets and WM versions and links with where to get them from (possibly even links to related forum topics).
Obviously I will start from my Wizard/Hemes and the software I have used, so I shall apologise for that in advance, but if I start adding this will anyone complain?
Or would it be appreciated?
Any thoughts, comments or ideas (and things I have overlooked, like this existing) are appreciated.
mikechannon said:
One question for you would be whether the software section would be a cross device section or under a specific device eg Hermes or Wizard?
Click to expand...
Click to collapse
Cross device, totally.
The way I look at it is that most of the software is written to work on "Any" WM device so it should therefore be written generically. I'd then try to include a compatibility list of "This software is confirmed (not) working on..." for people to add their devices to as well as notes on how to get it working if their may be trouble.
For example, Skype works on most, but not so well on a Hermes unless you use the beta.
Just wish I knew more about the advanced features on the wiki software xda-devs uses....
Had a play the other day and at least one other person has linked something into it so far...
Games and Emulators page.
Guess we will see how it goes....
I'd love to help, but I'm mainly a MediaWiki guy, is there a list of basic editing procedures and stuff for the software xda-developer wiki uses?
This is a new feature for WP7. An API will be provided for external services to validate that a call is coming from a Genuine Windows Phone. This will be accomplished by a requirement that every phone have a unique certificate applied during manufacturing process (similar to an IMEI, but more than a simple number, an actual .cer)
The certificate is to be stored in the "Device Provisioning Partition" during the manufacturing process and is to be destroyed upon completion of manufacturing. Any time a reflash occurs, a new certificate is to be issued.
This represents a significant change from the existing paradigm as your phone will be instantly uniquely identifiable through this method.
Bump for visibility
Is that going to make flashing custom ROMs an issue?
i think it gonna make flashing difficult..
if you flashed with custom, your WP7 would not be taken as genuine hehehe like Windows 7 lol
maharz said:
i think it gonna make flashing difficult..
if you flashed with custom, your WP7 would not be taken as genuine hehehe like Windows 7 lol
Click to expand...
Click to collapse
lol then you have to mod your bios.
On the bright side, we may have fewer reasons to flash custom ROMs on WP7. What are our current reasons for flashing?
1. We need new OS versions on our devices when OEMs don't provide that. Well, this is supposed to be taken care of by centralized update mechanisms for all devices. WP7 will also support partial updates where you don't have to change everything but rather update certain components. Also, firmware files should be replaceable - otherwise OS updates wouldn't work. We'll be less dependant on HTC or whomever.
2. We need components from other devices (newer versions of Manila etc.). Well, these won't exist anymore.
3. We want light ROMs. WP7 will need things added, not removed, for the most part, and crapware will be very limited.
vangrieg said:
On the bright side, we may have fewer reasons to flash custom ROMs on WP7. What are our current reasons for flashing?
1. We need new OS versions on our devices when OEMs don't provide that. Well, this is supposed to be taken care of by centralized update mechanisms for all devices. WP7 will also support partial updates where you don't have to change everything but rather update certain components. Also, firmware files should be replaceable - otherwise OS updates wouldn't work. We'll be less dependant on HTC or whomever.
2. We need components from other devices (newer versions of Manila etc.). Well, these won't exist anymore.
3. We want light ROMs. WP7 will need things added, not removed, for the most part, and crapware will be very limited.
Click to expand...
Click to collapse
Very true. With the OTA MS updates and such it will make life easier for updating the OS.
That could also bring a pitfall - hacking attempts that once worked get blocked.
Da_G said:
This is a new feature for WP7. An API will be provided for external services to validate that a call is coming from a Genuine Windows Phone. This will be accomplished by a requirement that every phone have a unique certificate applied during manufacturing process (similar to an IMEI, but more than a simple number, an actual .cer)
The certificate is to be stored in the "Device Provisioning Partition" during the manufacturing process and is to be destroyed upon completion of manufacturing. Any time a reflash occurs, a new certificate is to be issued.
This represents a significant change from the existing paradigm as your phone will be instantly uniquely identifiable through this method.
Click to expand...
Click to collapse
1. Project Echelon, lol.
2. End of dev'n'hacking, lol.
(now, remove both lol's)
M$ REALLY thinks it may compete with iphone(and apple stupidity), can you believe...
The "uniquely identifiable phone" feature is probably the major reason for this. Face it, outside of these forums, how many "non-genuine" WM builds are there?
What this provides is a token-pair for secure message encryption and a single point of origin/destination for all those notifications.
Thank you for the information, Da_G.
So it seems this will also affect us being able to port a WM7 ROM to another mobile?
So this means evry phone has a unique certificate
They will look for a way around that. For instance...who's to say microsoft are even implementing the certificate etc on prototypes...that would be darn impractical since there's so much chopping and changing in this developer stage, and do we know the servers are up and running? We should cross this bridge when we/Da_G come to it, and look for a bypass if not.
I do not think this money will be wasted if we dont port it to HD2, the fact is I will be the first to donate when pre-orders for the first HTC WP7 handset is outed so that Da_G can use his tools for that too. The JTAG test point will be useful to the community and I know Da_G will use it for the community...actually there's very little personal stuff he could do, and I doubt he would anyways, since all the uses will be of benefit to the community.
We should definitely start look at alternatives to the marketplace now, like Cydia. I'm not sure how the guy's doing it, whether he has servers etc, whether we could use them for multitasking/social networking or other uses. Depends how far microsoft go. Anyways, we all know that if m$ close it down and we cant jailbreak etc, then the community will have to migrate to android.
if i understand the situtation. If every phone is uniquely identifyable it means that imei may be part of cert calculations which means update code would have to be able to generate a cert or request a cert from the update server.
But if the phone checks the certs validity reverse engineering the check could help us fake cert files
EDIT:
after reading on rom deployment it seems that it cert files would need to be faked in order to port to other phones and updates will also involve trickery of its own
Unless somone does something even more awesome
First I would like to thank the whole forum (with few exceptions that I'd like to not mention here) for the past 2,5 years, which have been very educating for me regarding Windows Mobile as a system. During that whole time I have searched for the perfect simple-to-use, lightweight app for storing and retrieving a grocery list, yet unfortunately I have had to come to the conclusion that it does not exist to this date. There are some existing apps but these are either not simple to use or do not accomplish the simple task at all, or they are too heavy (requiring additionally the .NET framework to be installed for example, etc.).
The idea for the simple software is that one has a changeable groups and items of groceries, from which they can select the already saved ones needed at that shopping day (e.g. during a discussion with girlfriend), and later when in shop they can just check the ones they have already put into basket. I would like to see the person who will argue that it does not easily beat archaic mode of storing information, a.k.a. paper and pen.
I have found an app which, with some relatively small amount of effort can be rewritten to accomplish that task, this software is iContact AE. As far as I understand, there is judicially no problem using the source code from iContact AE as long as following the license restrictions (correct me please if I am wrong). Why AE? Just a selection based on the fact that AE has the most appealing interface and most settings. Of course, this could be a point of discussion, but so far it seems like the best choice.
CAB - http://icontactae.codeplex.com/releases/view/28951
Source - http://icontactae.codeplex.com/SourceControl/list/changesets
I created a possible, chronological tasklist in order to get from iContact AE to the shopping app, whatever it will be called (name suggestions also welcome in due time). Also, I already have a pretty clear vision about
Discuss the usability and feasibility of the selected software / it's source code and it's alternatives (as far as I remember there was the original iContact and some other derivate version).
[*]Create, discuss and review static prototypes of the interface (basically screenshots of each view).
[*]List the requirements to be implemented (or removed).
[*]Code in / remove code according the list from previous task.
[*]Create skin and graphics.
[*]Clean up rest of code, remove unnecessary parts of it (to make it more light).
[*]Test and review changes.
I can either take lead, perform or participate actively in the tasks that are listed green. I only need a competent C++ coder who can help and thinks this is a great idea.
The changes needed to the existing source code do not seem to be much at first glance, but of course as I cannot code in C++, I could be wrong. I just looked at the parts of code where to change the tabs and queries to storage files.
So there, got it off my chest. Any C++ gurus missing a simple, convenient grocery app?
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
aiiro said:
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
Click to expand...
Click to collapse
If I had money I to would offer some.
It's no wunder WinMo is falling behind no one wants to create apps even when offered a straight cash deal.
Amen to that. I was actually reading this and took a good hour of researching to see just how hard it might be and how time-consuming it might be. I would have loved to take this on...but alas, It would split me way too much. I am already working on my FFP_LS Pro 2.5 Improvements (Major Major improvements...I am practically re-writing the app), I am starting work on a game I plan to release (Its a rather popular game I have yet to find for WIndows Mobile), and I already volunteered to work on the Boggle Clone for WinMo ... so I am already pretty split as it is. heh...if I find free time, and nobody has taken this on, I will probably come back and make this my next project
Sorry though...I do hope some developer comes around to assist!
Thanks for Your support. I thought that I don't need to subscribe to my own threads in order to get a notification if a new post is made, but I was wrong. I certainly didn't get one for Your post. So, sorry for the late reply. I will subscribe to my own thread now
Really? I liked downloading and keeping CABs.
Yes you have to use the marketplace. I think the market saves all of your downloads for you.
Yeah but it's not the same is it?
If something is no longer available for WinMo 6.x, but if you have an old CAB you're ok. This new model takes the power from us and gives it to the vendors. This isn't in my interest at all.
at45 said:
This isn't in my interest at all.
Click to expand...
Click to collapse
I don't agree, at least in my experience it has been much easier to get my applications back with the MS store than with CABs for several reasons. After I flash a new ROM (analogous to a new phone, etc.):
I simply log in to get my store applications - 1 button push to 'install all'
I get the latest version
I don't forget which CABs I have to install, and don't have to make sure they're all up to date.
It's a trade-off, but it is in your interest.
I guess that's ok if you trust the apps to remain available.
I don't have to do much work either though after a hard reset or new ROM. I just run Sashimi which configures every part of the phone exactly how I told it to. I know this is a mile from what MS is doing with WP7 and that's not a bad thing.
But I am hopeful that devs will find a way to let us install apps independently of Marketplace. It might be that someone writes a great app that MS doesn't allow onto the marketplace, mightn't it?
I too am not a fan of the fact that MS gets to dictates which software I can and cannot use. Whilst I consider them to be far more liberal than Apple how can I be sure that what is permitted today will be allowed tomorrow.
It is conceivable that something I download today is retrospectively deemed to be in violation of some hitherto non existent rule- this could be the result of a legal ruling or MS regime change.
Nor am I comfortable about the fact that one firm will have the low down on ALL of the software that I buy.
Whilst i can see some advantages to the market place, what happens if I need to hard reset in an area with no internet access? Or if I am abroad?
An advantage of the cab scenario is that I am only reliant on my sd card. I can carry my backups wherever I go and reinstall at no cost and virtually instantly.
Straying off topic, perhaps, the success of yet another o/s orientated market place might have very serious implications for the way that we source software for our main computers...
whilst that may be true that it is nice to have cabs you can install yourself, the reason for just 1 market place is the fact that you'll end up with experiences like android where multiple market places exist and carriers are changing the market place so you can't access another. and then it's up to the developer to make it available in all these variations of market places. where as at least with iOS/WP market places, it's a 1 place submission.
you also get stupid conditions as well such as amazon's (future?) android marketplace where no app can be released before them in an update. they must be released all at the same time. how hard is that to co-ordinate?
clean thread.
I believe the answer was given. closed Thread.
As it is known that HTCUtility.dll will provide complete, unrestricted access to the TCB chamber on HTC devices, can this be used to unlock (at any level) the OS?
I have not heard anyone speaking of it and exists on my HTC Arrive. Seems to be a bypass for unrestricted access to anything within HTC devices.
I am looking at it myself, but thought I would share.
See details here...
http://labs.mwrinfosecurity.com/files/Advisories/mwri_htc-htcutility-kernmem_2011-11-10.pdf
Your link is down
very interesting but you link is down so please fix it so I can take a look. I too have a HTC arrive and have been working on an unlock.
Don't know what happened to the link.
Here is the link to the google docs version.
https://docs.google.com/viewer?a=v&...1C1HkN&sig=AHIEtbTwK-r8RyAyFmt1ai119m7EVAqsNA
-Paul
This looks promising, I'd like to know if what's written there is true ...
The paper is a couple months old, so it *could* have been patched by HTC... but hey, it also might not have been! This bears investigation post-haste.
It's easy enough to use this to execute some arbitrary code at high permissions, which is certainly useful as-is (do things like unrestricted registry and filesystem access). The real potential of it, though, is to turn off the security restrictions for specific apps. Essentially, get the benefits of a "fully unlocked" ROM but on a stock ROM, and only for the apps you specify.
One thing to note here: this is still going to require an interop-unlocked phone. It's opening a handle to a driver, and just like everything else that does so, it needs ID_CAP_INTEROPSERVICES. This is great news for owners of interop-unlocked/unlockabe phones (since this makes interop-unlock useful again) but probably doesn't help on 2nd-gen phones or on the Arrive (unless you want to roll back to NoDo, in which case this can probably be used to make an interop-unlock that works on Mango, though it wouldn't be easy).
I hope some one gets this working for the Arrive ASAP
Oh this was talked about a while back. It was patched back in NODO
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
GoodDayToDie said:
I'll try it out in any case, and report back.
Click to expand...
Click to collapse
Thank you
GoodDayToDie said:
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
Click to expand...
Click to collapse
Yeah I think it was mentioned here on XDA and it was believed to already have been patched.
I think by "patch" they mean that Interop was restricted as of Mango, thereby securing this exploit, in Mango. But for those that are Interop unlocked, this should still grant full access to everything else.
Just my observations. I have an Arrive and am not Interop unlocked yet, so I can't test it.
Looking at the hand-free provisioning to see if I can find a way to leverage that....
-Paul
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
All the information looks like it is in the advisory. KDataStruct is what you want. That is equivalent to the PEB in Windows CE.
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
Can you confirm this works only on already Interop Unlocked device ?
Thx for your efforts.
Could htclv.dll be helpful in setting security on an app? It supports the following functions:
LVModInitialize LVModUninitialize LVModAuthenticateFile LVModRouting LVModAuthorize LVModGetPageHashData LVModCloseAuthenticationHandle LVModGetHash LVModProvisionSecurityForApplication LVModDeprovisionSecurityForApplication LVModGetSignerCertificateThumbprint LVModSetDeveloperUnlockState LVModAuthorizeVolatileCertificate LVModGetDeveloperUnlockState
In particular the "Deprovision Security for App" and "Get/set DeveloperUnlock" or maybe "Authorize Volatile Certificate"....
Or maybe htcpl.dll which seems to be the HTC policy engine interface. Supports:
GetFunctionTable PolicyCloseHandle PolicyEngineInit PolicyRuleAbortTransaction PolicyRuleAddRawData PolicyRuleBeginTransaction PolicyRuleBuildRawData PolicyRuleCommit PolicyRuleCommitTransaction PolicyRuleCreate PolicyRuleDelete PolicyRuleFindFirst PolicyRuleFindNext PolicyRuleGetInfo PolicyRuleOpen PolicyRuleParseRawData PolicyRuleReadRawData
These all look good to modify the security policies on HTC, assuming Interop-Unlocked.
-Paul
@dragonide: Confirmed, this requires interop-unlock since the very first step is opening a handle to a driver.
@Paul_Hammons: The LVMod functions look quite interesting indeed. Where are you getting these functions from (straight out of the DLLs, or some doc somewhere, or decompiled code, or...?), are they user or kernel entry points, and what permissions do they require? The ability to modify app security doesn't do as much good if you already have to be high-privileged to call it, though it might simplify my current goal.
@n0psl3d: Cool, I'll get to work on it.
@n0psl3d: KDataStruct contains kernel information, but I'm pretty sure what I need is in a PROCESS struct (such as is pointed to by pCurPrc). The problem is, I can't find any documentation for that struct. I'm searching online but so far coming up empty. CE doesn't seem to use PEBs or TEBs as I've seen them on NT (not terribly surprising, but annoying).
EDIT: I'm downloading the Embedded CE toolkit, which comes with source code. It'll take a while but hopefully that will have what I need.
OK, digging through the CE source I've found some interesting things. No idea if this will work yet; it'll be exciting just to make it compile.
PROCESS struct -> hTok (handle to a Token) -> phd (PHDATA, pointer to the handle data) -> pvObj (PVOID to the actual object, which is probably a TOKENINFO) -> psi (pointer to ADBI_SECURITY_INFO) -> contains the actual ACLs and privileges, and can be created from an account ID.
Probably the easiest option is to find a relatively high-privilege process and clone its token or some such. Token re-use (if I increment the reference count, this should work) may be easier. Modifying an existing token might also be doable.
Anyhow, I'm not going to have this finished tonight, but it'll get there. For those wondering wht you can do with this, it basically breaks you out of the sandbox entirely. You can call any function, access any resource, etc. that is available to a userland process (executing in kernel mode is also possible but trickier). Practically speaking, this makes all the other high-privilege COM DLLs useless - instead of ComFileRW, just use the file IO methods (anywhere you want), instead of DMXMLCOM just call ConfigProvXml directly. Even things like launching native EXEs directly should become possible (run those Opera ports on a stock ROM, for example).
I'm sorry, I still don't know what any of that means. But it sounds good! I wish I knew how to do this kind of stuff. Thanks for all of your work!