Related
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
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!
Here is an app I made to quickly and easily change marketplace settings. Similar apps exist already, but this one has a few features I've not seen in the other ones. This project was more of a way for me to learn about homebrew dev, but it resulted in a useful program so nothing wrong with that
Source
This app is open source. It is hosted on Google Code. If anyone would like to help contribute, PM me and we'll discuss getting you added.
What you can do
Change OEM marketplace - You can choose from any of the 8 OEM stores, or view a combined market with all 8 at the same time.
Change MO marketplace - I'm working on getting as many as possible included. The app will ask kindly to submit if yours is a new one.
Change the maximum file size cap over 3g - Download larger apps and podcasts over 3G without needing a wifi connection
Lock the settings - Prevents your settings from reverting back in a day or two when the marketplace updates itself
Who can run this?
You need a root unlock. So either a full unlock or WP7 Root Tools with this app marked as Trusted.
Changelog
Beta 2.0.3 - 6/7/12 - Going off of the error reports I received from yesterday's release, I added better error handling to hopefully alleviate those problems.
Beta 2.0.2 - 6/6/12 - Added a better error handler. Users are now prompted with the option to submit bug reports, so I may better track down issues.
Beta 2.0.1 - 6/4/12 - Fixed a bug that would cause the app to crash if no MO store was configured on the device. The app also informs you if it's not set to Trusted in WP7 Root Tools.
Beta 2 - 5/31/12 - After spending too much time working on a rewrite, the next beta is ready. I've changed a ton of things under the hood, but the big new feature is viewing all OEM markets at the same time. I've also released the source as of this version, though I am not speaking for it's quality. Some parts are more polished than others.
Beta 1.4 - 5/2/12 - Added a few new mobile operators. Added country flags to MO selection screen. Fixed more crashed.
Beta 1.3 - 5/1/12 - Added a slew of new mobile operators, along with an option to remove it (for contract-free phones, direct from OEM, etc)
Beta 1.2 - 4/29/12 - Fixed crashing bug. Added Telekom MO (thanks contable). Added OEM logos.
Beta 1.1 - 4/28/12 - Removed device spoofing (it can break DRM, thanks for the heads up GoodDayToDie). Added Sprint MO.
Beta 1 - 4/28/12 - Initial release
Thanks to
Heathcliff74 for the wonderful WP7 Root Tools SDK
GoodDayToDie for his homebrew efforts, which I use for file IO
balcsida for providing new icons
It doesn't launch on my Titan...so it will probably need a higher level of unlock than a Dev unlock.
You'll need "root" unlock, meaning either full-unlock or WP7 Root Tools and the app marked as "Trusted".
@ken52787: Very cool! I was actually working on something very much like this. Would you mind sharing your source code? If I can merge what I was working on into what you've already got, that would be great.
One very big concern, though: changing the OEM name in DeviceTargetingInfo (which is what I assume you're doing to make apps like Nokia Drive work) is extremely dangerous. Although I'm not sure exactly what the trigger is (suggestions have been things like leaving it changed for more than 24 hours, or changing it more than 5 times), changing that value can permanently break the Marketplace DRM on your phone. All your Marketplace apps will stop launching, and you won't be able to install more. The only solution we know of is a hard-reset or a restore point; returning the registry value to the original OEM name does not help.
GoodDayToDie said:
You'll need "root" unlock, meaning either full-unlock or WP7 Root Tools and the app marked as "Trusted".
@ken52787: Very cool! I was actually working on something very much like this. Would you mind sharing your source code? If I can merge what I was working on into what you've already got, that would be great.
One very big concern, though: changing the OEM name in DeviceTargetingInfo (which is what I assume you're doing to make apps like Nokia Drive work) is extremely dangerous. Although I'm not sure exactly what the trigger is (suggestions have been things like leaving it changed for more than 24 hours, or changing it more than 5 times), changing that value can permanently break the Marketplace DRM on your phone. All your Marketplace apps will stop launching, and you won't be able to install more. The only solution we know of is a hard-reset or a restore point; returning the registry value to the original OEM name does not help.
Click to expand...
Click to collapse
Yikes! I was not aware of this. I took that out and reupped the xap.
And yes, I'll share the source soon, I just want to clean it up a bit first since it's rather sloppy at the moment
ken52787 said:
Here is an app I made to quickly and easily change marketplace settings. Similar apps exist already, but this one has a few features I've not seen in the other ones. This project was more of a way for me to learn about homebrew dev, but it resulted in a useful program so nothing wrong with that
The initial beta is a little rough around the edges, but should be stable. Please report any oddities you notice and provide feedback and suggestions.
What you can do
Change OEM marketplace - Included are Acer, Dell, Fujitsu, HTC, LG, Nokia, Samsung, and ZTE (although only HTC, LG, Nokia, and Samsung have accessible marketplaces)
Change MO marketplace - Included are AT&T, Orange, Sprint, and Verizon (I had a hard time finding other marketplaces. If you are on a carrier other than these, please send me your settings so I can include them, the program will automate this for you with your permission)
Change the maximum file size cap over 3g - Download larger apps and podcasts over 3G without needing a wifi connection
Lock the settings - Prevents your settings from reverting back in a day or two when the marketplace updates itself
Who can run this?
You need a root unlock. So either a full unlock or WP7 Root Tools with this app marked as Trusted.
Changelog
Beta 1.1 - 4/28/12 - Removed device spoofing (it can break DRM, thanks for the heads up GoodDayToDie). Added Sprint MO.
Beta 1 - 4/28/12 - Initial release
Thanks to
Heathcliff74 for the wonderful WP7 Root Tools SDK
GoodDayToDie for his homebrew efforts, which I use for file IO
Click to expand...
Click to collapse
not working with my mozart?
life25ak said:
not working with my mozart?
Click to expand...
Click to collapse
What kind of unlock do you have?
curious... why are XAPs being posted in this sub-forum when their is a WP7 Software Development sub-forum?
nice looking app, though. curious as to how you 'locked' the Market.
would love to add that into my version of this app, Market Select.
The Software Development sub-forum always seemsed more focused on general app development rather than tweaks to the OS. Last time I was reading that forum, it seemed like it was mostly stuff using the official APIs, too. Maybe I should start reading it again, though...
You can lock in changes to Marketplace configurations by setting read-only on the XML files.
@OP: Thanks for the quick fix, and you're welcome for the tip! The 1.1 version works well on my phone. Two (related) suggestions, though:
1: The messageboxes the pop up at first run block the UI from loading. If the UI doesn't load within a few seconds (10 or so) the OS will kill the app. You may want to cause them to pop up on a delay or something...
2: There's no option to send your MO (or OEM) files after the initial messagebox prompt. I'd like to send you the T-Mobile US files (not that the TMoUS apps are super-exciting) but the app was killed on me before I could click it! I can go pull them off the filesystem manually, of course...
Thx for this app.
I have sent you the settings for Telekom Germany (T-Mobile DE), would be nice if you could add them...
GoodDayToDie said:
@OP: Thanks for the quick fix, and you're welcome for the tip! The 1.1 version works well on my phone. Two (related) suggestions, though:
1: The messageboxes the pop up at first run block the UI from loading. If the UI doesn't load within a few seconds (10 or so) the OS will kill the app. You may want to cause them to pop up on a delay or something...
2: There's no option to send your MO (or OEM) files after the initial messagebox prompt. I'd like to send you the T-Mobile US files (not that the TMoUS apps are super-exciting) but the app was killed on me before I could click it! I can go pull them off the filesystem manually, of course...
Click to expand...
Click to collapse
See what I mean about sloppy coding and wanting to clean it up before releasing the source
App works good on my hd7. Although during first run it made a backup. Then asked me if I wanted to sent my carrier setting since you don't have them. I was going to then the app crashed and never gave me the option again. App runs fine other than the first run when it crashed.
Sent from my HD7 T9292 using XDA Windows Phone 7 App
I posted a quick update. This one fixes the crashing bug.
Thx for the quick update...
Sent from my OMNIA7 using XDA Windows Phone 7 App
Very Cool..!!! Thank you! Htc Arrive
v1.1 and v 1.2 are crash
it mean i install this app then set trust on root...it open but quickly get out
so;
whats the problem !?
Doesn't load on my Dev Unlocked TITAN.
Says something about an error occurred while reading current store config
VegaNovus said:
Doesn't load on my Dev Unlocked TITAN.
Says something about an error occurred while reading current store config
Click to expand...
Click to collapse
You need a full unlock or root access with WP7 Root Tools. Dev unlock is not enough (the phone doesn't like me messing about in the file system)
Also, I just posted an update. No changes other than adding a bunch of new MOs. Thanks to everyone who submitted them! I have some ideas for beta 2, if only I could find some time to work on it I also plan on releasing the source when I get that version out.
Using 1.3 with Samsung Focus... Set the Trust to ON through RootTools as well.
I Get the "an error occured while reading your current store config".
If i click on OK application shows the main screen briefly and then exists. Otherwise shows the following error:::
CreateFile failed for \My Documents\Zune\PimentoCache\Keepers\LKKG_MOStoreConfig.xml! GetLastError: 2
Thanks.
You're sure it's two Ks ("LKKG_MOStoreConfig.xml")? That's a typo, then. It would explain why you're getting an error of File Not Found as well.
Hi, I'm Trent and I co-created AppThwack, a service for on-demand automated testing of Android apps on real devices. Basically, you upload an apk and a couple minutes later you get screenshots and logcat dumps from actual phones and tablets we host.
Beta Users Needed
We're currently looking for devs to join our private beta. You can message me or sign up on our website and I'll get a beta code to you shortly. We're trying to stress the system and make additions/adjustments so the service is as useful as possible for developers.
Current Features
Real phones and tablets: About 20 high- and low-end devices and we add a few more every week.
Fast: See results in real time. Full test runs on all devices takes a minute or two to complete.
Selectable default tests: Install, launch, UI Monkey, Cleanup
Configurable tests: For example, specify the number of UI Monkey events and seed the randomizer
JUnit including Robotium support via uploaded test packages
Screenshots in portrait and landscape on all devices
Logcat and filterable logcat viewer
High-level results sortable by device or test
Full stack-traces for any exception that occurs
Future
We're working on adding more test frameworks like monkeyrunner and more default tests, particularly performance tests that measure battery consumption, CPU usage, etc. We're also adding more data visualization and charting so it's easy to see what some of the gathered statistics mean.
We plan to launch soon, but the beta program will remain in effect even after that. The service will follow a freemium model. Again, the beta is free and we're going to keep it in place even after we eventually launch.
Inter-device automation
Our back-end supports device-to-device automation, so if you have an app or scenario that you'd like to test that involves multiple devices or interaction with other devices, even non-Android devices, let me know. We're looking for people to help us develop how this service will be exposed.
Edit: I can't post links, but if you search for "appthwack" you'll find it. Btw, I've apparently lurked since October, 2008. Yikes.
Just wondering will this support of testing apps that require root?
Also any chance we can see like a live pic of the device when it installs the app and opens it?
Sent from my VS910 4G using xda premium
motodroidfreak said:
Just wondering will this support of testing apps that require root?
Click to expand...
Click to collapse
Right now it does not and all of our phones are as close to stock as possible. I'll look into making it an option so we automatically root before your app installs and then un-root after the tests are complete. Root opens up some new possibilities, both good and bad, so I'll need to think about it.
motodroidfreak said:
Also any chance we can see like a live pic of the device when it installs the app and opens it?
Click to expand...
Click to collapse
Yes! The launch test takes a screenshot in both landscape and portrait. You can see all screenshots sorted by device by clicking "By Device" or "By Test" and clicking the "Screenshots" link in the blue box at the top.
Screenshots also show up in each launch test log so you can see the context as the shot was captured. Logcat dumps show up in the same place (Link from the blue box at the top will open a filterable and highlighted log viewer).
Alright thanks I'll try it out tonight
Sent from my VS910 4G using xda premium
Holy cow. Didn't realize such web service existed.
I just signed up and currently having a look around. Is it possible for me to join the beta? Thanks!
Is it possible for a "free" upgrade for my account? Heh just asking
EDIT : Created a new project. Then I'm stuck. The "Runs" tab is empty.
EDIT again : Oh.. uploading had error previously. Uploading again.
Very interesting project. Good luck to your team and I hope I can be a good beta tester
Realy interesting, for us, almost of our apps needs root access, so please think about adding root to your service
Test on my Sensation
Will test on my sensation
test
nullFactory said:
Hi, I'm Trent and I co-created AppThwack, a service for on-demand automated testing of Android apps on real devices. Basically, you upload an apk and a couple minutes later you get screenshots and logcat dumps from actual phones and tablets we host.
Beta Users Needed
We're currently looking for devs to join our private beta. You can message me or sign up on our website and I'll get a beta code to you shortly. We're trying to stress the system and make additions/adjustments so the service is as useful as possible for developers.
Current Features
Real phones and tablets: About 20 high- and low-end devices and we add a few more every week.
Fast: See results in real time. Full test runs on all devices takes a minute or two to complete.
Selectable default tests: Install, launch, UI Monkey, Cleanup
Configurable tests: For example, specify the number of UI Monkey events and seed the randomizer
JUnit including Robotium support via uploaded test packages
Screenshots in portrait and landscape on all devices
Logcat and filterable logcat viewer
High-level results sortable by device or test
Full stack-traces for any exception that occurs
Future
We're working on adding more test frameworks like monkeyrunner and more default tests, particularly performance tests that measure battery consumption, CPU usage, etc. We're also adding more data visualization and charting so it's easy to see what some of the gathered statistics mean.
We plan to launch soon, but the beta program will remain in effect even after that. The service will follow a freemium model. Again, the beta is free and we're going to keep it in place even after we eventually launch.
Inter-device automation
Our back-end supports device-to-device automation, so if you have an app or scenario that you'd like to test that involves multiple devices or interaction with other devices, even non-Android devices, let me know. We're looking for people to help us develop how this service will be exposed.
Edit: I can't post links, but if you search for "appthwack" you'll find it. Btw, I've apparently lurked since October, 2008. Yikes.
Click to expand...
Click to collapse
I would like to test the tool, can you share with me..
Tested
Tested the tool, seems too good..
Suggestion : In-case if you want to reach maximum number of developer. Allow developer to use has free.
IDEA : You can request developer to post about you're tool on there app page, website & play store... As you're giving the tool as free you will get enough number of people to view & use the tool.. if the developer agree then you will allow him to use the tool for free of cost..
As a developer am ready to use the tool & post about you in my app & other places too...
This is a great tool, just uploaded an apk of my app that's in my signature and it worked, with a couple of NullPointers from the Play Store's licence service. That shouldn't happen, and doesn't on any of my devices, so I suspect it's an issue on your end. Any idea why?
HTML:
java.lang.NullPointerException at com.google.android.vending.licensing.LicenseValidator.verify(LicenseValidator.java:99) at com.google.android.vending.licensing.LicenseChecker$ResultListener$2.run(LicenseChecker.java:228) at android.os.Handler.handleCallback(Handler.java:605) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at android.os.HandlerThread.run(HandlerThread.java:60)
HTML:
FATAL EXCEPTION: background thread java.lang.NullPointerException at com.google.android.vending.licensing.LicenseValidator.verify(LicenseValidator.java:99) at com.google.android.vending.licensing.LicenseChecker$ResultListener$2.run(LicenseChecker.java:228) at android.os.Handler.handleCallback(Handler.java:608) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:156) at android.os.HandlerThread.run(HandlerThread.java:60)
Borland
We are using Silk Mobile for end to end applications testing. Do you ever used this tool?
What an interesting service! I'll look into this from work tomorrow.
Not having used this at all, the first things which do spring to mind are:
-streaming realtime logcat
-a (skype?) connection with live streaming video of the app running, so you can see layouts/animations etc.
Anyway, I'm going to check this out tomorrow!
Quinny899 said:
This is a great tool, just uploaded an apk of my app that's in my signature and it worked, with a couple of NullPointers from the Play Store's licence service. That shouldn't happen, and doesn't on any of my devices, so I suspect it's an issue on your end. Any idea why?
Click to expand...
Click to collapse
Thanks for checking out the service. My immediate guess it that this is caused by the absence of a default Play account. Many devices have no account as one of our supported frameworks, calabash, removes accounts upon cleanup after script completion. On the plus-side, if you were to write scripts you should be able to add a temporary account from the test itself.
Highly unlikely you'd hit this bug in a real world situation, but it is a bug nonetheless.
Really awesome service! Can't test it for the moment as it doesn't support root apps, but this is really a great concept :good:
Maybe you could build a superuser permissions manager which would grant root access but makes sure to keep /system mounted as read-only, this way no harm could be done to the devices and us root apps devs could use your awesome service.
I actually got quite a few ideas, you could delete the mount binary in /system/xbin and use it in an internal appthwack app's private data, so that it's the only app able to call this binary and thus to mount /system.
I'd definitely subscribe to AppThwack if it had root support.
If you want help with developing this kind of secure root environment for the testing, I'd gladly contribute.
EDIT : Strangely enough, I just tested it with my app (which asks for root in the launcher activity, so I really didn't expect it to work) and had 0 failures, 75 pass.
How comes ? Have you already added root support ?^^
Either way this is really cool, I'm going to spread the words and most likely subscribe a paid account :good:
Is there somewhere we can see pictures of your device lab? Gotta be one hell of a device museum you got over there^^
Androguide.fr said:
Really awesome service! Can't test it for the moment as it doesn't support root apps, but this is really a great concept :good:
Click to expand...
Click to collapse
Awesome, thanks for the kind words!
EDIT : Strangely enough, I just tested it with my app (which asks for root in the launcher activity, so I really didn't expect it to work) and had 0 failures, 75 pass.
How comes ? Have you already added root support ?^^
Click to expand...
Click to collapse
This is pretty interesting. The only two rooted devices are a couple running CM. I'll look into this further, and if you have any ideas I'd love to hear them as well.
Either way this is really cool, I'm going to spread the words and most likely subscribe a paid account :good:
Is there somewhere we can see pictures of your device lab? Gotta be one hell of a device museum you got over there^^
Click to expand...
Click to collapse
Sweet, I really appreciate it. As soon as I have the number of posts to do so I'll post a pic of the lab.
Some things can not be automated, like scanning a QR code or reading/writing to an NFC tag. Do you plan on adding "manual tests" for a fee?
This would be really great to test apps on specific hardware.
worldtiki said:
Some things can not be automated, like scanning a QR code or reading/writing to an NFC tag. Do you plan on adding "manual tests" for a fee?
This would be really great to test apps on specific hardware.
Click to expand...
Click to collapse
Thanks for the question! Our primary focus is on automation. There are existing test houses and services that will execute manual tests like those you describe, but of course because of the manual component they're slow and expensive.
We often push folks to break their testing down into more granular chunks. For instance, verify you can take a picture and deal with the image, even if it's not the QR code or whatever your app usually consumes. This will find problems with simply using the camera and resulting image location. Now, have a separate test that processes a photo of a QR code, but feed the image in as part of the test. This removes the camera component from the analysis part, meaning it's now possible to benchmark the image analysis algorithm on all devices.
With a combination of a service like ours where you test very, very quickly on tons of devices, you can now do some more UX/end-to-end tests on a handful of devices yourself. This hybrid approach is great for finding the vast majority of issues before release.
nice post
Realy interesting, for us
Awesome tool !
No Developer can test his/her app on many devices. But your tool ... A W E S O M E ! ... I Used it yesterday to test two of my new apps ... Found some error is my app on certain devices which i'd have never found without AppThwack .. :good: :good:
Some of us use Textsecure as replacement for Stock SMS app. Textsecure provides encryption for your SMS. However, my recommendation is: stay away or at least don't update to 2.X... versions.
The developer has introduced Google Cloud Messaging, which means that even if your sms are secure, the fact you are using the app will be recorded in Google Centralized database. In addition, he removed the ability of the user to regenerate new identity key. In last couple of releases, he forced the user to allow the app to contact the internet (otherwise, the app would crash). That is even if you compile the app from sources, which I did a couple of hours ago. If you download the app from Store, you can't even use it without Google account and GSF, the latter will record your every keystroke including the password used to encrypt the messages. In further addition, the app is only available through Googleplay and the developer is actively resisting third party distribution. If that is not enough, you should know that Whisper systems is owned by Twitter, which is a red flag in of itself. The code is growing larger and is more difficult to examine for back door purposes.
My advice: stay away from this development, which in my view is compromised...
Edit. In January of this year, the developer left Twitter. Interestingly, he is still working on Textsecure and it is published under Whisper, which is Twitter. About the same time, all those things described above started to happen. Also interesting is that the developer was put on federal watch list and was continuously harrased by various agencies when flying. So, I wouldn't be surprised to learn that his new employer is the previous harraser...
All more reasons to stay away from this app.
optimumpro said:
Some of us use Textsecure as replacement for Stock SMS app. Textsecure provides encryption for your SMS. However, my recommendation is: stay away or at least don't update to 2.X... versions.
The developer has introduced Google Cloud Messaging, which means that even if your sms are secure, the fact you are using the app will be recorded in Google Centralized database. In addition, he removed the ability of the user to regenerate new identity key. In last couple of releases, he forced the user to allow the app to contact the internet (otherwise, the app would crash). That is even if you compile the app from sources, which I did a couple of hours ago. If you download the app from Store, you can't even use it without Google account and GSF, the latter will record your every keystroke including the password used to encrypt the messages. In further addition, the app is only available through Googleplay and the developer is actively resisting third party distribution. If that is not enough, you should know that Whisper systems is owned by Twitter, which is a red flag in of itself. The code is growing larger and is more difficult to examine for back door purposes.
My advice: stay away from this development, which in my view is compromised...
Edit. In January of this year, the developer left Twitter. Interestingly, he is still working on Textsecure and it is published under Whisper, which is Twitter. About the same time, all those things described above started to happen. Also interesting is that the developer was put on federal watch list and was continuously harrased by various agencies when flying. So, I wouldn't be surprised to learn that his new employer is the previous harraser...
All more reasons to stay away from this app.
Click to expand...
Click to collapse
And here is some more fresh evidence. Today I posted this info on Cyanogen site related to Textsecure Push for CM.
http://www.cyanogenmod.org/blog/whisperpush-secure-messaging-integration
The site says it is neither censored no monitored. Within 5 minutes, the post has disappeared... . So, stay away from this app as the development has been compromised. In my view, of course...
You have no clue what youre talking about.
Corndude said:
You have no clue what youre talking about.
Click to expand...
Click to collapse
Thanks, pal... for a very, very thorough, thoughtful and factual argument.
Edit: by the way, what does no gapps project have to do with textsecure being compromised?
Thanks for the heads up. Something is really amiss, and I won't want to directly experience it. I'm staying away from TextSecure for sure.
abdelazeez said:
Thanks for the heads up. Something is really amiss, and I won't want to directly experience it. I'm staying away from TextSecure for sure.
Click to expand...
Click to collapse
Most messenger apps today work with Google Push Notifications, seems to be no problem for people there. Funny that it is here. As for SMS, I would never use that through another app. Besides, the phone carrier companies save those probably too, whats so different with that you said ? Text Secure is a very nice app I think. Right now people on iOS don't have that app yet, which makes it hard to establish in mixed system userbases among people. But I hope that will change.
Besides, most people here probably use Twitter. Funny to complain about something that might be related to Twitter then, isn't it ?
Wolfseye
wpkwolfseye said:
Most messenger apps today work with Google Push Notifications, seems to be no problem for people there. Funny that it is here. As for SMS, I would never use that through another app. Besides, the phone carrier companies save those probably too, whats so different with that you said ? Text Secure is a very nice app I think. Right now people on iOS don't have that app yet, which makes it hard to establish in mixed system userbases among people. But I hope that will change.
Besides, most people here probably use Twitter. Funny to complain about something that might be related to Twitter then, isn't it ?
Wolfseye
Click to expand...
Click to collapse
The difference is that Textsecure/Whisperpush/CMpush tell you your SMS are encrypted. If they are indeed encrypted and there are no backdoors, your carrier (and others) can only get encrypted SMS (good luck to them trying to decipher). All other SMS apps are in plain text. In my view earlier versions of Textsecure are indeed secure. Starting from version 2.X, we no longer know that considering all the facts I mentioned in the OP.
You should really get your facts straight. Twitter bought Whisper Systems in 2011, mainly to get Moxie and the other Whisper Systems folks to work for them.
Moxie went on to lead Twitters security team. Twitter allowed them a month or so after they aquired Whisper Systems to open source their apps TextSecure and RedPhone. In January 2013 Moxie left Twitter and started Open Whisper Systems with a few others. They took the newly open sourced apps and developed them further.
This is also covered in their FAQ.
You can see all of their code on GitHub.
And if you don't have GAPPS installed, you will simply get a message that you won't be able to use push messages and that's it. Several friends of mine use it for SMS only, with Xprivacy restricting the internet access. It doesn't crash or anything.
If you experience this, you may either have a problem with your build or it's a bug specific to your device/Android version.
Moxie also wrote exactly why he doesn't want TextSecure to be released via F-Droid: for security reasons. They use central signing, which may very well compromise the update channel.
The whole discussion can be found in the most infamous thread in their GitHub: #127
lindworm said:
You should really get your facts straight. Twitter bought Whisper Systems in 2011, mainly to get Moxie and the other Whisper Systems folks to work for them.
Moxie went on to lead Twitters security team. Twitter allowed them a month or so after they aquired Whisper Systems to open source their apps TextSecure and RedPhone. In January 2013 Moxie left Twitter and started Open Whisper Systems with a few others. They took the newly open sourced apps and developed them further.
This is also covered ir FAQ.
You can see all of their code on GitHub.
And if you don't have GAPPS installed, you will simply get a message that you won't be able to use push messages and that's it. Several friends of mine use it for SMS only, with Xprivacy restricting the internet access. It doesn't crash or anything.
If you experience this, you may either have a problem with your build or it's a bug specific to your device/Android version.
Moxie also wrote exactly why he doesn't want TextSecure to be released via F-Droid: for security reasons. They use central signing, which may very well compromise the update channel.
The whole discussion can be found in the most infamous thread in their GitHub: #127
Click to expand...
Click to collapse
Which fact did I not get straight? You can't get the app anywhere other than from Googleplay and for Googleplay you need GSF, which records your every keystroke. And by the way, try to restrict getnetworkinfo in internet settings in Xprivacy and the app will crash as soon as you try to open a conversation (checked on several devices). And why was it necessary to prevent users from generating new identity key? Why not have an app available on Whisper's github, as many devs do. And by the way, I asked the same questions on github and f-droid threads and in response got a suggestion to build an equivalent of Google's GCM, so then Moxie would stop using Google.
optimumpro said:
Which fact did I not get straight? You can't get the app anywhere other than from Googleplay and for Googleplay you need GSF, which records your every keystroke. And by the way, try to restrict getnetworkinfo in internet settings in Xprivacy and the app will crash as soon as you try to open a conversation (checked on several devices). And why was it necessary to prevent users from generating new identity key? Why not have an app available on Whisper's github, as many devs do. And by the way, I asked the same questions on github and f-droid threads and in response got a suggestion to build an equivalent of Google's GCM, so then Moxie would stop using Google.
Click to expand...
Click to collapse
You are not even trying to learn/understand why things are done the way they are done, but instead chose to blast an open source project by a security expert who has spoken at defcon various times and who is on a national security list and gets severely hassled by the TSA every time he tries to travel because of his involvement with secure communication projects.
You don't show the slightest form of objectiveness either. The truth content of what you are writing varies between "flat out wrong" and "there is a reason for how they do it that way, which you either didn't care to research or willingly ignored".
1. You can sideload the apk either from http://apps.evozi.com/apk-downloader/ or any of the dozens of sites that mirror packages from the app store.
They do not provide apks because it is a security risk: there is no automated upgrade channel from where a user can get a new version which may fix serious security flaws.
Everybody who is able to compile from source however should understand the importance of updating regularly and can do so on his/her own.
Moxie stated all of that in the github ticket I linked to.
2. GSF doesn't record your keystrokes.
3. If you had bothered to look it up, getNetworkInfo returns if a certain interface (like wifi) is used for internet.
This leaks no interesting information whatsoever. And it especially doesn't mean that TextSecure doesn't work without internet, because this permission does not give an app internet access. Xprivacy actually expects this behaviour by apps, that's why those fields are by default not restricted even if you restrict internet access of an app.
The program crashes without this, because it expects to get a needed value returned, which you chose to block. This is not something they willingly built in, to stop you from using it without Google Play.
If you can't manage the complexity of the permissions, you should use a simple firewall like AFwall+ to restrict internet access.
4. This was probably removed because it doesn't add any significant security and adds clutter to the user interface, because average users have no idea what it's for. The identity keys you are talking about are long term identity keys. TextSecure uses different keys in every message and actually uses the most secure protocol I know of. It has excellent forward secrecy, future secrecy and deniability. More so than OTR, which it is derived from.
You can learn more about that in their blog:
https://whispersystems.org/blog/simplifying-otr-deniability/
https://whispersystems.org/blog/asynchronous-security/
https://whispersystems.org/blog/advanced-ratcheting/
5. You asked them to not use the only free world wide push network that has contracts with all major providers to not kill idle TCP connections.
Moxie always answered that they would love to use something else, but none exists. And that they don't have the resources to build a push network themselves.
This is all in the comments to https://whispersystems.org/blog/the-new-textsecure/ and on ycombinator:
https://pay.reddit.com/r/Android/co..._cyanogenmod_is_integrating/cdyfxhm?context=3
https://pay.reddit.com/r/Android/co..._cyanogenmod_is_integrating/cdyfrv0?context=3
They are however working on using emails as identifiers and websockets as an alternative to GCM. Websockets are already implemented on the server side and people are working on the client side.
Right now you can use encrypted SMS without GCM, no problem at all. If you want to use it over the internet, you can help to speed up the websocket development:
https://github.com/WhisperSystems/TextSecure/issues/1000
lindworm said:
You are not even trying to learn/understand why things are done the way they are done, but instead chose to blast an open source project by a security expert who has spoken at defcon various times and who is on a national security list and gets severely hassled by the TSA every time he tries to travel because of his involvement with secure communication projects.
You don't show the slightest form of objectiveness either. The truth content of what you are writing varies between "flat out wrong" and "there is a reason for how they do it that way, which you either didn't care to research or willingly ignored".
1. You can sideload the apk either from http://apps.evozi.com/apk-downloader/ or any of the dozens of sites that mirror packages from the app store.
They do not provide apks because it is a security risk: there is no automated upgrade channel from where a user can get a new version which may fix serious security flaws.
Everybody who is able to compile from source however should understand the importance of updating regularly and can do so on his/her own.
Moxie stated all of that in the github ticket I linked to.
2. GSF doesn't record your keystrokes.
3. If you had bothered to look it up, getNetworkInfo returns if a certain interface (like wifi) is used for internet.
This leaks no interesting information whatsoever. And it especially doesn't mean that TextSecure doesn't work without internet, because this permission does not give an app internet access. Xprivacy actually expects this behaviour by apps, that's why those fields are by default not restricted even if you restrict internet access of an app.
The program crashes without this, because it expects to get a needed value returned, which you chose to block. This is not something they willingly built in, to stop you from using it without Google Play.
If you can't manage the complexity of the permissions, you should use a simple firewall like AFwall+ to restrict internet access.
4. This was probably removed because it doesn't add any significant security and adds clutter to the user interface, because average users have no idea what it's for. The identity keys you are talking about are long term identity keys. TextSecure uses different keys in every message and actually uses the most secure protocol I know of. It has excellent forward secrecy, future secrecy and deniability. More so than OTR, which it is derived from.
You can learn more about that in their blog:
https://whispersystems.org/blog/simplifying-otr-deniability/
https://whispersystems.org/blog/asynchronous-security/
https://whispersystems.org/blog/advanced-ratcheting/
5. You asked them to not use the only free world wide push network that has contracts with all major providers to not kill idle TCP connections.
Moxie always answered that they would love to use something else, but none exists. And that they don't have the resources to build a push network themselves.
This is all in the comments to https://whispersystems.org/blog/the-new-textsecure/ and on ycombinator:
https://pay.reddit.com/r/Android/co..._cyanogenmod_is_integrating/cdyfxhm?context=3
https://pay.reddit.com/r/Android/co..._cyanogenmod_is_integrating/cdyfrv0?context=3
They are however working on using emails as identifiers and websockets as an alternative to GCM. Websockets are already implemented on the server side and people are working on the client side.
Right now you can use encrypted SMS without GCM, no problem at all. If you want to use it over the internet, you can help to speed up the websocket development:
https://github.com/WhisperSystems/TextSecure/issues/1000
Click to expand...
Click to collapse
Your original statement was that I got my facts wrong. Since you have not cited any instance where I came up with a wrong fact, I will address your opinions.
Number one: you say GSF does not record keystrokes. How do you know? Have you seen the source (which is closed)? If you did, you work for Google and then everything you say is propaganda that has zero factual value. If you don't, then you are just speculating. You pick whichever is worse. If you use Google proprietary blobs, your device is totally open and there is no security measure/app on earth that is effective against this. That GSF phones home at regular intervals and transmits data there is a known fact. You can use encryption from Mars and yet it won't work because raw data (before encryption) is open to Google. As another user noted, having GSF and other closed source apps is like having a lock installed on your house door and not knowing who has access to it besides you.
Number two: inability to generate new identity key: It was there for a reason, the same way PGP or GPG keys have the ability to be limited in time, revoked or regenerated. It is a good security standard and removing it represents weakening. Clutter? LOL. A regular user wouldn't even be able to find it. Certainly, it does not pop up anywhere, one has to find it.
Number three: Sideload or compiling: a regular user will do neither, he/she will simply download the app from the market, which means he has to have Google blobs. Or you are suggesting that users should download the app from the market and then remove GSF and other Googleapps? LOL again.
As I said earlier, Moxie's argument that allowing third party apps on your device is a greater security risk than having closed source blobs is wrong and grand BS (especially coming from someone who is considered a security expert). It is security through obscurity, which is no security at all. The value of his open source project is completely defeated by having closed source blobs by a known private branch of known three letter agencies.
Now, these are facts. Let's get to opinions. I think that this deliberate weakening of security (again coming from a security expert) is a strong indication that development and/or developer has been compromised. And that is why I recommend to stay away from this app. But that is just my opinion, which is nonetheless based on facts.
optimumpro said:
Your original statement was that I got my facts wrong. Since you have not cited any instance where I came up with a wrong fact, I will address your opinions.
Click to expand...
Click to collapse
Do you even read what I write?
If that is not enough, you should know that Whisper systems is owned by Twitter, which is a red flag in of itself.
Click to expand...
Click to collapse
As I explained he does now work there any more.
You seem to have noticed that too:
Edit. In January of this year, the developer left Twitter. Interestingly, he is still working on Textsecure and it is published under Whisper, which is Twitter.
Click to expand...
Click to collapse
Are you kidding me? How the flying **** did you get to this conclusion? The company that was bought by twitter was Whisper Systems.
They are publishing the new source under Open Whisper Systems. (none of those was ever called Whisper)
See the difference? They also state this here: http://support.whispersystems.org/customer/portal/articles/1474591-is-textsecure-owned-by-twitter-
And here is some more fresh evidence. Today I posted this info on Cyanogen site related to Textsecure Push for CM.
http://www.cyanogenmod.org/blog/whis...ng-integration
The site says it is neither censored no monitored. Within 5 minutes, the post has disappeared... . So, stay away from this app as the development has been compromised. In my view, of course...
Click to expand...
Click to collapse
So you are saying CyanogenMod is part of this grand conspiracy of yours? Come on...
GSF, which records your every keystroke.
Click to expand...
Click to collapse
Number one: you say GSF does not record keystrokes. How do you know? Have you seen the source (which is closed)? If you did, you work for Google and then everything you say is propaganda that has zero factual value. If you don't, then you are just speculating. You pick whichever is worse. If you use Google proprietary blobs, your device is totally open and there is no security measure/app on earth that is effective against this. That GSF phones home at regular intervals and transmits data there is a known fact. You can use encryption from Mars and yet it won't work because raw data (before encryption) is open to Google. As another user noted, having GSF and other closed source apps is like having a lock installed on your house door and not knowing who has access to it besides you.
Click to expand...
Click to collapse
It's a binary blob and it sends data to google, but you have no proof whatsoever if it records keystrokes. You can know if you want to tough. Decompile it and analyze it. I don't like binary blobs, but you can't just say they do something without having any proof. I may not be able to guarantee that they don't do something, because I have not personally decompiled and analyzed every bit of it, but until you have and have proof that it does do something you can't just claim it does.
Number two: inability to generate new identity key: It was there for a reason, the same way PGP or GPG keys have the ability to be limited in time, revoked or regenerated. It is a good security standard and removing it represents weakening. Clutter? LOL. A regular user wouldn't even be able to find it. Certainly, it does not pop up anywhere, one has to find it.
Click to expand...
Click to collapse
It is not something the average user should have access to, for several reasons. The TextSecure V2 protocol is NOT comparable with PGP/GPG because it has forward secrecy and deniability. The keys that are actually used to encrypt a message are not static as with PGP.
They are derived from the original keys and are changed with every message. No need to change them after X days/months/years.
Even if one key is intercepted, you would only be able to decrypt one message and not every message as it is the case with PGP.
If you get a new key, all your contacts get alerts that your key changed and that somebody may be listening in. That's not something the average user should be exposed to. If you think for whatever reason that you really want to do this, back up your conversations, uninstall TextSecure, install it again, import the backup and you have your new key.
Number three: Sideload or compiling: a regular user will do neither, he/she will simply download the app from the market, which means he has to have Google blobs. Or you are suggesting that users should download the app from the market and then remove GSF and other Googleapps? LOL again.
As I said earlier, Moxie's argument that allowing third party apps on your device is a greater security risk than having closed source blobs is wrong and grand BS (especially coming from someone who is considered a security expert). It is security through obscurity, which is no security at all. The value of his open source project is completely defeated by having closed source blobs by a known private branch of known three letter agencies.
Click to expand...
Click to collapse
Every average user has the google blobs, because they are preinstalled on nearly every phone and it's nearly unusable without them. This app is supposed to make encryption available to the masses.
Google may be undermined by your beloved three letter agencies, but it's not one of them. This is not to hide from them.
You have your threat model wrong.
No app alone can ever protect you from those agencies. They have hundreds of 0days for every platform and will simply own your Android, open source or not.
And this is not what TextSecure tries to do. They protect the content of every conversation with extremely strong encryption, no matter what the transport is. This does protect you from dragnet surveillance. But they can not protect you from someone who targets you and is willing to spend hundreds of thousands or millions to break into your operating systems.
If the NSA really wants you they get you, period. But TextSecure protects you from theives, cyber criminals and nearly everybody else who wants to read your messages.
You say you think the encrypted SMS mode was safe? With this your provider (and thus your government and every agency that wants it) has all the metadata. Who sent something to whom etc.
Google on the other hand has actually LESS meta data, because your phone sends the message to the TextSecure server, which relays the message to GCM. GCM then delivers the message. Because everything is encrypted none of the servers get contact data. But google only gets the receiver, not the sender. Your provider gets everything.
A global passive adversary may still do time corellation attacks, by listening who sends something when and who receives something at this time. After some sessions it's pretty clear who is talking to whom. It doesn't matter if Google is evil or not in this case. They get the metadata if they want to.
If you want protection against something like this take a look at pond, or meet i person: https://github.com/agl/pond
Now, these are facts. Let's get to opinions. I think that this deliberate weakening of security (again coming from a security expert) is a strong indication that development and/or developer has been compromised. And that is why I recommend to stay away from this app. But that is just my opinion, which is nonetheless based on facts.
Click to expand...
Click to collapse
As I explained there is no weakening whatsoever. Even if you consider google the adversary, they get less meta data than your SMS provider.
You can use this exactly as before without the google blobs if you want to.
They are actively working on a way to get away from the play store and GCM by building their own distribution method (which is finished, but not yet released, see #127 in their github) and implementing Websockets (server works, client is on the way).
Before you start slamming something you should really understand how it works, or ask if you understood it correctly.
lindworm said:
Do you even read what I write?
As I explained he does now work there any more.
You seem to have noticed that too:
Are you kidding me? How the flying **** did you get to this conclusion? The company that was bought by twitter was Whisper Systems.
They are publishing the new source under Open Whisper Systems. (none of those was ever called Whisper)
See the difference? They also state this here: http://support.whispersystems.org/customer/portal/articles/1474591-is-textsecure-owned-by-twitter-
So you are saying CyanogenMod is part of this grand conspiracy of yours? Come on...
It's a binary blob and it sends data to google, but you have no proof whatsoever if it records keystrokes. You can know if you want to tough. Decompile it and analyze it. I don't like binary blobs, but you can't just say they do something without having any proof. I may not be able to guarantee that they don't do something, because I have not personally decompiled and analyzed every bit of it, but until you have and have proof that it does do something you can't just claim it does.
It is not something the average user should have access to, for several reasons. The TextSecure V2 protocol is NOT comparable with PGP/GPG because it has forward secrecy and deniability. The keys that are actually used to encrypt a message are not static as with PGP.
They are derived from the original keys and are changed with every message. No need to change them after X days/months/years.
Even if one key is intercepted, you would only be able to decrypt one message and not every message as it is the case with PGP.
If you get a new key, all your contacts get alerts that your key changed and that somebody may be listening in. That's not something the average user should be exposed to. If you think for whatever reason that you really want to do this, back up your conversations, uninstall TextSecure, install it again, import the backup and you have your new key.
Every average user has the google blobs, because they are preinstalled on nearly every phone and it's nearly unusable without them. This app is supposed to make encryption available to the masses.
Google may be undermined by your beloved three letter agencies, but it's not one of them. This is not to hide from them.
You have your threat model wrong.
No app alone can ever protect you from those agencies. They have hundreds of 0days for every platform and will simply own your Android, open source or not.
And this is not what TextSecure tries to do. They protect the content of every conversation with extremely strong encryption, no matter what the transport is. This does protect you from dragnet surveillance. But they can not protect you from someone who targets you and is willing to spend hundreds of thousands or millions to break into your operating systems.
If the NSA really wants you they get you, period. But TextSecure protects you from theives, cyber criminals and nearly everybody else who wants to read your messages.
You say you think the encrypted SMS mode was safe? With this your provider (and thus your government and every agency that wants it) has all the metadata. Who sent something to whom etc.
Google on the other hand has actually LESS meta data, because your phone sends the message to the TextSecure server, which relays the message to GCM. GCM then delivers the message. Because everything is encrypted none of the servers get contact data. But google only gets the receiver, not the sender. Your provider gets everything.
A global passive adversary may still do time corellation attacks, by listening who sends something when and who receives something at this time. After some sessions it's pretty clear who is talking to whom. It doesn't matter if Google is evil or not in this case. They get the metadata if they want to.
If you want protection against something like this take a look at pond, or meet i person: https://github.com/agl/pond
As I explained there is no weakening whatsoever. Even if you consider google the adversary, they get less meta data than your SMS provider.
You can use this exactly as before without the google blobs if you want to.
They are actively working on a way to get away from the play store and GCM by building their own distribution method (which is finished, but not yet released, see #127 in their github) and implementing Websockets (server works, client is on the way).
Before you start slamming something you should really understand how it works, or ask if you understood it correctly.
Click to expand...
Click to collapse
"Decompile GSF"
You are kidding. Aren't you? If one can examine closed source the same way as open one, then all problems would be solved. And by the way, there would be no point in having proprietary software. Would it? Of course Java is easier to reverse engineer, but want to try Oracle's java?
"Google" Google has root access to your device: It can pull/install any application without you noticing it. They can install another version of TextSecure with backdoors. They can do whatever they want or told to. So, if you have Google, there is no point in any security at all. And when a developer forces users to have Google for his app to work, that's no security at all.
Cyanogenmode/Conspiracy? There is no conspiracy. The US has a law that requires providers to have back doors in their software/hardware for law enforcement, and there are wild claims (by those who know (and don't) what they are talking about) of TextSecure as "weapon" against this kind of surveillance. And that is pure bull. All that the app can provide is the false sense of security, while in reality making users more transparent to surveillance.
Phone service providers vs. internet: when you use Textsecure as a pure sms app, your provider gets gibberish, but they have no way of knowing what you are using. With GCM/GSF/Googleplay, they know exactly what you are doing, as you are marked as using this particular app. So, Moxie is making life of "survaillors" much easier.
Thanks for telling me to uninstall the app if I want to generate new key. So, if I do it this way, you think my contacts won't receive a message that my key has changed?
Here is how I began to suspect foul play: First I noticed the app wanted access to the internet, then I discovered that I can no longer generate a new key, then I went to read about F-droid/Whisper problems. Then I read that he wants the app be available through Google only, because he cares about security and does not want users to allow third party apps (BS). Then I read about feds harassment. You think the 3 letter agencies wouldn't like to have him?
In my view, Moxie's arguments no longer make sense. And by the way, when he is against the wall, he tells you to create a world wide push service - alternative to GCM. LOL.
For me that's enough to stay away from the app. Others will decide accordingly...
Does anybody work on an alternativ push service in order to replace hard requirement on Google services for TextSecure, Redphone and lots of other useful apps?
I understand that GAPPS are needed to run textsecure.
Is it possible/ has anyone succeed to get it to run with the no GAPPS apps such as the blank store etc or is the app relying too much on google infrastructure?
i can use textsecure sms without internet. besides registering with push is not mandatory at all so the crash you've experienced must be a bug in the version of textsecure you're using. also why compare it to pgp/gpg? textsecure uses otr with improvements to deniability and forward secrecy. also textsecure supports mms (which uses internet).
if you're really that paranoid, avoid android at all and stop spreading FUD claiming it to be fact. i don't find the statement factual at all. it lacks any evidence (show us the code with the backdoor first).
and also avoid openguardian project too as they conspire with textsecure since they are recommending it.
and by the way, whisper and openwhisper are different.
It really is ashamed when misinformed people comment on things they do not have enough information to intelligently speak about. Especially when it discourages people from using an application that is one of the only current means of communicating over SMS in a secure manner. Is it perfect? Certainly not... Security and encryption are never perfect, and there will always be flaws to be found, but to insist that someone such as Moxie Marlinspike is somehow working against the security researcher community in some undercover role as an agent of the government or some corrupt company is really insulting. If you have some absolute proof, or even a reasonable solid suspicion, please share it, but otherwise do not taint these incredible people with false accusations. Learn a bit about encryption, reverse engineering, and packet inspection, and then come back and give an intelligent analysis of your findings of the application you suspect to be playing some nefarious role. Until then, your accusations are completely unfounded and damaging to the community as a whole. There are many people who have worked hard to make this product a reality, and I believe they should be praised for their efforts. Obviously these are my own opinions, and you are free to dismiss them outright as you have done to others in previous posts. In addition, I realize I am not an active member of the xda community, but I am an active member of the security/reverse engineering community. My job and nearly all of my free time is spent reverse engineering software and I see no basis for your accusations.
Here is more update on Textsecure: there was a major vulnerability found last October-November. And Moxie's response (not surprisingly) - fixing "feels pretty cumbersome" and "I dunno."
Also, Open Whisper is now accepted into the family of such a bastion of privacy, as Facebook (kids love it, NSA approves). So, If you had any doubt about this app before, now you can sleep well at night (sarcasm).
https://moderncrypto.org/mail-archive/messaging/2014/001029.html
https://moderncrypto.org/mail-archive/messaging/2014/001030.html
To those who like to attack the messenger ( I call them Google thugs or pacifier babies). One says decompile GSF, the other - false accusations and absolute proof?! Wake up and get the pacifier out of your mouth. There is no such thing in real life. I give you the dots, you can't connect them with the pacifier in your mouth.
Here is some more damning evidence that Textsecure is a totally compromised project no longer to be trusted: during 2013-2014 Open Whisper Systems received over $1.3 mln from BBG, which is an arm of US Government and its 3-letter-agencies.
http://pando.com/2015/03/01/internet-privacy-funded-by-spooks-a-brief-history-of-the-bbg/
So, Moxie, it appears, has turned from someone who was harrased by TSA in airports (presumably for a failure to cooperate with the government) to a receipient of major funds from the same government. I am not even talking about him getting a once in a life-time project to work on "securing" Facebook's What's up application. Pitty and shame...
Replacement for Textsecure
Here is a pure sms app, which replaces compromised Textsecure, as well as stock messaging. There is no over the internet messaging, no google binaries and no Google Services Framewor all closed sourse. In addition, starting from version 2.7, textsecure no longer encrypts SMS. Pitty.
Here is the latest version: http://forum.xda-developers.com/android/apps-games/sms-secure-aes-256-t3065165