Develop Bugs

[IDEA] Why we don't update chevron?

Do you have a locked phone with Nodo?
So, at this moment your chances are:
Restore the phone to previous version (from Zune)
If your device is LG, you can use the integrated registry editor to unlock it
Buy a developer account subscription
What if your country is not supported by the Marketplace to buy a developer account subscription?
Well, you can ask someone to unlock your phone via remote desktop with their account, then apply any relock prevention
You can use Yallapps unlocking service
I was thinking on update chevron for nodo. There is no marketplace in my country to test and check what is the token used by the developer unlocker application from the phone tools.
Recently I discovered yallaapps (where everyone can register and unlock their phones). It is very unfair compared to the standard marketplace rules (you can upload only free apps, and like 3-4 every 80 dollars).
Anyone here have a yallaapps account to share? (via remote-ethernet usb for example) and unlock my phone to check what is the token, and test if microsoft did something to avoid chevron.cer, etc... I can work some nights trying to get an updated unlocker for us.
Comments?

I've thought about this too. But I have an unlocked Omnia 7 now, with NoDo. And I'm kinda afraid to test for locking/unlocking, because it might lock my phone, while not being able to unlock again. Only a restore of backup or reflash firmware would possibly fix that, but I too busy to risk that now. If it wasn't for that I would've tried a couple of things.
With registry access we can set the value of HKEY_LOCAL_MACHINE\Software\Microsoft\DeviceReg\PortalUrlProd to anything we like. Set it to something like this: http://www.wp7unlock.com. That site does not exist, but that doesn't matter. Note that I mention "http" and not "https" to make it easier. Then add this url to the hosts-file on your computer. Open a http-server on port 80 which logs all http-requests. Now run ChevronWP7 unlocker and try to lock / unlock. Note: Don't try this if your device is upgraded to NoDo and unlocked, and you wish to keep it like that. You can grab the exact request. That is the first step. But this may already lock your device, if you got it unlocked. You need an unlocked device in the first place to edit the registry. If you got the exact http-request that is sent by the NoDo-device, you can manually try to send it to the original url: https://developerservices.windowsphone.com/Services/WindowsPhoneRegistration.svc/01/2010. Now grab the response. That will be the second step. Having the request and response may already provide very useful information and help us further.
I think the chance of getting your device re-locked is small. But only someone who is doesn't matter restoring a backup or older firmware in order to re-unlock should try this. If someone feels like testing this, we may get a start on unlocking NoDo.
Ciao,
Heathcliff74

I'm just guessing here, I haven't actually done any research into it, but I believe the patch was relating to the certificate - aimed at the fact that ChevronWP7 relied on WP7 accepting an untrusted certificate being used by the unlocking server if that certificate had been installed to the phone's store. Simply doing some basic checking on the certificate to ensure it's from a trusted authority for example, is probably the route Microsoft took, or something along those lines.
I'm kinda busy with other things right now, but I'll have to get a copy of a NoDo ROM at some point and take a peak at the relevant files.

Another possibility is to hide a registry editor in some app and submit it to the marketplace. But soon or later they will notice the trick.
Pretty convenient the LG devices with their integrated registry editor...

The odds of being able to sneak any app with the InteropServices capability into the marketplace is pretty low, I think. Without that capability, you can't access COM, which means no native code, which means no registry editing.

GoodDayToDie said:
The odds of being able to sneak any app with the InteropServices capability into the marketplace is pretty low, I think. Without that capability, you can't access COM, which means no native code, which means no registry editing.
Click to expand...
Click to collapse
I am just guessing here, but can't you download a dll file to the isolatedStorage, then on the next app start use that file (for example the samsung dll to edit registry keys used by samsung "root" tools)?

