仙石浩明の日記: Android 端末 IS01 のカーネルを入れ替えてみた〜さよならデッカード LSM

2010年12月4日

Android 端末 IS01 のカーネルを入れ替えてみた〜さよならデッカード LSM

先週末 IS01 で root 権限が必要なアプリが使えるようになったばかりなのに、そのわずか 4日後、スマートフォン＠2ch掲示板に以下の書き込みがあり、カーネル空間への侵入口が明らかにされてしまった。一番乗りを果たした goroh_kun さんに敬意を表しつつも、 IS01 のプロテクトがこの程度だったことが残念でもある。「root を取られても大丈夫な作りになっている」と開発者が豪語し、しかも IS01 の発売から 5ヶ月間も破られなかったのだから、さぞかし鉄壁の守りなのだろうと思っていたのに、こんな分かりやすい穴があったとわ... (負け惜しみ ^^;)。

【ROM焼き】au IS01 root2　〜わたくし達も未来へ〜

...

317 ：goroh_kun：2010/12/01(水) 03:14:21 ID:LGLTLBmZ

自動起動仕込むところを大体見つけました。
どなたか協力お願いします。

/data/の直下にlocal.propを置く
ここで、内容をoverrideできます。
サービス起動時のおダイナミックライブラリがある
サービスプログラムを探す。

getpropしてみると、

rild.libpathが/system/lib/libril-qc-1.soといかにも起動時に使っていそう。
rildaemonから使われているプラグインと思われます。

そこで、
local.propの中身を
rild.libpath=/data/lib/libril-wrapper.so
rild.wrapper.cmd=/data/rootkit.boot.sh
rild.libpath2=/system/lib/libril-qc-1.so

で、このプラグインを/data配下から読み出されるようにして、
libril-wrapper.soにて、ダイナミックロード時に
自動実行したいプログラムを指定できるようにします。
で、自動実行したいプログラムをlibril-wrapper.soで実行後
本来のrild用のプラグインをロードして、rildに引き渡すようにします。

これでいけるのではないかと思っているのですが、やるよって方は
いらっしゃいますか？

rild.libpath プロパティは、 RIL (Radio Interface Layer) デーモン rild が参照している。 rild は rild.libpath の値をダイナミックライブラリのパス名として dlopen(3) に渡し、 dlsym(3) でライブラリ内の関数 RIL_Init 呼び出す。つまり、 rild が起動される前に rild.libpath の値を書き換えておけば、 rild に任意のプログラムを起動時に実行させることが可能になる。

したがって守る側 (つまり開発者の立場) から考えると、 (1) rild.libpath が書き換えられないようにするか (2) 任意のプログラムの実行が脅威にならないよう、 rild 起動前に防御を固めてしまえばよい。

プロパティは、以下の 4 つのファイルで設定できる。どれか一つでも改変可能であれば、 (1) の方法は使えない。

/default.prop
/system/build.prop
/system/default.prop
/data/local.prop

IS01 の場合、 (たとえ root が奪取されても) /system ディレクトリ下は改変できないようになっている。また、 /default.prop は initramfs 内のファイルなので、改変しても再起動すれば揮発してしまう。だから上記 4ファイルのうち /data/local.prop 以外は改変不可能。

Android では /system ディレクトリ下は read only でも構わないが、 /data ディレクトリ下は Android 動作中に書き換えることが前提となっている。もちろん /data/local.prop だけは書き換え不可能にするとか、あるいは再起動時に自動的に /data/local.prop を書き戻す、という方法も考えられなくもないが、そもそも論で言えば /data/local.prop は、システムのプロパティをオーバーライドするための設定ファイルであって、その本来の趣旨からいえば書き換え不可能にすることは望ましくない。

したがって守るなら (2) の方法が自然。というか、 /data/local.prop で rild.libpath の値を変更されても、 rild はユーザ空間で動くデーモンなのだから、本来は「任意のプログラムの実行」が可能でも脅威にはならないはず。

ところが IS01 の開発チームは致命的なミスを犯した。

IS01 の /init.rc から引用:

        ...

on boot
# basic network init
    ifup lo
    hostname localhost
    domainname localdomain
        ...

        setprop net.pppbtdg.servIp 1.2.3.4
        setprop net.pppbtdg.clientIp 1.2.3.5
        setprop net.pppbtdg.portspeed 115200
        setprop net.bt.data.option 0 # 0 - eth0 ; 1 - gprs no dial required; 2 - gprs dial required

