挂了一块希捷移动硬盘

这块希捷硬盘是我台机上硬盘里最年轻的一块，居然就挂了……
Power On Hours也就刚过一年，买来还不到两年。希捷最近真是不行……

挂掉的是Seagate Expansion 3TB，里面的硬盘是希捷酷鱼7200.12（ST3000DM001）。
花了不少功夫拆开来，里面就是一块硬盘插在一个小电路板上。
貌似这个移动硬盘散热很糟糕，最高温度超过60，平时跑着也有55+。看看其他硬盘也就40度左右的温度，可能散热不好是挂掉原因之一。
整个硬盘盒上部完全密封，就底下有些眼，难怪散热不好……

做了个盘面扫描，碰到坏块很慢所以就做了一点。貌似挺有规律，基本上是坏掉2块，好一块，坏掉2块，好7-8块，然后重复。每块大小大约是286M。第一个坏块是第三块。
这些坏掉的部分估计物理上有啥共同的地方，具体也不清楚。说这个硬盘是三碟装，没看出有啥关系……
恢复数据挺麻烦的，稍微大点的文件就可能读不出来，只好跳过去。幸好这盘才用了500G，多数也不是啥重要的数据，所以损失不大……

台机上另外的本科买的WD Elements 1TB（15862小时）一点问题也没有，开机时间都快赶上这货两倍了。
另外台机内部的其他硬盘，包括古老的西数硬盘（120G，20377小时），希捷硬盘（500G，17794小时）都没有问题。
难道传言最近希捷不行了是真的…… 以后还是避开希捷买西数算了……

胡写脚本于是又bug了

说写一个monitor进程是否在跑的脚本，本来用的是ps ax | grep $sig | grep -v grep。
这个脚本写的时候好好的，用xxx.sh &跑也没问题。但是只要一关那个term分页，就挂了……

把ps ax的内容dump出来看，居然右边被切掉了……
那当然是宽度问题，改成ps axww就好了。想想看见过别人脚本里的ps axww，原来是这个道理……

想是有term分页的时候，输出检测用的是term宽度，所以没有被切。分页干掉之后输出宽度没法检测了，于是用了个默认值，于是就被切掉了…… 加上ww之后想多宽就多宽，就不会被切了……
胡写还真是能写出奇怪的bug…… 而且要不是这次$sig出现在比较靠右的位置还发现不了…… 说不定哪天换sig就莫名其妙不工作了……

ps. 其实用pgrep -f就完了么……

Code Keyboard在BSD下的多媒体快捷键配置

在之前买了个Das Keyboard之后，这回为了在家里用搞了个Code Keyboard。
Code Keyboard自带一堆多媒体键，不过要让这些多媒体键发挥作用还要费些功夫。
刚插上去的时候，多出来一个键盘和一个鼠标设备：

ukbd2: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/1.10, addr 8> on usbus0
ums2: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/1.10, addr 8> on usbus0

作为一个键盘来说，有个鼠标设备还是很奇怪的，所以多半是用来给多媒体键的。Ports Tree里有个uhidd，https://wiki.freebsd.org/uhidd，可以用来处理这些多媒体键对应的hid事件。ukbd驱动不错，我们只要干掉ums驱动就可以了。为了这个，先配置uhidd让他干掉ums自己attach上去：

0x04d9:0x0169:0={
    detach_kernel_driver="NO"
}

0x04d9:0x0169:1={
    detach_kernel_driver="YES"
}

之后跑uhidd -h /dev/ugen0.7 (这里ugen0.7是这个键盘对应的ugen设备，-h启动HID类设备)，就会发现/dev底下多了uvhid0。
跑系统自带的usbhidctl -f /dev/uvhid0 -l -a，然后按那些多媒体键，就能看见HID状态变化的事件，例如Volume_Increase从0变到1然后变回去之类。

之后，要让uhidd把这些事件翻译成键盘按键。在配置文件的0x04d9:0x0169:1那段里加一段：

    cc_keymap={
        Play/Pause="0x54"
        Stop="0x5a"
        Volume_Decrement="0x62"
        Volume_Increment="0x63"
        Mute="0x6f"
        Scan_Previous_Track="0x7a"
        Scan_Next_Track="0x7c"
    }

，之后用uhidd -o /dev/ugen0.7重新启动uhidd，然后再跑起一个xev，就会看见有键盘事件进来。-o参数启动Consumer Control类驱动，uhidd会参考cc_keymap映射表来映射那些事件。在uhidd.conf里列出了一些一般不会用的scancode，都可以拿来映射。

之后要把那些keycode映射到X的符号名上。xev收到的是keycode，上面指定的是scancode，映射的时候用xev里收到的。修改.Xmodmap，加上一些：

keycode 92  = XF86AudioPlay
keycode 130 = XF86AudioPrev
keycode 132 = XF86AudioNext
keycode 170 = XF86AudioStop
keycode 189 = XF86AudioLowerVolume
keycode 190 = XF86AudioRaiseVolume
keycode 207 = XF86AudioMute

在跑xmodmap .Xmodmap之后，xev里看见的应该就是类似于XF86AudioMute这样的符号名而不是光keycode了。

