Oakington 13 Posted April 7, 2015 Share Posted April 7, 2015 Background: I'm trying to add ssl pinning support to the Android app utilizing the memorizing trust manager (github). In order to do so, I need to change the mediabrowser.apiinteraction.android jar, specifically the volley http client. I want to hack around and test out if it works but I cant edit the api JAR directly from android studio as a compiled lib. I've already started to move the mediabrowser.apiclient.java (and /android) into their own java modules in the project and add them as dependencies but I still need to resolve a few dependency errors. Question: What is the development workflow in order to debug changes to the api in android? and what tool is the apiclient.java repo built on? (IntelliJ/eclipse/etc...) Also, is there a dedicated development forum? I've tried searching the forums here for some dev specific topics and I've come up empty most of the time. 1 Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 7, 2015 Share Posted April 7, 2015 Welcome! I develop the ApiClient library with IntelliJ and the android app with android studio. You might want to sync up to the latest code because I have already begun extracting the android-specific parts into it's own module. Also as for dev forum, we try to do everything out in the open publicly to encourage more contributors to come forward. But if you want to discuss something privately, we can do that. Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 7, 2015 Share Posted April 7, 2015 Also just a heads up, there's a couple methods in ApiCient that use HttpUrlConnection so that we can avoid buffering the whole response into memory. You'll have to update those too, or if you can get the volley client to support it that'd be even better. Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 7, 2015 Author Share Posted April 7, 2015 Excellent @@Luke! hanks for the quick reply. I'll continue down the path of adding the source as dependencies in android studio until you have it broken out into its own module. (which will be sweet.) Im up to 35891ea on the api and 41aca08 on the android app. Ill try to form a neat PR and submit on github when done. Thanks again! Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 7, 2015 Author Share Posted April 7, 2015 Also just a heads up, there's a couple methods in ApiCient that use HttpUrlConnection so that we can avoid buffering the whole response into memory. You'll have to update those too, or if you can get the volley client to support it that'd be even better. Well, I can just set the ssl context on load and that should take care of the singleton. OkHttp uses its own client so I need to point it's ssl context back at the singleton on creation. Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 8, 2015 Author Share Posted April 8, 2015 So I submitted pull-requests to the repos and I've tested it out on my Nexus 6 and the emulator and all seems to work as it should. Next task: create a local https->http proxy as the source for chromecast because it is not a fan of self-signed certs. Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 10, 2015 Author Share Posted April 10, 2015 @@Luke I'm trying to add a local http proxy to the android app to be used whenever the memorizing trust manager is in use. I've got the MTM detection working properly as well as the proxy. The issue now is the authentication token. Is there any support built into the API? If not should I build it in or should I just hack around it? Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 10, 2015 Share Posted April 10, 2015 what exactly is the issue? Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 10, 2015 Author Share Posted April 10, 2015 (edited) The response from the server is 401. I'm assuming this is because the caller is no longer the chromecast but the android device and the host is probably incorrect in the authorization hash. The goal is for all intranet external traffic to and from the Emby server to be HTTPS. The certificates created by Emby are self-signed. Chromecast does not support self signed certificates so only http traffic can play. Therefore, I am creating a local http proxy on the android device, which has the ability to accept a self signed certificate now with my last pull-requests for API and Android (still have one more commit to add to Android that will add the trust manager as a module instead of a library. API built fine with the lib). The host that Emby sees is generated by the android device and not the chromecast so i think that will cause a mismatch in the hash. I'm going to make a local copy of the chromecast receiver and enable debugging and have a look at what is going on there next. Just wondering if you have any suggestions as of now. I know this kind of defeats the model of Chromecast directly streaming URLs but until they improve their API to accept self-signed certs, this hack has worked for me in a couple things I have done already. Edited April 10, 2015 by Oakington Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 10, 2015 Share Posted April 10, 2015 does the proxy preserve http headers, including custom ones? also, will all chromecast traffic be done this way or only when necessary? Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 10, 2015 Author Share Posted April 10, 2015 (edited) does the proxy preserve http headers, including custom ones? also, will all chromecast traffic be done this way or only when necessary? All headers are forwarded. 11 of them I believe. I can fire up the debugger and give you an example of a GET and OPTIONS if you need This will only be implemented when the memorizing-trust-manager is in use. I check by matching the host to the mtm's certificate store's CNs Edited April 10, 2015 by Oakington Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 10, 2015 Share Posted April 10, 2015 given all of the work for this, isn't there a point where we put some value on practicality and just say buy a real cert? Link to comment Share on other sites More sharing options...
Luke 36992 Posted April 10, 2015 Share Posted April 10, 2015 Also, this is a shared chromecast receiver that allows android and the web client to both start playback, jump on, jump off, remote control, etc, all seamlessly. And iOS will soon be switched to this receiver as well. So how will that work? Link to comment Share on other sites More sharing options...
Oakington 13 Posted April 10, 2015 Author Share Posted April 10, 2015 (edited) Also, this is a shared chromecast receiver that allows android and the web client to both start playback, jump on, jump off, remote control, etc, all seamlessly. And iOS will soon be switched to this receiver as well. So how will that work? The cast receiver won't be affected. I haven't explored it to see what is happening on that side. Kinda just a black box to me ATM. The goal is to have a sort of pinned trust manager. It remembers the servers you connected to so if it encounters a MITM/invalid cert with matching CN, it will deny. given all of the work for this, isn't there a point where we put some value on practicality and just say buy a real cert? Well, we built the server to generate self signed certs. If there was a way to include a root CA from Emby, (real/trusted) and have the server submit csr's on generation and download a "real" cert, that would be a way, but that could simply be hijacked and MITM certs easily created. Edited April 10, 2015 by Oakington Link to comment Share on other sites More sharing options...
Untoten 295 Posted June 12, 2017 Share Posted June 12, 2017 The cast receiver won't be affected. I haven't explored it to see what is happening on that side. Kinda just a black box to me ATM. The goal is to have a sort of pinned trust manager. It remembers the servers you connected to so if it encounters a MITM/invalid cert with matching CN, it will deny. Well, we built the server to generate self signed certs. If there was a way to include a root CA from Emby, (real/trusted) and have the server submit csr's on generation and download a "real" cert, that would be a way, but that could simply be hijacked and MITM certs easily created. So did this die? Link to comment Share on other sites More sharing options...
Luke 36992 Posted June 12, 2017 Share Posted June 12, 2017 No, it's in the mobile android app. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now