## SHARP_EXTEND MotionEmojiFactory 2009.10.14 Add-Start
       setprop ro.config.libmotionemoji libmotionemoji_impl.so
## SHARP_EXTEND MotionEmojiFactory 2009.10.14 Add-End

    class_start default

# 2009.10.06 sbc H.Nozaki Add
        setprop wifi.interface wlan0

# SC Shirakawa 2010/03/10 <- prohibit insmod after start-up 
insmod /system/lib/modules/unifi_sdio.ko
setprop wlan.driver.status loaded
# SC Shirakawa 2010/03/10 -> prohibit insmod after start-up 
write /proc/sys/kernel/modules_disabled 1

## Daemon processes to be run by init.
##
service console /system/bin/sh
    console
        ...

service ril-daemon /system/bin/rild
    socket rild stream 660 root radio
    socket rild-debug stream 660 radio system
    user root
    group radio cache inet misc
        ...

「on boot」から始まる一連のブートスクリプトはデーモン類の起動前に実行される。だから普通に init.rc を記述すれば防御を完璧にした後に、デーモン類を起動することになる。そうしていれば、デーモン類に多少のセキュリティホールがあっても問題にはならなかっただろう。

ところが、何を血迷ったか sbc H.Nozaki さんは「class_start default」の後にスクリプト「setprop wifi.interface wlan0」を書いてしまった (2009年10月6日)。

「class_start default」はデーモン類の起動命令である。この行の後にスクリプトを書いても構わないが、そのスクリプトとデーモンの処理と、どちらが先に実行されるかはタイミング次第ということになる。デーモンを起動する前に実行すべきブートスクリプトは「class_start default」の行より前に書かなければならない。

sbc H.Nozaki さんが書き加えたのは、 wifi.interface プロパティの値を「wlan0」に設定する処理で、普通に考えればデーモン類の起動「class_start default」より前に書く方が素直だが、 wifi.interface プロパティを参照するタイミングはずっと後なので、どこに書こうが大差ない。なので特に問題視もされず、そのままになってしまったのだろう。

しかしながら、 sbc H.Nozaki さんがこの変更を行なった結果、 2009年10月14日時点での init.rc は以下のようになってしまう:

        ...

## SHARP_EXTEND MotionEmojiFactory 2009.10.14 Add-Start
       setprop ro.config.libmotionemoji libmotionemoji_impl.so
## SHARP_EXTEND MotionEmojiFactory 2009.10.14 Add-End

    class_start default

# 2009.10.06 sbc H.Nozaki Add
        setprop wifi.interface wlan0

## Daemon processes to be run by init.
##
service console /system/bin/sh
    console
        ...

「## Daemon processes to be run by init.」というコメント行があることも相俟って、その直前までがブートスクリプトであるかのように見えてしまう。実際は「class_start default」の前に書かなければならないのに。

その 5ヶ月後、 IS01 発表 (3月30日) の直前、 SC Shirakawa さんが IS01 のプロテクトの最大の要「write /proc/sys/kernel/modules_disabled 1」を、「## Daemon processes to be run by init.」の直前に書いてしまったことを誰が責められるだろうか。まあ、ちょっと見渡せばすぐ上に「class_start default」と書いてあるのが見えただろうから、この行の意味を少しでも考えていたらこのようなミスは避けられたかも。

「write /proc/sys/kernel/modules_disabled 1」を実行することにより、それ以降カーネルモジュールをロード (insmod) することが禁止される。すなわちカーネル空間へ侵入することが格段に難しくなる。 OS に脆弱性が無ければ (そんなことはまず無いが) カーネル空間への侵入は不可能と言ってもいい。

ところが既にデーモン類の起動命令「class_start default」は発行してしまった。後は野となれ山となれ、一斉に走り出したデーモン類において任意のコードが実行可能であれば、 insmod が禁止される前に、そのデーモンに任意のモジュールを insmod させてカーネル空間への侵入が果たせてしまう。

dmesg で見るとこんな感じ:

        ...
<6>[    0.008933] Memory: 232MB = 232MB total
<5>[    0.008960] Memory: 157824KB available (4828K code, 1499K data, 160K init)
<6>[    0.009273] Calibrating delay loop... 511.18 BogoMIPS (lpj=2555904)
<6>[    0.240166] Security Framework initialized
<6>[    0.240193] DECKARD LSM module initialized
        ...
