Fixing OpenHU - Revision history

AdminTeam: Rollup on Encryption topics

2016-07-05T14:13:36Z

Rollup on Encryption topics

AdminTeam at 14:13, 5 July 2016

2016-07-05T14:13:05Z

AdminTeam: Revised based on community feedback, realigned to final CDR terms

2016-06-28T06:44:55Z

Revised based on community feedback, realigned to final CDR terms

AdminTeam: Documentation alert

2016-06-27T21:19:17Z

Documentation alert

AdminTeam at 07:37, 25 June 2016

2016-06-25T07:37:24Z

AdminTeam at 06:50, 25 June 2016

2016-06-25T06:50:31Z

AdminTeam: Created page

2016-06-25T06:45:21Z

Created page

New page

OpenHU was broken by some undocumented change in Google Play Services 9.2. The best person to fix it, was the original author of OpenHU, Mike Reid. Sadly, he recently died. So we need the community's help to fix it.

=Description of The Problem=

Communication for Android Auto is actually not handled by the Android Auto app itself. It plays a role, but the device-to-device communications layer is actually handled by Google Play Services framework. OpenHU worked fine with Play Services 8.0, and Mike himself authored an update to react to changes in Play Services 9.0.

But, for some reason, Play Services 9.2 broke OpenHU. Google has not released a specific changelog for Play Services 9.2, but it does add the Nearby framework, which made many changes to the ADB and Android peer-to-peer communications subsystems.

==More Specifics==

With Play Services 9.2 installed, the OpenHU app will detect the presence of an Android Auto client via ADB. It enumerates the MAC address of the USB OTG client without issue.

Unfortunately, from there, Android Auto services (part of Google Play Services) fail to establish a connection.

We have isolated this to being a client-side issue, the presence of Play Services 9.2 on the host/OpenHU device does not cause an issue. And the latest versions of both the Android Auto app, and Google Play Store are not an issue. When we manually overwrite Play Services 9.2 with Play Services 9.0 on the client, everything works again.

=Is it Encryption?=

We don't think so. While most Android Auto head units today use digitally signed encryption, many early ones do not. Google would have had to make every owner, of everyone one of those cars, update their radio head units to plug that bypass - and mandate encryption.

Mike Reid himself commented that it is unlikely future breaks (like this one) will be due to encryption, but rather, due to the OpenHU app using some protocol in an undocumented manner - one that the Android Auto client (and Play Services 9.2) were not expecting.

This could become a cat-and-mouse game if Google was determined to block OpenHU... but again, that's not likely what happened here. It's far more likely some bad code in the OpenHU app simply is operating out of specification.

But, anything's possible. We aren't ruling out a code signing check just yet.

=So you're offering $10,000 to fix it?=

Pretty much. Mike wasn't just our "point man" on Android Auto R&D, he was the community's point man.

We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing Play Services 9.0 to communicate with the Android Auto client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.

=Where are the details?=

Details are currently being posted to [[Console Developer Rewards]]. But in a nutshell, if we can get OpenHU up and running by the end of August, we'll divide the $5,000 in free gadgets, and $5,000 in cash, amongst the contributors that get it working.

And yes, a successful fix is a requirement. We're a tiny startup, we can't reward failure (sorry).

@@ Line 25: / Line 25: @@
 Technical experts in the community have raised (and tested) several theories. This is not meant to be a task list, but rather, some theories - and is '''not''' all-inclusive.
-* The OpenSSL implementation in OpenHU may be failing due to being out of date.
+* The OpenSSL implementation in OpenHU may be failing due to being out of date
-* The OpenSSL implementation (calls/format/etc) in OpenHU may be malformed.
+* The OpenSSL implementation (calls/format/etc) in OpenHU may be malformed
 * The self-signed certificate in Mike Reid's original source code has expired
-** Note: Replacing this certificate with a current certificate does not resolve the issue.
+** Note: Replacing this certificate with a current certificate does not resolve the issue
 * The updated GMS 9.2 may be validating/searching now for a CA-signed certificate
 * The updated GMS 9.2 may be validating/searching now for an EV-level certificate

← Older revision		Revision as of 21:19, 27 June 2016
Line 38:		Line 38:

	A few. Mainly, the fixes have to be substantial to earn the full amount. If it's a few lines of code (''and we'd be as thrilled as anyone else if that's all it will take''), we reserve the right to award only 25% or 50% of the total amount, at our discretion. We'll try to be as generous as possible, without angering angel investors. This isn't part of our core line of business, so we have to watch the numbers.		A few. Mainly, the fixes have to be substantial to earn the full amount. If it's a few lines of code (''and we'd be as thrilled as anyone else if that's all it will take''), we reserve the right to award only 25% or 50% of the total amount, at our discretion. We'll try to be as generous as possible, without angering angel investors. This isn't part of our core line of business, so we have to watch the numbers.
		+
		+	While we appreciate documentation, API documentation or reverse-engineering documentation doesn't qualify. Only code does.

	=Where are the details?=		=Where are the details?=

