Everything you care about in one place

Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.

Get Feeder

wechat2rss.xlab.app

全闲话

Get the latest updates from 全闲话 directly as they happen.

Follow now 13 followers

Latest posts

Last updated about 1 month ago

热点探讨:你手上正在玩的AI画图画对了嘛?

about 2 years ago

看图说话,我说你画画画,你画我猜猜猜。

热点探讨:你手上正在玩的AI画图画对了嘛?

about 2 years ago

原创 高艹 2023-03-24 16:30 广东 看图说话,我说你画画画,你画我猜猜猜。 先看图,再说话。最近玩几个新发布的工具上头了,无论是看别人玩还是自己上手,都是真的太好???了,太有意思了。说问题,你认为AI把这个图画对了吗?先别着急回答,很可能答错哈。如果不小心试图从目前AI框架的技术实现原理角度来理解这个结果,就会发现答案应该是画的没毛病!在目前这套AI框架的数据世界里面,“人”就是一直坚持不懈地这么教它的,教了好多年:这玩意他妹的就叫饺子,而且是通过反复上显卡调教出来的!从概率计算结果来理解,饺子的概率就是远高于其他可能性,嘀!那个看起来像笼子的碗也是同一个理由出来的。因此,AI画的完全没有任何问题!嘿~(简单粗暴的略过如何改变这个计算结果,因为探讨下去,很可能会涉及到更深层次的哲学伦理问题:要不要给AI打上思想钢印,要不要...)AI画对了!同理,扩展到AI编程、AI视频、AI PPT也是一样的。关键是,这种风格太尼玛上头了,简直就是一种“艺术”。相信目前大部分人都开始把AI看作一个应该能帮得上忙的工具,激进一点的看成差不多可以替代你工作的工具了。那么作为工具的使用者,你更应该知道它能干什么,它不能干什么,对吧!特别是当这个工具是你专门人肉纯手工打造,专门用来适应自己特殊操作癖好的,那更是自然就知道这玩意的工作原理,不然后果不堪设想呀!划重点:如果一个人不能正确能认知一个东西在另一个东西眼里是个什么东西以及为什么这个东西会认为那个东西会是什么东西,那大概率这个人也用不好这个东西。挺好玩的,确实挺好玩的,有点上头,每天不玩睡不着觉。 阅读原文 跳转微信打开

不要盲目迷信任何基于特征识别的技术

about 3 years ago

看图快速回答问题

不要盲目迷信任何基于特征识别的技术

about 3 years ago

原创 高艹 2022-04-15 14:26 看图快速回答问题 看图,请快速回答问题:这是什么摩托车?俗话说开局一张图,剩下全靠编......高尔基说过,只有先把基调定好,才能确保不翻车~起因来自一个玩笑,龙某大师傅因为频繁访问443端口,于是被某防护系统警告。于是本人果断甩出一张图,想请这个系统判断一下,这是什么摩托车,不要求给出型号,猜出品牌即可。难不?不难?其实,上面问题就是一个典型的特征计算过程,但是很不幸,计算过程中会遇到以下几个典型问题:大部分系统的关注重点焦点不会在车上,不会在车上!那会在哪儿呢?这是一个计算目标可能就有根本错误的问题!很大概率根本就不是摩托车,如果硬要系统给出一个摩托品牌,结果大概率能拿到几个,至于准不准那就......这是一个限定领域的计算问题,需要综合判断其他特征,但是画面内能提取的特征太少!太少!需要增加一系列辅助条件。而且需要注意,辅助条件大概率是假设条件!比如,有朋友会注意到汽车的车牌:云A,还有街边的植被环境,可猜测是云南,因为云南大部分地区不禁止摩托车,所以给出一个摩托车品牌的可信度会大大增加......比如,有朋友会进一步发挥,也有可能是???南车行驶在广东省会啊,因为省城禁摩,所以应该是电动车...那...这个目标问题岂不是给不出答案了?因为车头没有拍到摩托车车头的典型结构,但有没有可能是一部精心伪装过的小排量摩托?大部分正常人会告诉你:这是电动车!但是,绝大部分基于特征计算系统,会强行给一个摩托车识别结果!好玩不?搞笑不?但是确实又很真实,而且还在真实地发生着。所以不要迷信任何基于特征计算的系统,是任何!段子讲完了,按照本人一贯尿性,此文禁止联想! 阅读原文 跳转微信打开

