见geohop的blog:
http://geohotps3.blogspot.com/2010/01/hello-hypervisor-im-geohot.html
坚持了三年多,SONY到底是老大。。。
见geohop的blog:
http://geohotps3.blogspot.com/2010/01/hello-hypervisor-im-geohot.html
坚持了三年多,SONY到底是老大。。。
doubanclaime67571027e9d9184
累了,搞点轻松的玩意。
convert -depth 8 splash.png rgb:splash.raw
rgb2565 < splash.raw > splash.raw565
然后把splash.raw565烧入flash就好
fastboot flash splash1 splash.raw565
android系统是一个典型的嵌入式linux,基础是linux kernel,整个android框架运行于一个称为dalvik的虚拟机之上,因此app是平台无关的,如果没有使用特殊的硬件,在armv6上运行的app可以直接放在android on mips中一致运行。事实上android为常用的硬件(gps,加速度感应等)提供了jni的接口,移植时只要重新把硬件操作包裹成.so供框架调用。
flash分为几个block:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 “misc”
mtd1: 00500000 00020000 “recovery”
mtd2: 00280000 00020000 “boot”
mtd3: 05a00000 00020000 “system”
mtd4: 05000000 00020000 “cache”
mtd5: 127c0000 00020000 “userdata”
mtd6: 20000000 00020000 “msm_nand”
#
boot存放kernel和ramdisk,dump出来后需要split_bootimg.pl或者unpack-H.pl来把两者分离出来。boot区的结构如下:
format (from bootimg.h)
** +—————–+
** | boot header | 1 page
** +—————–+
** | kernel | n pages
** +—————–+
** | ramdisk | m pages
** +—————–+
** | second stage | o pages
** +—————–+
**
** n = (kernel_size + page_size – 1) / page_size
** m = (ramdisk_size + page_size – 1) / page_size
** o = (second_size + page_size – 1) / page_size
header中存放kernel和ramdisk的偏移信息:
header_format (from bootimg.h)
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
这样系统就可以在启动时找到kernel和ramdisk。
ramdisk结构如下
$ tree root -p
root
|– [drwxr-xr-x] data
|– [-rw-r--r--] default.prop
|– [drwxr-xr-x] dev
|– [-rwxr-xr-x] init
|– [-rw-r--r--] init.goldfish.rc
|– [-rw-r--r--] init.rc
|– [-rw-r--r--] init.sapphire.rc
|– [drwxr-xr-x] proc
|– [drwxr-xr-x] sbin
| `– [-rwxr-xr-x] adbd
|– [drwxr-xr-x] sys
`– [drwxr-xr-x] system
android不使用init.d管理启动过程,init读取init.xxx直接管理启动过程,主要完成重要目录、文件、环境变量的建立,挂载block,启动服务等。
system block存放系统目录,启动的时候ro挂载在ramdisk的/system下:
$ tree -p system -L 1
system
|– [drwxr-xr-x] app
|– [drwxr-xr-x] bin
|– [-rw-r--r--] build.prop
|– [drwxr-xr-x] etc
|– [drwxr-xr-x] fonts
|– [drwxr-xr-x] framework
|– [drwxr-xr-x] lib
|– [drwxr-xr-x] usr
`– [drwxr-xr-x] xbin
framework存放android框架文件,app存放系统自带的apps,以.apk的形式,不可由用户卸载。其他的目录沿袭linux传统。
userdata block存放用户数据,启动的时候rw挂载到/data,用户安装的apps存放于这里,apps的配置文件也在此目录中。
recovery block 存放一个小型的rootfs,recovery模式启动的时候会挂载此区域,此时系统一些基本的功能用于备份还原等管理功能。recovery模式下init过程较为简单,启动adbd服务后就执行recovery程序接受用户操作:
$ tree -p recovery -L 3
recovery
`– [drwxr-xr-x] root
|– [drwxr-xr-x] data
|– [-rw-r--r--] default.prop
|– [drwxr-xr-x] dev
|– [drwxr-xr-x] etc
|– [-rwxr-xr-x] init
|– [-rw-r--r--] init.goldfish.rc
|– [-rw-r--r--] init.rc
|– [-rw-r--r--] init.sapphire.rc
|– [drwxr-xr-x] proc
|– [drwxr-xr-x] res
| |– [drwxr-xr-x] images
| `– [-rw-r--r--] keys
|– [drwxr-xr-x] sbin
| |– [-rwxr-xr-x] adbd
| `– [-rwxr-xr-x] recovery
|– [drwxr-xr-x] sys
|– [drwxr-xr-x] system
`– [drwxr-xr-x] tmp
Linux localhost 2.6.21.7 #143 SMP Thu Nov 26 01:46:05 UTC 2009 mips GNU/Linux
替换了linux的协议栈,总算跑通了一个数据包,加解密都没问题了,明天开会确定下一步方案。
今天同科室聚餐,吃的不错,聊的很好,只是分了两桌所以交流圈小了些。
单板的初步调试也通了,之后就要同另一部分合并,争取赶在月底前完成。
^ω^
对路由和交换的部分兴趣不大,但还是得好好参与设计,只是苦于之前产品的设计文档不太全,努力寻找中。
linux的内核开发方面没搞啥新东西,只是把原来arm上做的事情移到mips上,好吧,其实还是会很不一样的,但那部分仍未开始。
总之处于很微妙的状态,不知道这个项目会进展到什么程度,会重新设计开发还是接续完善维护。。。
供方便查询
4301 Security Architecture for the Internet Protocol
4302 IP Authentication Header
4303 IP Encapsulating Security Payload (ESP)
4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
4306 Internet Key Exchange (IKEv2) Protocol
4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
4308 Cryptographic Suites for IPsec
4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
4807 IPsec Security Policy Database Configuration MIB
4809 Requirements for an IPsec Certificate Management Profile
4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
4869 Suite B Cryptographic Suites for IPsec
4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels
4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec
5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways
5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
5406 Guidelines for Specifying the Use of IPsec Version 2
2401 4301
2402 4302
2403 The Use of HMAC-MD5-96 within ESP and AH
2404 4305
2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
2406 4305 4303
2407 4306
2408 4306
2409 4306
2410 The NULL Encryption Algorithm and Its Use With IPsec
3585 IPsec Configuration Policy Information Model
3948 UDP Encapsulation of IPsec ESP Packets
mips, ipsec, linux kernel, linux driver
半高负荷中。。