5
15
2013
Montana 600のフォント環境
Montala 600 で使用されているフォントを検証
前の記事で 「日本登山地図 TOPO 10M Plus V2」を Montana 600上で表示すると日本語のテキストが全く表示されないことを紹介したが、その原因を探るためにとりあえずMontala 600 で使用されているフォントがどのようなものなのか検証してみた．
Garminの英語版ハンドヘルドGPSで日本語を表示させる方法については、既に多くの方々が挑戦していて、その手順等はWEB上で公開されているので、ここではその手法についての説明は省くが、地図データの文字表示を日本語化する大まかな手順として、
１．日本語フォントの入手
２．入手したフォントデータに対して Garminが用いているフォント暗号化を施す
３．作成した日本語フォントを所定のフォルダーのフォントファイルと置き換える
という一連の作業が必要になる．作業自体はコンピュータをある程度使いこなせる人であればそれほど難しいものではないが、フォントの暗号化の作業がちょっと難しいかもしれない．
さて、上記の作業を行って「日本登山地図 TOPO 10M Plus V2」を Montana 600上で表示してみたものの、この方法では日本語テキストがMontana 600の画面上では全く表示することができなかった．WEB上の情報はちょっと前の機種 Colorad300やOregonの初期の機種などについての情報が多く、最近発売された機種やファームウェアについての情報は少ないようだ．これらの情報が間違っているわけでは無さそうだが、新しい機種や最新版のファームウェアではどうも様子が違うようだ．
そこで、手始めに現行のMontana 600 (ファームウェアは現時点で最新の V4.90）のフォント環境がどのようになっているのか調査してみた．
Montana 600のフォントデータの配置先
Garminのフォントデータは Montana 600に限らず、最近のUSBマスストレージ対応の機種は “Garmin”フォルダの配下にある “ExtData” フォルダに配置されている．Montana 600の場合、”006-D0952-05.bin” と “006-D0952-06.bin”の２つのフォントファイルが置かれている．
中身を調べると -05 がBold体で -06 がRegular体のフォントだった．Garminで用いられているフォントの形式は、WindowsやMac OS X で多く使われているTrue Typeフォントのようだが、ファイル拡張子が “.bin” になっているので、この状態のままではWindowsやMac上からはこれらのファイルがフォントファイルとは認識されない．
単純に 拡張子を “.bin” から “.ttf” に変更すればTrue Type Fontファイルと認識するようになるが、Garminの嫌らしいFont暗号化が施されているので、このままではWindowsやMac OSからは有効なフォントとは見なされない．Garminのフォント暗号化を解除するには、どのような暗号化が施されているのか知っていなければならないが、これについては既に先人達によってハックされていて、単純にFontデータのファイルデータのバイトストリームに対して 0x76 （小文字の “v”）というキーで XOR演算を行うだけという暗号化としてはとても幼稚で簡単なものだ．
コンピュータのプログラミングに少しでも携わったことがあれば、このようなプログラムを作成するのは簡単な事だろう．C言語の入門テキストなどではファイル入出力の章の最初に載っているような最も初歩的なプログラムで、全体でも数行程度で収まる簡単なものだろう．暗号化（エンコード）が簡単なXOR演算であれば、復号化（デコード）も簡単で、暗号化されたデータに対してもう一度同じキーでXORするだけである．
プログラミングが苦手という人はフリーのXORツールが幾つか出まわっているのでそれらを利用すれば良い．先ずは、オリジナルのフォントファイルの16進ダンプを取り、先頭の256バイトの中身をチェックしてみることにする．
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
00000000: 76 77 76 76 76 63 77 76 76 72 76 26 31 32 33 30 vwvvvcwvvrv&1230 00000010: E5 04 EE 29 76 75 D4 26 76 76 76 92 31 26 39 25 ...)vu.&vvv.1&9% 00000020: D1 46 5D 11 76 75 D5 42 76 77 77 8C 31 25 23 34 .F].vu.Bvww.1%#4 00000030: D3 46 CB E3 76 72 D3 46 76 76 CC F4 3A 22 25 3E .F..vr.Fvv..:"%> 00000040: F0 FA E4 EE 76 76 69 5E 76 76 71 34 39 25 59 44 ....vvi^vvq49%YD 00000050: DA FF 10 91 76 76 77 AE 76 76 76 20 20 32 3B 2E ....vvw.vvv 2;. 00000060: 2E B2 16 4D 76 73 29 C2 76 76 73 96 15 1B 17 06 ...Mvs).vvs..... 00000070: EA 0E 07 EE 76 76 D7 C2 76 76 7D AC 15 00 02 56 ....vv..vv}....V 00000080: 76 5C 76 76 76 76 D9 7E 76 76 76 74 10 06 11 1B v\vvvv.~vvvt.... 00000090: 70 2F EA 41 76 76 DB E6 76 76 77 05 11 17 05 06 p/.Avv..vvw..... 000000A0: 76 63 76 55 76 75 D4 36 76 76 76 66 11 1A 0F 10 vcvUvu.6vvvf.... 000000B0: 7B D8 5D 2A 76 76 D9 7A 76 74 2F BE 1E 12 1B 0E {.]*vv.zvt/..... 000000C0: 9E 68 95 D0 76 76 50 1A 76 76 0D 3E 1E 13 17 12 .h..vvP.vv.>.... 000000D0: 99 1B ED 7F 76 76 77 2A 76 76 76 40 1E 1E 13 17 ...vvw*vvv@.... 000000E0: 62 45 7A C0 76 76 77 E2 76 76 76 52 1E 1B 02 0E bEz.vvw.vvvR.... 000000F0: C6 37 4E 92 76 76 74 46 76 76 6A 8E 1D 13 04 18 .7N.vvtFvvj..... |
バイナリデータとしては見るからに不自然なデータストリームで、やたらと0x76がデータの中に含まれている．この事からやはり 暗号化キーは 0x76で間違いなさそうだ．XOR演算を施すまでも無く 0x76 と 0x76 の XOR の値は 0x00 なので、デコードされたデータは 0x76の部分が0x00となり自然なデータストリームになる．上記のデータに対して 0x76 でXOR演算を施すと、
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
00000000: 00 01 00 00 00 15 01 00 00 04 00 50 47 44 45 46 ...........PGDEF 00000010: 93 72 98 5F 00 03 A2 50 00 00 00 E4 47 50 4F 53 .r._...P....GPOS 00000020: A7 30 2B 67 00 03 A3 34 00 01 01 FA 47 53 55 42 .0+g...4....GSUB 00000030: A5 30 BD 95 00 04 A5 30 00 00 BA 82 4C 54 53 48 .0.....0....LTSH 00000040: 86 8C 92 98 00 00 1F 28 00 00 07 42 4F 53 2F 32 .......(...BOS/2 00000050: AC 89 66 E7 00 00 01 D8 00 00 00 56 56 44 4D 58 ..f........VVDMX 00000060: 58 C4 60 3B 00 05 5F B4 00 00 05 E0 63 6D 61 70 X.`;.._.....cmap 00000070: 9C 78 71 98 00 00 A1 B4 00 00 0B DA 63 76 74 20 .xq.........cvt 00000080: 00 2A 00 00 00 00 AF 08 00 00 00 02 66 70 67 6D .*..........fpgm 00000090: 06 59 9C 37 00 00 AD 90 00 00 01 73 67 61 73 70 .Y.7.......sgasp 000000A0: 00 15 00 23 00 03 A2 40 00 00 00 10 67 6C 79 66 ...#...@....glyf 000000B0: 0D AE 2B 5C 00 00 AF 0C 00 02 59 C8 68 64 6D 78 ..+\......Y.hdmx 000000C0: E8 1E E3 A6 00 00 26 6C 00 00 7B 48 68 65 61 64 ......&l..{Hhead 000000D0: EF 6D 9B 09 00 00 01 5C 00 00 00 36 68 68 65 61 .m.....\...6hhea 000000E0: 14 33 0C B6 00 00 01 94 00 00 00 24 68 6D 74 78 .3.........$hmtx 000000F0: B0 41 38 E4 00 00 02 30 00 00 1C F8 6B 65 72 6E .A8....0....kern |
となる．何となくちゃんとした意味のある？バイナリデータぽくなったでしょう(笑)
暗号化が解けたと言ってもこのままでは単純なバイナリデータのままなので、何が何だか分からないのでWindowsやMac OS のフォントツールで中身を確認して見ることにする．
006-D0952-05.binのフォント情報
006-D0952-06.binのフォントの情報
これらのフォント情報から、Monata 600 で使われているフォントは “Sakkal Majalla” というUNICODEに対応した True Type Fontデータであることが分かる．Garminの最新機種はUNICODE対応になっており、FONT環境さえ整っていれば直ぐにでも日本語表示ができそうなものだが、やはり何か特殊な仕掛けでも組み込んであるのだろうか．
WEB上で紹介されているVL-Gothicフォントの情報
WEB上で一般的に紹介されている英語版の日本語対応化に関する記事では地図データの文字化けの話がでてくるが、これなどはSHIFT-JISの文字空間固有の問題で、英語版のファームウェアが “SAN FRANSISCO” のような記述を “San Fransisco” のように先頭の文字以外を無理矢理小文字に変換してしまう仕様によるものだろう．
日本語の “山” が “屍” に文字化けするのは SHIFT-JISの “山” (0x8E52) の２バイト目が勝手に小文字（ R “0x52” → r “0x72″ ） に変換されて、”屍” (0x8E72) になるためで、SHIFT-JISで記述された文字コードを無理矢理英語版ファームウェア上で表示しているために起きる現象だろう．
現在日本で売られている某代理店扱いの日本語版の新しい機種がどのような文字コードを前提に作られているのか不明だが、WEBサイトで配布している山小屋情報のPOIファイルの文字コードがSHIFT-JISであることからも、ひょっとすると日本語版のファームウェアは相変わらずSHIFT-JISのままなのかもしれない．
英語版のファームウェアのバージョンに対して日本語版のファームウェアのバージョンはあまりにも掛け離れているのでいつも不思議に思っていたが、日本語バージョンのファームウェアだけ姑息な手段の日本語化対応を無理矢理導入したためガラパゴス化してしまい、最新のファームウェアの流れから取り残されてしまっているのかもしれない．