hounsell said:
I'm just guessing here, I haven't actually done any research into it, but I believe the patch was relating to the certificate - aimed at the fact that ChevronWP7 relied on WP7 accepting an untrusted certificate being used by the unlocking server if that certificate had been installed to the phone's store. Simply doing some basic checking on the certificate to ensure it's from a trusted authority for example, is probably the route Microsoft took, or something along those lines.
I'm kinda busy with other things right now, but I'll have to get a copy of a NoDo ROM at some point and take a peak at the relevant files.
Click to expand...
Click to collapse
Ok.. Think with me please.. I am by no means a HTTP or SSL expert, but I know a little bit about it. So please correct me if I'm wrong.
HTTPS is HTTP over SSL. SSL does a handshake for encryption keys. Any HttpListener will support this. And SSL with mutual authentication will also do a certificate check. Tom, if what you said is true, then we should install a genuine certificate for developerservices.windowsphone.com. I'm sure some devs have one laying around for us to use. The phone will accept it, because a certified authority has issued it. That would solve things at the end of the WP7 device.
Now the important part. As far as I know, but I may very well be wrong about this, the certificate is only verified on the end of the server. In this case that would be our own HttpListener on the local PC with the hosts-file containing a mapping for developerservices.windowsphone.com to 127.0.0.1. I think the WP7 device does not validate the server, isn't it? So when we let our server accept the certificate, we're done. We can let it accept the certificate with this line of code:
Code:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Would that do the trick???
Ciao,
Heathcliff74

eried said:
I am just guessing here, but can't you download a dll file to the isolatedStorage, then on the next app start use that file (for example the samsung dll to edit registry keys used by samsung "root" tools)?
Click to expand...
Click to collapse
I'm guessing now. But I think the capabilities are stored somewhere. And if you didn't have the Interop-capability when you installed the app, you will still not be able to load a COM-dll later on. Also, I don't think you will be able to call LoadLibrary on a file in the IsolatedStorage.
And in my WP7 Root Tools, there are NO Samsung dll's. Only my own code. Both native and managed dll's are written 100% by me. No copyrighted dll's from another party in my code. I explicitly avoided that, because my app will never be banned for that reason. I think Julien Schapman's Windows Phone Device Manager does ship the HTC dll's (not 100% sure about that though). I think he might have a problem with that if he ever want to sell his product.
Ciao,
Heathcliff74

Heathcliff74 said:
Now the important part. As far as I know, but I may very well be wrong about this, the certificate is only verified on the end of the server. In this case that would be our own HttpListener on the local PC with the hosts-file containing a mapping for developerservices.windowsphone.com to 127.0.0.1. I think the WP7 device does not validate the server, isn't it? So when we let our server accept the certificate, we're done. We can let it accept the certificate with this line of code:
Code:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Would that do the trick???
Ciao,
Heathcliff74
Click to expand...
Click to collapse
Just a guess here, but I would say that it's the phone who verify the certificate, not the server. That's why you had to install the chevron cert on the phone.

Im not up to date on how these certificates work and where or how they are approved and if there is a difference between certain certs but i was wondering about the cert that we used by xboxmod when he released those omnia apps for all devices or was that just another way to get xaps to work instead of resigning them? Could it be used if not?

I did a bit of reading up on SSL and certificates. I'm still not sure about alot of things, but this is what I get from it:
SSL sets up a secure transport layer by exchanging encryption-keys. And it also supports client-authentication and server-authentication. Authentication can take place by letting one party send its certificate and let the other verify it. For a client this usually means that the issuing party sent a generated certificate against which it can be authenticated. A server is authenticated by its certificate. The certificate needs to be verified. The verification is done by checking the certification-path. The issuers must be trusted by the verifying device. I'm not sure, but I don't think it is normally necessary to install a certificate when you genuine unlock your device. If it is necessary, then that means that the unlock server from Microsoft does client-authentication too. But that is not important when we want to spoof that server with a http-server on our localhost (like ChevronWP7), because we can just skip the client-authentication. We simply don't care about that.
(nico) said:
Just a guess here, but I would say that it's the phone who verify the certificate, not the server. That's why you had to install the chevron cert on the phone.
Click to expand...
Click to collapse
I think the unlocking software on the WP7 device probably does something like this (pseudo-code):
Code:
if (!SecureConnection.Server.IsTrusted())
{
LockDevice();
return;
}
If the server is not trusted, the unlock will fail. So Chevron has its own built-in http-server. With its own certificate. Except that certificate is normally not trusted by the WP7 device, because that certificate is not signed/issued by one of the Certified Authorities that is known by the device. So in order to let the IsTrusted() succeed, a certificate must be installed on the device first. That certificate adds the signing authority (self-signed by Chevron) to the trusted authorities.
Now in NoDo, if Tom is right, Microsoft changed it into something like this:
Code:
if (!SecureConnection.Server.IsTrustedByCertifiedAutority())
{
LockDevice();
return;
}
That means, that it does not only verify if it is trusted, but the top of the certification-path must be a Certified Authority. In this case a self-signed certificate is not accepted anymore.
I have access to the certificate-stores on my Samsung Omnia 7. But for that the device needs to be unlocked. So, that is not useful for unlocking devices. And that exploit only works on Samsung devices.
Now that I understand this better, I see that my previous proposal won't work. But it gives me something to think about. Got to get a way around that.
lucasryan said:
Im not up to date on how these certificates work and where or how they are approved and if there is a difference between certain certs but i was wondering about the cert that we used by xboxmod when he released those omnia apps for all devices. Was that a cert that just allowed us to use those apps to work on other devices just like we do now by resigning a xap to work from another brand, or is it a cert that might could be used?
Click to expand...
Click to collapse
That was some developer-certificate from the WinMo 6.5 SDK or something. It didn't really do anything other than invalidating the signature, which in combination with removal of the DRM file in the XAP would remove the DRM-protection. It works even better to simply remove the certificate from the file. The certificate was simply to replace the valid certificate with an invalid one. The certificate from xboxmod is not of any use here.
Ciao,
Heathcliff74