<6>[    8.061633] init: command 'setprop' r=0
<6>[    8.061666] init: command 'setprop' r=0
<6>[    8.061699] init: command 'setprop' r=0
<6>[    8.061739] init: command 'setprop' r=0
<6>[    8.061759] init: command 'setprop' r=0
<3>[    8.061773] init: service 'console' requires console
<5>[    8.086566] init: starting 'logd'
<5>[    8.088086] init: starting 'dgstmgrd'
<5>[    8.105699] init: starting 'servicemanager'
<5>[    8.108533] init: starting 'vold'
<6>[    8.109439] init: Created socket '/dev/socket/vold' with mode '660', user '0', group '1009'
<5>[    8.111886] init: starting 'usbmgrd'
<6>[    8.112773] init: Created socket '/dev/socket/usbmgrd' with mode '660', user '0', group '1009'
<5>[    8.163386] init: starting 'debuggerd'
<5>[    8.167306] init: starting 'fotad'
<5>[    8.170679] init: starting 'ril-daemon'
<6>[    8.171473] init: Created socket '/dev/socket/rild-debug' with mode '660', user '1001', group '1000'
<6>[    8.171753] init: Created socket '/dev/socket/rild' with mode '660', user '0', group '1001'
        ...
<6>[   13.184319] init: command 'class_start' r=0
<6>[   13.184353] init: command 'setprop' r=0
        ...
<6>[   13.653133] init: command 'insmod' r=0
<6>[   13.653179] init: command 'setprop' r=0
<6>[   13.653786] init: command 'write' r=0

8.061759秒の「init: command 'setprop' r=0」が「class_start default」直前の
「setprop ro.config.libmotionemoji libmotionemoji_impl.so」を実行したときの出力。その後、デーモン類を次々と起動し、「class_start default」の実行が完了するのは 5秒以上たった 13.184319秒時点。「write /proc/sys/kernel/modules_disabled 1」を実行してようやく insmod が禁止できたのは、さらに 0.5秒もたってからで、その間に rild はカーネル空間への侵入口を提供してくれた。

goroh_kun さんの発表からわずか 2時間後の 5:28 (なんちゅー時間だ)、 goroh_kun さん自身によって、 mtd0 (カーネルイメージ), mtd2 (リカバリイメージ), mtd5 (/system) を変更可能にするカーネルモジュール msm_nand_ex.ko が発表され、これを rild に insmod させることによってカーネルイメージ等の改変が可能になった。

なので早速 (といっても平日は時間が取れないので週末になってから) カーネルを再構築してみる。 SHARP が公開している IS01 のカーネルを menuconfig してビルドする:

% make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
        ...
% make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
        ...
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
        ...
% cp -a arch/arm/boot/Image ~/tmp/IS01/kernel.bin

当然のことながら、にっくき (Android とりわけ Nexus の敵) デッカードを消す。勢い余って CONFIG_SECURITY=n にした。また、kernel/drivers/mtd/devices/msm_nand.c に、「#define CONFIG_ANDROID_ENGINEERING 1」を追加して MTD protect を丸ごと消してしまう (12/9追記: menuconfig でも CONFIG_ANDROID_ENGINEERING を設定可能なので、 msm_nand.c を書き換えるよりは menuconfig にて設定した方がよい)。これで IS01 特有のプロテクトは全て無くなる。ついでに CONFIG_SWAP=y を設定した。

--- config        2010-11-24 07:40:41.051499180 +0900
+++ .config        2010-12-04 10:30:27.037625342 +0900
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.29
-# Mon Sep 20 04:09:00 2010
+# Sat Dec  4 10:30:27 2010
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -36,7 +36,7 @@
 CONFIG_INIT_ENV_ARG_LIMIT=32
 CONFIG_LOCALVERSION="$(KERNEL_LOCAL_VERSION)-perf"
 # CONFIG_LOCALVERSION_AUTO is not set
-# CONFIG_SWAP is not set
+CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_POSIX_MQUEUE is not set
@@ -430,7 +430,6 @@
 CONFIG_DEFAULT_TCP_CONG="cubic"
 # CONFIG_TCP_MD5SIG is not set
 # CONFIG_IPV6 is not set
-# CONFIG_NETLABEL is not set
 CONFIG_ANDROID_PARANOID_NETWORK=y
 # CONFIG_NETWORK_SECMARK is not set
 CONFIG_NETFILTER=y
@@ -492,7 +491,6 @@
 # CONFIG_IP_NF_TARGET_ULOG is not set
 # CONFIG_IP_NF_MANGLE is not set
 # CONFIG_IP_NF_RAW is not set
