Leon's Blog

　　早晨上班一到实验室，weekface告诉我说实验室的那台服务器貌似出问题了。他之前写过一个crontab脚本来每天执行一次备份任务，结果今天上去一查，已经不执行好久了，然后查crontab -l，他的那句任务竟然消失不见了，取而代之的指向了一个莫名其妙的脚本。

　　我立刻上去看，因为从没遇到这种情况，首先想到的会不会是实验室有同学上来动过，于是问了一下，房间里知道root密码的一共就四个同学，依次询问都说没有动。一边问着，一边看那个脚本的内容，立刻懵了，里面是一些很难阅读的shell命令，这才意识到不妙，出事了。然后查当前在线用户，结果who命令竟然返回的是空！接着last，我靠last也被替换了。赶紧去拔了网线，已经很明显了，我们服务器被黑了。

　　接下来一步一步去查找蛛丝马迹。who、last命令已经直接被替换了，root用户的.bash_history已经被我们这几天的新操作给覆盖掉，/var/log/secure也被清空，很干净嘛。然后看crontab修改记录，时间是Jun 27 17:27:21，这时上个周日，这个时间我们都没人上来动过服务器，所以判断这个时间就是被黑的时间。原来已经这么久了我们都没发现，真汗。。。然后查看是否有什么损失，服务器上在跑的服务有http、mysql、svn、ftp这几个，这几个服务都没有被添加账号，其实就我们做东西的这水平，真没什么值得别人费尽周折来偷窥甚至偷窃的。即便如此，还是心有余悸。

　　那个神秘的脚本是窥视所有破坏的关键，比较长，改天再分析。跟weekface反思，本来这台服务器跑的centos版本很低了，应该有很多漏洞，并且我们的防范意识一直不强，root密码仅仅是一个10位的纯英文，很容易就被暴力破解了，而且shell的roo密码还跟mysql的root密码是一样的，再而且吧，当时我为了能够回宿舍后，ssh远程回实验室继续干活（唉，一言难尽哇），还把这台服务器的22端口从路由器上映射了出去……这不是自己找着被人黑么……

　　Android的底层是纯粹的linux内核，可以简单的理解为上面跑了个Dalvik Java虚拟机而已。因此，构建android上C/C++的交叉编译环境也就成为了一个很大的需求。特别是对于已经取得root权限的机器，如果能直接运行按需编译的二进制文件，那么将可以做很多有意义和有趣的事情。

　　很不幸，Google没有直接给出如何建立这个交叉编译环境，但是我们可以借助Google提供的强大的NDK (Native Development Tools)来达到这一目的。NDK的本来目标是编译得到.so动态链接库文件，然后通过JNI提供给上层的Java调用，从而实现C/C++程序的简易迁移。而编译.so和编译成二进制可执行文件的过程是完全一样的，这就给了我们可以发挥的空间。

　　有两种方式获取交叉编译所需的工具链：git下prebuilt这个project或者直接去下载NDK，我这里arm-eabi的版本是最新的4.4.0。

1

git clone git://android.git.kernel.org/platform/prebuilt.git

　　然后创建一个helloworld.c文件。

1
2
3
4
5
6

//// root@delleon:~/android/myapp# cat helloworld.c
#include <stdio.h> 
int main() { 
  printf("HelloWorld!\n"); 
  return 0; 
}

　　接下来创建Makefile文件。注意修改其中的NDK_DIR和SDKTOOL为自己的目录，修改APP为自己的待编译程序主文件名。另外注意自己的arm-eabi的版本，若有变化则也需要修改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

#### root@delleon:~/android/myapp# cat Makefile 
APP=helloworld
 
NDK_DIR := ~/android/android-ndk-r4
NDK_HOST := linux-x86
SDKTOOL := ~/android/android-sdk-linux_86/tools
 
