Day 3469 三星840 EVO与Windows 7 x64配合使用时无法使计算机进入睡眠模式的问题

当三星840 EVO SSD(120G,估计与容量没关系)与Windows 7 x64配合使用时,在极其罕见的情况下,会导致选择电源菜单下的「睡眠」后,未进入睡眠状态而立即返回登录界面,即屏幕只黑一下然后立刻就回到登录界面。

解决方法:将页面文件设置为「无页面文件」,重启后再重新建立页面文件即可。

上次出现这个问题是今年3月,五个月后的今天又来一遍,因为之前用机械硬盘时从未见过这个问题,所以怀疑与SSD有关,但也不敢确定。

2015-09-03:又来了一遍……最近准备加内存,干脆不设页面文件了。

Day 3414 用Arduino制作RFID钥匙链

rfid_keychain

很多人对管理密码感到由衷的麻烦,在生物特征验证尚未完全普及的今天(好像迄今为止做的最好、最为人所知的就是专属于iPhone 5S起的Touch ID),假设服务商没有(被迫)采取明文存储密码的2B做法,那么密码太短可能很容易被猜解出来,而密码太长又很容易记不住,而且在输入时也很麻烦。

因此有许多基于软件的密码管理器出现了(如1Password),只要记住一个主密码,剩下的密码都由其负责管理,并且很多优秀的产品已经出了很多平台的版本,可以跨平台进行使用,然而这种方式仍然有一点局限性:

  1. 在程序无法运行的环境下无法使用,例如:使用TrueCrypt加密的系统分区,在开机时要求输入密码;
  2. 主密码是拥有一切的前提,换句话说,如果忘记了主密码又没有备份,那么所有的密码可能都要丢失掉;
  3. 很多人有对商业软件与生俱来的不信任,在米国的棱镜项目被揭露后尤其如此。

我一直觉得很奇怪,为什么没有一种硬件,将密码离线存储在诸如IC卡之类的外部存储设备上,在需要的时候只要读卡,就能能模拟真实的键盘将密码输入。经过一番搜索,发现这种东西可能早就有了,只是没有供个人使用的商业化产品出现,其中的一个例子就是Mooltipass。

Mooltipass是一款设计精良的硬件密码管理器,除了实现以上所述的功能外,还能在适合的环境下与插件配合进行自动登录、帮助用户生成强密码(并存储下来供下次使用)。当时看到这款产品时,它还处在早期研发阶段,后来上了Indiegogo众筹。我没有双币卡,而且看到众筹也晚了些,$80的价格对我来说也有点贵(虽然说真的,值这个价钱),并且关于International Shipping说得好像也不是很清楚,所以就这么错过去了。

后来我听说了Arduino这个电子积木,其使用一种近似C的语言进行编程,并且通过一些方式可以模拟USB键盘。虽然我不会写C,但懂一点C#,两者有共通之处,所以二话没说就买了一堆零件开始尝试。

在拖延症和急功近利心理的共同作用下,一共走了以下几个弯路:

  1. 买错型号:设计上我想让成品既能读卡,又能写卡,但买了一圈之后我才知道能同时模拟USB键盘并与SPI总线上的RFID读卡模块RC-522通讯的型号是Arduino Leonardo,等我终于意识到时,已经额外买了Uno和Nano了。
  2. 多买了许多零件:跟以上理由相同,一开始以为需要用V-USB去模拟USB键盘,所以电阻、稳压二极管等等买了一大堆,最后才买到真正需要的东西。

虽然造成了许多不必要的支出,但最终这个东西还是做出来了,只有两个基本功能:

  1. 读卡,并将解密后的数据模拟键盘输入。
  2. 写卡,将加密后的明文(最长16位)存储到RFID标签中。

真正用到的元器件成本如下:

  1. Arduino Leonardo R3(¥30)
  2. 3×4矩阵键盘(¥5)
  3. RFID读卡模块RC522(含2张S50卡)(¥18)
  4. 无源蜂鸣器1枚(¥4)
  5. 公对母杜邦线一堆(¥5)
  6. 10K单联电位器(¥0.5)
  7. 8.5×5.5cm面包板(¥4)
  8. 1602 蓝色背光LCD(¥8)

合计¥74.50元——这么一算好像也不便宜,但是如果从一开始就核算成本,以自己的惰性怕是永远也做不出来。

不过以后输入16位长的密码简单些了。

源码和接线方式就算了,写的太烂。

2015-08-16更新:由于我手太笨,一直学不会焊接,所以这东西的最终形态是:

封装形式为PBC,即Paper Box Container

Day 3367 迅雷离线的坑

偶然想起手机上的Wikipedia离线资料还是2013年的,于是去Kiwix那边找更新的下载包,zh-cn语言带图版要7.2G,直接下载只有10KB/s,BT挂不动,结果把种子往迅雷离线里一拖发现已经离线好了,于是就下吧。

