add support for other devices - Avidyne ?

[n251ea]

Maybe add support for other devices such as the Avidyne IFD navigator? JDM downloads 3 files navdata.dsf - the navdata obstacles.dsf - the obstacle database .jdm - looks to be a simple text file except 3 numbers change whenever the files are downloaded, I suspect they are either encoded time and/or location on the thumb drive. If you copy all 3 files to another thumbdrive they download will not instal

JDM requires any thumbdrive that is FAT32

jdm file contents (some items masked for privacy) for navdata only -

{"ss":[{"a":"Avidyne IFD 400 Series, Bendix King AeroNav Series","c":"XXXXX","cd":"North America","date_label_override":"Effective Date:","dv":"2404","f":[{"fh":"eacbcd26 ","fp":"navdata.dsf","fs":15412018,"sh":"33da0052"}],"fid":"","filter_applied":"no","gsi":"","jvsn":"","ndv":"2405","nvad":"2024-05-06 06:00:00","nvsd":"2024-05-16 06:00: 00","oatn":"YYYYY","pi":"DAE40253","s":"NavData","sc":"North America","u":"42029628","uv":"42029628_2404","v":"2404","ved":"2024-05-16 06:00:00","vsd":"2024-04-18 06:00: 00"}],"ver":"1.1","z":"0368217f"}

XXXXX - is the jeppesen customer number YYYYY - is the aircraft N number

fp - filename to load fs - file size in bytes sh - unknown and changes for each time the (same) database is downloaded pi - unknown but doesn't change when downloading the same database u & uv - unknown but doesn't change when downloading the same database z - unknown and changes for each time the (same) database is downloaded

The obstacle file entry is similar, an actual file can be provided

I suspect the numbers that change each time the same database is downloaded are either time/date encodings or location/sectors on the thumbdrive as you cannot simply use "cp" to move all the files to a new thumbdrive.

[dimaryaz]

It might be doable, depending on how much JDM obfuscates the data.

Does jdmtool download anything successfully - at least the .dsf files? Would you mind posting your services.xml? (Should be in ~/.local/share/jdmtool/services.xml; you should mask anything sensitive - your username, email, name, customer ID, N number). I may also need an example of the downloaded databases - but we'll see; their server may let me download them even with the wrong subscription.

I suspect the numbers that change each time the same database is downloaded are either time/date encodings or location/sectors on the thumbdrive as you cannot simply use "cp" to move all the files to a new thumbdrive.

Yeah, that's completely possible. I've been trying to reverse engineer G1000 for a while; it uses the SD card serial number, and encodes it to hide it.

[n251ea]

xml.txt

xml file is renamed with .txt and is attached.

I can confirm that the .jdm file doesn't have a checksum in it and if I simply change the N number in the .jdm file you can load the files into a different unit, and if you download the subscription for two different users/aircraft the datafiles are exactly the same so everything is controlled by the .jdm file.

here's the output from jdmtool, it downloads my database as a zip file

me@laptop:~$ jdmtool login
Username: me@somewhere.org
Password:
Logged in successfully
me@laptop:~$ jdmtool refresh
Downloading services...
Downloading keychain...
Success
me@laptop:~$ jdmtool list
ID  Name                                                                    Coverage              Version   Start Date  End Date    Downloaded
 0  Avidyne IFD 400 Series, Bendix King AeroNav Series - NavData            North America         2404      2024-04-18  2024-05-16
me@laptop:~$ jdmtool download 0 
Downloading database: 100%|████████████████| 21.7M/21.7M [00:05<00:00, 4.17MB/s]
Downloaded to /home/me/.local/share/jdmtool/downloads/dae402_2404_bbbb36dd.zip
me@laptop:~$ 

[dimaryaz]

Ok nice, the XML file worked - I've successfully downloaded the DB. Though it's a .zip file containing a whole bunch of files - but not navdata.dsf or obstacles.dsf - so figuring out where those come from could be a challenge, too. Anyways, I'll try the real JDM next, and see what happens.

[n251ea]

I logged in with a different account and found that the obstacle database down downloadable with "jdmtool download 1" I have attached the xml file for that one as well. Also I can provide the bin file that the Jeppesen tool makes for this cycle, I suspect they are simply joining the files together to make a single bin file. I believe the avidyne is using some sort of unix OS so it might be as simple as making a tar or cpio archive with a simple offset. services.txt navdata.dsf.txt

[dimaryaz]

Made some progress here. Looks like the zip files contains a bunch of data files and an "Avidyne E2 MX script" that is used to build the .dsf file - e.g., NavData.dsf.txt in the NavData zip, and Obstacles.dsf.txt in the Obstacles zip.

Let's look at Obstacles.dsf.txt cause it's much smaller:

; Avidyne E2 MX script
;
; Key:
;  0 - Script (Base)
;  1 - Copy
;  2 - Delete
;  3 - Execute
;  4 - Versions
;  5 - Preserve Config
;  6 - Persist
;  7 - Button
;  8 - KVF Merge or Delta
;  9 - Extract Directory
; 10 - Date Verify
; 11 - Upload
; 12 - Write SNS registry
;
0 Obstacle Update
 Done Updating Obstacles

 Updating Obstacles
 1

1 Copying Obstacle Files
 /Map
 0444
 ObsHigh.rt2
 ObsHighGrp.rt2
 ObsLow.rt2
 ObsLowGrp.rt2

All of the text strings end up in the .dsf file, as well as the contents of the data files (though they're zlib-compressed). All data is prefixed with its size, encoded in a 4-byte big-endian format. For each file, it includes the original and the compressed size. So we end up with a table like this:

File name length	File name	Uncompressed size	Compressed size	Data
11	ObsHigh.rt2	14384	9204	<9204 bytes of data>
14	ObsHighGrp.rt2	3153	2043	<2043 bytes of data>
...

There's one annoyance: when uncompressing zlib, you get back the original file exactly as it was - that's easy. But when compressing, you can set various parameters like compression level, so you get different results. And figuring out exactly how JDM does it can be difficult. It most certainly doesn't matter - but it means, the .dsf file generated by jdmtool won't be 100% the same as the one from JDM, so it'll be hard to prove that it's correct...

[dimaryaz]

Info about the .jdm file:

• "fh": crc32_q of the file
• "sh": crc32_q of the first 8KB of the file
• "u": from services.xml
• "z": crc32_q of the .jdm file, with the value of "z" replaced by "DEADBEEF"