我食言了,哈哈哈

about 3 years ago

这个号...终于更新了哈...哈哈哈

我食言了,哈哈哈

about 3 years ago

原创 高艹 2022-03-16 19:57 这个号...终于更新了哈...哈哈哈 先说为啥食言了。很久之前曾经diss过订阅号的新排列方式,认为采用的弱智推荐算法,会非常不利于中小用户的推广,等于是否定了当年那句著名的“再小的个体也有自己的品牌” 这句。我还放言这个推荐不改,我不更新...于是1年多没有发1篇...但是今天不得不食言了,原因是被伟大的2胡同学推荐了一下,有幸跟众多大佬出现在一起,看到1年没有涨过的粉蹭蹭往上跑,吓到了,感觉不写点啥出来,对比起lake2的列表~ 阅读原文 跳转微信打开

展示个新折腾出来的小玩意 自制最简单的电吉他无限延音+激励回授外挂

over 4 years ago

原创 高艹 2020-11-01 23:44 曝光一下最近折腾的小玩意 自制最简单的电吉他无限延音+激励回授外挂原文发在了gc上面,这里也贴一下。=====================先上2图,给大家看看啥叫无限延音外挂。最近折腾这玩意,目标是用市售最便宜的电路板搭出来一个无限延音系统,必须够灵活,单节锂电池3.7v供电,也就是得省电才行。实现的效果:1. 无限延音2. 激励回授,可以通过琴体音量钮控制回授大小3. 手持共振喇叭靠近拾音器上方,会有惊喜出现(暂不揭秘),另类玩法 我前后做了3套,内嵌到半空心吉他里面一套,就是之前我发过贴无聊自制的那把半空无头琴。不过总觉得不够环保,不够方便。继续折腾外挂方案。照片上展示了2套外挂,右边檀木外壳的是第一版,尺寸大了点,因为为了调试,全部用了接插线。第二版就是正常焊接,也就是左边那个铝壳的,一个打火机长度,串接在琴身和吉他线之间,有开关,可以随时关闭打开。没有采用琴体埋线圈的办法,经过验证发现这个是真的没必要!用木吉他加震套装那种共振喇叭不香嘛?没有纸盆,不粘在平面上自己基本没啥动静的那种喇叭,目标是把弹奏的声音反馈回来直接震动琴体,从而持续带动琴弦振动。琴体振动起来,手感也会非常美妙~铝壳的上面带2个旋钮,1个用来粗略调节共振喇叭和的输出音量,1个用来精细调节前级放大板放大倍率,这样会比较容???找到无限延音的起点卡在那里。电路部分比较简单,前前后后试验了各种成品电路,发现还是lm386最好用,耗电低,放大倍率够高。需要改动的地方只有2个。把R1地方换成10k的电位器,用来控制放大倍率,可调范围大概是几十到200倍,板子上自带的那个电位器引出来,不换也行,就是调整起来麻烦点。(我叫LM386电路原理图)(成品LM386电路板长这样,输出的座子要焊下来,太大了)但是只有lm386还是不够,不足以产生让共振喇叭振动琴体的能量,后面加一个后级板,这玩意可选的很多,比如下面这个号称8002的小板子。共振喇叭试验了好几种,最后发现这个4欧的比较合适,双面胶粘在白色圆盘上,然后在琴身上找个地方沾下去就行了。总结一下用料造价方面:  锂电池 厚10...

由于蜜罐这几天比较热闹,蹭热度说个故事

over 4 years ago

蹭个热度,我也说说部署蜜罐系统那点破事...

由于蜜罐这几天比较热闹,???热度说个故事

over 4 years ago