最后做一些对应这些符号名的快捷键，例如mpc next之类，就大功告成了……

本来uhidd应该自动启动，不过貌似不靠谱，我在/etc/devd/里加了codekbd.conf:

notify 100 {
    match "system"      "USB";
    match "subsystem"   "DEVICE";
    match "type"        "ATTACH";
    match "vendor"      "0x04d9";
    match "product"     "0x0169";
    action "/usr/local/sbin/uhidd -o /dev/$cdev";
};

这样uhidd就会自动启动了……

PS. 我在学校的Arch上试了一下，音量调整直接就能用……

implicit declaration又出来害人了

说把vps迁移到64位系统后，collectd不记数据了，rrdupdate直接crash……
调试发现是implicit declaration干的好事情……
rrdupdate.c用到了basename()，但是没有引用libgen.h，于是basename()是隐式声明的。
根据古老的c的规定，隐式声明的函数返回值被当作了int，而64位系统上int是32位的。
所以本来好好的char*的返回值就被当作了int，返回值的高32位被干掉了，指针直接就飞了……
其实是有编译警告的，但是who cares……
所以c代码都该直接当c++编译，好的c代码应该可以直接编译…… 不声明就用算是什么feature，简直是个bug……
另外其实上游已经修了这个bug： https://github.com/oetiker/rrdtool-1.x/commit/d0bd4217d9fb69db9f94363087936cf93fa9b4ea，不过修完之后没有发新release，于是下游也没人管，毕竟谁喜欢用git tag打包……

在Firefox里用光大网银

// WIP，光大网银很多javascript代码貌似在ff下就有问题，这里只是说ActiveX的问题

光大网银用了ActiveX，于是看上去很难在别的系统/浏览器下用。

但其实就结果来说，那个ActiveX控件没啥用……

页面上有三个<object>，其中一个啥sign貌似啥都没干，另外俩负责加密密码/提交。

提交登录表单的时候，多数域都是空的。根据观察，控件就填了一个域：Password

为了观察那个控件都调了啥加密函数，找了个很好用的工具，叫WinAPIOverride。粗粗一看调了若干Crypt* API，于是缩小范围到各个Crypt*函数上。分析记录在 http://wiki.henryhu.net/wiki/CEB。

最后发现这个控件很匮乏，在用公钥加密了密码之后（公钥在JS里……），它蛋疼的生成了一个随机数加密了一下，之后有解密了一把，最后完全没用…… 而那个Password域，内容其实就是密码加密结果反过来之后base64一把……

分析的时候有个地方很奇怪。看上去CryptEncrypt()的输入每次都一样，但是结果每次不同…… 后来自己写了个程序试试发现的确每次不同…… 再次看见网上说，加密时候会随机pad到block长度，才理解……

接下来嘛，写个Greasemonkey脚本来帮助登录。第一步就是把那几个控件替换成我们的对象。替换完之后，可以登录过第一步了，之后手机短信验证还是不成。看console里有个错说HiddenSubmitArea不存在，于是插入一个进去…… 这货找遍各个地方都没找到，貌似也没啥用。

这样就可以过短信验证了…… 进去之后貌似还是有一些js错误，慢慢来…… 反正可以登录了。

作为库调用跟踪工具，WinAPIOverride还是挺好用的，功能上类似于ltrace，还有调试器的一部分功能，可以在库函数调用前后断下来，观察内存/寄存器等。IEinspector作为分析IE数据包的工具也不错，看上去比HttpFox功能更多…… 只是要收钱。

Greasemonkey代码：

// ==UserScript==
// @name        cebbank
// @namespace   net.henryhu
// @description ceb bank
// @include     https://www.cebbank.com/per/perlogin*
// @include     https://www.cebbank.com/per/prePerlogin.do?_locale=zh_CN
// @version     1
// @grant       none
// ==/UserScript==
 
function reset() {
    console.log('reset');
}
 
function publicKeyBlob(blob) {
    console.log('blob: ' + blob);
}
 
function commit(field) {
    console.log("commit: " + field);
}
 
function submit(formName) {
    console.log('submit: ' + formName);
    form = document.forms[formName];
    form.Password.value = '';
    form.submit();
}
 
function HiddenSubmitArea(foo) {
    console.log('HiddenSubmitArea: ' + foo);
}
 
oldpc = document.getElementById('powercommit');
newpc = document.createElement('div');
newpc.id = 'powercommit';
newpc.reset = reset;
newpc.submit = submit;
 
oldpp = document.getElementById('powerpassword');
newpp = document.createElement('input');
newpp.id = 'powerpassword';
newpp.type = 'password';
newpp.publicKeyBlob = publicKeyBlob;
newpp.commit = commit;
 
counter = document.createElement('input');
counter.value = 1;
counter.id = 'counter';
document.body.appendChild(counter);
 
if (oldpc) {
    oldpc.parentNode.replaceChild(newpc, oldpc);
    console.log("replaced pc");
}
 
if (oldpp) {
    oldpp.parentNode.replaceChild(newpp, oldpp);
    console.log("replaced pp");
}
 
window.HiddenSubmitArea = HiddenSubmitArea;