honeylab's blog

各種ハードウェアの改造、主にファミコンミニなどをやってます（ました）

イオシスで売ってる翻訳機 VT300LをAndroid端末として自由に使う、の前に

akiba-pc.watch.impress.co.jp

 

こんなものを見つけました。

機能などを考えると、LinuxないしAndroidが入っているような気がしましたので
早速、調べてみることにしました。

どうやら、国内代理店が輸入していて、技適があるようです。

総務省の技適検索から型番を検索すると、内部の写真を見つけることができました。

 どうやら、結構遊べそうです。
イオシスの通販サイトを見てみましたが、この時点で見つけられませんでした。

そのため、メルカリを見てみていると、この機種の前の機種である「TW30A SpeakMe」というものを見つけました。どうやら同じ会社が関係しているようです。

…というか、どうやらTW30AとこのVT300L、基板が同じようです…

 

とりあえず、こいつを調達して、中身を解析してみることにしました。

というか、どうもこいつは去年、ツクモで大量入荷・特価販売されていたもののようです。

akiba-pc.watch.impress.co.jp

 

f:id:honeylab:20210320030532p:plain

 

到着して早速分解します。基板のシルクに親切にもTX、RXが書いてあるためUSBシリアル変換でPCに接続して起動します。

すると、想定通りLinux→Androidが起動していることがわかりました。

 

 Androidが起動しているなら、adbでshellなどの操作ができることを期待してしまいます。
USBで接続すると、確かにADBインターフェイスが現れましたが…
接続しようとすると"closed"というメッセージが出て切断されてしまいます。
どういうこっちゃ。

ADBインターフェイスを使えるように

Image

とりあえず、シリアルコンソールから最低限の操作ができます。

この端末は「翻訳機」として売られていますので（というか、翻訳機としての性能はなかなかいい感じです。このまま使ったほうがいいいと思うんですが…）

Androidのホーム画面や設定画面を表示することができません。
しかし、シリアルコンソールからコマンドを入力することで、Androidの設定画面を表示することができました。

設定画面の中、ホームアプリの設定を出してみると、どうやら翻訳アプリがホームアプリとして設定されていましたが、なんと通常のホームアプリとして使用できる「Launcher3」が残されていました。

 これに切り替えると、普通のAndroidとしてのホーム画面が現れました！

まずはここまで、順調に来ているようです。

しかし、シリアルコンソールからの操作しかできないのでは本体のふたが閉められません。

なんとかadbで接続できるようにしてみたいです。

この翻訳機のCPUはMediaTekです。MediaTekのスマートフォンでは、「SP FlashTool」というアプリを使用して、ファームウェアの書き換えなどができる環境があります。

このアプリを使用してシステムイメージを吸い出し、原因を探ってみることにしました。

 吸い出したシステムイメージを、起動中に表れていたパーティション情報と比較し、ファイルシステムとしてマウントしてみます。

 adbでPCから接続する際、Android側ではadbdというデーモンが動作しています。
このデーモンが何か特殊な操作をしていて、特定の手順でないと動作しないのではないか、と推測し、adbdを解析してみます。

 どうやら、ここに違いがあるようです。

この端末に内蔵されたadbdは、Android環境の環境変数の値によって挙動が切り替わるようになっていました。本来、この値はシステムに組み込まれていて変更しにくいものですが、本機はシリアルコンソールが有効になっているため、そこから書き換えてみました。

すると、見事にadbが接続でき、shellが利用できるようになりました。

しかし、この環境変数の書き換えは起動中の一時的なものなので、恒久的にするには起動ファイルシステムを書き換える必要がありそうです。

 さて、adbも動作するようになったら、あとは自由にAPKをインストールできれば普通のAndroid端末として使えるようになります。

 

しかし、…　adb pm install を行っても、INSTALL_FAILED_INVALID_APK のエラーでインストールができません。
INVALID_APKというので、APKの中身をいろいろ確認してみますが問題なさそうです…

あれー？？？

いったい何が起きているのか詳細なログを探してみると、logcatの出力内にヒントがありました。

 isWhiteListApplicationかどうか、というチェックを行っているようです。
やはり専用端末、このように勝手にアプリをインストールされては困ります。
そのため、ホワイトリスト方式でAPKのインストールを撥ねているようです。

このメッセージでググってみましたが、他に実装されている例は見つかりません。
つまり、このベンダが独自にホワイトリストを実装していると思われました。

さて、ではこの部分をどうしようか。ホワイトリストを編集するのはブラックリストの編集より大変です。
これはハッカーの勘ですが、先ほどのadbdのように、何らかのフラグがシステム内に存在すると期待し、APKをインストールする部分を解析してみることにしました。

Androidのパッケージマネージャ「pm」を解析する

Androidのシステム解析はあまりやったことがありませんが、どうにかなるだろう、とソースコードやファイルシステムを漁っていくと、どうやらpmコマンドは /frameworkディレクトリの下にjarファイルとしてインストールされていることがわかりました。
しかし、このjarファイルはほぼ空で、実態はその下、にodexファイル、として存在しているようでした。

f:id:honeylab:20210320033306p:plain

 

f:id:honeylab:20210320033428p:plain

odexファイルはELFフォーマットのバイナリです。

 

f:id:honeylab:20210320033541p:plain

 

…しかし、pmコマンドは実際にはAndroidコアのAPIを呼び出しているだけで、その実装はPackageManagerServiceというクラスに実装されていることがわかりました。

その部分はどこにあるかを調べてみると、実態は /framework/arm/boot.oat というバイナリに実装されているようです。
さて、これを解析することができるでしょうか。

boot.oatを解析する

forum.xda-developers.com

調べていくと、このページのやり方でoatファイルをデコンパイルできる、と書いてありました。
（「java -jar baksmali.jar -x -c boot.oat -d framework NAME.odex -o out」の部分ですが、この部分間違いがあり、-xではなく x が正解です）

その通りにやってみると…

おお！smaliファイルとやらがたくさん生成されました。

f:id:honeylab:20210320034404p:plain

まさに、今回求めているPackegeManagerServiceの逆コンパイル結果です。

検索していると、この部分でAPKのチェックを行っているようです。

 このjavaアセンブリコード、正確に読むのはめんどくさそうですが、明らかに怪しい「const-string/jumbo v4, "ro.yuntian.kyt"」という部分が見えます。

どうやら、このプロパティが怪しい、ということでシリアルコンソールからこの値を適当に、１　と設定してみました。

すると…

これまで絶対に成功しなかったAPKファイルのインストールが成功しました！！！

 しかし、そのあと二つ目がインストールできずに悩みます…
とりあえず再起動して、改めてプロパティを設定したら続けてインストールできました。

 

やはり、ファイルシステムを改変してプロパティを恒久化するのがよさそうです。

ここまで、VT300Lが届くまで、このTW30Aで解析していましたが、おそらくこれと同じ手法でVT300Lが解析できると思っています。

 

 

うまくいくかな？

それは次の記事で。