-# CONFIG_IP_NF_SECURITY is not set
 # CONFIG_IP_NF_ARPTABLES is not set
 # CONFIG_IP_DCCP is not set
 # CONFIG_IP_SCTP is not set
@@ -1661,14 +1659,9 @@
 # Security options
 #
 # CONFIG_KEYS is not set
-CONFIG_SECURITY=y
+# CONFIG_SECURITY is not set
 # CONFIG_SECURITYFS is not set
-# CONFIG_SECURITY_NETWORK is not set
-CONFIG_SECURITY_PATH=y
 # CONFIG_SECURITY_FILE_CAPABILITIES is not set
-CONFIG_SECURITY_DECKARD=y
-CONFIG_SECURITY_DECKARD_SYSTEM_DEV_PATH="/dev/block/mtdblock5"
-CONFIG_SECURITY_DECKARD_CHROOT_PATH=""
 CONFIG_CRYPTO=y
 
 #

カーネルの次は initramfs の改変。

/init.rc における防御の要をコメントアウト:

--- init.rc.org        1970-01-01 09:00:00.000000000 +0900
+++ init.rc        2010-12-04 11:24:53.943962272 +0900
@@ -361,7 +361,7 @@
 insmod /system/lib/modules/unifi_sdio.ko
 setprop wlan.driver.status loaded
 # SC Shirakawa 2010/03/10 -> prohibit insmod after start-up 
-write /proc/sys/kernel/modules_disabled 1
+#write /proc/sys/kernel/modules_disabled 1
 
 ## Daemon processes to be run by init.
 ##

ついでに /default.prop も書き換えてより使いやすく ;-)

--- default.prop.org        1970-01-01 09:00:00.000000000 +0900
+++ default.prop        2010-12-04 11:24:59.013753953 +0900
@@ -3,5 +3,5 @@
 #
 ro.secure=1
 ro.allow.mock.location=0
-ro.debuggable=0
-persist.service.adb.enable=0
+ro.debuggable=1
+persist.service.adb.enable=1

ビルドしたカーネル kernel.bin と、 initramfs を cpio で固めた ramdisk.bin から、 mkbootimg コマンドを使ってブートイメージ boot.img を作る:

senri:/home/sengoku % fg %su
# find . | cpio -o -H newc > ~sengoku/tmp/IS01/ramdisk.bin
591 blocks
# suspend
senri:/home/sengoku % cd ~/tmp/IS01/
senri:/home/sengoku/tmp/IS01 % ls -l kernel.bin ramdisk.bin
-rwxr-xr-x 1 sengoku wheel 5312864 Dec  4 10:40 kernel.bin
-rw-r--r-- 1 root    root   302592 Dec  4 10:44 ramdisk.bin
senri:/home/sengoku/tmp/IS01 % mkbootimg --kernel kernel.bin --ramdisk ramdisk.bin --cmdline "console=ttyMSM2,115200n8 androidboot.hardware=qcom" --base 0x20000000 -o boot.img

ただし IS01 のブートイメージは、 Android Donut 標準の mkbootimg が作るブートイメージとは若干差異があった。 IS01 のブートイメージでは、 ramdisk_addr が 0x03000000 ほど後ろへずれていて、かつ padding が 2048 バイト区切りではなく 4096 バイト区切りになっていた。なので、以下のようなパッチをあてる:

--- system/core/mkbootimg/mkbootimg.c.org        2010-11-27 09:46:55.000000000 +0900
+++ system/core/mkbootimg/mkbootimg.c        2010-12-04 10:13:46.381056328 +0900
@@ -71,7 +71,7 @@
 
 
 
-static unsigned char padding[2048] = { 0, };
+static unsigned char padding[4096] = { 0, };
 
 int write_padding(int fd, unsigned pagesize, unsigned itemsize)
 {
@@ -143,7 +143,7 @@
         } else if(!strcmp(arg, "--base")) {
             unsigned base = strtoul(val, 0, 16);
             hdr.kernel_addr =  base + 0x00008000;
-            hdr.ramdisk_addr = base + 0x01000000;
+            hdr.ramdisk_addr = base + 0x04000000;
             hdr.second_addr =  base + 0x00F00000;
             hdr.tags_addr =    base + 0x00000100;
         } else if(!strcmp(arg, "--board")) {
@@ -229,10 +229,10 @@
     }
 
     if(write(fd, &hdr, sizeof(hdr)) != sizeof(hdr)) goto fail;
