無標題文檔

改造笔记本的散热系统

该死的惠普,有时候也是「实惠但不靠谱」,特别是散热方面。终于忍受不了我笔记本的散热 问题了,决定非要搞定这事。

从 Google 那儿得知原来 这款机子设计上有问题 , CPU 芯片和 GPU 芯片不在同一水平线上,因此 GPU 的散热无法直接通过金属散热片。更要 命的是惠普还用海绵将 GPU 和散热片垫起来(是怕压坏?),从而造成 GPU 的散热更加的 困难。

PC 的优势就这样发挥出来了, 三下五除二就用把螺丝刀将笔记本大卸八块 。拆开那销魂的主 板,发现事实果然如此。

https://friable.rocks/_/2009_11_05/456648171061.jpg

中间的灰色物质便是海绵垫,看得出其实惠普是给 GPU 留个散热片的位置,但不过间隙实 在太大,因此没派上用场。

https://friable.rocks/_/2009_11_05/897398170c3b.jpg

再来看看这块捣蛋鬼,现在 GPU 的发热量不比 CPU 低多少,难熬的还是用户自己。

去数码城搞定了散热硅胶以及相关的工具,里面的间隙我用的是硬币慢慢用锉刀和砂纸打磨 而成(别告发我破坏人民币呀)。

https://friable.rocks/_/2009_11_05/007738170a85.jpg

垫上打磨好的硬币,加上导热硅胶,使 GPU 直接和散热片接触(上面张为图例), 这样据说这样就能解决问题了。

重新装回去,这花了我不少的时间,到最后还多出四颗小螺丝、少了三颗大螺丝。 测试了下温度,发现平时稍微跑个大型程序 GPU 温度就能狂飙 100 摄氏度的情况大有改善。基本上一晚 上按照平时的使用情况,GPU 的温度始终没有超过 70 摄氏度。

https://friable.rocks/_/2009_11_05/470848170a74.jpg

垫了块硬币就能直接降温三四十度?!我对这个结果感到很惊讶 -- 惠普不会穷得连每 台机子加个硬币的成本都没有把,我文明用语。

好吧,总结下今晚折腾的心得

  • 将笔记本风扇清理干净,能让耳根清静不少
  • 硬币一定要打磨光滑,尽可能大的增加与芯片的接触面积(我用的是 800 号的砂纸)。
  • 最好是人民币一毛钱,因为它是铝制的。不过近些年的一毛钱硬币都是合金的了,所以最好用前几年的(铝制硬币要相对灰暗些,当然那如果你不差钱,用银币那更好)。
  • 拆机的时候要记住螺丝的位置呀,否则要像我一样现在总想着要从哪里拆三颗螺丝下来。
  • IBM 不做 PC 了,现在买什么牌子的 PC 笔记本真的很让人纠结。
  • 买惠普一定要买商务机,不要像我贪便宜搞了台家用机活受罪。

最后,笔记本的散热问题一定要早解决,否则烤大腿是小事,影响子孙后代的质量可就是大 事了。

-- EOF --

便槽协议的脆弱性

标题党下,其实这篇是伪科学文章。老外老外能将生涩的算法举例得如此的生动,着实让我感到佩服。这篇文章只为 博君一笑,所以翻译方面就不用那么严谨啦,嘿嘿~

原文链接: http://blag.xkcd.com/2009/09/02/urinal-protocol-vulnerability/ 的评论也很精彩,在这里摘抄些:

  • 「在印度,厕所的背面有块非常大的墙,而且我不知道什么原因,他们总喜欢在后面放块镜子。」 via beli
  • 「为什么我们要反对共用一个便池?」 via Richard
  • 「其实当你真正‘着急’的时候,你就顾不了那么多了,无论前方是个便槽还是颗树」 via canvas
  • 「是否可以将便槽协议(urinal protocol)缩写成 UP/IP 协议?(这个恐怕学计算机的人听的懂)」 via Sophmoric

禁止使用 Firebug