← Older revision		Revision as of 07:37, 25 June 2016
Line 34:		Line 34:

	Why are we offering $10,000 in goods and cash? We respect Mike's tireless efforts to keep Android Auto at least somewhat open-source. We want to see that continue, even after his passing. But we don't have people on our team that can do that - and time is of the essence here, especially as a future Android Auto client app update will likely block Play Services 9.0 from loading.		Why are we offering $10,000 in goods and cash? We respect Mike's tireless efforts to keep Android Auto at least somewhat open-source. We want to see that continue, even after his passing. But we don't have people on our team that can do that - and time is of the essence here, especially as a future Android Auto client app update will likely block Play Services 9.0 from loading.
		+
		+	==Any Caveats?==
		+
		+	A few. Mainly, the fixes have to be substantial to earn the full amount. If it's a few lines of code (''and we'd be as thrilled as anyone else if that's all it will take''), we reserve the right to award only 25% or 50% of the total amount, at our discretion. We'll try to be as generous as possible, without angering angel investors. This isn't part of our core line of business, so we have to watch the numbers.

	=Where are the details?=		=Where are the details?=

← Older revision		Revision as of 06:50, 25 June 2016
Line 30:		Line 30:

	We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing Play Services 9.0 to communicate with the Android Auto client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.		We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing Play Services 9.0 to communicate with the Android Auto client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.
		+
		+	==Why?==
		+
		+	Why are we offering $10,000 in goods and cash? We respect Mike's tireless efforts to keep Android Auto at least somewhat open-source. We want to see that continue, even after his passing. But we don't have people on our team that can do that - and time is of the essence here, especially as a future Android Auto client app update will likely block Play Services 9.0 from loading.

	=Where are the details?=		=Where are the details?=

@@ Line 17: / Line 17: @@
 =Is it Encryption?=
-We don't think so. While most Android Auto head units today use digitally signed encryption, many early ones do not. Google would have had to make every owner, of everyone one of those cars, update their radio head units to plug that bypass - and mandate encryption.
+Yes, but we're not convinced this is a blockade by Google. All Android Auto head units are encrypted two-way communicators, using the Android Debug Bridge (ADB) for device-to-device communication. This is facilitated by an OpenSSL certificate, that is then vetted by Google Play Services (or Google Mobile Services, aka GMS).
-Mike Reid himself commented that it is unlikely future breaks (like this one) will be due to encryption, but rather, due to the OpenHU app using some protocol in an undocumented manner - one that the Android Auto client (and Play Services 9.2) were not expecting.
+GMS has a file called libsslwrapper.so that vets security certificates. When GMS 9.2 is updated on a device, that is when OpenHU breaks. We can confirm this by swapping in the libsslwrapper.so from GMS 9.0, and suddenly OpenHU works again.
-This could become a cat-and-mouse game if Google was determined to block OpenHU... but again, that's not likely what happened here. It's far more likely some bad code in the OpenHU app simply is operating out of specification.
+We aren't sure what, exactly, changed in libsslwrapper.so - It's an undocumented API and file. But something changed that is causing self-signed OpenSSL certificates stop working.
-But, anything's possible. We aren't ruling out a code signing check just yet.
+Technical experts in the community have raised (and tested) several theories. This is not meant to be a task list, but rather, some theories - and is '''not''' all-inclusive.
 =So you're offering $10,000 to fix it?=
@@ Line 29: / Line 37: @@
 Pretty much. Mike wasn't just our "point man" on Android Auto R&D, he was the community's point man.
-We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing Play Services 9.0 to communicate with the Android Auto client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.
+We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing GMS 9.0 to communicate with the Android Auto™ client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.
 ==Why?==

@@ Line 43: / Line 43: @@
 =Where are the details?=
-Details are currently being posted to [[Console Developer Rewards]]. But in a nutshell, if we can get OpenHU up and running by the end of August, we'll divide the $5,000 in free gadgets, and $5,000 in cash, amongst the contributors that get it working.
+Legal details and process for code submission are posted at [[Console Developer Rewards]]. But in a nutshell, if we can get OpenHU up and running by the end of August, we'll divide the $10,000 amongst the contributors that get it working.
-And yes, a successful fix is a requirement. We're a tiny startup, we can't reward failure (sorry).
+And yes, a successful fix is a requirement. We're a tiny startup, we can't reward failure (''sorry'').