-    if(write_padding(fd, pagesize, sizeof(hdr))) goto fail;
+    if(write_padding(fd, pagesize*2, sizeof(hdr))) goto fail;
 
     if(write(fd, kernel_data, hdr.kernel_size) != hdr.kernel_size) goto fail;
-    if(write_padding(fd, pagesize, hdr.kernel_size)) goto fail;
+    if(write_padding(fd, pagesize*2, hdr.kernel_size)) goto fail;
 
     if(write(fd, ramdisk_data, hdr.ramdisk_size) != hdr.ramdisk_size) goto fail;
     if(write_padding(fd, pagesize, hdr.ramdisk_size)) goto fail;

Android Donut 標準と異なる点はまだあって、 IS01 のブートイメージは UBI (Unsorted Block Images) 上にある。なので ubinize コマンド (mtd-utils に含まれる) を使って「UBI 化」してからフラッシュに書込まねばならない。

senri:/home/sengoku/tmp/IS01 % ls -l boot.img
-rw-r--r-- 1 sengoku user 5623808 Dec  4 10:48 boot.img
senri:/home/sengoku/tmp/IS01 % ubinize -o ubi.img -p 128KiB -m 2048 -O 256 ubi.cfg

IS01 のブートイメージでは、 VID header offset として 256 を指定する必要があるので、 ubinize コマンドに「-O 256」オプションを指定している。また、 ubinize は設定ファイルを引数に与える必要があるので、以下のようなファイル ubi.cfg を作って ubinize を実行する。

[boot]
mode=ubi
image=boot.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=boot
vol_flags=autoresize

こうしてできた IS01 ブートイメージ ubi.img を、 adb push して IS01 に送り込み、 IS01 上で flash_image コマンドを使ってフラッシュへ書込む:

senri:/home/sengoku/tmp/IS01 % ls -l ubi.img
-rw-r--r-- 1 sengoku user 6029312 Dec  4 10:48 ubi.img
senri:/home/sengoku/tmp/IS01 % adb push ubi.img /sdcard/tmp/
1937 KB/s (6029312 bytes in 3.038s)
senri:/home/sengoku/tmp/IS01 % adb shell
$ su
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00b00000 00020000 "boot"
mtd1: 00500000 00020000 "cache"
mtd2: 00b00000 00020000 "recovery"
mtd3: 00180000 00020000 "splash"
mtd4: 00b40000 00020000 "ipl"
mtd5: 10000000 00020000 "system"
mtd6: 00300000 00020000 "log"
mtd7: 06420000 00020000 "userdata"
mtd8: 00b00000 00020000 "boot_wr"
mtd9: 00b00000 00020000 "recovery_wr"
mtd10: 10000000 00020000 "system_rw"
# flash_image recovery_wr /sdcard/tmp/ubi.img
# exit
senri:/home/sengoku/tmp/IS01 % adb reboot recovery

すでに goroh_kun さんのカーネルモジュール msm_nand_ex.ko を insmod してあるので、書込み可能な boot_wr および recovery_wr パーティションがある。ブートイメージは boot_wr と recovery_wr どちらにも書込むことができるが、まずは実験として recovery_wr へ書込んだ。 boot_wr (と system_rw) さえ変更しなければ、失敗しても文鎮化は避けられる。つまり何か問題が起きても、リセットスイッチを押せば boot パーティションから起動する。

adb reboot recovery すれば recovery パーティションから起動する。

12/9 追記: IS01 を工場出荷状態に初期化する操作を行うと、 recovery パーティションから起動して初期化処理を行うらしい (未確認)。つまり recovery パーティションに書き込んだイメージが期待されている処理 (つまり初期化処理) を行わずに、通常のブートイメージの処理 (つまり IS01 の通常の起動) を行うと、再び初期化処理に入ろうとして recovery パーティションから再起動させて無限ループに陥る恐れがある (憶測)。
もちろん、「初期化」しても書き換えたブートイメージは元には戻らないわけで、いったん boot / recovery を書き換えたら、決して「初期化処理」は行うべきではないし、「初期化処理」以外にも recovery パーティションを使用する処理があると思われる (おそらく、ケータイアップデートなど) ので、実験目的での recovery 書き換えの後は、なるべく速やかに元のイメージ (あるいは同等の処理を行うイメージ) に書き戻しておくほうが無難。

前述したように /default.prop を書き換えて「ro.debuggable=1」にしたので、使い勝手が向上している ;-) 例えば、以下のように「adb root」が可能になっている。

