APK ファイルの署名の仕様 - urandroid’s blog
APK ファイル (や一部の jar ファイル) において利用される「署名」の内部仕様について解説し，およびアルゴリズム的に OpenSSL 等を利用して自力で署名をおこなってみる。誰得企画であるが，せっかく調査した (そして署名つき JAR ファイルの仕様のひどさに吃驚した) のでメモとして残しておく。 はじめにざっくりいうと，APK ファイルの署名の仕様は Java における JAR ファイルの署名 (のサブセット) に独自仕様を追加したものである。 build/tools/signapk/SignApk.java を読むのが一番わかりやすい。 以下のサンプルでは build/target/product/security/ に存在する testkey.pk8 と testkey.x509.pem*1 を署名用鍵・証明書として利用する。 testkey.pk8RSA 秘密鍵 (の PK
edify script 文法大全 - urandroid’s blog
注意: 以下の記述は Froyo (2.2) 時点のソースに基づく リカバリモードのアップデータ (update.zip) で使われるアップデータスクリプトは Donut (1.6) 以降 edify というミニスクリプトが採用されている。 edify の文法はおおまかに次のような特徴をもつ。 一見 C 風*1だが異なる部分も多い 型はおもに文字列。ほかに BLOB (ファイルの中身) と NULL も一応ある (NULL はほとんど使われていない) 変数はない ユーザ定義の関数やプロシージャもない 文法については bootable/recovery/edify/README にて説明されている。 bootable/recovery/edify/README の訳 donut 以降では edify という新しい簡易スクリプト言語でアップデートスクリプトを書く。 edify は以前のスクリプ
Android のブートモード - urandroid’s blog
通常ブート MTD の boot 領域をルートツリーとし，system, userdata, cache 等をマウントして起動する。 リカバリーブート MTD の recovery 領域をルートツリーとする。他のブロックをマウントするかどうかは知らない。 起動方法 なんらかの物理キーの組み合わせで起動すると移行できる場合が多い (デバイスによって異なる) adb reboot recovery でいける なんらかのアプリを使う fastboot かなり boot loader レベルに近い素の環境？fastboot プロトコルによりホストとやりとりする，らしい。 Fastboot - Android Wiki Android Fastboot - eLinux.org 機能 各 MTD ブロックを flash したり消去したりできたりする (危険) ホスト上のカーネルや initramfs
リカバリイメージの解体と再構築 - urandroid’s blog
フラッシュメモリストレージへの直接アクセス - urandroid の続き。 なお，たいていの Android 端末ではリカバリイメージと通常のブートイメージは同じ構造をしている*1。リカバリ時であっても Linux カーネルが立ち上がり，通常のブート時と異なる /init.rc ((この init.rc では，最小限の recovery プログラム (サービス) を起動する。必要がない限り /system パーティションや SD Card をマウントしない。))を実行するだけである。つまり，端末機器からみて通常起動とリカバリ起動の駆動の仕方はかわらない。どのパーティションを kernel + root ramdisk として利用するかが違うだけである((このため，一部の機種のハッカーは実験用のカーネルやシステムをリカバリパーティションに焼きこんでテストしたりするらしい。(なお fastb
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
