Need some feedback from the community. What the title says. I can download Hulu on Windows 11/10 (desktop computer with unlocked processor and root permissions of the OS) and watch everything through my account but with Android P6P rooted, it's a PAIN IN THE ASS to watch hulu through the app.
I just don't understand the logic here. Can someone explain the difference?
rester555 said:
Need some feedback from the community. What the title says. I can download Hulu on Windows 11/10 (desktop computer with unlocked processor and root permissions of the OS) and watch everything through my account but with Android P6P rooted, it's a PAIN IN THE ASS to watch hulu through the app.
I just don't understand the logic here. Can someone explain the difference?
Click to expand...
Click to collapse
They are different things. I am not an expert but I know that android is linux based and windows isn't. There are different techniques used to display things, get root access, use the internet/apps etc. Also, the processor comes unlocked and it is meant to be that way unlike the phone which comes locked.
stelmilt said:
They are different things. I am not an expert but I know that android is linux based and windows isn't. There are different techniques used to display things, get root access, use the internet/apps etc. Also, the processor comes unlocked and it is meant to be that way unlike the phone which comes locked.
Click to expand...
Click to collapse
Fair point, my computer comes with an unlocked processor, but the phone comes with an unlockable bootloader, but that's a pretty weak argument with over the top restrictions from these vendors. It seems like they all have a vision in the future and that's everything behind a server wall in the future I bet and you are just a dumb terminal with a data pipe.
I guess another side point is how do you check which level of widevine you have? If memory serves me, on A13 if you don't have the proper level apps don't show movies like Hulu. Has this been solved for A13 on P6P?
Further review of doing identity check, I am getting an HDCP disconnected error when using hulu. Seems like the Hulu apk is looking for HDCP connect status.
Yep, Windows is a very different animal. Even with UAC (User Account Control) that has existed since Windows Vista, the main account of a Windows PC is still an Admin and effectively has root control. You can store Word documents in the Windows\System32\Drivers subfolder if you want. This kind of thing happens by accident all the time. It's pretty crazy, really.
I think even "Standard" (non-Admin) Windows accounts have far greater permissions than they would for some aspects they would on a Linux-based device. I think Standard users can still store things in the wrong places, but probably not as many wrong places, and they can't access other users' folders.
In the end, streaming services operating on a Windows PC have to operate without as strict conditions because the computer is already "rooted" as it comes from the manufacturer.
rester555 said:
Need some feedback from the community. What the title says. I can download Hulu on Windows 11/10 (desktop computer with unlocked processor and root permissions of the OS) and watch everything through my account but with Android P6P rooted, it's a PAIN IN THE ASS to watch hulu through the app.
I just don't understand the logic here. Can someone explain the difference?
Click to expand...
Click to collapse
There is ZERO difference, except EXPECTATION.
Because the software vendor CANNOT expect any desktop/laptop to not provide elevated privileges on demand, but STUPID FRIKKIN GOOBLE built it with these fundamental restrictions in as expectation.
I have hulu bought, but I can't watch it, so I ended up getting a modded apk
tl;dr; because android and Linux are open source
Whenever the app is starting either in windows or android, the only thing it can reach out it's an operating system. The app has almost no privileges over the OS while the OS has ALL over the app. Since the app wants to work with its own data that shouldn't be leaked, the app somehow must ensure it can trust the highly privileged OS before it brings the data into it. How an app can ensure? Well, with certain assumptions it can.
Windows is a proprietary OS with proprietary drivers. All drivers and critical binaries in the OS are passing Microsoft's signing to ensure they aren't modified and their developers are known. OS and drivers are all binaries which makes them hard to be modified or at least such modification would require abnormal resources like expertise, time, money, and knowledge. Windows passes different certifications, security audits, and under permanent attention from security researches. Such things as audits are trying to ensure the OS applies all available security measures and is using available hardware to protect the system and apps from intrusion/modification, thus enterprises trust it. Considering the all above, you, as an app developer, can easily assume: I can trust Windows as its binaries can be hardly modified as it leverages hardware to secure everything, so whenever our app will ask the OS to provide a hardware protected storage for the data, the app will get it.
The all above applies to the stock Android as well, and apps trust such systems. The only difference here is that app developers know that Android and Linux kernel are open source and anyone can modify them and flash into the phone. Now, how an app can ensure it runs on the OS that can be trusted? The app can do that by checking whether the OS is rooted or not. If it's rooted, the OS is certainly somehow modified. The app's devs are assuming that highly privileged modified OS can fake/emulate secure storage and steal the app's data from the less privileged app.
If you wish here is an analogy: Windows is a Ritz Hotel and Android is AirBnB. While they are serving the same purpose: host you as a guest, they are different, and you'll deal with them differently as a guest. Ritz has reputation, a license to run a business, and no one can fake a Ritz hotel. When you stop in a Ritz hotel, you can 100% be sure you can trust it and there are no hidden cameras in rooms as well as you can expect a decent service. Absolutely different story with AirBnB. In AirBnB everyone can be a host, and this brings a problem with a trust to a random person. Once you stop in Airbnb apartments, you highly likely will try to find a hidden camera to understand whether you can trust the host or not.
PS: as per my knowledge, some banking apps aren't running on rooted phones due to same reasons
burned-donut said:
tl;dr; because android and Linux are open source
Whenever the app is starting either in windows or android, the only thing it can reach out it's an operating system. The app has almost no privileges over the OS while the OS has ALL over the app. Since the app wants to work with its own data that shouldn't be leaked, the app somehow must ensure it can trust the highly privileged OS before it brings the data into it. How an app can ensure? Well, with certain assumptions it can.
Windows is a proprietary OS with proprietary drivers. All drivers and critical binaries in the OS are passing Microsoft's signing to ensure they aren't modified and their developers are known. OS and drivers are all binaries which makes them hard to be modified or at least such modification would require abnormal resources like expertise, time, money, and knowledge. Windows passes different certifications, security audits, and under permanent attention from security researches. Such things as audits are trying to ensure the OS applies all available security measures and is using available hardware to protect the system and apps from intrusion/modification, thus enterprises trust it. Considering the all above, you, as an app developer, can easily assume: I can trust Windows as its binaries can be hardly modified as it leverages hardware to secure everything, so whenever our app will ask the OS to provide a hardware protected storage for the data, the app will get it.
The all above applies to the stock Android as well, and apps trust such systems. The only difference here is that app developers know that Android and Linux kernel are open source and anyone can modify them and flash into the phone. Now, how an app can ensure it runs on the OS that can be trusted? The app can do that by checking whether the OS is rooted or not. If it's rooted, the OS is certainly somehow modified. The app's devs are assuming that highly privileged modified OS can fake/emulate secure storage and steal the app's data from the less privileged app.
If you wish here is an analogy: Windows is a Ritz Hotel and Android is AirBnB. While they are serving the same purpose: host you as a guest, they are different, and you'll deal with them differently as a guest. Ritz has reputation, a license to run a business, and no one can fake a Ritz hotel. When you stop in a Ritz hotel, you can 100% be sure you can trust it and there are no hidden cameras in rooms as well as you can expect a decent service. Absolutely different story with AirBnB. In AirBnB everyone can be a host, and this brings a problem with a trust to a random person. Once you stop in Airbnb apartments, you highly likely will try to find a hidden camera to understand whether you can trust the host or not.
PS: as per my knowledge, some banking apps aren't running on rooted phones due to same reasons
Click to expand...
Click to collapse
That is all hogwash. They harass owners of mobile devices *because they can*, which is exclusively connected to expectation and not security.
As for your example of a custom compiled kernel, THAT IS NOT ROOT. That's just a custom compiled kernel.
96carboard said:
As for your example of a custom compiled kernel, THAT IS NOT ROOT. That's just a custom compiled kernel.
Click to expand...
Click to collapse
It’s not a “just”. Kernel is the most privileged part of the whole system and “just custom compiled” for app developers means “it’s no longer a kernel signed by the manufacturers we trust as they have contracts with vendors supplying a DRM subsystem and this unknown kernel has endless power over the system and who knows how it was altered”. Thus “just custom compiled android” with “just root functionality” is the same thing from the app’s perspective. Google for “android verified boot” and you’ll learn why “just custom compiled kernel” breaks the chain of trust.
PS: in past I was a developer of a linux multimedia devices that had supported the same thing to play drm media. Without proper drm support which requires a verified boot no one will allow you to join the US media market and import your devices. If Hulu app would allow to play a licensed content on devices without drm+verified boot — the Hulu immediately would be kicked out from the market by other players.
burned-donut said:
tl;dr; because android and Linux are open source
Whenever the app is starting either in windows or android, the only thing it can reach out it's an operating system. The app has almost no privileges over the OS while the OS has ALL over the app. Since the app wants to work with its own data that shouldn't be leaked, the app somehow must ensure it can trust the highly privileged OS before it brings the data into it. How an app can ensure? Well, with certain assumptions it can.
Windows is a proprietary OS with proprietary drivers. All drivers and critical binaries in the OS are passing Microsoft's signing to ensure they aren't modified and their developers are known. OS and drivers are all binaries which makes them hard to be modified or at least such modification would require abnormal resources like expertise, time, money, and knowledge. Windows passes different certifications, security audits, and under permanent attention from security researches. Such things as audits are trying to ensure the OS applies all available security measures and is using available hardware to protect the system and apps from intrusion/modification, thus enterprises trust it. Considering the all above, you, as an app developer, can easily assume: I can trust Windows as its binaries can be hardly modified as it leverages hardware to secure everything, so whenever our app will ask the OS to provide a hardware protected storage for the data, the app will get it.
The all above applies to the stock Android as well, and apps trust such systems. The only difference here is that app developers know that Android and Linux kernel are open source and anyone can modify them and flash into the phone. Now, how an app can ensure it runs on the OS that can be trusted? The app can do that by checking whether the OS is rooted or not. If it's rooted, the OS is certainly somehow modified. The app's devs are assuming that highly privileged modified OS can fake/emulate secure storage and steal the app's data from the less privileged app.
If you wish here is an analogy: Windows is a Ritz Hotel and Android is AirBnB. While they are serving the same purpose: host you as a guest, they are different, and you'll deal with them differently as a guest. Ritz has reputation, a license to run a business, and no one can fake a Ritz hotel. When you stop in a Ritz hotel, you can 100% be sure you can trust it and there are no hidden cameras in rooms as well as you can expect a decent service. Absolutely different story with AirBnB. In AirBnB everyone can be a host, and this brings a problem with a trust to a random person. Once you stop in Airbnb apartments, you highly likely will try to find a hidden camera to understand whether you can trust the host or not.
PS: as per my knowledge, some banking apps aren't running on rooted phones due to same reasons
Click to expand...
Click to collapse
A custom kernel is not the same thing as root. In classic Linux and UNIX, root is a user account that can do pretty much anything (even delete the entire OS if you know what flags to pass to rm, I will not go into what they are). Root is present on a lot of Linux distros until disabled, and all variants of BSD.
Next time do your research before acting like you know what you're talking about, there will always be someone who actually knows that will take you down a peg.
dragynbane222 said:
A custom kernel is not the same thing as root.
Click to expand...
Click to collapse
You didn't read my comment carefully. I did say:
burned-donut said:
Now, how an app can ensure it runs on the OS that can be trusted? The app can do that by checking whether the OS is rooted or not. If it's rooted, the OS is certainly somehow modified.
Click to expand...
Click to collapse
The app doesn't care about the rooting itself, it has only concerns about whether it can trust the whole system or not. If the system is rooted → it came from an unverified source → it's likely somehow modified because it's open source → no trust. The rooting is only a red flag because none of stock Androids have it. Nowadays, there could be other options to check whether the chain of trust is broken or not, so apps could decline to work even if there is no rooting at all but custom kernel had broken the chain.
dragynbane222 said:
root is a user account that can do pretty much anything even delete the entire OS
Click to expand...
Click to collapse
That's no longer true. The Linux kernel (and Android particularly) has the SELinux subsystem that can be tuned up to prevent a root user from doing that. Kernel has absolute privileges, and kernel can manage what's allowed to the root user. Next time, do your research before acting like you know what you're talking about.
burned-donut said:
It’s not a “just”. Kernel is the most privileged part of the whole system and “just custom compiled” for app developers means “it’s no longer a kernel signed by the manufacturers we trust as they have contracts with vendors supplying a DRM subsystem and this unknown kernel has endless power over the system and who knows how it was altered”. Thus “just custom compiled android” with “just root functionality” is the same thing from the app’s perspective. Google for “android verified boot” and you’ll learn why “just custom compiled kernel” breaks the chain of trust.
PS: in past I was a developer of a linux multimedia devices that had supported the same thing to play drm media. Without proper drm support which requires a verified boot no one will allow you to join the US media market and import your devices. If Hulu app would allow to play a licensed content on devices without drm+verified boot — the Hulu immediately would be kicked out from the market by other players.
Click to expand...
Click to collapse
What are you on about? That has nothing to do with this discussion.
burned-donut said:
it's likely somehow modified because it's open source
Click to expand...
Click to collapse
Being open source has NOTHING AT ALL to do with whether or not it is modified.
96carboard said:
Being open source has NOTHING AT ALL to do with whether or not it is modified.
Click to expand...
Click to collapse
Sorry, no wish to continue a discussion after such confident but fallacy statement. Good luck.
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
I've gone to a couple WP7 training courses and whenever the developers ask about having access to parts of the OS and things of that nature, the microsoft rep mentions theres a OEM SDK. That SDK is unavailble to normal developers and only available to OEMs. If any very resourceful xda members got ahold of that SDK and leaked it, we would see some very interesting apps! It would be a great start to a jailbroken/rooted app store or something of that nature. Just offer all the great apps that wouldn't normally get approved by MSFT. ie wifi tethering, emulators....
Unless you can magically make sideloading happen, this will not work.
Skatingn330 said:
[...] It would be a great start to a jailbroken/rooted app store or something of that nature. Just offer all the great apps that wouldn't normally get approved by MSFT. ie wifi tethering, emulators....
Click to expand...
Click to collapse
I think that the OP is counting on some kind of "jailbreak" will solve that problem
(and so am I)
Actually if you have your phone registered as a dev phone, you kind of have a jailbroken one. Because you have the freedom to put any xap on you want.
It's just going to be the standard WindowsCE dev environment, right? All the WinCE libraries are on the phone, anyway. If you have Visual Studio, I think you can download the WindowsCE version from Microsoft, at least the trial version. Look around, you'll find it.
There's still a limit on the number of apps you can load. I believe it's 10 apps.
Skatingn330 said:
Actually if you have your phone registered as a dev phone, you kind of have a jailbroken one. Because you have the freedom to put any xap on you want.
Click to expand...
Click to collapse
Iridox said:
Unless you can magically make sideloading happen, this will not work.
Click to expand...
Click to collapse
Wait, but it will still require you to stay in the silverlight/XNA jailbox, right?
WP7 desperately need a 3g to wifi tethering app like myfi. I used to have an iphone but switched WP7 and now I need a 'myfi' like app badly.
Can someone some building this app ASAP.
at present it's not possible to even build one as there aren't any APIs for it. I'm sure this has been asked quite a few times on this forum already... please search... rather than just continually asking what people deem as a common requirement. also search the pinned threads as they're a good place to start for missing functionality...
There are APIs. Samsung phones can tether so yh APIs are there. WP7 is just CE with some changes/additions. Microsoft just isn't allowing access to the APIs...
Sent from my HD7 using Board Express
I would think that OEMs have a different set of APIs which provide them with native capabilities. I doubt the OEMs are writting their apps in just C# otherwise MS would have released those APIs as well.
also to note, those phones that can tether is done through the diagnostics, which would imply that they should be already in all windows phones and just dormant. i highly doubt it's specific to samsung phones. it may be that we only know how to do it with samsung phones now.
The Gate Keeper said:
I would think that OEMs have a different set of APIs which provide them with native capabilities. I doubt the OEMs are writting their apps in just C# otherwise MS would have released those APIs as well.
Click to expand...
Click to collapse
That's my point. The APIs exist, as does the base Windows CE system.
We just don't have the development tools nor do we have access to that level of the system to be able to write those applications ourselves.
We're limited to sandboxed Silverlight-based applications, but Microsoft and OEMs can use Native Code and APIs we don't have access to.
They exist, we just don't have access to them. Apple does the same thing with iOS.
Thanks for agreeing with me, though
also to note, those phones that can tether is done through the diagnostics, which would imply that they should be already in all windows phones and just dormant. i highly doubt it's specific to samsung phones. it may be that we only know how to do it with samsung phones now.
Click to expand...
Click to collapse
Which also means WP7 supports tethering. The functionality just isn't exposed to users in the general user interface, that is why you have to dig for it. The same thing is true for Sideloading XAPs, among other things.
It's there. The OS is totally capable of it. WP7 did, in fact, inherit a ton of functionality from Windows Mobile. The difference is that the new UI doesn't expose it to the user, and applications (and the system) are managed in a totally different way.
There's a huge difference between "does not exist" and "exists, but functionality is not exposed in the UI."
Windows on a PC can access drives, etc. by device name, but that is not exposed in the UI - for example. The same is true for many features in WP7 that are there by virtue of it being based on CE and tied (although Microsoft would want you to think differently) to Windows Mobile. They just chose not to expose this functionality.
Not saying it's totalyl based on WM, since that's obviously untrue. If that was the case stuff like full Exchange support, Video support for MMS, etc. would be working.
But the fact that this stuff is there and they're dragging their feet to allow users to use it is what's keeping lots of users off of WP7 at the moment. It's taking them too long to make changes that seem too simple... Maybe for the sake of security, I don't know. They haven't really been transparent with early adopters, IMO.
EDIT: Also, you can call Native Code from managed languages (C#, VB.NET, Java, etc.), so I'm pretty sure they are writing their apps in C# and only calling native code/libraries when they need to. Writing it in straight C/C++ is [potentially] more dangerous than using a Managed Language with Interop. I can't see Microsoft going for that.
I am not talking about sideloading. Android and iOS are hacked within weeks if not days of being released. WP7 has been out for a while and it seems there hasn't been any major progress in this front.
Anyone know why this is? Has MS made WP7 THAT secure that even xda can't break into it?
digger1985 said:
I am not talking about sideloading. Android and iOS are hacked within weeks if not days of being released. WP7 has been out for a while and it seems there hasn't been any major progress in this front.
Anyone know why this is? Has MS made WP7 THAT secure that even xda can't break into it?
Click to expand...
Click to collapse
If you're not talking about sideloading, what are you talking about? The primary modes of "hacking" iOS and Android involve sideloading homebrew apps that do different stuff, which is already happening on WP7.
I was mostly talking about system modifications. Where are utilities like quick toggles for the settings and such? Or for example having folders in the app list. These were added pretty quickly when iOS was jailbroken I believe.
digger1985 said:
I was mostly talking about system modifications. Where are utilities like quick toggles for the settings and such? Or for example having folders in the app list. These were added pretty quickly when iOS was jailbroken I believe.
Click to expand...
Click to collapse
Awaiting the proper APIs
Hmm... I was under the impression that the APIs were there but just not available to the devs. Cracking open WP7 was meant to solve this right?
digger1985 said:
Hmm... I was under the impression that the APIs were there but just not available to the devs. Cracking open WP7 was meant to solve this right?
Click to expand...
Click to collapse
Not really. Devs have no access to native APIs and the access they have managed to gain is still sandboxed to restrict what they can do with the phone.
You could still crack open WP7 without access to native APIs, but it makes it more unlikely that anybody will. When devs have access to native APIs, there is more of a chance that somebody has overlooked a method of gaining access to the phone's features.
I'm not 100%, but I'm pretty sure iPhone did not have a native API available when it was jailbroken. Android is mostly open source, so it's pretty much already jailbroken
Just to mention, i was today able to get full root control of running processes on the current phone (phone sided code). And some api's that are hidden by microsoft can easily be reloaded with "LoadLibrary" and "GetProcAddress" like enumerate running processes. (Look under wp7>hacking>dllimport).
its coming...very soon
Why is it taking so long for WP7 to be fully "cracked" open?
Click to expand...
Click to collapse
Microsoft developers are not amatuers, and TBQH I hope it never is. They need to shut down homebrew IMO, or certainly not facilitate it. All it does it lead to issues and I don't think Microsoft wants the solution to issues to be "go to XDA" or "flash CustomROM_01."
Android is a mess because of all that ****.
How long it took for the first iPhone JB?
fiinix said:
Just to mention, i was today able to get full root control of running processes on the current phone (phone sided code). And some api's that are hidden by microsoft can easily be reloaded with "LoadLibrary" and "GetProcAddress" like enumerate running processes. (Look under wp7>hacking>dllimport).
Click to expand...
Click to collapse
Wait-Are you saying you have the ability to run and exit processes from another application on the device?
Edit: Never mind, found your thread here. Just gave me an idea, nice work!
http://forum.xda-developers.com/showthread.php?t=1006331
Many are aware of my recent concern about this app relying on Google proprietary GCM network and spying Google Services Framework.
Here is TextSecure 2.0.6 compiled by myself from source, but without GCM/Push/GSF/Googleplay/Google Account.. No Google services required to use it at all. All other features are preserved including the latest encryption protocols. This is pure SMS with no internet needed. I am sharing this app under GPL3 license.
INSTRUCTIONS: Unzip and install as a regular app. Keep in mind that you have to uninstall previous versions as they are signed with different signature. Just back up your app with Titanium backup and restore data only.
Source: https://github.com/WhisperSystems/TextSecure
Creidt to original developer Moxie Marlinspike.
You pretend like it's not possible to use the current version without GCM/GSF installed, which is plain wrong.
It works very well, there is simply a message that tells the user he/she won't be able to use push messages without GCM.
You are basically telling people to trust that you didn't mess with it, instead of trusting Moxie (an accomplished security expert) and Open Whisper Systems.
If you want people to use this, you should release the source code, which you are already required to do by the GPL (https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic), add documentation how an identical build can be built and the hash of it.
It's also funny that your "pure SMS with no internet needed" version still requires full internet access in the permissions...
lindworm said:
You pretend like it's not possible to use the current version without GCM/GSF installed, which is plain wrong.
It works very well, there is simply a message that tells the user he/she won't be able to use push messages without GCM.
You are basically telling people to trust that you didn't mess with it, instead of trusting Moxie (an accomplished security expert) and Open Whisper Systems.
If you want people to use this, you should release the source code, which you are already required to do by the GPL (https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic), add documentation how an identical build can be built and the hash of it.
It's also funny that your "pure SMS with no internet needed" version still requires full internet access in the permissions...
Click to expand...
Click to collapse
What a pure bull...
I am not telling people to trust me. All I did was remove Push and GCM ability. And all I need to say is what I said in the original post. That's it. Now, here, unlike Google blobs, the app could be decompiled and easily examined.
Now, with each your response, I am more and more convinced that the development is compromised...