TOOLCHAIN_PREFIX := $(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/bin/arm-eabi-
CC := $(TOOLCHAIN_PREFIX)gcc
CPP := $(TOOLCHAIN_PREFIX)g++
LD := $(CC)
 
COMMON_FLAGS := -mandroid -ffunction-sections -fdata-sections -Os -g \
	--sysroot=$(NDK_DIR)/build/platforms/android-5/arch-arm \
	-fPIC \
	-fvisibility=hidden \
	-D__NEW__
 
CFLAGS := $(COMMON_FLAGS)
 
CFLAGS += -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -DANDROID -DSK_RELEASE -DNDEBUG
 
CFLAGS += -UDEBUG -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -ffunction-sections -funwind-tables -fstack-protector -fmessage-length=0 -Bdynamic
 
CPPFLAGS := $(COMMON_FLAGS) \
	-fno-rtti -fno-exceptions \
	-fvisibility-inlines-hidden 
 
LDFLAGS += --sysroot=$(NDK_DIR)/build/platforms/android-5/arch-arm 
LDFLAGS +=  -Bdynamic -Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,nocopyreloc   
LDFLAGS += -L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0 
LDFLAGS += -L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/lib/gcc 
LDFLAGS += -L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/arm-eabi/lib 
LDFLAGS += -nostdlib -lc -llog -lgcc \
	--no-undefined -z $(NDK_DIR)/build/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o $(NDK_DIR)/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o 
 
OBJS += $(APP).o 
 
all:    $(APP) 
 
$(APP):    $(OBJS) 
	$(LD) $(LDFLAGS) -o $@ $^ 
 
%.o:    %.c 
	$(CC) -c $(CFLAGS) $< -o $@ 
 
%.o:    %.cpp 
	$(CPP) -c $(CFLAGS) $(CPPFLAGS) $< -o $@ 
 
install: $(APP) 
	$(SDKTOOL)/adb push $(APP) /data/local/bin/$(APP) 
	$(SDKTOOL)/adb shell chmod 755 /data/local/bin/$(APP) 
 
run: 
	$(SDKTOOL)/adb shell /data/local/bin/$(APP) 
 
clean: 
	@rm -f $(APP).o $(APP)

　　最后直接make，然后make install进手机里看一下吧。通过adb shell和手机里的Terminal等软件执行的结果是一样的。

　　后记：还有一个叫Codesourcery的工具链，下载下来有130多M，我使用它来编译helloworld时无误但是放到手机上则运行不起来。不想细究了，我认为NDK提供的工具链已经非常优秀。感兴趣的朋友可以自己试试Codesourcery。

　　昨天帮实验室买了个Linode 360的VPS，梦寐以求哇，迫不及待的去折腾。选在了加州的fremont机房，北京网通的ping值大概在210ms左右，很极品的速度了，ssh上去交互只有一点点地小卡。装的CentOS 5.5，然后配了几个shell账号，通过he.net提供的tunnel broker增加了IPv6的支持，最后装了个启用passenger-ruby模块支持的nginx。明天继续折腾。

　　下班前顺便跑了一下Unix Bench 5.1.2，硬件配置上是一颗Intel Xeon L5520 2.27GHz四核的CPU， 8M Cache, Xen虚拟化，360M RAM，16GB Hard Drive。结果如下。

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.2)

   System: li165-73: GNU/Linux
   OS: GNU/Linux -- 2.6.32.12-linode25 -- #1 SMP Wed Apr 28 19:25:11 UTC 2010
   Machine: i686 (i386)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4533.5 bogomips)
          Hyper-Threading, MMX, Physical Address Ext
   CPU 1: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4533.5 bogomips)
          Hyper-Threading, MMX, Physical Address Ext
   CPU 2: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4533.5 bogomips)
          Hyper-Threading, MMX, Physical Address Ext
   CPU 3: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4533.5 bogomips)
          Hyper-Threading, MMX, Physical Address Ext
   18:35:04 up 1 day,  2:19,  1 user,  load average: 0.00, 0.00, 0.00; runlevel 3

------------------------------------------------------------------------
Benchmark Run: 二  6月 08 2010 18:35:04 - 19:03:21
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        9671772.5 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1914.6 MWIPS (10.5 s, 7 samples)
Execl Throughput                               1259.3 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        302168.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           77339.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        880748.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                              425294.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  22283.7 lps   (10.0 s, 7 samples)
Process Creation                               2188.1 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3003.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    846.0 lpm   (60.0 s, 2 samples)
System Call Overhead                         437322.7 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    9671772.5    828.8
Double-Precision Whetstone                       55.0       1914.6    348.1
Execl Throughput                                 43.0       1259.3    292.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     302168.6    763.1
File Copy 256 bufsize 500 maxblocks            1655.0      77339.6    467.3
File Copy 4096 bufsize 8000 maxblocks          5800.0     880748.9   1518.5
Pipe Throughput                               12440.0     425294.5    341.9
Pipe-based Context Switching                   4000.0      22283.7     55.7
Process Creation                                126.0       2188.1    173.7
Shell Scripts (1 concurrent)                     42.4       3003.2    708.3
Shell Scripts (8 concurrent)                      6.0        846.0   1410.0
System Call Overhead                          15000.0     437322.7    291.5
                                                                   ========
System Benchmarks Index Score                                         433.5