ok I understand now how they work and what it needs to be. Alot more to it than i was thinking, so there is a chance to find a cert somewhere. somehow.

Very good information, I am not too much into SSL security also. I have an Idea for a new unlocker (not based in chevron's method):
Someone in a Marketplace-enabled country buys a subscription
An application uses that subscription + the code inside the Developer unlock application to unlock a phone
Then the same application deploys (and executes) a xap (like samsung tools) to prevent the device relocking
The same application then deletes the device from the developer account
So, with a minor cost, we can have unlocked phones. I don't know if the dev account can get blocked if the user unlocks and "relocks" a lot of devices, but if one account is good for 10 phones, its fine ($10 usd each unlock)

lucasryan said:
ok I understand now how they work and what it needs to be. Alot more to it than i was thinking, so there is a chance to find a cert somewhere. somehow.
Click to expand...
Click to collapse
No. These are the best kept secrets in the industry. When those key leak a lot of DRM is compromised. And in most systems certificates, once compromised, can be revoked (through updates that are pushed or pulled). The ChevronWP7 guys did a brilliant job in finding the loophole in the server-authentication. I think Microsoft has closed that one now. But maybe there's another loophole in the unlocking system.
There might also be other attack-vectors. If we can get XML-provisioning working from outside the device we can set the registry-values to unlock the device. Maybe OTA Provisioning can be done with WP7 devices.
Another possibility for XML provisioning can be found in this dll:
Code:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0\v4 .0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0.dll
You can open it in Reflector. There's a class called DevicePackageClass. It has a method called ProvisionDeviceXML(). So I tried using it, but when I instantiate the DevicePackageClass it gives me an error:
Retrieving the COM class factory for component with CLSID {E987B9DE-8471-11DB-96A9-00E08161165F} failed due to the following error: 80040154 Class not registered (REGDB_E_CLASSNOTREG)
The class is actually a wrapper for a COM class. So I looked it up in the registry. It seemed to be found in this dll:
Code:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\dip.dll (VSD Device Integration Package)
But is actually part of Visual Studio 2008, not Visual Studio 2010. The dip.dll is not installed with Visual Studio 2010. So I figured I might have a better chance with this dll:
Code:
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.DeviceConnectivity.Interop.9.0\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DeviceConnectivity.Interop.9.0.dll
But it gives me the same error. I also tried to register dip.dll with regsvr32. The registration worked, but the error was still the same. I even tried to access dip.dll directly, but I still couldn't create the COM class DevicePackageClass ("Can't create object").
So if we can somehow instantiate that class we might get XML provisioning working and unlock the device directly in the registry. Needs more research.
Ciao,
Heathcliff74

eried said:
Very good information, I am not too much into SSL security also. I have an Idea for a new unlocker (not based in chevron's method):
Someone in a Marketplace-enabled country buys a subscription
An application uses that subscription + the code inside the Developer unlock application to unlock a phone
Then the same application deploys (and executes) a xap (like samsung tools) to prevent the device relocking
The same application then deletes the device from the developer account
So, with a minor cost, we can have unlocked phones. I don't know if the dev account can get blocked if the user unlocks and "relocks" a lot of devices, but if one account is good for 10 phones, its fine ($10 usd each unlock)
Click to expand...
Click to collapse
Microsoft scans the apps that are submitted for the marketplace. I doubt very much this will ever pass through. And if it will Microsoft will block it as soon as they find out. And it also needs the InteropService capability, which will never be allowed in the Marketplace.

Heathcliff74 said:
Microsoft scans the apps that are submitted for the marketplace. I doubt very much this will ever pass through. And if it will Microsoft will block it as soon as they find out. And it also needs the InteropService capability, which will never be allowed in the Marketplace.
Click to expand...
Click to collapse
My idea was not an app for the marketplace but a desktop app like Chevron

eried said:
My idea was not an app for the marketplace but a desktop app like Chevron
Click to expand...
Click to collapse
Ohw. Sorry. Misunderstood. I get what you meant. But you're gonna need new dev-accounts all the time. Everytime Microsoft will block one dev-account after a certain amount of unlocks, you'll have to get a new one. Who is willing to get all these accounts? This will probably run out very fast.

Heathcliff74 said:
Ohw. Sorry. Misunderstood. I get what you meant. But you're gonna need new dev-accounts all the time. Everytime Microsoft will block one dev-account after a certain amount of unlocks, you'll have to get a new one. Who is willing to get all these accounts? This will probably run out very fast.
Click to expand...
Click to collapse
Of course, but I personally don't have a problem about paying $10-$40 usd to unlock my device. Even $100-$200 seems fair to me for the complete developer account, but I can't pay here in Chile

eried said:
Of course, but I personally don't have a problem about paying $10-$40 usd to unlock my device. Even $100-$200 seems fair to me for the complete developer account, but I can't pay here in Chile
Click to expand...
Click to collapse
Personally I don't like the idea, that I just bought a device of €550 and I have to pay another €100 to actually be able to have control over the device. I also needed to put in countless hours of work to get access to my system and to be able to set the colordepth for instance.
To be real honest, I really don't like the locked-down nature of the device. I liked Microsoft for their open systems (not open source, but highly customizable etc). And I also highly appreciate their developer tools and SDKs. And I love Silverlight. But if I would have known that the phone was so much locked down, I may have considered a Samsung Galaxy S instead of Samsung Omnia 7. Both great phones with super AMOLED etc. WP7 looks much better than Android, but Android is an open OS, which I would prefer. I think Microsoft should have made 2 flavors of WP7; one locked down version for the privacy-freaks and an open version for the tweakers. Anyway, I have the Omnia 7 now with WP7. And I will get it open, even if I have to break it open myself.

Heathcliff74 said:
Personally I don't like the idea, that I just bought a device of €550 and I have to pay another €100 to actually be able to have control over the device. I also needed to put in countless hours of work to get access to my system and to be able to set the colordepth for instance.
To be real honest, I really don't like the locked-down nature of the device. I liked Microsoft for their open systems (not open source, but highly customizable etc). And I also highly appreciate their developer tools and SDKs. And I love Silverlight. But if I would have known that the phone was so much locked down, I may have considered a Samsung Galaxy S instead of Samsung Omnia 7. Both great phones with super AMOLED etc. WP7 looks much better than Android, but Android is an open OS, which I would prefer. I think Microsoft should have made 2 flavors of WP7; one locked down version for the privacy-freaks and an open version for the tweakers. Anyway, I have the Omnia 7 now with WP7. And I will get it open, even if I have to break it open myself.
Click to expand...
Click to collapse
Nobody likes a locked device.
But I do understand the Microsoft posture about this.

Image Sizes and Costs

I downloaded somewhere some image sizes - below are two. I am not too sure which one I downloaded these for / from. But can these icon information be used for Windows Mobile 7, Android, and iPad / iPhone?
From what I think I remember speaking with one developer helping him with testing his game, I think he said it was $99.00 a year for 100 applications. If I only wanted to submit one (free) application, would it be better to find someone that already has the feature to develop this application? The application is very small - mainly to read one specific RSS feed.

Hey
the developer account costs are not connected to the image license price. If you want to submit a WP7 app to the marketplace, you have to own a developer account, that costs $99/year. But this price does not grant the permission to use these pictures. You have to ask the creator whether you're allowed to use them.
Regards
Chris

Thanks - sorry I did not mean to imply I would use these images, I just did not know if it was these image (sizes / quality) that was needed.
If the developer has an account though and he develops the app that I need, can he use that account to upload the app?

Hey
For the licensing procedure and requirements you should visit this link:
http://msdn.microsoft.com/en-us/library/hh184843(v=VS.92).aspx
But I don't get your question. If you're asking wheter you could have another developer programming and submitting the application you need the answer is yes. Every developer that has an account can send apps in. You just have to find someone that wants to create your application. Another possibility would be to program your app yourself and send the compiled version to a developer, so that he can pass it to the WP marketplace...
Regards
Chris

If you need an app built for something easy like an RSS feed, check this thread:
http://forum.xda-developers.com/showthread.php?t=941248
it discusses a build your own app website.
http://thirdlabs.com/
I have never used it and have no afiliation with the site, but it looks easy enough...
Anywho, once the app is made, you can
sideload it (if you're unlocked)
pay for a dev account and submit it ($99 a year)
try to get a free student account and submit it (see here )
find someone with a dev account that will submit it for you
good luck

Thanks for the links! I have run into the RSS feed link - but it was not that site.
Yes, Chris - that answers that question. I thought as much but wanted to make sure. (Sorry it is difficult for me to sometimes get my point across due to my health).

[SDK] LiveLibs ~ auto-updating code in your apps!

LiveLibs is an SDK that you can use in your apps. It allows you to have automatically updating code written in JavaScript. And yes, it'll even pass Marketplace approval. For more info, go here:
LiveLibs.com
Alpha 2 changes:
- Completely changed over from IronRuby to Jurassic (JavaScript) engine
- Improved security (hints and libraries are signed; lib.xml contains more verification data)

(Reserved)

Even though I do respect all the effort you may have put in this project, I'm still not too sure about it. As we've already seen and learned from Android and even iOS there's always the risk of a misuse of such an updating method as unauthorized code can be injected. I rather wait for updates to pass the official certification ways than let my apps update on their own and not knowing what exactly was downloaded.

You are right. With alpha 1 there is a risk of a MitM attack causing apps to download something they shouldn't. However, the framework is already in place to mitigate that - I just haven't had time to implement it fully.
All library ZIP files are signed on the server side with the LiveLibs private key, and the signature is checked by the SDK upon download. Starting with alpha 2, hints will also be signed, which will ensure that erroneous updates are never downloaded.
Also, you don't have to trust the LiveLibs.com site to do the updating. The SDK lets you specify alternate URLs for hints and for libraries.

Just stumbled across this link from your sig. Very cool idea. However, I want to know: have you tested it on a developer-locked phone? Dev-unlock allows the phone to execute code that doesn't have a Microsoft signature (Marketplace apps receive this on all DLLs) but user-replaced or self-compiled binaries won't have that signature. I don't know exactly how your libs worked, but from the look of things (based on your choice of languages) you're looking at monkey-patching the code in place. That's a cool idea, and may well get through Marketplace ingestion, but as soon as the patching is used, you'll have a file without a valid Marketplace signature, and the app won't run anymore...
At least, that's my guess on what would happen. If you can get around that, it would be incredible. That would provide a way to run homebrew code on dev-locked Windows Phones...

The way it worked with IronRuby is the Ruby code was interpreted on the fly. With Jurassic, the JavaScript is compiled into anonymous classes (IIRC from docs/forums on Jurassic.codeplex.com) and executed w/o ever creating separate assemblies. In other words, there's no monkey patching - just live emitted code via Reflection.Emit and similar methods. I'm in the process of getting alpha 2 ready for release now, actually.

Hmm, it's sounds quite interesting! However it's not a way to get an interop-unlock. Also (from the marketing side) it has another cons: an official updates via marketplace for some reasons are increasing number of app customers/downloads (so, good idea - if you have ads-based app - to publish updates at least monthly) but silent, "self-update" I afraid will not.

There's no reason to stop doing proper Marketplace-based updates. The biggest benefit of LiveLibs is the ability to quickly crush bugs instead of having to wait for Marketplace approval while your users complain and give your app bad ratings because of some simple bug.

Arktronic said:
There's no reason to stop doing proper Marketplace-based updates. The biggest benefit of LiveLibs is the ability to quickly crush bugs instead of having to wait for Marketplace approval while your users complain and give your app bad ratings because of some simple bug.
Click to expand...
Click to collapse
Agree. But your code also may have a bugs so it's still not an easy decision: should I add that app's overhead or better to spend more time/money for beta-testing

That, my friend, is entirely up to you

LiveLibs alpha 2 is out. Also, here's a little demo app I wrote using LiveLibs: Rando!

DropBox ver 1 API and/or non-MS and not ugly SkyDrive API

First, I'd like to wish happy New Year for everybody!
Second, I have a question to xda's developers: is there a working and non-ugly (without involving WebBrowser window) library for WP7 to access DropBox API version 1 (it's important, new apps can't use ver 0 anymore; all codeplex'es libs are using version 0 and seems like nobody planned to improve their non-working stuff).
I'm also interested in non-ugly (as Microsoft Live SDK) access library to SkyDrive, also without WebBrowser (it's a most stupidest and ugly API I've ever seen!).
If you have your own working code, could you please share with me for my new free app? I don't have much time to write my own implementation, and I hope that someone has already done this job.
Thanks!

I saw already apps, check BoxShot:
Free: http://www.windowsphone.com/en-US/apps/0be109c4-08be-4ac3-a96b-70ef2b0580e3
Pay: http://www.windowsphone.com/en-US/apps/1abb6e8c-d1ca-4209-a7b8-c2d657ffc9b4

Budniu said:
I saw already apps, check BoxShot:
Click to expand...
Click to collapse
Hmm... Seems like you didn't understand me, I need Silverlight library, not an app.
BoxShot is using DropNet library, ver 0 of DropBox API only...

Ok, sr. You're right, I don't understand.

How about this: http://sharpbox.codeplex.com/releases/view/74634

singularity0821 said:
How about this: http://sharpbox.codeplex.com/releases/view/74634
Click to expand...
Click to collapse
Unfortunately, not working at all (for DropBox) even their demo app Also, they are using synchronous http calls and current code just block whole thread execution.

sensboston said:
Unfortunately, not working at all (for DropBox) even their demo app Also, they are using synchronous http calls and current code just block whole thread execution.
Click to expand...
Click to collapse
I'm sure we can figure out how to get it without using the web browser . I'll see what I can figure out if you want.

snickler said:
I'm sure we can figure out how to get it without using the web browser . I'll see what I can figure out if you want.
Click to expand...
Click to collapse
I'm 100% sure it's possible I just don't have time to work with the new API (v 1) specs and OAuth. So if you have time and want to implement - it's really will be great! And of course I can help you with testing (using my project).
P.S. BTW, SharpBox designed to use synchronous calls; I don't like this way. IMHO good implementation should be more "WP7-oriented"...

And how about this: http://dkdevelopment.net/what-im-doing/dropnet/

singularity0821 said:
And how about this: http://dkdevelopment.net/what-im-doing/dropnet/
Click to expand...
Click to collapse
This one is working but it's "lazy" and kinda ugly solution (author is using WebBrowser window to login to Dropbox account). I completely dislike this way. Same ugly as MS SkyDrive API

sensboston said:
This one is working but it's "lazy" and kinda ugly solution (author is using WebBrowser window to login to Dropbox account). I completely dislike this way. Same ugly as MS SkyDrive API
Click to expand...
Click to collapse
Isn't that how most apps that use OAuth work?

PG2G said:
Isn't that how most apps that use OAuth work?
Click to expand...
Click to collapse
I don't know, actually, but all Dropbox access libs (API v. 0) are working without showing browser window.
P.S. I've found on the Dropbox devs forum, it's possible (but not a guaranteed) to ask dropbox support team to change your app and secret keys to API version 0.

sensboston said:
I don't know, actually, but all Dropbox access libs (API v. 0) are working without showing browser window.
P.S. I've found on the Dropbox devs forum, it's possible (but not a guaranteed) to ask dropbox support team to change your app and secret keys to API version 0.
Click to expand...
Click to collapse
Hello,
I'm the developer behind DropNet. Just a bit of background on the change to API v1: Dropbox wanted to support the full oauth spec which actually requires the web login. I know this makes it not as "clean" for the apps but makes it more secure for Dropbox. They have also announced they will be turning off API v0 sometime in the future (Though they have not stated when).
I dont think the authentication is process is too bad, once you get your head around it. Its accepted by users that they will have to login via the website nowadays (Twitter and Facebook do it as well).

d1k_is said:
actually requires the web login
Click to expand...
Click to collapse
What do you mean by that? I don't know term "web login"... If you mean - "I guess it requires a kinda unknown - for me - parameters or headers for HTTP POST/GET request" - I'll agree but it's definitely not a point to display slow loading and ugly web page each time you need an access to your files. Do you know, what is the actual login technique in API 1 (I mean what kind of params , headers, cookies are used, not a "web login" stuff)?

sensboston said:
What do you mean by that? I don't know term "web login"... If you mean - "I guess it requires a kinda unknown - for me - parameters or headers for HTTP POST/GET request" - I'll agree but it's definitely not a point to display slow loading and ugly web page each time you need an access to your files. Do you know, what is the actual login technique in API 1 (I mean what kind of params , headers, cookies are used, not a "web login" stuff)?
Click to expand...
Click to collapse
Hmmm, sounds like you have the wrong idea about the authentication.
First of all the authentication is a 3 step process (for the developer), step 1 is to get a request token from the API, step 2 is to browse to the site (using the request token as page parameters) so the user can login, step 3 is authorizing the request token (changing it to an access token).
Once you get an access token you can save that in your app and use it forever (or until the user removes access from your app) this means the user will only have to login the first time they run the app as you will have their access token saved locally which you can use to access the API functions (but the access token only works with the API Keys it was created with).
For more info check out the DropNet documentation for the Authentication process (http://dkdevelopment.net/what-im-doing/dropnet/) Theres also a sample app in the Github project.

It sound like you have no idea how the browsers works... "Browse", "navigate" - it's good terms for users, not for developers. From a technical point of view, browser makes an HTTP or HTTPS request to the host and receive a response. So, what you (and dropbox dev and marketing team) called "token" is a text/binary data, part of the response.
So, what is preventing you to make a direct call to dropbox web service using WebRequest?
P.S. I definitely don't like the whole idea to use browser cookies (it suppose to be a kind cookie) for authentication: as for dropbox, as for ms skydrive. It's just ugly - period. And about security - I don't think it's a huge improvement.

sensboston said:
It sound like you have no idea how the browsers works... "Browse", "navigate" - it's good terms for users, not for developers. From a technical point of view, browser makes an HTTP or HTTPS request to the host and receive a response. So, what you (and dropbox dev and marketing team) called "token" is a text/binary data, part of the response.
So, what is preventing you to make a direct call to dropbox web service using WebRequest?
P.S. I definitely don't like the whole idea to use browser cookies (it suppose to be a kind cookie) for authentication: as for dropbox, as for ms skydrive. It's just ugly - period. And about security - I don't think it's a huge improvement.
Click to expand...
Click to collapse
Sorry I was only trying to help.
The tokens are string values and you use a GET via HTTPS sending them as page parameters.
You dont use browser cookies as the dropbox API keeps track of the token you are authenticating against.

Just tried your WP7 example app from DropNet. Actually it demonstrates a little bit more than nothing Could you make a real example, with folders browsing and file operations, please?
P.S. You should use mobile version of dropbox - it feets WP7 screen much better than regular desktop.

600 MB additional free storage
Hi all
Just found a smart way to increase your Dropbox account with 600 MB:
1 Sign into your existing Dropbox account (or create a new account)
2 Goto https://www.dropbox.com/free
3 Follow instructions ... and voila 600 MB additional free storage

thx for the tip, I now got 3,12 GB

Audit my code please

Short version: I programmed a Windows 8 Oauth app. I didn't know where to post this, but it's mostly done in javascript and HTML so I figured this forum might be best. If others have time, I'd really appreciate it if someone would audit my code. Due to the nature of the amount my request, I thought it would be best to post a link to the GitHub repo. If this is wrong, please correct me.
GitHub: https://github.com/mepis/Windows8OauthAuthenticator
Long Version: I use 2-step for a lot of my accounts. The problem is, I'm lazy. I don't feel like getting up to get my phone after I set it down at night. I wanted a metro Oauth app for Windows 8. I looked on the store, but didn't recognize any of the developers. Due to the nature of Oauth, I choose to err on the side of caution and not use the apps. I'm not saying that other devs aren't well intentioned and good devs. I'm just saying that it's a better idea in the name of security that I not use the apps if I can't verify anything. So I decided to write my own.
That leaves another issue though. Due to the nature of Oauth, the token device shouldn't be on the same device you're putting passwords in. I'm choosing to ignore this a bit. I do recognize that tokens shouldn't be stored in plain text though in the Windows storage space. Instead, I push and pull the token from the Windows Credential Manager and the password vault.
I was thinking of running the tokens, labels, and account names through an AES algorithm and then storing that information in the credential manager. This would require a user password on opening the app though. I'm not sure I want to go that route yet, though it would be easily implemented later on.
The mission of this app is simple. I want to offer an Oauth app that is open source and able to be audited by the general public. I want others to have access to a free tool that they can trust and review. I will never charge for this app nor ask for donations. It's also posted under the GNU version 3 license.
At some point, I am thinking about porting this app to Windows Phone.
I'm very much a amateur developer though. I was hoping that others could audit my app, offer suggestions, and point out mistakes. I very much appreciate any help or time that any person is willing to offer.

While you may well get some takers, and some of them might even know what they're doing, you realize you're asking for something that is usually done by people who do this stuff professionally for hundreds of dollars per hour, right? It's like writing up a legal contract and posting it online and saying "do you think this will hold up in court?"
OK, training to be a security engineer doesn't take as long as training to be a lawyer. But there's *more* lawyers than there are security engineers, and our time is very much in demand (yes, I'm a security engineer; no, I will not audit your code for free unless I expect to have a use for it personally).
I'm not even sure what you mean by "OAuth app". OAuth is a standardized protocol (v2.0, RFC 6749, is more accurately described as a framework) for delegated authentication. For example, you've seen how a lot of web sites let you sign in using your Facebook account? That's because they use Facebook as an OAuth provider. The website delegates the responsibility of authenticating users to Facebook, which is handy for them because they don't have to handle passwords and so forth, handy for the user because many users already have FB accounts, and handy for FB because they gain information about what kinds of sites you visit and can use that to target ads. It also has downsides, of course; the OAuth client (web site) has to trust that FB knows what they're doing and to remain available, the user gives FB info they might not want FB to have and also ends up essentially re-using passwords across sites (a bad idea), and FB bears the cost and responsibility of managing all those logins.
Now, to make any authentication scheme (including but not limited to OAuth) stronger, you can multi-factor authentication (sometimes called two-factor auth or 2FA). The most common way of doing that is using Time-based One Time Password (TOTP, standardized as RFC 6238) security tokens, either in small hardware devices or in mobile apps. Is that what this is supposed to be? Because... that has nothing to do with OAuth.
I have a hard time imagining a situation in which I'd use a TOTP generator written by somebody who didn't know the difference between TOTP and OAuth.

Well, your response thus far has been excellent (I'm not being sarcastic). I need to read more about Oauth then. I must have my definitions and understanding a bit confused.
In actuality, to phrase it better, the application would be a TOTP app then - like Google Authenticator. I used Javascript provided by Google for the TOTP generation. The app itself is rather simple. My biggest concern though is the safety of the tokens. I used Windows Credential Manager to store the tokens on the device. I couldn't find much information about the security of Windows Credential Manager though. That's my biggest concern.
Other than that, thanks for the information. I'm going to do some more reading.

For what it's worth (and without having read your code), it sounds like you're doing OK; TOTP generators are not complex by themselves, and usually the only threat to them is in the secret storage (which you're addressing). Of course, most of them offer things like QR code scanning (as a way to load secrets more easily) and I don't know if you have anything like that or whether there are any security pitfalls there.