Shell's Home

手机上app的权限对比和分析

Nov 7, 2014 - 2 minute read - Comments

简述 今天看到这篇文章,勾起了我的好奇。我的手机里有多少app有安全隐患呢?当然,我知道很多有安全问题的app我不能删——例如企鹅家。但是如果某个app没有必然需要,或者有替代品。我不介意换一个用。所以我写了这篇blog,对比了各种同类或近似app的权限要求。 先说明一点,这篇文章所列出的app权限,是根据当前(2014-11-07)google play上的应用权限数据,截取我感兴趣的部分权限汇总的。既不是完全的敏感权限列表,也不可能不变化。如果有什么补充,欢迎你联系我。 同时你需要知道,app需要某个权限,并不一定表示要用来做坏事。很多时候是因为功能确实需要。因此我也在下面点评了部分我知道的功能需要对应权限。即便我们在app里面找不到权限对应功能,也不能绝对断言app正在作恶——只是相比起来我更信任不需要提供这个权限的app而已。这也是为什么我做的是分类对比——方便你来比较和替换。 IM类 telegram read SMS 照相 录音 location read/modify contacts run at startup talkback change audio setting 我太感动了。 QQ read SMS read/modify contacts 照相 录音 location read/write call log read/write calendar disable screen lock NFC bluetooth run at startup change audio setting 流氓权限大集合啊。你说要contacts我还能理解,要call log干嘛?还要write?而且功能里也找不到为什么需要NFC和蓝牙。 微信 read SMS 照相 录音 location read/modify contacts bluetooth run at startup change audio setting 基本同QQ,不过权限少了很多。 评论 虽然我们都知道talkback比企鹅家的对隐私更友好,可是有本事你别用企鹅家。。。 SNS facebook read sms

context切换测试——C语言协程有关部分请求review

Nov 6, 2014 - 1 minute read - Comments

setjmp/longjmp测试 使用s_jmp程序来测试setjmp的性能。1G次循环。下面是结论: 5.77,0.00,29,0,0,0,99% 5.70,0.00,30,0,0,0,99% 5.71,0.00,22,0,0,0,99% 5.71,0.00,23,0,0,0,99% 5.70,0.00,30,0,0,0,100% 5.70,0.00,23,0,0,0,99% 统计结果如下: time mean = 5.715 time var = 0.000625 单次调度开销只有5.7ns,在所有测试中性能最优。(glibc-2.19/sysdeps/x86_64/setjmp.S) getcontext/setcontext测试 使用s_context程序来测试setcontext的性能。100M次循环。下面是结论: 12.96,5.88,79,0,0,0,99% 13.13,5.94,105,0,0,0,99% 12.95,6.18,57,0,0,0,99% 13.13,5.90,64,0,0,0,99% 12.95,5.88,82,0,0,0,99% 12.96,5.80,51,0,0,0,99% 统计结果如下: time mean = 13.01 time var = 0.0068 单次调度开销高达130ns,仅比系统的sched在高线程下略快。这事很奇怪,因为根据我看到的源码(glibc-2.19/sysdeps/unix/sysv/linux/x86_64/setcontext.S),getcontext/setcontext在glibc中是用汇编实现的。其中陷入内核只是为了设定signal mask。

context切换测试——线程创建有关部分请求review

Oct 31, 2014 - 1 minute read - Comments

线程模式开销 使用t_thread程序,循环1M次,重复6次,原始数据如下: 9.57,8.22,21098,0,0,0,104% 9.77,8.40,29704,0,0,0,104% 9.36,8.17,10390,0,0,0,106% 9.56,8.50,14514,0,0,0,107% 9.35,8.34,7244,0,0,0,108% 9.57,8.43,26351,0,0,0,106% 统计结果如下: time mean = 9.53 time var = 0.02 kernel mean = 8.34 kernel var = 0.013 解读数据可以看到,thread模式的开销为9530ns(已经降到纳秒级了),CPU将为8340ns,精确级别在20ns级别。粗略换算一下每次create的开销大约是30k个时钟周期。简单对比可以看出,thread模式比fork模式大约快了5倍。