原创 高艹 2020-09-16 14:35 蹭个热度,我也说说部署蜜罐系统那点破事... 提前声明:本文不说打穿蜜罐的那些破事,哈哈哈,失望了?没有?众所周知,搞安全的都喜欢部署蜜罐系统/钓鱼系统,一般是丢在内网玩。除非是有实力,而且是非常有一腚实力的才敢放外网,不然呢?大家都看到xxx被爆菊了吧,哈哈哈~所以,传统安全领域里说的蜜罐,咱就不说了,讲个不太一样的用法。这个其实是个旧事,距今大概10几年了。那时候高草还在邮箱部门搬砖,重头构建新的安全体系。说重头做,其实都是被逼的,全TMD是被逼的,原系统基本没啥架构可言,破腚百出...当时花了好几天时间,做了个半年计划,写完了自己看着PPT总觉得缺点啥,总感觉有一个环节没打通。当时的情况是,每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点:量大,重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来,归纳总结,用算法(当时不流行说AI、深度、神经病算法这些)分析分析。这事苦恼了好久也不知道怎么搞,索性静下心来人肉分析样本。于是,从系统各个环节采集样本,大概有几百万的规模。等都看完,问题有答案了,办法自己就来了,你说神奇不神奇!咱直接在前面协议交互时,从HELO开始,就把那些发送给不存在人的邮件都收下来。在正常的协议交互里,自然是会告诉你这个账户不存在或者系统错误,然后byebye断开连接。这里可以做点手脚,另外找个地方继续往下走,邮件体咱都存下来,然后内容+行为分析下不就行了!嗯,当然为了增加点迷惑性,还得加个随机,一会账号存在,一会账号不存在。这个做法开发量非常少,很快就能上线,内容行为归纳总结的模块基本都是现成的,怼进去就行,把发现的异常样本按照出现数量排个序,定期更新,ban就是了,都不用担心会存在误判。于是,每天80%-90%的垃圾就这样被搞定了,哈哈哈~为了方便非邮件系统圈子内读者的理解,这里稍微解释一下。逻辑是这样的,正常的邮件系统肯定是知道准确的收件人地址,手误写错地址的情况有,但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境,黑产灰产还是采用基于字典广度覆盖的方式比较多。所以,在系统侧会发现,每天都有数目庞大的不存在地址探测。只是,正常情况下,这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”,然后断开了,不会往下面流程走。咱既然是要做个蜜罐,理论上100%都采集下来也问题不大,当然大系统就不推荐这么干,浪费资源不说,你这系统咋啥地址能收到呢?对方一眼就能发现问题,所以,设置一个不大不小的概率肯定是必须的。至于存下来后面接的东西,无论是交互行为分析,还是内容分析,都不是什么难事,直接略过。这套蜜罐直接对外网服务,按道理是不妥的,要解析内容就会遇到很多未知风险,如果给开了shell那就更sb了不是。所以,进入到后期分析之前,还是要做一些必要的过滤处理的,该丢的先都丢掉,也就是只解析一些我们感兴趣的东西,一般只要包括文字、图片、JS就行了。但是,JS不要解析不要解析不要解析!说到图片,必须多讲几句,图片的处理库当年还不是那么多,开源的就几个,也不是很好用,都有一些大大小小的兼容性问题,core掉还不是大问题,单是溢出开shell都已经有很多了。咋办?完全重写肯定不现实,所以高草当时做了一件几乎不被开发理解的事情:把几种主要格式的处理库都剪裁出来了,重新包装了一遍,第一层必须是对buffer做限制性复制,然后才丢给相应的解析库处理。格式也不多,干起来也不难,BMP,JPEG,GIF...也就那么几种格式,很好搞。至于剪裁解析库这个事,其实不需要过多解释,搜一下过去几年的开源图片处理库漏洞,比如imagemagick库给人家弄出来多少远程shell,你就知道那时候我在担心啥了。反正该做的都尽量做好,剩下的就是更衣沐浴抽根烟上线。故事讲完了,这里说的这个蜜罐系统的做法,只是想说一句蜜罐其实也可以这么玩。不必纠结,蜜罐是好东西,小心用就是了,哈哈哈~谨以此图,献给对蜜罐又爱又恨的朋友~

由于蜜罐这几天比较热???,蹭热度说个故事

over 4 years ago