------------------------------------------------------------------------
Benchmark Run: 二  6月 08 2010 19:03:21 - 19:31:52
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       34776757.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     7017.4 MWIPS (10.3 s, 7 samples)
Execl Throughput                               4465.6 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        279935.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           73559.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        993067.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1545852.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 153438.0 lps   (10.0 s, 7 samples)
Process Creation                               4991.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   6503.9 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    985.1 lpm   (60.1 s, 2 samples)
System Call Overhead                        1479565.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   34776757.0   2980.0
Double-Precision Whetstone                       55.0       7017.4   1275.9
Execl Throughput                                 43.0       4465.6   1038.5
File Copy 1024 bufsize 2000 maxblocks          3960.0     279935.4    706.9
File Copy 256 bufsize 500 maxblocks            1655.0      73559.9    444.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     993067.5   1712.2
Pipe Throughput                               12440.0    1545852.2   1242.6
Pipe-based Context Switching                   4000.0     153438.0    383.6
Process Creation                                126.0       4991.3    396.1
Shell Scripts (1 concurrent)                     42.4       6503.9   1533.9
Shell Scripts (8 concurrent)                      6.0        985.1   1641.9
System Call Overhead                          15000.0    1479565.4    986.4
                                                                   ========
System Benchmarks Index Score                                         999.7

　　从Sprint 5月19号发布官方2.1升级，到今天获取root，一共用了整整半个月的时间，期间我和其他朋友尝试过各种方法来试图获取都失败，怪不得Sprint发布2.1时老是跳票，其实绝大多数时间都是去给kernel打补丁去了。期间跟regaw讨论过好几次，都进展不佳，要找kernel版本为2.6.29的提权漏洞并且最好是5月份以后泄露的，这真是一件困难的事情。

　　Regaw最后使用的办法是通过修改matt写的一个EVO 4G提权漏洞进而使帮助CDMA Hero也获取了提权。感谢大家的努力！

　　另外在root的过程中我没有刷boot.img。昨晚我帮regaw重新打包了一遍boot.img，这个新boot.img与官方ruu版本中的boot.img唯一差别就是其kernel中的build.prop文件ro.security的值从1改为0。刷与不刷的区别就是，新的boot.img可以使得开机时即进入root，而保留原来的boot.img则需要开机后手动之行su命令才可以切换到root。

　　历史会永远记住伟大的这一天（你们懂的）。需要获取root的请check这个连接：[GUIDE] How to Root Sprint 2.1 Release for CDMA Hero。

　　实验室有一个SIP相关的项目，客户端选用linphone。因为涉及到音频视频还有图形界面，所以依赖的包很杂，特别是GTK的编译安装。

1.环境：Fedora 7，内核版本2.6.21

2.需要编译的linphone版本3.2.1

3.GTK 2.18.3与Linphone 3.2.1的依赖关系如下：

Read the rest of this entry »

　　前两天捣鼓了一个USB ADSL在VMWare虚拟机中Linux系统中的安装配置和拨号方法。目前青岛网通这里，如果是在Windows环境下，拨号后能够自动获取6to4自动穿隧方式的2002开头的IPv6地址，Linux下的获取需要手动配置一下，并不是很复杂。

　　如果是Windows系统，那么通过ipconfig可以得到类似如下的信息。

C:\Documents and Settings\Administrator>ipconfig
Windows IP Configuration
 
PPP adapter AccessRunner DSL:
   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 123.235.169.32
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 123.235.169.32
 
Tunnel adapter 6to4 Tunneling Pseudo-Interface:
   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 2002:7beb:a920::7beb:a920
   Default Gateway . . . . . . . . . : 2002:c058:6301::c058:6301

　　其中IPv6地址中的7beb:a920正好对应动态IPv4的地址123.235.169.32，而IPv6网关地址中的c058:6301对应的是不变的192.88.99.1，这个192.88.99.1是一个特定的6to4中用于任意点传送的中继路由地址。需要做的就是记好这几个地址的规律。

　　然后换到Linux中，配置好ADSL，拨号后连入IPv4网，ifconfig查询到新获得的动态IPv4地址，然后按照上面的规律自行将其转换到6to4方式下2002开头的IPv6地址。例如现在得到的是124.135.17.179，对应的6to4地址为2002:7c87:11b3::7c87:11b3。下面将手动添加6to4隧道和中继路由。

[root@leon ~]# ip tunnel add 6to4 mode sit remote any local 124.135.17.179
[root@leon ~]# ip link set dev 6to4 up
[root@leon ~]# ip addr add 2002:7c87:11b3::7c87:11b3/16 dev 6to4
[root@leon ~]# ip -6 route add ::/0 via ::192.88.99.1 dev 6to4 metric 1026