dmesg すると、以前は 0.240193秒あたりに出ていた「DECKARD LSM module initialized」という出力が消えているのが分かる。さよならデッカード！

senri:/home/sengoku/tmp/IS01 % adb root
restarting adbd as root
senri:/home/sengoku/tmp/IS01 % adb shell
# dmesg
<5>[    0.000000] Linux version 2.6.29-perf (sengoku@senri.gcd.org) (gcc version 4.3.5 (GCC) ) #3 PREEMPT Sat Dec 4 10:40:33 JST 2010
<4>[    0.000000] CPU: ARMv7 Processor [510f00f2] revision 2 (ARMv7), cr=10c5387f
<4>[    0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache
<4>[    0.000000] Machine: SHARP DECKARD
        ...
<6>[    0.008700] Memory: 232MB = 232MB total
<5>[    0.008720] Memory: 157952KB available (4792K code, 1480K data, 160K init)
<6>[    0.009040] Calibrating delay loop... 511.18 BogoMIPS (lpj=2555904)
<4>[    0.240286] Mount-cache hash table entries: 512
<6>[    0.240753] CPU: Testing write buffer coherency: ok
<6>[    0.242906] net_namespace: 444 bytes
<6>[    0.243606] NET: Registered protocol family 16
<6>[    0.245393] socinfo_init: v2, id=30, ver=2.0, raw_id=640, raw_ver=2
<3>[    0.245406] qsd8x50_cfg_smc91x: invalid machine type
<6>[    0.245433] Max ACPU freq from efuse data is 998400 KHz
<6>[    0.246006] ACPU running at 768000 KHz
<6>[    0.246020] 5 scaling frequencies supported.
<4>[    0.267433] bio: create slab <bio-0> at 0
<5>[    0.268873] SCSI subsystem initialized
<6>[    0.269166] msm_i2c_probe
<6>[    0.269206] msm_i2c_probe: clk_ctl 317, 369230 Hz
<6>[    0.273240] Bluetooth: Core ver 2.15
<6>[    0.273493] NET: Registered protocol family 31
<6>[    0.273506] Bluetooth: HCI device and connection manager initialized
<6>[    0.273526] Bluetooth: HCI socket layer initialized
<6>[    0.275353] NET: Registered protocol family 2
<6>[    0.275533] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
<6>[    0.275873] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
<6>[    0.276046] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
<6>[    0.276126] TCP: Hash tables configured (established 8192 bind 8192)
<6>[    0.276140] TCP reno registered
<6>[    0.276320] NET: Registered protocol family 1
<6>[    0.276713] checking if image is initramfs... it is
<6>[    0.278820] Freeing initrd memory: 292K
        ...
# dd if=/dev/zero of=/data/swapfile bs=1048576 count=64
64+0 records in
64+0 records out
67108864 bytes transferred in 11.703 secs (5734330 bytes/sec)
# mkswap /data/swapfile
Setting up swapspace version 1, size = 67104768 bytes
# swapon /data/swapfile
# free
free
              total         used         free       shared      buffers
  Mem:       158576       155480         3096            0         1184
 Swap:        64620            0        64620
Total:       223196       155480        67716
#

ついでに有効にした SWAP が使えるようになっている。フラッシュの損耗を考えると、常用はしないほうが無難?

Filed under: Android — hiroaki_sengoku @ 12:59

Comments (2)

2 Comments

はじめまして。

CyanogenModというプロジェクトのソースツリーからmkbootimgを持ってくるとパッチいらないかんじです。
https://github.com/CyanogenMod/android_system_core/raw/froyo/mkbootimg/mkbootimg.c
標準(?)のものを差し替える、という意味ではどちらも同じですが…

ご参考まで。

Comment by fukaumi — 2010年12月5日 @ 22:18
「IS01｣起動ロゴ画面で止まる回復方法は？
ご恐縮！IS01携帯アップデート後起動ロゴ画面で止まる→リセットボタン押しても電源を押して再起動の[ IS ]ロゴ画面で止まる！回復方法は？もしお判り次第にお知らせて下さいますよう今後もよろしくお願い致します。

Comment by inaka — 2011年4月5日 @ 22:50

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

仙石浩明の日記

Android 端末 IS01 のカーネルを入れ替えてみた 〜 さよならデッカード LSM

2 Comments

Android 端末 IS01 のカーネルを入れ替えてみた〜さよならデッカード LSM