选型 之前一直用的显示器是 iMac 2020 款以及明基的 PD2700U 显示器。作为最后一款 intel 芯片的 iMac，显示器比新款的感觉更好一些，毕竟是买显示器送电脑。而明基的这款显示器显示效果也不错，同时也比较护眼，使用体验也很好。这种双屏的组合不论做啥都很爽。
奈何公司只提供 1080P 的显示器，在 Mac 上面的使用效果和看马赛克差不多。为了提高工作效率。只好忍痛把家里的明基显示器带到公司去使用。而 Studio Display 作为苹果推出时间不久的显示器，之前一直有种草。其显示效果是业界有目共睹的。但是这款显示器的摄像头以及麦克风的收音效果据说都还好，虽然对于我来说没有特别大的区别。
这款显示器支架有三种版本，普通支架，可升降的支架以及 vesa 版本。vesa 版本和普通支架的价格是一样的，但是普通支架占地方不说，而且调节的范围非常有限。之前明基显示器也是通过乐歌的显示器支架来使用的。之前也一直后悔 iMac 没有选择 vesa 版本，后来还是买一个魔改的配件来配合使用。关于 iMac 的使用体验，可以参考之前的这篇文章。所以这次毫不犹豫地选择了 vesa 版本，不过 vesa 版本等货的周期更长，差不多要晚半个月的时间。最终，也是等了一个半月才拿到了显示器。
开箱 显示器到手之后就是开箱。说实话，这个箱子和当初的 iMac 有一点类似，箱子都非常大。本来想拍一个开箱视频，但是实在是不好开箱，就简单地录了一点点视频。显示器的包装还是传统的牛皮纸箱加内包装的组合，打开来除了比较大而已，其实还是非常方便的。配件也非常简单，显示器主体，连接在一起的电源线（注意电源线是不能拔掉的），还有一根雷电线，可以直接通过 type-c 接口连接电脑。对于 vesa 版本一开始还想会不会提供螺丝，结果找了半天没有，后来在网上也看了别人的介绍，vesa 版本的确也是没有提供螺丝的。
简单的开箱视频：
https://www.bilibili.com/video/BV1NB4y1t7eb
然后就是把明基显示器拆下来，把新的显示器装上去。过程还是比较简单的，基本就是拆拆螺丝，拧拧螺丝而已。最终显示的效果还是比较满意的，虽然说这款显示器和之前的使用体验上来说可能并没有什么质的飞跃，但是看着就很爽。不过貌似是新的显示器比以前的要更重一些，现在在使用升降桌的时候，升到高的时候，比以前更容易晃动。这可能是相对于以前来说使用体验比较下降的一个点之一吧，不过总体来说并没有什么大的毛病。
使用体验 这款显示器使用也有将近两个礼拜的时间。说实话和以前的体验并没有本质的区别，可能实际的性价比并没有那么高。但是这款 5k 屏的素质还是非常高的。同时也为了使用这款显示器，也把自己一直使用的 Catalina 系统升级到了最新的版本。老的版本似乎有一些奇怪的 bug，而且还有一些功能不能使用，虽然还是比较喜欢以前的老系统。但最终为了配合使用这款显示器，还是对系统进行了升级。
不过这款显示器最让人惊艳的可能就是扬声器了，感觉音响的效果非常好，虽然我这个木耳可能并不太会欣赏。但明显可以感觉到和以前的 iMac 自带的扬声器还是有着很大的区别。至于人物自动居中的这些功能对于来说并没有什么卵用，所以也暂且不提。不过这款显示器继承了一个 A13 的芯片，未来可能会升级更多的功能。
岗位 目前 Base 有新加坡、上海、深圳、北京等地、覆盖各种岗位，包括开发、QA 、PM 、运营、安全等各种岗位。
岗位参考链接 https://app.mokahr.com/recommendation-apply/shopee/2964?sharePageId=1477124&recommendCode=NTALl86#/
校招 https://app.mokahr.com/recommendation-apply/shopee/2964?sharePageId=1480471&recommendCode=NTALl86&codeType=1#/jobs?zhineng=111395
薪酬范围 可以参考 Boss 直聘上岗位薪酬范围：
https://www.zhipin.com/gongsir/0e1bc15942b85a7d1nB90ty8.html?ka=company-jobs
目前股价是非常具有性价比的。
投递方式 自主投递 https://app.mokahr.com/recommendation-apply/shopee/2964?sharePageId=1477124&recommendCode=NTALl86#/
点击链接，参考自己心仪的岗位投递即可。
邮箱投递 邮件标注自己希望投递的岗位以及 BASE ，以及你的个人简历。邮件发送 hacknanahack@gmail.com 即可，邮箱会实时更新进度。
福利 薪资对标大厂，15 薪保底，现在股价具有性价比。 五险一金+商业保险（试用期即可使用） 15 天年假（新加坡 18 天），14 天带薪病假 无限量水果零食供应，还有冰淇淋供应 年度旅游、季度团建 每月健身补贴（部分 office 是自己的健身房） Orange Day ，公司每个月末周五特色活动，迎接新人、寿星生日等，游戏+下午茶形式 Open Day ，与老板面对面建言献策、自由交流的机会 每年都有五千培训经费，可以用于报名考试学习报销 热招岗位 金融信贷-后端开发专家/Leader
Shopee Express后台开发专家/Leader
保险业务后端开发专家/Leader
Shopee Express 前端开发专家/Leader
资深/专家数据开发工程师-用户画像方向
Shopee Express资深Golang开发工程师
Shopee Express后台开发工程师
保险技术中高端 Multimedia Center
金融风控后台负责人
RTC音视频SDK专家/Leader（深圳）-Multimedia Center
视频转码后端Leader（深圳）-Multimedia Center
自从有了车之后，停车似乎就变成生活中最大的烦恼之一。而停车停着不动被别人蹭，那就烦恼加倍。而被人蹭了还找不到人，那则是烦恼再加倍。被蹭了找到了人，别人不承认，然后你还没有直接证据，烦恼又又加倍。那如果用二进制表达的话，那么就是 1111，就有 15 倍烦恼了。前段时间已经是我停着不动，第三次被人蹭了，而且基本上只有第一次人都是直接在现场的，后面都是基本确定了作案对象，但是由于没有直接的视频证据，所以也没有办法。
第一次是在公司园区的地下停车场，当时一个十字交汇处人一直挺多的，走来走去。我就在那停车等待。大聪明急不可耐的冲了过来，左转，充满自信的把我蹭了个满怀。我当时真的是。。。这个人本来还说要跟我责任一半一半，他说我压了道路线。这里想解释下为什么压道路线的问题，因为右边都是停车位，而且很多车的车头都会露出来，所以会往左边开一点。后来打了110，当场民警是不愿意定责的，不过他还是讲了这个责任主要还是在于他没有把握好距离导致的，最后他还是认了全责。
https://www.bilibili.com/video/BV16M4y1L73L
这里的保险过程也比较简单，他报了保险，保险要了双方的驾驶证和行驶证，以及 4s 店的地址。定损由于责任清晰，定损员也没有过来定损，直接通过照片定损的。像这种发生事故其实是特别坑的，保险不会赔偿你的时间，你还要过去修车，修车过程中还要耽误用车。而且如果你的车比较新，别人也不会给你折损费。一开始保险公司定损的价格过低，保险杠当时车灯附近当初已经有好几处已经扭曲了，保险公司想做修复，4s 店说做不了，后来才同意换新的。这里涉及到另外一个潜规则，一般来说保险公司都想能修就修，所以他们会把零件自己带出去修，而车主当然是希望换新的，尤其还是别人的责任的情况。所以，这种情况还是需要 battle，当然一般小的保险公司，甚至包括平安，评价都很不好，赔偿的时候不痛快。好像只有人保比较爽快，但是人保的保费又比较高。当时整个上海都没有保险杠，我顶着破保险杠开了半个多月，然后修车也等了好几天。
第二次，其实也是在园区停车场，不过这一次当时没有发现，发现的时候已经是第二天。后来去翻了下行车记录仪，应该当时是一辆大众倒车入库的时候蹭到了我车的右前方。但是行车记录仪只有缩时录影，这种一般都是几十秒拍一张照片，而且没有声音，所以这种视频证据也很难拿出来作为直接证据。因为当时是周五，园区的物业只有周一才上班。周一上班的时候才联系上物业。我原本以为车位前面那个圆圆的是摄像头，后来物业那个是检测车位是否占用的，另外一个角度有摄像头，但是被一个大柱子挡住了。当时是通过 imagemagick 把视频分割成照片，然后再自己组合起来合成一个帧率低的一个视频。这样获取到了车牌号，后来报警，通过警察对方联系了我，我把这个视频给她看了，她的车身左侧位置的确是有一道划痕，但是她不承认就是这一次蹭的。她说她自己经常蹭这蹭那，不一定就是我的车蹭的。因为没有直接的视频拍到接触画面，所以这一次事故也没有办法。而且这一次报警，警察连来都不愿意来的。
https://www.bilibili.com/video/bv14S4y1E7e
第三次，就是最近的一次了，停在小区。当时车辆有震动告警了，然后我就下去了看了，然后发觉是有工人在搬空调。当时就问他是不是搬空调时不小心蹭到了，对方很激动地否认了。继续报警，警察过来看了，然后看了四周没有摄像头，就说应该不行了。其实当初远处一个摄像头，但当时警察说肯定拍不到，也就没有看了。后来问了邻居，邻居说可以看到的。后来就去找物业看监控，的确是能看到那个时间点，他们在面包车车尾处下货，但是他们的车身已经把前面全部挡住了，所以根本看不到后面。这一次虽然报了警，还去做了笔录，但是依然没有什么卵用，还是得自己去修车。
所以停车被蹭几乎是个无法解决的问题，这是一个薛定谔的猫，你也不知道什么时候会发生。如果能够遇到素质高的人，能够主动承认就已经非常不错了。当然对于这种情况也想到了以下几种尽可能能够去追回肇事方的方法：
监控 行车记录仪 哨兵模式 监控是最有效以及最直接的证据。而且一般监控其实覆盖的距离还是比较远的，所以停车的时候可以尽量找那种摄像头可以覆盖的区域。一般这种区域都是停车场主干道附近，以及一些交汇处。不过这个也需要结合时间段来去找，如果车子有震动告警，这样会比较好找一些。
接降压线的行车记录仪理论上是可以做到24小时监控的。但是一般会有电压保护，防止小电瓶没有电，所以可能有的时候电压保护就断电了。另外，就是普通的可能是缩时录影，一般一分钟或者几十秒拍一张照片，这种视频也难以作为直接证据。但是如果是正常录制的话，可能录不了特别长的时间，往往可能只能录满几个小时。所以，行车记录仪往往也只能作为辅佐手段之一。
目前很多新能源汽车已经有哨兵模式了。这种模式下发生震动事件后，会自动记录四周的照片和一点点视频，这个往往是比较好用的。但是小鹏有一个缺点，就是哨兵模式需要手动开启，所以会经常忘记。
插件开发，是一件即快乐又痛苦的事情。快乐的是你可以根据自己的需求通过插件来进行实现，比如经常看到的 Chrome 的插件开发。插件对于应用的原生生态有着很大的益处，往往那些特别优秀的插件甚至会被官方收编或者在正式功能中加入插件的功能。痛苦的是你需要去看文档，看插件开发的各种文档，如果文档不详细的话，痛苦加倍。程序猿最讨厌的事就是看别人的文档以及自己写文档。当然，除了文档，作为小白你还会踩到各种各样的坑。
先吐槽 五一期间，疫情实在是憋得无趣，于是就成生了编写一款 Goland 上的 SCA 检测的插件的想法。Jetbrains 作为一个 IDE 开发公司，通过 Java 的语言生态开发出 IDEA 全家桶系列如此精美并且功能强大的 IDE 产品。其背后的技术能力不得不让人折服。IDE 是程序猿开发的生产力，而 Jetbrains 公司则是生产力的生产力。这几天，笔者就在着力开发一款针对 Goland 的第一款 SCA 检测插件。相较于以往 Chrome 或者 Burp 的插件开发而言，Jetbrains 插件开发的难度大大提升，主要是因为以下几点原因：
API 文档过于简单 IntelliJ 只提供了官方的文档地址。这里面包含了一些 API 的实现以及介绍，但是太简单了。全篇中几乎找不到相关实现的示例代码，通常只有寥寥数语的介绍。举一个例子，希望能够通过插件能够创建文件，在找遍了官方的文档后，只发现了以下内容：
文档里面提到可以使用 PsiDirectory 中的 add 方法来保存 PSI 文件，但它没说 HOW！那怎么办，只能去 Github 中去搜索代码关键字，然后扒别人的代码去看别人是如何实现的，这绝对是一个非常痛苦的过程，尤其是你看的是一个实现很糟糕的插件。
API 复杂性 由于 IDEA 强大的生态，其 API 要考虑到兼容性以及很多特性，所以 API 中很多的含义不好理解。其本身也是包含了很多复杂的配置项，同时还需要综合考虑插件是通过什么样的形式去实现。
太“强大的”官方模板 官方提供了一个创建插件的模板。首先承认的一点是这个模板的功能非常强大，涵盖插件开发、单元测试、质量检查、发布的整个生命周期，并且与 Github 无缝集成。不过作为模板，它包含的内容是不是太多了呢？这个模板的 README 几乎看了3遍之后才知道里面包含了哪些内容。实际上，对于一个小白来说，这个过程挺痛苦的，甚至可能有的人看了一下就萌发了退意。里面的一些模块，比如单元测试模块以及覆盖率检查这些模块，可以作为可选项，并不一定要默认就包含进去。
Bug 有一点点多 目前尚未确定是否这是一个 Bug，但是笔者严重怀疑这是一个 Bug。上面提到的模板，通过 Gradle 实现了一系列的任务。在 Run Verifications 中，有个小任务是 .
在 Go 的开发过程中，经常遇到一个非常麻烦的问题就是 JSON 的解析。因为 Go 中的 JSON 的解析，一般来说需要定义对应 JSON 的 struct。或者使用 interface{} 类型来进行定义，然后再进行类型的转换。当然这在 Python 中可能两三句话就搞定了。
在 Goland 2022.01 最新版本中，终于迎来了在 JSON 方面解析的便捷功能。在最新版本中，只要将 JSON 粘贴到 IDE 中就会提示是否转化为 struct 类型，所有的字段都会被生成，相对于以前的一个个的手动的定义要方便太多太多了。
还可以使用 Action 来进行转换动作，Generate Go Type form JSON：
同时还可以添加新的 tag，key 以及修改 key 的代码风格，调用来说一般使用 alt+enter 快捷键即可。
Intention actions 字段添加新的 tag
点击 struct 的字段然后按 alt+enter 选择 Add key to tags 修改 key
点击 struct 的字段然后按 alt+enter 选择 Update key value in tags 修改 key 的代码风格
在搞完 gobuster 系列源码阅读的第一篇以及dir篇之后，对于 gobuster 的实现思路已经比较熟悉。本文就对剩下的模块进行一个讲解，由于一些公共模块在前面的两篇文章中已经提过，所以本文主要专注于每个模块所独有的部分。
在前面的文章中提到过，gobuster 中的各个模块中的核心功能都是基于 libgobuster/interfaces.go 中接口的实现。而 PreRun 以及 Run 函数则是每个模块实现的核心所在，所以关注其它模块这两个函数的实现的即可。
dns 对于 dns 模块中的 PreRun，其内部也有一个 ErrWildcard 的实现。其实现过程也有一点类似于 dir 模块。通过将 uid 和 domain 进行拼接，理论上这个域名应该不存在，会报一个 no such host 的报错。如果不存在这个报错，则表明对于任意域名都会解析成同一个 IP。如果没有报错，则表明这里可能存在 ErrWildcard。
wildcardIps, err := d.dnsLookup(ctx, fmt.Sprintf("%s.%s", guid, d.options.Domain)) if err == nil { d.isWildcard = true d.wildcardIps.AddRange(wildcardIps) if !d.options.WildcardForced { return &ErrWildcard{wildcardIps: d.wildcardIps} } } 在通过 PreRun 函数之后，即是 Run 函数的实现，这个函数的实现基本上逻辑非常简单，就是解析出域名对应的 IP 即可。
s3 s3 模块主要用于亚马逊云存储桶的包括，里面的实现逻辑比较简单，主要是基于 https://%s.
gobuster 作为一款信息收集工具，深受安全业界的欢迎。希望通过阅读优秀工具的源码，能够了解其工作的具体细节，为自己日后造轮子也做好准备工作。
入口 得益于 Golang 的跨平台属性，其编译过程极其简单，编译的结果直接为二进制程序，可以直接使用，这也是越来越多安全工具选择 Golang 的原因之一。对于每一个 Golang 项目，其根目录下都有一个 main.go 的文件，gobuster 也不例外。
func main() { cmd.Execute() } 这里即是作为程序的入口来展开这次代码之旅。Execute 其实主要是接受程序中断的信号做相应的处理操作，里面的主要涉及的知识点为 context 以及 Signal，前者主要是为了方便程序的取消、退出，后者则是捕获系统中断的信号。Notify 函数负责将 signal 一直传送到管道 c，这个函数可以一直调用。直到调用 sinal.Stop 的时候，signalChan 中的 sinal 则会被清空。这一段代码里面的内容主要是 signal 这一块的内容，可以参考 Golang 的官方文档，里面讲的非常的详细。
func Execute() { var cancel context.CancelFunc mainContext, cancel = context.WithCancel(context.Background()) defer cancel() signalChan := make(chan os.Signal, 1) signal.Notify(signalChan, os.Interrupt) defer func() { signal.Stop(signalChan) cancel() }() go func() { select { case <-signalChan: fmt.
在本系列的第一篇中，主要阅读了 gobuster 入口的这一部分。后续主要是阅读各个模块工作的细节，本文主要讲解 dir 模块。dir 模块主要是实现目录爆破的功能，其主要命令行配置项包括以下内容：
Usage: gobuster dir [flags] Flags: -f, --add-slash Append / to each request -c, --cookies string Cookies to use for the requests -e, --expanded Expanded mode, print full URLs -x, --extensions string File extension(s) to search for -r, --follow-redirect Follow redirects -H, --headers stringArray Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2' -h, --help help for dir -l, --include-length Include the length of the body in the output -k, --no-tls-validation Skip TLS certificate verification -n, --no-status Don't print status codes -P, --password string Password for Basic Auth -p, --proxy string Proxy to use for requests [http(s)://host:port] -s, --status-codes string Positive status codes (will be overwritten with status-codes-blacklist if set) (default "200,204,301,302,307,401,403") -b, --status-codes-blacklist string Negative status codes (will override status-codes if set) --timeout duration HTTP Timeout (default 10s) -u, --url string The target URL -a, --useragent string Set the User-Agent string (default "gobuster/3.
原文：3 parameters to measure SAST testing
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
在我们之前的博客中，为什么你不能仅使用列表、测试套件和基准测试来比较 SAST 工具，我们探索了当今常用来评估和比较 SAST 测试工具的各种工具和指标。我们还研究了为什么这些工具可能会产生不一致的结果并且对于评估 SAST 测试工具可能根本不可靠的一些原因。
相反，在评估 SAST 测试工具时，你需要考虑 3 个参数：
准确性 完整性 任意其它独特价值 在本文中，我们将探索这些参数并研究测量它们的方法。在评估 SAST 测试工具时，有两种相关类型的测量 - 定量（意味着结果的数量与“误报”）和定性（特别是语言深度和支持）。
定量方面 以下对准确性和完整性的定义起初有点复杂，因为它们实际上是同一枚硬币的两面。数学上不可能（根据赖斯定理）进行完美的静态程序分析。人们可能会认为增加建议的数量会发现所有可能的问题。可悲的是，这也会将误报 (FPs) 的数量达到干扰让结果无法处理的级别。SAST 测试供应商可以使用一些技巧来改进结果，但在数学上完美是不可能的。
准确性 在 SAST 测试的上下文中，准确性被松散地定义为具有最高数量的 TP（真正类，即实际问题的发现），同时保持最少数量的 FPs（误报，因此是错误的）。
准确性尤其重要。高准确率意味着我们可以获得更有价值的结果，以及更少的“噪音”（不相关的、无法操作的报告）。“噪音”也是阻碍开发者使用 SAST 测试产品的第一大因素，这就是为什么准确性越高，整体开发者体验就越令人满意的原因。
为了计算准确性，你首先需要对结果进行分类。那么公式就是 TP*100/(TP+FP)。这将产生一个介于 1 到 100 之间的数字。数字越大，准确度越高。例如，找到 140 个 TP 和 40 个 FP 的工具的准确率为 77.
最近偶然间有看到某家的一个站点中的网站中的前端代码的“泄露”。此处的泄露为什么打引号，因为一般来说网站的前端代码都是可以通过浏览器即可访问。但是一般生产环境中的 JavsScript 代码都是经过压缩和混淆的，所以可读性大大降低，这也提升了从前端的角度挖取更多信息的门槛。这里的泄露指的是在 Chrome 浏览器的 Sources 面板中可以看到完整的以及原始的前端代码。
通过这样的源码，可以非常清晰地了解应用的前端业务，包括接口信息，如果前端包含加解密的逻辑的话，这样也非常有利于攻击者进行破解。
目前市面上绝大多数应用都是前后端分离，基本上绝大多数是基于 Vue 或者 React 这样的前端框架。而大多数应用配套的构建工具则是 Webpack。而这种源码的泄露真是因为 sourceMap 而导致的，但是这种配置在前端开发环境中是必不可少的，因为如果缺少了 sourceMap 那么前端开发者就无法进行前端代码的调试，sourceMap 正是帮助开发者进行前端代码的调试。通常通过 devtool 的配置即可开启 sourceMap，Webpack 会为相应的 js 文件生成对应的 map 文件，在 js 文件的最后一行会有 sourceMap 的申明，表示 map 文件的地址。
module.exports = { ... devtool: 'source-map', ... } 市面上的绝大多数浏览器都是支持 sourceMap 的，Chrome 浏览器默认支持。打开浏览器的开发者工具，在 Sources 面板中的设置可以看到相应的配置项，勾选后即可在面板中看到对应解析的源码。
不过大家可能有一个疑惑，在 Chrome 的 Network 面板中看不到 map 文件的网络请求。但是如果直接使用抓包工具去抓包的话，是可以看到对应的 map 文件的请求的。通过 chrome://net-export 可以捕获请求，通过 https://netlog-viewer.appspot.com/#events 即可查看捕获的日志文件，可以看到对应的 map 文件的请求记录。
毫无疑问，sourceMap 如果在生产环境开启的话，必然具有一定的安全风险，因为从很大程度上帮助攻击者了解应用，获取应用的更多信息。那么，我们是不是可以写一个 Chrome 插件来检测这种问题并且来直接进行源码的下载呢。实现这样的插件不是件很困难的，检测 js 文件请求，然后尝试请求对应的 map 文件。有不少开源库能够进行 sourceMap 的解析，Mozilla 的 source-map 即是一个能够解析 sourceMap 的 js 库，亦可以通过这个库生成 js 的对应的 sourceMap。