相信没有人不知道 Firebug 是什么东西,但有时候我们糟糕的代码不想让同行轻松的使用 F12 就能一览无遗。

那么怎么办呢?

这里有个猥琐的办法帮你实现这个愿望

if( window.console && window.console.firebug ) {
    document.body.innerHTML = '';
}

如果还觉得不保险,那顺便连 F12 也禁止吧

document.onkeydown = function(e)  {
    if (123 == (e || {}).keyCode)  return false;
}

哦也,从此大家开始写垃圾代码吧,没人看我们代码喽

「安全那些事儿」

这段时期由于 找到几个线上的漏洞 ,勾起了兄弟们对于安全方面的兴趣。我也正好乘热打铁,做了个简单的分享( 在线观看 / 下载 )。主要内容有:

  1. 前端同样应该关注安全
  2. 典型的 Web 攻击方式(XSS、CSRF 等)

虽然内容不是很多,但结合实例,能让我们的组员能对安全这块的感兴趣,我想就已经达到目的了 :^)

叽歪的 CSRF 漏洞

声明,此漏洞已提交叽歪官方处理(2009-02-05),本案例仅作技术研究。由此漏洞造成的所有后果,本人不承担任何责任。

参加集团「精武门」安全峰会时, 80sec 团队对于饭否的 CSRF 蠕虫攻击 案例还记忆犹新。抱着对比的心态,逐个检测国内各微博客类站点的安全性能,最终「很不幸」的锁定到了 叽歪 上。

分析 叽歪页面发布信息页面 的表单,结果发现全部都是交给 updateStatus 方法处理,如图

https://friable.rocks/_/2009_02_05/1233811266.png

那么我们来看下 updateStatus 的脚本 是怎么写的(通过这个脚本,也可大体的了解叽歪的 API):

https://friable.rocks/_/2009_02_05/1233811318.png

发现 updateStatus 的脚本非常简单,就是检测下 textarea 的值是否为空(其实那样敲几个空格就可以绕过),然后就提交给服务器处理。而且逻辑上似乎有问题,返回的都是 false (或许是为了防止事件冒泡)。

既然 Javascript 方面没有增加额外的提交参数,这说明在 Javascript 禁用的情况下提交表单服务器那边也是能处理的。那么,根据叽歪发布页面的表单,尝试本地构建个同样的表单发送叽歪信息

<form action="http://jiwai.de/wo/status/update" method="post">
    <textarea name="jw_status" ></textarea>
    <input type="submit" />
</form>

结果成功了。这表明有存在 CSRF 的可能 -- 用户可以自行表单,发送信息给叽歪服务器处理,并且没有任何验证信息。

然后,非常「邪恶」地将 POST 方式改成 GET 尝试,结果发现又成功了。看来叽歪的接口没有区分 POST 和 GET,那么这样攻击的危害更扩大了层。

根据这个漏洞,简单的写了个本地 Javascript 脚本,尝试每隔一秒发送叽歪信息

setInterval(function() {
    var img = new Image();
    var message = '明城很帅';
    var api = 'http://jiwai.de/wo/status/update';
    img.src = api + '?jw_status=' + message + '&t=' + new Date().getTime();
}, 1000);

剩下就是社会学的范畴了。想到 沉鱼 小姑娘是叽歪的重度用户,于是让她打开这个页面(这时候,相貌是多么的重要)。

https://friable.rocks/_/2009_11_05/419606edd996.jpg

结果自然是预期所想的,顺便发现叽歪也没有限制发送信息的频率。就这样打住,通过这个漏洞进行蠕虫等进一步攻击等已是唾手可得。

最后,啰嗦下防范 CSRF 攻击 的「军规」:

  1. 在请求中使用 Security token
  2. 正确使用 GET、POST 和 Cookie
  3. 使用 Referer 判断请求来源

后记

截止发文时(2009-02-07),叽歪已经修复了该漏洞,增加了个 Security token :

<input type="hidden" value="..." name="crumb" />

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章