几个小时后文件下载完毕了,双击打开:

kiwix_package_1

于是换用7-zip,扫描了一阵子之后:

kiwix_package_2

六个多小时啊就这么白瞎了?于是想看看是不是扩展名问题,结果有了意外的发现:

kiwix_package_3

……迅雷你用六个小时给我下了9.5个G的0!?

怀疑离线服务器上的文件就是个dummy……鄙视。

Day 3365 PsExec和UAC

直接说方法:要使用PsExec在启用了UAC的远程系统上运行程序,需要这样做:

RunAs /user:domain\user “psexec \\remote-computer-name -h executable-file”

而不能这样做:

psexec \\remote-computer-name -u domain\user -h executable-file

详细原因见此:http://www.riosec.com/articles/Windows-UAC-PsExec

顺便把内容复制过来留给自己看:

Recently I ran across a scenario where the Microsoft Sysinternals tool PsExec would not work against a Windows 7 domain-joined computer. The command was failing with an “Access Denied” error. On Vista and newer, User Access Control (UAC) issues a restricted token to processes, but PsExec requires an elevated token. On the local system’s Microsoft-Windows-UAC\Operational log the following event appeared: The process failed to handle ERROR_ELEVATION_REQUIRED during the creation of a child process.

Further research found that newer versions of PsExec have a command argument (-h) to specify elevated rights.

However, even with specifying -h PsExec was still failing with “Access Denied”. After some digging, I discovered that it’s all about how the authentication credentials are presented to the remote system. UAC has an exception for remote connections using domain credentials, so that machines can still be administrated remotely (otherwise, there would be no way to respond to UAC prompts). When connecting remotely and authenticating with NTLM using a domain account, Windows 7 issues an elevated token.

With PsExec when you specify the username on the command line it causes an explicit (local) authentication to occur on the remote system, and Windows issues a limited rights token, causing PsExec to fail. However, if you authenticate as the target user on the local computer (using RunAs or logging in directly), and then use PsExec with implicit (NTLM) authentication to the remote computer, the process gets the elevated token on the remote system and it works.

This behavior becomes more obvious when using telnet. The built-in Windows telnet client automatically authenticates using NTLM (top window in the screen shot below), and the user is given an elevated token. However, logging in with the same user from a third-party telnet client results in a restricted token (bottom window).

Day 3353 Mac Pro 2007全新安装OS X Mavericks

因为一些事情,从其它部门弄来一台Mac Pro 1,1 2007年款的台式机,而因为某些原因需要给这台跑着OS X 10.4 “Tiger”机器升级到10.9 Mavericks。由于对OS X下操作的不熟悉,以及苹果对直接从Mac App Store中升级至新版系统时所做的限制,足足折腾了两天才达到目的。

网上有教程,但都是英文的,我不确定那些高大上的中文论坛里是否有教程,不过估计搜不到是有付费墙之类的,所以还是记录一下自己折腾的过程好了: 继续阅读 “Day 3353 Mac Pro 2007全新安装OS X Mavericks”

Day 3348 复制带有刻意制作的坏道的防拷光盘

copyprotected_cd_with_badsector_on_purpose

盘长这样,可以明显看到有一圈银色,那个是可以制作的坏道,如果使用按Sector复制的工具,读到这里就会因为读不下去而制作镜像失败。

这张盘是某部门下发的软件数据盘,因为某些奇怪的原因,在对应需要装的机器上无法识别,但是又必须尽快安装,于是处理方法如下:

  1. 使用IsoBuster的Extract RAW模式将光盘制作成镜像,当读到那圈银色的坏道时会出错,这时取消操作,会出现是否删除文件的提示,点击否即可。
  2. 此时制作出来的文件因为文件尾没有封口,是不能直接载入虚拟光驱软件的(尝试使用7-zip之类的软件也会出错),但UltraISO可以识别,所以在UltraISO中打开镜像文件,然后对其进行另存,文件就会被修正到可用状态。
  3. 在Daemon Tools Lite之类的软件中载入镜像安装即可。

话说现在已经是软件任意派发然后通过各种方式限制使用授权了,某些部门还在用这种落后的方式防拷,真是不思进取。

P.S. 这张盘检测安装程序是否是从光盘引导的方式是检测两个隐藏文件(不是简单的加了隐藏属性,而是从ISO目录中隐藏),所以通过制作镜像的方法很轻易就能绕过去。

Day 3341 Excel 2007 启动时提示配置 Visual Studio 2013

事情是从今年初安装了Visual Studio 2013 Community Edition后开始的,每次启动Excel 2007时都会出现以下Windows Installer的提示,让它走完或者按取消,下次启动Excel 2007都会重复出现:

excel_vs2013_msi_on_startup

解决方法:

  1. 如果系统配置了UAC,则去Office安装目录中「使用管理员权限运行」Excel.exe。
  2. 点击Excel左上角圆圆的Office图标,选择「Excel选项…」,点击左边的「加载项」,然后在右边找到「管理:」,下拉选择「COM加载项」。
  3. 在新弹出的「COM加载项」管理窗口中,取消选择「Chinese Translation Addin」即可(如出现「无法更改 HKEY_LOCAL_MACHINE中注册的……」请重做第一步)。

至于具体原因不得而知,因为给出这个解决方案的是Excel某次启动后给出的提示:「似乎中文翻译加载项出错了太多次,要禁用它吗」,点了确定就OK了。

Day 3337 Acrobat XI 使用amtlib.dll破解的后遗症

事情的起因是:最近使用WinRAR解压缩文件时,出现了一个奇怪的现象:通过双击打开压缩包中的某个文件时,无论选择的文件是什么,都会自动打开桌面上的第一个文件。我的桌面上第一个文件是1.jpg,就算双击一个exe文件,这个jpg也会冒出来,而如果用WinRAR内置的「查看」功能(右键点击文件选择「查看」菜单项),则会用WinRAR内置的文本查看器打开这个1.jpg,奇怪之极。

一开始完全不明所以,直到后来发现另一个软件也开始出问题,这个软件的中文名字叫影之袜(请自行翻译)。原本其运行良好,但最近每次在系统启动时,都会弹出一个它的异常,上书:拒绝访问。经过一番研究,发现这个软件需要向临时文件目录写一点东西才能运行,所以拒绝访问指的是向Temp目录写失败。

因为最近将UAC设置拉到了最高级别(始终通知),于是尝试降低甚至关闭UAC,没有变化,并且通过查阅资料得知,UAC拉到最高并不会影响Temp目录的写入权限,于是排除之。

问题指向Temp目录的写权限赋予,去C:\Users\{用户名}\AppData\Local下查看Temp目录的安全设置,发现变成了这样: 继续阅读 “Day 3337 Acrobat XI 使用amtlib.dll破解的后遗症”

Day 3325 ownCloud Permission Denied in mappedlocal.php

尝试了一下私有云ownCloud,版本为8.0,OS为Windows Server 2008 R2,一开始配置很顺利,但实际用客户端传文件时,稍微开始一会儿就出现Internal Server Error的提示,去看系统的日志,可以发现有类似这样的php错误出现(非实际错误信息,为转帖):

unlink(C:\inetpub\wwwroot\owncloud\data/jerome/files-trashbin/files/owncloudusermanual.pdf.d1423825653): Permission denied at C:\inetpub\wwwroot\owncloud\lib\private\files\storage\mappedlocal.php#270

Workaround方案(来自此帖):

下载7.0.4版本的ownCloud,将/lib/private/files/storage/mappedlocal.php覆盖掉即可。

Day 3318 为啥我的微信Access Token有效期那么短

最近给单位做了一个微信活动,由于要求甚多,现成的服务无法满足需求,最后决定从头开始开发。

由于自己的PHP、HTML和JS都是半瓶子醋(JS更是按滴算),所以编写代码的过程中遇到了不少磕磕绊绊。感谢这个信息便利的时代,大部分问题在查找资料后都得到了解决,最后活动于前两天正式上线了,除了一开始一点小意外,运行还算正常。

但是有一个问题从一开始就困扰着自己:调用微信的API需要先用微信公众号的APP ID和Secret向微信服务器申请Access Token,然后用这个Token去调用API,官方的文档中指出目前的Access Token有效期是7200秒(2小时),但是调试时Token的有效期一直在10分钟左右摇摆,活动上线后变得更加糟糕,几乎每7-8分钟就会在日志中看到某个Session下出现Token超时的记录。

最后终于找到了问题的原因,很蠢:我将Access Token理解成了一个per user而不是per APP的令牌,代码中为每个进入的用户都重复申请了token,并存储在了缓存中,于是一个新token没有失效前,如果有另一个用户进入了活动,那么这个跟公众号关联的token就会被刷新,其它用户再使用之前的token访问时,由于旧令牌已经失效,又会再次进行申请,于是陷入了恶性循环。

直到这时我才明白微信API文档中为什么要让一个「中控服务器」对Token进行存储,因为Access Token(和JS-SDK Ticket)是与公众号、而不是微信用户相关联的。

现在的问题是:由于多设计了这些没有必要的东西,数据表变得很庞大(没错,为了调用微信的JS-SDK我还为每个用户存储了JS Ticket,这同样也导致了毫无意义的频繁刷新),所以准备如果本次活动期间不出问题,就等到结束后对所有内容进行重写。