原创 高艹 2020-09-16 14:35 蹭个热度,我也说说部署蜜罐系统那点破事... 提前声明:本文不说打穿蜜罐的那些破事,哈哈哈,失望了?没有?众所周知,搞安全的都喜欢部署蜜罐系统/钓鱼系统,一般是丢在内网玩。除非是有实力,而且是非常有一腚实力的才敢放外网,不然呢?大家都看到xxx被爆菊了吧,哈哈哈~所以,传统安全领域里说的蜜罐,咱就不说了,讲个不太一样的用法。这个其实是个旧事,距今大概10几年了。那时候高草还在邮箱部门搬砖,重头构建新的安全体系。说重头做,其实都是被逼的,全TMD是被逼的,原系统基本没啥架构可言,破腚百出...当时花了好几天时间,做了个半年计划,写完了自己看着PPT总觉得缺点啥,总感觉有一个环节没打通。当时的情况是,每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点:量大,重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来,归纳总结,用算法(当时不流行说AI、深度、神经病算法这些)分析分析。这事苦恼了好久也不知道怎么搞,索性静下心来人肉分析样本。于是,从系统各个环节采集样本,大概有几百万的规模。等都看完,问题有答案了,办法自己就来了,你说神奇不神奇!咱直接在前面协议交互时,从HELO开始,就把那些发送给不存在人的邮件都收下来。在正常的协议交互里,自然是会告诉你这个账户不存在或者系统错误,然后byebye断开连接。这里可以做点手脚,另外找个地方继续往下走,邮件体咱都存下来,然后内容+行为分析下不就行了!嗯,当然为了增加点迷惑性,还得加个随机,一会账号存在,一会账号不存在。这个做法开发量非常少,很快就能上线,内容行为归纳总结的模块基本都是现成的,怼进去就行,把发现的异常样本按照出现数量排个序,定期更新,ban就是了,都不用担心会存在误判。于是,每天80%-90%的垃圾就这样被搞定了,哈哈哈~为了方便非邮件系统圈子内读者的理解,这里稍微解释一下。逻辑是这样的,正常的邮件系统肯定是知道准确的收件人地址,手误写错地址的情况有,但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境,黑产灰产还是采用基于字典广度覆盖的方式比较多。所以,在系统侧会发现,每天都有数目庞大的不存在地址探测。只是,正常情况下,这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”,然后断开了,不会往下面流程走。咱既然是要做个蜜罐,理论上100%都采集下来也问题不大,当然大系统就不推荐这么干,浪费资源不说,你这系统咋啥地址能收到呢?对方一眼就能发现问题,所以,设置一个不大不小的概率肯定是必须的。至于存下来后面接的东西,无论是交互行为分析,???是内容分析,都不是什么难事,直接略过。这套蜜罐直接对外网服务,按道理是不妥的,要解析内容就会遇到很多未知风险,如果给开了shell那就更sb了不是。所以,进入到后期分析之前,还是要做一些必要的过滤处理的,该丢的先都丢掉,也就是只解析一些我们感兴趣的东西,一般只要包括文字、图片、JS就行了。但是,JS不要解析不要解析不要解析!说到图片,必须多讲几句,图片的处理库当年还不是那么多,开源的就几个,也不是很好用,都有一些大大小小的兼容性问题,core掉还不是大问题,单是溢出开shell都已经有很多了。咋办?完全重写肯定不现实,所以高草当时做了一件几乎不被开发理解的事情:把几种主要格式的处理库都剪裁出来了,重新包装了一遍,第一层必须是对buffer做限制性复制,然后才丢给相应的解析库处理。格式也不多,干起来也不难,BMP,JPEG,GIF...也就那么几种格式,很好搞。至于剪裁解析库这个事,其实不需要过多解释,搜一下过去几年的开源图片处理库漏洞,比如imagemagick库给人家弄出来多少远程shell,你就知道那时候我在担心啥了。反正该做的都尽量做好,剩下的就是更衣沐浴抽根烟上线。故事讲完了,这里说的这个蜜罐系统的做法,只是想说一句蜜罐其实也可以这么玩。不必纠结,蜜罐是好东西,小心用就是了,哈哈哈~谨以此图,献给对蜜罐又爱又恨的朋友~ 阅读原文 跳转微信打开

由于蜜罐这几天比较热闹,蹭热度说个故事

over 4 years ago

