December 2020 Update to EU App/Servers Breaks Authentication

[nigelm]

There was an update on 15 December of the IOS NissanConnect EV App - their changelog had:-

3.5.1 16 Dec 2020

· Security Update · Updated screenshots. · Versions prior to V3.5.1 are no longer supported. Please update your app to this latest version.

It looks like that broke user authentication - although I am currently working on a new laptop which did not have a working app on prior to trying this.

Debug looks like this (I have changed the identifiable bits but think those are irrelevant to the error)

Logging into Carwings...
POST https://gdcportalgw.its-mo.com/api_v200413_NE/gdc/InitialApp_v2.php map[initial_app_str:[9s5rfKVuMrT03RtzajWNcA]]
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Date: Sat, 26 Dec 2020 19:21:36 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000

45
{"status":200,"message":"success","baseprm":"88dSp7wWnV3bvv9Z88zEwg"}
0

Error loading session from /Users/xxxx/.carwings-session: open /Users/xxxx/.carwings-session: no such file or directory
POST https://gdcportalgw.its-mo.com/api_v200413_NE/gdc/UserLoginRequest.php map[Password:[?????????????????????==] RegionCode:[NE] UserId:[username@example.com] initial_app_str:[9s5rfKVuMrT03RtzajWNcA]]
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Date: Sat, 26 Dec 2020 19:21:37 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000

29
{"status":404,"message":"INVALID PARAMS"}
0

ERROR: received status code 404 (INVALID PARAMS)

It looks like the login parameters have changed.

I'll have a further poke at this as I have the time.

[joeshaw]

Yeah, I see the same problem. Unfortunately the US app uses a different API and so i can’t do any reverse engineering on it myself. I implemented the new API in https://github.com/joeshaw/leaf but if I can find a fix for this repo I’ll update it.

[bebettecamb]

I took a dump to see if it wasn't just a change of url and I could identify it and it looks to be exchanging data with this server: ec2-54-199-141-237.ap-northeast-1.compute.amazonaws.com

This is quite beyond my technical level but I'm wondering if this isn't a completely new thing, not just a fix...

[maku1604]

Hello, I was using this lib in europe (germany) to get the SOC of our 2018 Leaf ZE1 into the evcc tool (https://github.com/andig/evcc). I get the same error and debug log as @nigelm above. Additionally I tried to access the data through the myleaf android app (https://gitlab.com/tobiaswkjeldsen/carwingsflutter) and it is still working. Access in that app is handled through a dart library (https://gitlab.com/tobiaswkjeldsen/dartcarwings). The library is unchanged since 3 Months and I have also compared the server url and initial app str: they are identical. So this might still be only a little change in the message flow or parameters that is required to fix this library. I am happy to help and test if that brings this issue to a solution, but I am not familiar with go or dart.

[maku1604]

I also checked pycarwings2 (https://github.com/filcole/pycarwings2) and it was getting access and I will now compare the protocol to see if I can spot the differences.

[joeshaw]

@maku1604 i appreciate the effort, thank you!

[joeshaw]

I just gave pycarwings2 a try, and it's not working for me. I get INVALID_PARAMS there also.

[nigelm]

I also found pycarwings2 did not work for me around the time I originally raised the issue. Not had a chance to retest recently but will do when I get a chance.

[joeshaw]

@maku1604 if you run carwings with the -debug flag, it will print out the raw HTTP requests and responses, so you can see if there are differences in how requests are being serialized and compare them to the pycarwings2 ones.

[joeshaw]

@maku1604 your log looks like it still contained some unredacted info, so I deleted the comment. The rest of your comment is below.

Hmm, pycarwings is working for me here in germany. Here is a log with anonymous login data and including http headers: redacted I also tried the newer API url 200413 and the result is the same. I now try to change the postform request in carwings.go func apiRequest with more generic http.NewRequest("POST" method to gather all header data like here: golang.cafe

[nigelm]

Just retried pycarwings2 (which had had an update since I last tried in December). First attempt the session establishment worked and then something went very wrong, but second attempt managed to login and gave me some vehicle data.

Not a lot of time right now to follow up - although did check that Joe's carwings in go is still failing. Hope to find time to follow up later in the week.

[maku1604]

@maku1604 your log looks like it still contained some unredacted info, so I deleted the comment.

Thanks for removing the file. I put some more effort into cleaning it up this time: pycarwings2.log

[maku1604]

@maku1604 if you run carwings with the -debug flag, it will print out the raw HTTP requests and responses, so you can see if there are differences in how requests are being serialized and compare them to the pycarwings2 ones.

@joeshaw I tried that before, but it shows only the response headers but not the request headers like user-agent, mime-type etc. I added the differences in post params compared to pycarwings2 to carwings.go, but it still resulted in the same error. Therefor I wanted to check next if it is caused by a difference in the request headers.

[joeshaw]

Ah, right you are. I forgot that I'm just calling PostForm rather than constructing the request manually. It should be pretty straightforward to change that to construct a request, dump the request, and post it. I'll make that change now.

[joeshaw]

Ok, I did a little poking around and the server seems to dislike the old User-Agent we were sending (Go-http-client/1.1) so I've added code to remove it altogether and it seems "happier" in the sense that I still get INVALID_PARAMS but the error code is different. Perhaps it'll work for you now as well as pycarwings2 does. (But still doesn't for me, in the USA.)

Commit dacfdd3

[maku1604]

@joeshaw, Yes, it is working again for me in europe now with your change. Thank you! One thing I noticed was, that you are polling the battery status quite frequently until it arrives at the nissan backend. Perhaps the user agent was blacklisted because it created to much load on the backend servers to tolerate it from Nissan and you could increase the cycle time a bit? Regarding the USA access, have you tried the MyLeaf Smartphone App that I linked above. If it works, perhaps you can find some more hints in the dart libraries it uses.

[joeshaw]

@maku1604 The CLI is making a request every 3 seconds. I mean, I hope their servers can sustain the load of 0.3 RPS from a single client. (And their API is designed to start a request and poll the request, so there should be very little overhead to this request... it's not like it's going all the way to the vehicle.)

That said, if the requests are always taking (for example) at least 10 seconds, I'm fine to adjust timings higher so we're not making unnecessary calls.

I do have the MyLeaf app, and it is not working for me either in either the USA or World regions. (Which I think is new -- I recall it working in the USA region previously, but that uses the new API under the hood.) I'll investigate that further.

[joeshaw]

Was fixed in dacfdd3.