context切换测试——调用开销有关部分请求review

Oct 30, 2014 - 1 minute read - Comments

函数调用开销 使用s_call来测试性能,循环1G次。 2.35,0.00,17,0,0,0,99% 2.34,0.00,13,0,0,0,99% 2.34,0.00,10,0,0,0,100% 2.35,0.00,10,0,0,0,99% 2.34,0.00,14,0,0,0,99% 2.34,0.00,6,0,0,0,99% 统计结果如下: time mean = 2.34 time var = 0.000022 每次call的开销为2.34ns,约7个指令周期。当然,这些并没有考虑调用压栈和数据返回。 内核调用开销 使用s_syscall来测试性能,循环1G次。这里特意选用了一个不可能失败的内核函数,getpid,来衡量每次进入getpid的开销。 4.37,0.00,76,0,0,0,99% 4.34,0.00,43,0,0,0,99% 4.37,0.00,124,0,0,0,99% 4.37,0.00,63,0,0,0,99% 4.36,0.00,48,0,0,0,99% 4.36,0.00,47,0,0,0,99% 统计结果如下: time mean = 4.36 time var = 0.00011 这里可以看到,纯粹的内核进入开销小到非常惊人,只有4.36ns,约合13个指令周期,而且这里还要进行数据的查询和返回。所以内核调用开销在下面的测试中全部忽略不计。

context切换测试——python有关部分请求review

Oct 29, 2014 - 1 minute read - Comments

python yield模式性能测试 python下的测试就不用time了,我们改用python的timeit,循环100M次。具体可以看py_yield.py。数据结果如下: 7.64262938499 9.2919304393e-06 5.41777145863 4.94284924931e-06 从结果来看,100M次循环的平均时间是5.4s,平均每次大约54ns。使用yield后变为76ns,增加了22ns。 python greenlet模式性能测试 这次代码在py_greenlet.py,循环10M次。数据结果如下: 5.35270996888 7.44085846125e-05 5.31448976199 5.82336765673e-05 单次循环时间消耗为535ns。比最初的54ns,增加了481ns。基本来说,时间增长了10倍率。 这是预料中的,因为greenlet早就声明自己通过堆栈拷贝来实现上下文切换。这会消耗大量CPU时间。从原理上说,栈越深,消耗越大。但是测试结果表明两者几乎没有差异,栈深反而性能更加优异(TODO: why?)。

context切换测试——进程有关部分请求review

Oct 28, 2014 - 1 minute read - Comments

测试环境 Intel® Pentium® CPU G2030 @ 3.00GHz 8G内存 debian jessie Linux 3.16-2-amd64 2014年10月27日 附注一下,该CPU有2核心,无HT,1ns3个时钟周期。 测试方法 测试代码如下: time -f "%e,%S,%c,%r,%s,%K,%P" ./perf_fork 数据的意义分别为: 总时间,占用CPU时间,context switch次数,读/写次数,内存耗用,CPU使用百分比。 数据处理方法如下: import numpy as np p = lambda s: [float(line.strip().split(',')[0]) for line in s.splitlines()] q = lambda s: [float(line.strip().split(',')[1]) for line in s.splitlines()] np.array(p(s)).mean() np.array(p(s)).var() np.array(q(s)).mean() np.array(q(s)).var() 进程fork开销 使用s_fork程序(注释语句关闭模式),粒度1M次,重复6次,原始数据如下: 49.04,26.83,29784,0,0,0,55% 51.53,26.38,32057,0,0,0,52% 49.88,26.02,30892,0,0,0,53% 51.39,27.13,37573,0,0,0,54% 52.89,28.12,37924,0,0,0,54% 51.19,27.02,35880,0,0,0,54% 统计结果如下: time mean = 50.98 time var = 1.52 cpu mean =

bash严重漏洞

Sep 25, 2014 - 1 minute read - Comments