原创 高艹 2020-09-16 14:35 蹭个热度,我也说说部署蜜罐系统那点破事... 提前声明:本文不说打穿蜜罐的那些破事,哈哈哈,失望了?没有?众所周知,搞安全的都喜欢部署蜜罐系统/钓鱼系统,一般是丢在内网玩。除非是有实力,而且是非常有一腚实力的才敢放外网,不然呢?大家都看到xxx被爆菊了吧,哈哈哈~所以,传统安全领域里说的蜜罐,咱就不说了,讲个不太一样的用法。这个其实是个旧事,距今大概10几年了。那时候高草还在邮箱部门搬砖,重头构建新的安全体系。说重头做,其实都是被逼的,全TMD是被逼的,原系统基本没啥架构可言,破腚百出...当时花了好几天时间,做了个半年计划,写完了自己看着PPT总觉得缺点啥,总感觉有一个环节没打通。当时的情况是,每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点:量大,重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来,归纳总结,用算法(当时不流行说AI、深度、神经病算法这些)分析分析。这事苦恼了好久也不知道怎么搞,索性静下心来人肉分析样本。于是,从系统各个环节采集样本,大概有几百万的规模。等都看完,问题有答案了,办法自己就来了,你说神奇不神奇!咱直接在前面协议交互时,从HELO开始,就把那些发送给不存在人的邮件都收下来。在正常的协议交互里,自然是会告诉你这个账户不存在或者系统错误,然后byebye断开连接。这里可以做点手脚,另外找个地方继续往下走,邮件体咱都存下来,然后内容+行为分析下不就行了!嗯,当然为了增加点迷惑性,还得加个随机,一会账号存在,一会账号不存在。这个做法开发量非常少,很快就能上线,内容行为归纳总结的模块基本都是现成的,怼进去就行,把发现的异常样本按照出现数量排个序,定期更新,ban就是了,都不用担心会存在误判。于是,每天80%-90%的垃圾就这样被搞定了,哈哈哈~为了方便非邮件系统圈子内读者的理解,这里稍微解释一下。逻辑是这样的,正常的邮件系统肯定是知道准确的收件人地址,手误写错地址的情况有,但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境,黑产灰产还是采用基于字典广度覆盖的方式比较多。所以,在系统侧会发现,每天都有数目庞大的不存在地址探测。只是,正常情况下,这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”,然后断开了,不会往下面流程走。咱既然是要做个蜜罐,理论上100%都采集下来也问题不大,当然大系统就不推荐这么干,浪费资源不说,你这系统咋啥地址能收到呢?对方一眼就能发现问题,所以,设置一个不大不小的概率肯定是必须的。至于存下来后面接的东西,无论是交互行为分析,还是内容分析,都不是什么难事,直接略过。这套蜜罐直接对外网服务,按道理是不妥的,要解析内容就会遇到很多未知风险,如果给开了shell那就更sb了不是。所以,进入到后期分析之前,还是要做一些必要的过滤处理的,该丢的先都丢掉,也就是只解析一些我们感兴趣的东西,一般只要包括文字、图片、JS就行了。但是,JS不要解析不要解析不要解析!说到图片,必须多讲几句???图片的处理库当年还不是那么多,开源的就几个,也不是很好用,都有一些大大小小的兼容性问题,core掉还不是大问题,单是溢出开shell都已经有很多了。咋办?完全重写肯定不现实,所以高草当时做了一件几乎不被开发理解的事情:把几种主要格式的处理库都剪裁出来了,重新包装了一遍,第一层必须是对buffer做限制性复制,然后才丢给相应的解析库处理。格式也不多,干起来也不难,BMP,JPEG,GIF...也就那么几种格式,很好搞。至于剪裁解析库这个事,其实不需要过多解释,搜一下过去几年的开源图片处理库漏洞,比如imagemagick库给人家弄出来多少远程shell,你就知道那时候我在担心啥了。反正该做的都尽量做好,剩下的就是更衣沐浴抽根烟上线。故事讲完了,这里说的这个蜜罐系统的做法,只是想说一句蜜罐其实也可以这么玩。不必纠结,蜜罐是好东西,小心用就是了,哈哈哈~谨以此图,献给对蜜罐又爱又恨的朋友~ 阅读原文 跳转微信打开