生成钱包

以太坊的钱包是基于椭圆曲线数字签名算法ECDSA保护的。

因此每一个钱包对应的是一个ECDSA的密钥对。

这个密钥对在 go-ethereum 项目的 crypto/crypto.go 的 GenerateKey() 函数生成，
生成后得到一个ECDSA的私钥 (ecdsa.PrivateKey)。

以太坊所采用的椭圆曲线是 secp256k1。由于其特殊构造的特殊性，其优化后的实现比其他曲线性能上可以提高30%，有明显以下两个优点：

1. 占用很少的带宽和存储资源，密钥的长度很短；
2. 让所有的用户都可以使用同样的操作完成域运算。

生成钱包私钥代码：

1
2
3

func GenerateKey() (*ecdsa.PrivateKey, error) {
  return ecdsa.GenerateKey(S256(), rand.Reader)
}

得到私钥后，可以使用 ecdsa.PrivateKey 的 Public() 方法取得公钥 ecdsa.PublicKey。

生成一般的钱包地址

因为业务的需要，需要在C++写的Native库中调用由C语言写的SO库。

之前就已经知道，如果想在Native层上混用C语言和C++所写的代码，就必须要在C++的函数声明上增加 extern "C" 的标识，或者使用 extern "C" {} 包含多个C++的函数声明。

如果不这么做，会导致编译时出现链接器无法链接函数的问题，所提示的错误类似于
error: undefined reference to 'init(int)'。

除此之外，还有几个坑点需要注意！

使用 extern "C" {} 时，务必要把你需要链接到的C语言的库的头文件也包含在里面，如：

1
2
3
4
5
6

extern "C" {
    // C语言所写的库
    #include <openssl/xxx.h>

    void init(int id); // C++函数声明
}

并且，需要把类似于 map 这样的使用了模板的C++库放在 extern "C" 的外部。下面是错误示范：

1
2
3
4
5
6
7
8
9
10

extern "C" {
    // C++使用了模板的库
    #include <map>

    // C语言所写的库
    #include <openssl/xxx.h>

    void init(int id); // C++函数声明
}

这样会引发类似下面的错误： error: templates must have C++ linkage

下面是正确示范：

因为项目的需要，我对Android系统加载.so文件有一些些研究，
把最近看过的一些大牛的分析和现状结合一下，
写篇东西做一下笔记。

.so 文件是什么

.so 文件是 Shared Object 文件的后缀，
直白的说就是Linux系统中的“动态链接库” ，
就和Windows系统下的 .dll 文件（Dynamic Link Library）类似。

.so 文件实则是 ELF 格式的文件，和Linux的可执行文件的格式一致。

ELF 文件结构

ELF 格式的文件中的“数据”实际上是以“段”（节，英文：Section）的形式存储的。
其顺序大致符合下面的排序：

• ELF Header：ELF头部
• .dynsym：保存动态链接相关符号，记录其偏移值
• .dynstr：.dynsym 的辅助段
• .hash：快速查找符号的哈希表，类似 .dynstr
• .rel.got：数据引用修正，修正到 .got
• .rel.plt：函数引用修正，修正到 .got.plt
• .text：代码段
• 其他自定义的代码段
• .rodata：字符串常量段
• .fini_array：终止函数段
• .init_array：初始化函数段
• .dynamic：动态链接库特有，存储动态链接用到的表信息
• .got：函数的绝对地址
• .data：存放已经初始化的全局变量，静态内存分配相关
• .bss：存放未初始化的全局变量，静态内存分配相关

ELF 头部：ELF Header

其中，一切的起点都在ELF头部，其偏移量（offset）为 0。
ELF头部的结构体为 elf32_hdr 或 elf64_hdr，
在Android系统源代码的 /bionic/libc/kernel/uapi/linux/elf.h 可以找到。

以32位程序的ELF头部为例：