今天估计各大消息都在报这个漏洞,可能有些人看到有修复就放松了。目前来看,事情没那么简单。 CVE-2014-6271 第一个漏洞,编号为CVE-2014-6271。相应的dsa和usn。 具体的文章可以看这里。 简单来说,当bash执行时看到有变量定义了一个函数,函数尾部又剩余了部分代码。会直接把剩余代码执行了。导致简单的变量定义动作有机会执行任意代码。 对于未修补的系统,执行以下代码出现以下提示: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test 注意echo vulnerable应当不被执行的。 修复的系统则是以下表现: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test CVE-2014-7169 第二个漏洞,编号为CVE-2014-7169。 这个漏洞是第一个漏洞没有修复完全导致的,最麻烦的是,这个漏洞没有修复,细节却满天飞了。 表现如下: $ env X='() { (a)=>\' sh

送书

Sep 4, 2014 - 1 minute read - Comments

最近清理家中藏书,打算送掉一部分纸质书。于是顺手列了一批自己需要,但是可以外借的书。 送人的部分,如果你需要,两个月内联系我,自己想办法拿走(例如H4,或者直接上门)。逾期我就直接送去资源回收了。借阅的部分,记得好好保管图书,不管借阅多久,记得回头还我。 送人 delphi 5.0 开发多媒体应用 ISBN 7-5084-0470-X C++语言程序设计 ISBN 7-302-03926-7 计算机绘图 ISBN 7-313-01482-1/TP.273 borland C++ windows程序设计 ISBN 7-115-05265-4/TP.117 最新C++语言精华 ISBN 7-5053-3975-3/TP.1731 C++语言程序设计 ISBN 7-302-04504-6 C++使用手册 ISBN 7-5053-2890-5/TP.959 microsoft visual C++ .net技术内幕 ISBN 7-302-08931-0 操作系统教程 ISBN 7-04-012664-8 借阅 模式识别 ISBN 7-121-02647-3 深入解析Windows操作系统 ISBN 978-7-121-03969-0 计算机网络 ISBN 7-302-08977-9 深入浅出MFC ISBN 7-900614-93-1 Python源码解析 ISBN 978-7-121-06874-4 数据结构与算法(Java语言版) ISBN 7-111-11902-9 网络渗透技术 ISBN 7-121-01035-6 密码编码学与网络安全 ISBN 7-5053-9395-2 人工智能及其应用 ISBN 7-302-02127-9 神经网络原理 ISBN 7-111-12759-5

如何分辨网站真假

Aug 19, 2014 - 1 minute read - Comments

老婆想去新疆玩,结果她居然从百度上搜了一下新疆国旅就联系开了。我一直不知道,直到她和我说,对方要求缴500元到一个支付宝帐号里。我立刻要求她不要付钱,然后开始查证真假。 第一家网站 她开始给我的是这家:http://www.17xjly.net/。 老规矩,先whois,再dig,再whois。 whois域名的结果是没有任何信息?! dig后的IP是113.10.247.20。再whois一遍,发现服务器在香港。此外也没有任何信息。 ICP是新疆的,查全国ICP登记无信息。 开始想不通,这家伙在新疆背景这么深厚?突然醒悟过来。这家伙是个.net域名,注册地不在中国,服务器不在中国,凭什么要人家ICP备案啊。就因为号称是新疆的网站? CAO,这种网站给的支付宝,鬼知道打进去会发生什么。。。 第二家网站 百度上排名很高的是这家http://www.yuyutrip.net/和这家http://www.yoyotrip.net/。两家的页面很像,但是又明显有区别,不知道是竞争对手还是什么。 老规矩。 whois域名的结果是这个: Registrant State/Province:Shanghai Registrant Name:shxg shxg 注册地上海? dig了更好玩。这两个域名的IP指向是同一个。121.52.217.137。再whois发现是这个: netname: TopnewNET descr: Beijing Topnew Info&Tech co., LTD. 没听说过。 ICP倒是有: 北京博通天下网络技术有限公司 U旅商旅网 2013-06-09 咳咳,漏底了吧。虽然号称国旅,但是是一家北京公司在上海注册的域名。 好玩的是,这家网站上面给出的地址,是真的(具体后面会说)。但是电话却不对。 真的国旅 google出手,马上就有。结果是这个http://www.cits.com.cn。 老规矩。 whois域名可以看到这个: Registrant: 中国国际旅行社总社有限公司 注册者看着就很NB。 dig一下,发现IP是这个,219.143.192.35。这个IP可牛逼了。whois一下: inetnum: 219.143.192.0 - 219.143.192.255 netname: CITS 我擦,专属C类IP段! ICP查询后结果是这样的: 中国国际旅行社总社有限公司 国旅在线 www.cits.com.cn 2014-07-23 www.cits.net 2012-11-29 这个网站上有400电话,打过去说新疆只有团体游。不过人家给了正确的地址和电话,和第二家网站的地址一致,电话却不一样。 事情到这里,我的基本判断是。和第二家网站做生意还是有点谱的,ICP是真的,地址国旅也认。最低限度,他至少是一家合法的旅行社——虽然不保证是国旅下属。第一家么,谁爱信谁信。 上海国旅 后面有点更好玩的事情。国旅在线上有上海,而google查询结果上也有不少上海国旅。那么谁是真的呢? 上海国旅1 例如这家http://www.scits.com/。 域名的whois是这样的: Registrant Organization: SHANGHAI CHINA INTERNATIONAL TRAVEL SERVICE CO.,LT Registrant City: shanghai dig后发现IP是210.14.68.234,再whois是这样的: netname: SVA descr: Science & Technology Network Communication Co., Ltd.

