Support for Garmin login and database downloads

[dimaryaz]

I'm working on supporting Garmin databases from https://fly.garmin.com/fly-garmin/ . If anyone wants to follow the progress, see the garmin_login branch: https://github.com/dimaryaz/jdmtool/compare/garmin_login

Log in:

jdmtool flygarmin login

(it will start a local webserver and open a browser)

List aircraft, avionics, and databases:

jdmtool flygarmin list-aircraft

List series (needs a series ID; does not require login):

jdmtool flygarmin list-series 2380

List files (needs a series ID and issue name; does not require login):

jdmtool flygarmin list-files 2380 25B4

[eld400]

when we install garmin_login branch, folder resources/flygarmin is forget

[dimaryaz]

Thanks, should be fixed now!

[dimaryaz]

Just added list-series and list-files. They don't even require authentication - so you can try random numbers like jdmtool flygarmin list-series 2 and see what you find.

[zyv]

The latest code is working really nicely. Extremely impressive work! 👍

However, is it correct that there is no support for transferring downloaded TAW files to the SD cards of GTN 650s and similar devices? From reading the code, it seems that the transfer command works only with Jeppesen service IDs but not TAW files.

[dimaryaz]

Correct. I'm working on that right now, and in theory, it's pretty easy. (My main problem right now is a bit silly, but I can't decide if jdmtool should support both Jeppesen and Garmin at the same time, or only one at a time. E.g., should jdmtool login let you log in twice, and should jdmtool list show services from both providers? Seems nice to have - but I wonder if anyone here actually uses both Jeppesen and Garmin?)

Also, I don't know exactly how GTN 650s works cause I don't have one - but, in case of Jeppesen's subscriptions, it just extracts a .zip and updates featunlk.dat. See the code here (the function is called g1000, but turns out, it works for other avionics, too).

So I'm guessing that for .taw files, you would need to:

• Extract the database from the .taw file
• Copy the database to the SD card - probably to location that's specified here
• Update featunlk.dat
  • There is already a script called featunlk that verifies the contents of featunlk.dat; I should add an option to update it, too.

[zyv]

Correct. I'm working on that right now, and in theory, it's pretty easy. (My main problem right now is a bit silly, but I can't decide if jdmtool should support both Jeppesen and Garmin at the same time, or only one at a time. E.g., should jdmtool login let you log in twice, and should jdmtool list show services from both providers? Seems nice to have - but I wonder if anyone here actually uses both Jeppesen and Garmin?)

To be honest, now that I've looked deeper into this stuff, I'm not quite sure that any support like what you are programming actually does make sense for Garmin in practice. That is for as long as AVDB remains directly accessible (especially including TAW downloads): https://fly.garmin.com/fly-garmin/support/avdb-files . Also, your way is very clever, but what if they one day wake up to the correct setup of OAuth2? I do admit that it’s a fun exercise in RE and definitively would provide a seamless experience for the users.

I don’t think that there are people using Garmin and Jeppesen subscriptions at the same time, though. It’s not that they are mutually exclusive, but does it really make any sense? Maybe the best way would be to really support both at the same time, in that with login you can log in to both, and list would show the consolidated list of options. Sounds like the most difficult way though :)

• There is already a script called featunlk that verifies the contents of featunlk.dat; I should add an option to update it, too.

I have missed that! Will need to have a look. Thank you!

[dimaryaz]

That is for as long as AVDB remains directly accessible (especially including TAW downloads): https://fly.garmin.com/fly-garmin/support/avdb-files .

I was wondering if that's where everyone gets the .taw files. They're not even linked directly, right? Yeah, you can replace ".exe" with ".taw" in the URL... but is this common knowledge? I'd assume that most people just use GADM.

Also, your way is very clever, but what if they one day wake up to the correct setup of OAuth2?

Haha, yes, when I was implementing it, I thought, "There's no way they'll allow a redirect to an arbitrary URL like http://localhost, right? ... Oh. I guess they do allow it." But, even if they restrict the redirects, it will be possible to either 1) do whatever GADM itself does; maybe that will require building a UI and embedding WebKit or whatever, or 2) reimplement the whole login flow - i.e., ask the user to type the password.

I do admit that it’s a fun exercise in RE and definitively would provide a seamless experience for the users.

A seamless experience is one reason - but I'm also trying to be cautious and make sure jdmtool only downloads the data you're actually supposed to have access to. (Sure, it's trivial to get around it - I just don't want to be the one responsible for that...)

Maybe the best way would be to really support both at the same time, in that with login you can log in to both, and list would show the consolidated list of options. Sounds like the most difficult way though :)

Yeah... Well, I should probably start with the simpler way first, and then, some day, unify them and allow both at the same time.

[zyv]

That is for as long as AVDB remains directly accessible (especially including TAW downloads): https://fly.garmin.com/fly-garmin/support/avdb-files .

... but is this common knowledge? I'd assume that most people just use GADM.

Can't comment on that, just stumbled upon it by accident when exploring my subscription on the website.

A seamless experience is one reason - but I'm also trying to be cautious and make sure jdmtool only downloads the data you're actually supposed to have access to.

Yes, this absolutely makes sense. I wasn't proposing to do anything to circumvent any type of restrictions. I was just saying that to me it makes more sense to focus on low-level issues assuming you have the updates first, and then the fancy integration with subscription. Of course, in addition to being the officially supported way, the latter has a big advantage of being easy to use - it will show exactly the right versions of the files for your hardware, etc.

[ryandrake08]

Great work on this so far! I started writing my own (Garmin/G3X only) updater tool before finding this project, but got blocked pretty much right away because I couldn't figure out the API endpoints. Are you willing to share how you are doing it? GADM checks the SSL certificate chain for self-signed certs, and is therefore resistant to MITM. I'll be following this project with interest. I can verify the API endpoints you've implemented work flawlessly for me, too.

[dimaryaz]

Hi @ryandrake08! I don't remember the exact details - but I started by using mitmproxy, installing its root CA, and so on. As long as Windows trusts the CA, that's good enough for GADM.

If I run certmgr.msc, I have mitmproxy in the list:

Then, I created a certificate for *.garmin.com, and signed it using the mitmproxy CA. (Making * work was a bit of a pain - but you can probably get away with just fly.garmin.com). This is what my cert looks like:

$ openssl x509 -noout -subject -ext subjectAltName -in flygarmin.crt 
subject=C=US, L=Default City, O=Default Company Ltd, CN=fly.garmin.com
X509v3 Subject Alternative Name: 
    DNS:*.garmin.com
$
$ openssl verify -show_chain flygarmin.crt 
flygarmin.crt: OK
Chain:
depth=0: C=US, L=Default City, O=Default Company Ltd, CN=fly.garmin.com (untrusted)
depth=1: CN=mitmproxy, O=mitmproxy

And then I added it to Nginx like this:

ssl_certificate "/etc/nginx/flygarmin.crt";
ssl_certificate_key "/etc/nginx/flygarmin.key";