　　添加完后通过ifconfig可以看到新多出的网卡6to4，同时ping6一下ipv6.google.com已经可以正常的显示结果。

[root@leon ~]# ifconfig
6to4      Link encap:IPv6-in-IPv4
          inet6 addr: 2002:7c87:11b3::7c87:11b3/16 Scope:Global
          inet6 addr: ::124.135.17.179/128 Scope:Compat
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)
 
nas0      Link encap:Ethernet  HWaddr 00:08:5C:14:C0:FB
          inet6 addr: fe80::208:5cff:fe14:c0fb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:275 errors:0 dropped:0 overruns:0 frame:0
          TX packets:281 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23972 (23.4 KiB)  TX bytes:19561 (19.1 KiB)
 
ppp0      Link encap:Point-to-Point Protocol
          inet addr:124.135.17.179  P-t-P:124.135.17.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:236 errors:0 dropped:0 overruns:0 frame:0
          TX packets:236 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:20202 (19.7 KiB)  TX bytes:9883 (9.6 KiB)

[root@leon ~]# ping6 -c 4 ipv6.google.com
PING ipv6.google.com(tx-in-x68.google.com) 56 data bytes
64 bytes from tx-in-x68.google.com: icmp_seq=1 ttl=58 time=384 ms
64 bytes from tx-in-x68.google.com: icmp_seq=2 ttl=58 time=385 ms
64 bytes from tx-in-x68.google.com: icmp_seq=3 ttl=58 time=387 ms
64 bytes from tx-in-x68.google.com: icmp_seq=4 ttl=58 time=390 ms
 
--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3396ms
rtt min/avg/max/mdev = 384.629/386.821/390.147/2.146 ms

　　总结配置过程，首先观察windows下6to4方式IPv4地址与IPv6地址的对应关系及其中继路由地址，然后在Linux中添加隧道，设置6to4网卡，添加IPv6地址和中继路由，最后测试成功。

　　延伸阅读：http://en.wikipedia.org/wiki/6to4，http://en.wikipedia.org/wiki/IPv6

　　鉴于北京和山东网通已经提供原生ipv6服务（via newboysyb@newsmth）提供了6to4方式的ipv6服务，不过家里的路由器和vmware目前根本就不支持ipv6穿透。为了将ipv6充分利用起来，打算在VMWare中的Linux环境下进行USB ADSL的拨号，这样就跨越了路由器的限制。很繁琐，研究了一个上午才搞定。

1.可行性分析

　　网络环境：青岛网通ADSL
　　硬件设备：大亚科技ADSL USB Modem，型号DB101-A（Conexant芯片）
　　操作系统：VMWare Workstation 6.5.0虚拟机下的Fedora 10（内核版本2.6.27.5）

　　整个过程之所以繁琐，最重要的原因是这个ADSL是USB接口的，要像学校里武汉电信ADSL使用的都是RJ-45接口从而system-independent也就舒服了。所以，首先设备必须被kernel所支持，幸运的是一般比较新的kernel都是没有问题的。然后需要检测一下自己的USB ADSL Modem是否被Conexant  AccessRunner芯片的Linux驱动所支持。简单方法如下图，在Windows的设备管理器中查询该设备的16进制Vendor ID和Product ID，然后看是否在这个网页http://accessrunner.sourceforge.net/modems.shtml所示的列表中。如若不然，奉劝早点收手，后面一些都是白费功夫。

2.让USB ADSL穿透VMWare

　　这一步的目的是屏蔽掉VMWare这层马甲的影响，让Linux客户机能够“直接”存取这个USB ADSL设备。方法是在虚拟机客户端的设置页中，将USB Controller的Connections三个选项都打勾，然后重新启动Linux客户机，在VMWare窗口的右下角应该就出现了新的USB设备，指向它时会出现“Conexant ADSL USB Modem”字样的提示，然后点击它选择Connect (Disconnect from Host)，这样主机便会失去设备连接，转而让Linux客户机获取。

Read the rest of this entry »

　　新版本特点：主要解决了明文存储Gmail账号信息和飞信账号信息而导致的不安全问题。可以真正的worry free。

　　其实很好办，无非是通过shc来将shell脚本加密，生成二进制文件，就无法明文观察到密码了。有人会问，shc的加密真的那么可靠吗？一般来说是安全的，除非使用gdb等调试工具来获取源代码，这种安全级别对我们来说已经足够了。

　　如同前一版本一样，fGmail的获取地址在这个Google Code的工程里面。欢迎试用。