服务器操作系统的选择

Aug 14, 2014 - 2 minute read - Comments

今天被LTN问了一下怎么看一个知乎问题: 服务器操作系统应该选择 Debian/Ubuntu 还是CentOS? 其实我觉得他的大部分说法都没有错。如果你需要装一个服务器,确实首选是RH系的。 但是。。。 选用RH系的主要理由 其实你把回复从头看到尾,主要论点就一点: 哪个发行版,可以在长达7-10年的时间里,始终保持硬件稳定性的同时,又持续的升级补丁? 结论当然是RH!这是RH的主要卖点。 我们真的需要长达7年的硬件稳定性支持? 咳咳,今年上半年,蔽厂的运维碰到了这么一件尴尬事。 他们进货,去机房装系统,配置网络结构,加入运维管理系统,添加监控,交付。除去采购外,整个一套流程大概是一周。 我们在机房里面原本大约有10个机柜,那么一般扩充的时候,一次扩充一个机柜。 结果今年上半年的某一段时间,一周一个机柜的事情持续了两个月。运维同学辛辛苦苦装好一个机柜,周末打算轻松一下。被老大通知,又来客户了,机柜又不够用了,下周继续。 是的,我们现在20个机柜不止。机房有多少机柜我不知道,不过照这个趋势来看,我们快把机房包下来了。现在我们的带宽已经没有限制了,每个月月底按照合同秋后算账。 我们有一些有三年历史的服务器,台数不多。现在来看,性能已经远远不够。CPU不够快,也没有SSD,硬盘读写次数也太多。这些机器的下场,多数会被换下来折旧卖掉,或者作为测试服务器,搬去测试机房。而现在机房里面大半机器,都是两年以下历史的。而且至少一半服务器历史不超过半年(。。。)。从现状上看,把老服务器留在机房,其性价比并不合算。因为机房有机架密度问题,限制着我们的单机房极限,这相当于变相的租金。 如果考虑到这点,我们的线上服务器生命周期大概也就三年。最多。很多时候甚至还不到。 比我们更极端的是页游。他们的一组服务器生命周期一般是半年。半年内,要赚钱的也赚完了,不赚钱的也死完了。所以他们甚至不会新采购硬件服务器,而是直接使用虚拟机。 当然,虚拟机内的系统,支持时间是一年还是十年,对他们一点意义都没有。 为什么我们不喜欢三年以上的系统? RH系的提供10年级别的维护性,我换个说法,也就是最近的软件在RH的官方库里面找不到。当然,装最新的RH是有的,但是在安装了三年的一个系统上?肯定没戏。 怎么办?编译呗。 这大概就是国内谈到RH必编译的由来。 可是,我引用文内的一段话。 如果我今天告诉大家,我要做一个 http 的服务器,我不用 apache 不用 nginx, 为了性能我要用 xxx 为基础重写一套出来。我相信绝大多数人会问同样的问题, “你觉得你写的能比 ng 好么?” 再回头看看那时候你们自己吧。 同样,自己编译的软件,补丁维护速度,能和新系统比么?而且我们还得扔一个人下去搞补丁维护。 所以,正解是什么? 装一套新的,把数据导过去用呗。 我们的”数据“,都是装载在磁盘上的。而换”系统“并不需要更新这些数据,只要把系统盘擦掉重部署一遍,然后配置好deploy系统就OK。在开发之初,”环境“,”程序“和”数据“分离,就是一项基本原则。而且即使是”数据“,丢掉一台机器上的所有”数据“也不会构成问题。这应当是运维基础中的基础。只有少数几台服务器,既不能直接更换也不能停机。这些机器我们做特别的管理。 为什么蔽厂使用Ubuntu? 很简单。因为最初的开发希望在Linux上进行。直接在Linux上开发和测试,对于startup的快速开发是非常重要的。而开发用什么版本,服务器跟什么版本,这是最省事和好办的。如果你硬要和我争,说开发在Mac上,跑在Linux上一点事都没有。或者说开发一个发行,服务器一个发行也OK。 我至少得说这对于golang和python都不是事实。除非不用cgo,也不用python的C扩展。 先不提Mac下和Linux下的差异。我们今年在升14.04的时候就发现,12.04和14.04的编译互不通行。所以现在12.04的编译可以程序员自己编译了本地测,14.04的就必须在测试环境里干。一帮程序员远程tcpdump出结果,拷回本地wireshark一把。。。 看看就蛋疼。 当然,这也有个问题。就是上面”我们不喜欢三年以上的系统“。所以呢。明年我们的系统大概会轮换重装,14.04。。。 也很蛋疼。 Debian系的补丁不靠谱么? 那要看和谁比。这里有HeartBleed事件的统计。虽然不普遍,但是我觉得这种大漏洞比较有代表性。 CVE-2014-0160 - OpenSSL安全漏洞的非技術事件 我引用他的重点整理: RedHat 修復的速度比 OpenSSL 官方還快。 RedHat 派系的修復時間,除了 RedHat 外都算慢,如 Fedora 及 CentOS、Scentific, 他們都比 RedHat 慢 16 小時以上。 Debian 派系的修復時間,如 Debian 及 Ubuntu,都比 RedHat 慢上至少 12 小時以上。 Scentific 是列表中修復最慢的。 若以資安黃金 6 小時來說,Fedora、CentOS、OpenSUSE、Gentoo 及 Scentific 都不及格。 如果和RH比,Debian的修复速度是不及格,但是和CentOS比。。。怎么说呢?6个小时对10个小时,有种五十步笑百步的味道? 换你你愿意走几步? 另外,我也不知道原文说的升级一大包是怎么回事。我在Debian stable上查询ssl: $ dpkg -s libssl1.0.0 Version: 1.0.1e-2+deb7u12 Depends: libc6 (>= 2.7), zlib1g (>= 1:1.1.4), debconf (>= 0.5) | debconf-2.0 但是同时。 $ dpkg -l | grep libc6 ii libc6:i386 2.13-38+deb7u3 i386 Embedded GNU C Library: Shared libraries libc的依赖早就满足到不能再满足了。直到今天为止,openssl在debian上的升级还不需要你强制跟随升级libc6。而kernel根本没有依赖。 纠正原文的一点理解错误 Debian 是由社区维护、贡献的发行版本,其从选包、打包、都是由社区组织,分散行动的。 Debian 是没有真正意义的 release 概念的。Debian 有众多仓库,stable,testing, unstable ,experimental.