Anonymous曝光域名注册提供商Epik 180GB数据-附下载链接 业界新闻
点进来的人也是想下载,不明白的就看 Anonymous 原文:
***************************************************************************************** ________ __ .__ \_____ \ _____...
关于SQL中join的各种用法总结 技术文章
首先声明:文章来源于国外的 codeproject 我这里只是由于复习SQL的时候需要就Google搜索[可以用我个人搭建的Google搜索供大家搜索文章学习使用]了一下,找到这篇文章,再次做个简单的记录同时也方便以后的有缘人,如有侵权的地方还请来信注明,感谢原文的作者的勤劳付出,留下如此详细全面的关于SQL的join的用法。
codeproject是国外一个免费的可以公开自己写的代码与程序的优秀网站有点类似于GitHub只不过是社区版,在这个网站所有用户都可以发布自己写过的代码,程序,或者是详细的文档说明。比国内的cnblog、csdn都要好,如果要说缺点的话,就是全英文的,当然大部分还是比较容易理解的。但是codeproject也有中文区: https://www.codeproject.com/Forums/1580230/General-Chinese-Topics.aspx ,感兴趣的可以去注册玩。
我们先用一张图来看一下 LEFT JOIN、RIGHT JOIN、INNER JOIN、OUTER JOIN 等七种 join 相关的用法:
下面分开说明这七种用法,先说第一种:
1.INNER JOIN(内连接)
这是最简单,最容易理解的Join,也是最常见的。此查询将返回左表(表A)中右表(表B)中都具有匹配记录的所有记录(共同拥有的相同的部分)。此Join用法的代码大致如下:
SELECT <select_list> FROM Table_A A INNER JOIN Table_B B ON A.Key = B.Key
2.LEFT JOIN
(左连接)
LEFT JOIN 关键字会从左表 (table_name1) 那里返回所有的行,即使在右表 (table_name2) 中没有匹配的行。此Join用法的代码大致如下:
SELECT <select_list> FROM Table_A A LEFT JOIN Table_B B ON A.Key = B.Key
3.RIGHT JOIN
(右连接)
RIGHT JOIN 关键字从右表(table2)返回所有的行,即使左表(table1)中没有匹配。如果左表中没有匹配,则结果为 NULL。此Join用法的代码大致如下:
SELECT <select_list> FROM Table_A A RIGHT JOIN Table_B B ON A.Key = B.Key
4.OUTER JOIN
(外连接)
FULL OUTER JOIN 关键字只要左表(table1)和右表(table2)其中一个表中存在匹配,则返回行. FULL OUTER JOIN 关键字结合了 LEFT JOIN 和 RIGHT JOIN 的结果。此Join用法的代码大致如下:
SELECT <select_list> FROM Table_A A FULL OUTER JOIN Table_B B ON A.Key = B.Key
5.LEFT JOIN EXCLUDING INNER JOIN
(左连接-内连接)
此查询将返回左表(表A)中与右表(表B)中的任何记录都不匹配的所有记录。此Join的编写如下:
SELECT <select_list> FROM Table_A A LEFT JOIN Table_B B ON A.Key = B.Key WHERE B.Key IS NULL
6.RIGHT JOIN EXCLUDING INNER JOIN
(右连接-内连接)
此查询将返回右表(表B)中与左表(表A)中的任何记录都不匹配的所有记录。此Join的编写如下:
SELECT <select_list> FROM Table_A A RIGHT JOIN Table_B B ON A.Key = B.Key WHERE A.Key IS NULL
7.OUTER JOIN EXCLUDING INNER JOIN
(外连接-内连接)
此查询将返回左表(表A)中的所有记录以及右表(表B)中都不匹配的所有记录。我还没有需要使用这种类型的Join,但是其他的类型,我经常使用。此Join的编写如下:
SELECT <select_list> FROM Table_A A FULL OUTER JOIN Table_B B ON A.Key = B.Key WHERE A.Key IS NULL OR B.Key IS NULL
下面举一些例子:
TABLE_A PK Value ---- ---------- 1 FOX 2 COP 3 TAXI 6 WASHINGTON 7 DELL 5 ARIZONA 4 LINCOLN 10 LUCENT TABLE_B PK Value ---- ---------- 1 TROT 2 CAR 3 CAB 6 MONUMENT 7 PC 8 MICROSOFT 9 APPLE 11 SCOTCH这七种连接方式的结果如下所示:
-- INNER JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A INNER JOIN Table_B B ON A.PK = B.PK A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- 1 FOX TROT 1 2 COP CAR 2 3 TAXI CAB 3 6 WASHINGTON MONUMENT 6 7 DELL PC 7 (5 row(s) affected)
-- LEFT JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A LEFT JOIN Table_B B ON A.PK = B.PK A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- 1 FOX TROT 1 2 COP CAR 2 3 TAXI CAB 3 4 LINCOLN NULL NULL 5 ARIZONA NULL NULL 6 WASHINGTON MONUMENT 6 7 DELL PC 7 10 LUCENT NULL NULL (8 row(s) affected)
-- RIGHT JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A RIGHT JOIN Table_B B ON A.PK = B.PK A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- 1 FOX TROT 1 2 COP CAR 2 3 TAXI CAB 3 6 WASHINGTON MONUMENT 6 7 DELL PC 7 NULL NULL MICROSOFT 8 NULL NULL APPLE 9 NULL NULL SCOTCH 11 (8 row(s) affected)
-- OUTER JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A FULL OUTER JOIN Table_B B ON A.PK = B.PK A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- 1 FOX TROT 1 2 COP CAR 2 3 TAXI CAB 3 6 WASHINGTON MONUMENT 6 7 DELL PC 7 NULL NULL MICROSOFT 8 NULL NULL APPLE 9 NULL NULL SCOTCH 11 5 ARIZONA NULL NULL 4 LINCOLN NULL NULL 10 LUCENT NULL NULL (11 row(s) affected)
-- LEFT EXCLUDING JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A LEFT JOIN Table_B B ON A.PK = B.PK WHERE B.PK IS NULL A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- 4 LINCOLN NULL NULL 5 ARIZONA NULL NULL 10 LUCENT NULL NULL (3 row(s) affected)
-- RIGHT EXCLUDING JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A RIGHT JOIN Table_B B ON A.PK = B.PK WHERE A.PK IS NULL A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- NULL NULL MICROSOFT 8 NULL NULL APPLE 9 NULL NULL SCOTCH 11 (3 row(s) affected)
-- OUTER EXCLUDING JOIN SELECT A.PK AS A_PK, A.Value AS A_Value, B.Value AS B_Value, B.PK AS B_PK FROM Table_A A FULL OUTER JOIN Table_B B ON A.PK = B.PK WHERE A.PK IS NULL OR B.PK IS NULL A_PK A_Value B_Value B_PK ---- ---------- ---------- ---- NULL NULL MICROSOFT 8 NULL NULL APPLE 9 NULL NULL SCOTCH 11 5 ARIZONA NULL NULL 4 LINCOLN NULL NULL 10 LUCENT NULL NULL (6 row(s) affected)注:原文连接:https://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins
利用d3.js对大数据资料进行可视化分析 网络安全
作者: Anthr@X [email protected]
0x00 背景
对于前段时间流出的QQ群数据大家想必已经有所了解了,处理后大小将近100G,多达15亿条关系数据(QQ号,群内昵称,群号,群内权限,群内性别和年龄)和将近9000万条群信息(群号,群名,创建时间,群介绍),这些数据都是扁平化的2维表格结构,直接查询不能直接体现出用户和群之间的直接或者间接关系。通过数据可视化,可以把扁平结构的数据作为点和线连接起来,从而更加直观的显示出来从而进行分析。
d3.js是一个近年来推出的基于javascript的数据展示库,全称为Data Driven Document, 在浏览器数据展示领域的地位类似于通用js框架里的jQuery。d3.js的官网是d3js.org,大家可以在上面看到很多例子和应用。d3.js也是图形数据库neo4j所内置的数据展示工具。
说到图形数据库,其实正确的翻译应该是图数据库,图即所谓的Graph,来自于数学里的图论,比如四色定理和推销员过桥的问题(著名的NP问题之一)。图数据库着重于数据之间的关联和属性,对于关系错综复杂的关系分析效率很高。例如,我想知道谁是我朋友的朋友,并且他们有哪些朋友也认识我。对于这种问题,普通关系型数据库的计算复杂度是O(N^c)左右或者更高,N为选择范围的数据集合大小,你好友数量加上好友的好友的数量等,c为关系层数。图数据库的计算复杂度在O(N^2)左右或者更低,但是基本不会超过O(N^2)。图数据库对于复杂关系数据查询起来效率高的主要原因是在数据输入的时候就已经对关系进行了处理和索引,这样做在查询的时候具有很高的效率,但是在数据导入的时候会很慢。QQ群的15亿个关系在向图数据库neo4j里导入的时候花了3天都没弄完,也没有进度提示,所以后来我直接放弃了。
0x01 数据处理
在QQ群和群成员关系里面,对于层数我是这么定义的:
第1层:目标QQ加入的所有群 第2层:目标QQ加入的所有群的所有成员 第3层:目标QQ加入的所有群的所有成员加入的所有群 . . .
大家可以看出这样的查询是可以递归的,假设每个QQ号所加入的群数量和每个群的成员数量为N,那么查询3层数据时总计算量为N*N*N
=n^3,所以当查询层数为c层的时候,计算复杂度是N^c。
前面说过,图数据库的计算复杂度一般在N^2以下,所以当使用普通的关系型数据库的时候,如果查询的层数不多,效率和图数据库比起来差不多,加上关系数据库自带的便于管理和导入导出的属性,所以我还是选择了mysql数据库。
对于QQ和QQ群之间的关系,每个QQ号都能加入群,一个群里也有很多QQ,基本都在几十到几百人,所以两个QQ号在同一个群里不一定代表他们的关系很紧密,换句话说QQ和QQ群之间的关系相对于QQ好友而言相对较弱。但是这并不代表我们从中不能分析出有用的资料,俗话说的好,大数据就像一座金矿,只有用力挖才能挖到金子。
d3.js支持多种数据格式,比如JSON,XML,CSV,HTML等,因为PHP的数组可以很简单的转换为JSON格式,所以我选择用PHP写API来获取JSON数据。QQ和QQ群是一种典型的图数据的应用,QQ和QQ群作为节点(node),QQ加入了哪些群作为关系(link),d3.js内置了一个功能很强大的内建布局,叫做Force-Directed Graph(受力导向图),后面简称为force。force布局模拟了一些基本的物理粒子原理,比如引力和斥力(确切的说是模拟了电磁力和引力,在离的远的时候会互相吸引,在离的近的时候斥力急剧增加),并且可以调节力的大小和受力距离等等,可以说是自由度相当高。关于d3.js的force布局,在官网有详细的API和不少例子,这里我就不贴代码了。
在force布局里面,数据源的JSON可以有很多种不同的格式和属性,但是基本格式如下:
{"nodes":[{"num":10001,type:"qq"},{"num":12345678,type:"qun"}],"links":[{"source":"10001","target":"12345678","auth":1,"nick":"pony"}]}
其中nodes数组对应的是节点列表,links对应的是关系列表。
每个节点可以有很多自定义属性,在d3.js可以针对每个节点存取节点的属性,比如我定义num是QQ号或者群号,type代表节点是QQ还是群,另外我在js里设定在type==‘qun’的时候显示群的图标,是qq的时候显示qq的图标。关系里面默认的属性有source和target,分别对应一个关系的两头,默认情况下关系里面的source和target对应的数字是节点在节点数组里面的位置index。但是我自定义成了qq号和群号。另外你也可以定义其他属性,比如auth代表这个QQ号在群里的权限,nick是群昵称。
对于QQ群这样的关系来说,基本上在第4层和以上的QQ和群的关系就比较弱了,所以为了提高查询速度和减少节点数量,我只查询2层关系(少么?不少,要想想有些群有超过500人……)。
首先,d3.js需要在浏览器里面运行,我的首选是Google Chrome,V8引擎的效率果然不错,在节点和关系不多的时候基本感觉不到延迟,后来在FF和IE11里面测试了一次,FF比Chrome卡一半左右,IE的话我只能呵呵了……
先拿小马哥做个测试,QQ号是霸气的10001。当d3.js导入完数据JSON的时候,各种节点会在屏幕上乱飞几秒钟,直到他们的力达到一个稳定的平衡点。结果如下:
说明:
企鹅图标的节点代表QQ,群图标的节点是群(废话么)。 每条线代表一个关系,一个QQ可以加入N个群,一个群也可以有N个QQ加入。 线的颜色分别代表: 土豪金:群主 狗腿绿:群管理员 屌丝蓝:群成员
大家也可以看到,群主和管理员的关系线也比普通的群成员长一些,这是为了突出群内的重要成员的关系。
图标旁边自动标注了QQ号和群号,如果有的话还有群名。没有在QQ号旁边标注昵称是因为很多人加入不同的群使用的是不同昵称,所以把昵称放到了其他的地方显示。
在下图中大家可以隐约的看到,所有的关系都是以QQ 10001为起点的。
在图上节点是可以拖拽的,拖拽后会固定在你释放的地方。我们把几个群稍微拖的分开一点,关系就一目了然了
这个时候我们可以看到在目标的QQ群里也有很多共同QQ号,比如有些QQ号同时加入了2,3个群。群名显示的都是各种产品开发讨论群,这些同时加入2,3个产品群的人估计不是产品经理就是主管吧……
鼠标悬停到群图标上可以看到群的详细信息(如果有的话)
因为很多人在不同群里的昵称不一样,所以群内昵称等信息就只能放到link上面了,因为线比较细,所以鼠标比较难对准,这个功能还待修改。
这个家伙和小马哥一起同时在3个群里,好基友?
小马哥的QQ群信息展示完了,下面我们来看看更加实际的应用,比如把某圈子里的人找出来。我们先从某土豪大黑阔大牛的QQ号入手:
初始数据好多……此大黑阔加入的群够杂的,不过就是因为杂所以才能更深入的了解一个人的所有喜好。看看群名神马的,我好像看到了dota,XX国际俱乐部,web技术交流,XXsec等群……充分说明了此人……是个屌丝技术宅大黑阔,XX国际俱乐部又似乎带着那么种高大上的感觉……
图中错综复杂的各种关系组成了一朵朵盛开的菊花,向我们诉说着他的历史……
为了理清他那不堪回首的过去和关系网,我特地把浏览器窗口拖到第二个屏幕上,然后把群挨个分开。为了保护当事人的隐私,这张图我打码了。
这张图比较宽,建议大家下载下来放大看
0x02 总结
假如把层数扩展到4层,不知能否筛选出中国所有黑阔的QQ号呢?至少我已经在这张图里看到了很多熟悉的名字和号码。
腾讯总是说漏洞早已修复,不存在问题了,广大网民放心,但实际上信息泄露这种事情,岂是你漏洞修复好了就结束了的事情?
注:转载自乌云文库,原作者为QQ群关系查询站的站长 --- insight-labs ,原文地址:http://drops.wooyun.org/tips/823
互联网黑市分析:社工库的传说 业界新闻
任何一个行业都是一个江湖,有江湖就有故事,追名逐利的人喜欢被写入故事,踏实做事的人却希望被隐匿。久而久之,江湖上的故事越来越虚名浮利,听故事的人也越来越坐井观天。岂不见无数江湖武侠小说,开篇的人物总是让我们误以为是江湖大侠,看着看着才发现一山更比一山高,到最后才发现开篇人物简直是不入流的小啰啰。而真正的高人,反而隐匿成传说。
互联网行业也是如此,大家喜欢创造故事,故事也越来越千篇一律的浮躁:什么产品上线7天就几百万用户、什么开发阶段就上亿投资、什么90后霸道总裁颠覆行业、什么大咖的内部分享、从xx看xx的四大趋势、从xx看xx的十大价值、xx的专注力、xx的微创新、xx的平台化、xx的独家专访首次讲述xx辛酸、xx概念的深度解析加独特见解,等等。翻来覆去,好像也就是那么多东西了。
就好像有些江湖人士,是需要靠卖艺为生,请个会吆喝的帮忙吆喝吆喝,弄个猴子上蹿下跳一下,响啰使劲的敲几下,骗骗几个外行人,撒点碎银子,仅此而已。接下来大家再接着吹嘘一番,比比谁拿的碎银子多点,动口不动手。长期以往,有些人招摇撞骗,也竟然成为了一代口碑中的大侠。久而久之,如今很多江湖人士只是卖艺拿贵客的碎银子为生,如何卖艺卖的更好是大家追求的目标。那些内功心法,武功秘籍,也都成为了历史,那些大侠们,也成为了传说。
难道江湖不再是那个江湖了么?其实不然,浮躁沉沦的只是江湖白道,只是这些大内侍卫,镖局镖师,衙门捕头而已。而江湖黑道中,黑客技术、海盗精神,继续被追捧,虚浮的商业模式永远不如深度技术被重视,“铁甲依旧在”的情怀还在回荡,而地下产业链相关的进步也在不断的深入,并且潜伏起来暗自发展,为了更大的目标和黑暗梦想。
什么是社工库
社工库是社会工程学数据库的简称(Social Engineering Data)。
提到社工库就必须先介绍一下社会工程学(Social Engineering),这个名词最早是在2002年由传奇黑客米特尼克(Kevin David Mitnick)在提出,但其初始目的是让全球的网民们能够懂得网络安全,提高警惕,防止没必要的个人损失。由于米特尼克在黑客界的传奇地位,很快社会工程学就开始被深入研究并且发扬光大。
社会工程学,准确来说是一门艺术和窍门的集合。它利用人性的弱点、心理的缺陷,以顺从意愿、满足欲望的方式,让人们上当,或以此为入口进行攻击。社会工程学的窍门也蕴涵了各式各样的灵活的构思与变化因素,利用人的弱点如人的本能反应、好奇心、信任、贪便宜等弱点进行攻击。它集合了心理学、社会心理学、组织行为学等一系列的学科,由于其非法性和在很多国家地区都被严厉的打击,社会工程学也变成了一个见不得光的学派。
但是在黑客群体中,社会工程学就是他们的第一方法论和必修课。离开了社会工程学,黑客们运用的网络技术几乎都没有用武之地。如果我们用黑客最喜欢的海盗来比喻,各种网络技术可以比作航海、游泳、剑术、而社会工程学即是海盗们的行为准则和创新指引。
那么什么是社会工程学数据库(社工库)呢?即黑客在运用社会工程学进行攻击的时候,积累的各方面数据的结构化数据库。简单的说,社工库是黑客用来记录攻击手段和方法的数据库,这个数据库里面有大量的信息,甚至可以找到每个人各种行为记录(每个人在每个网站上的账号、密码、分享的照片、信用卡记录、订的机票记录、通话记录、短信内容、各种社交软件的聊天等等包罗万象),比如之前有很火爆的查询开房记录的数据库,就是一个典型的极简单的社工库的例子。
那么社工库又是如何产生的,在国内的互联网地下产业链中,又是什么模式的存在,发展又是什么情况呢,我们接着分析。
社工库的发展:数据盗窃
既然是传说,背后就有很多故事,说到社工库的产生和发展,我们就得先从互联网的数据窃取与交易开始说起。
互联网用户数据泄露一直是行业关注的焦点,从最近的京东用户密码泄露事件,到之前的CSDN的数据库完全爆出,再到如家酒店的用户数据泄露,网站和黑客在用户数据上一直在进行着旷日持久的攻防战。但是爆出来的数据泄露,仅仅是冰山一角,甚至也不到。而且这些信息其实对于黑客来说,根本没有什么价值。而对于用户来说的危害,也没有想象的那么大,因为大多数时候这些数据在黑市中几乎都已经是半公开的性质了。
而数据窃取与交易这个细分领域也几乎是地下产业链隐藏的最深的一部分,很多在互联网地下产业链中沉寂了多年的大佬都并不了解此道的相关信息。绝大多数被盗窃后的网站数据,并不会公开与众,只是交易后进入到地下产业链的其他环节而已。所以目前到底有多少网站的数据已经被窃取我们没法客观的进行数据分析。但在互联网黑市中,大家说起来类似的问题,常用的一个词是“十墓九空”,也许这个说法有点夸张,但是也可以参考。
我们从2009年以来,通过黑市的舆情监控和专业网络调查,对互联网每年的流量排名前100的网站(刨去没有用户账号机制的)进行调查,结果如下:
数据窃取产业虽然隐藏的非常深,但是发展历史永久,地下产业链也随之成熟,对于如何把数据变成货币,已经有了非常完整的程序的分工协作渠道。而其模式相对简单,一般只包括:脱库、洗库、撞库这几个阶段。
在地下产业术语里面,“脱库”是指入侵有价值的网络站点,把数据库全部盗走的行为,因为谐音,也经常被戏称作“脱裤”。在取得大量的用户数据之后,黑客会通过一系列的技术手段清洗数据,并在黑市上将有价值的用户数据变现交易,这通常也被称作“洗库”。最后黑客将得到的数据在其它网站上进行尝试登陆,叫做“撞库”,因为很多用户喜欢使用统一的用户名密码,“撞库”也可以是黑客收获颇丰。
在早期的数据窃取过程中,这几个阶段几乎都是由同一个团队、甚至单个人来完成的。发展到今天,已经完全细化成产业链,很少有人从脱库、洗库一起做了,而变成:定制化模式,或交易化模式。
定制化模式:就是现有下游客户指定的某一家网站,然后聘请黑客去脱库,脱库后获得佣金的模式,在定制化模式中,有很强的黑产规矩即数据属于下游客户,而黑客不可以再次出售,或者在一定的窗口期内不能再次出售。
交易化模式:黑客去某一家网站脱库,脱库后直接在黑市上寻找下家,在这种模式下一般可以反复出售,但是由于风险较大,而且数据真实度和新鲜度不一定能得到保证,又充满了骗局,越来越没落了。
而下游客户定制某特定一家网站的脱库,是怎么盈利呢?
大多数时候,都是竞争对手或者上下游企业采购,而且大多数都是主流互联网产业链中的客户,甚至是传统企业客户。其实这个模式很简单,想一想在生意场上,这家网站的数据库对谁谁有利,谁就可能是潜在的定制客户,只不过由于很多主流互联网企业或者传统行业很少了解这个地下产业,所以就会有一些中间人,来做中介促成相关的生意,而这些中间一般情况就是黑市里面的买家或者定制客户了。
我们用实际的例子说明:M哥在黑客圈小有名气,技术过硬。某互联网医疗产品最近要拿投资,深度用户不够啊,通过中间人,辗转的找到了M哥。M哥奋战了几天,直接脱裤了几家三甲医院的网络挂号系统,历史数据应有尽有,结构化分类一应俱全。M哥到手200w,中间人到手300w,而这家互联网医疗产品由于用户的激增和数据的全面性,以及对应新产品的虚假运营,多拿来1000w的投资,绝对双赢。
社工库的发展:洗库撞库
如之前分析,不管数据如何贩卖交易,卖给谁,怎么卖,最后黑客手里面还会有一份数据,由于黑市一般都采取定制化交易,黑客们不能再次出售了,所以一般情况下黑客们会用这份数据进行洗库撞库再洗库操作。
洗库主要是清洗这些数据中可以直接变现的部分,但是这样可以直接洗库的就能洗出价值的数据,其实并不多。一般都是有预存款或者虚拟物品交易的数据库才能洗出来价值,例如:游戏账号、电商账号等等。
更多的时候,黑客将得到的数据在其它网站上进行尝试登陆,叫做“撞库”,因为很多用户喜欢使用统一的用户名密码,“撞库”其实可以收获颇丰。而撞库和洗库的过程是配合的,黑客使用自己开发的工具、直接数据库匹配登录技术以及配合黑色产业链中的打码机制(之前TOMsInsight报告中有介绍)可以对很多网站进行批量撞库,一旦成功,可以进行再次洗库。
这就好比黑客们拿到了一份没什么价值的网站的全部用户名和密码,没关系,可以用这份用户名密码来尝试着登录有价值的网站嘛,如果能登录,不就可以洗出来价值了么,我们还是继续看M哥的例子。
M哥卖掉了几家三甲医院患者的挂号数据,虽然到手200w,但是也不满足。想想这几百万条数据,应该还会有别的价值吧。但是M哥又是一个传统的讲道义的黑客,不会再次出售给别的买家。只能从这些数据本身来找到价值了。
M哥尝试用这些数据登陆QQ、京东、支付宝、淘宝、各类网游,从而洗掉里面的资产,但是由于各种网络的安全策略的保护,M哥虽然有收益,但是却不多,甚至都不够自己的洗库撞库的网络成本,于是M哥继续沉寂下来,这一沉寂,开辟了一个传说。
社工库的发展:构建传说
在很多时候,社工库都是一个传说,就像海盗里面流传的那笔谁也不知道的宝藏,只有那块已经不知道转了多少手的脏兮兮的残缺的藏宝图才预示着它的存在。但是社工库却又很客观的放在那里,一直存在,一直沉寂。
除了贩卖数据本身得到金钱上的利益之外,黑客还会把得到的数据进行整理,制作成社工库。社工库是一个积累的过程,也需要大量的人力物力的去建设,同时还是一个漫长的过程。开始的时候就像M哥一样,单兵作战的去积累,今天是三甲医院的数据库,明天是旅游网站的数据库,后天的演唱会订票网站的数据库,这些数据库积累越来越多。
M哥后来遇到了V哥,V哥是同行,手里面也有很多数据库,可以和M哥互补,两人一拍即合,把双方的数据库融合起来,内容变得更丰富。而且两个人不断的进行分析维护,排除噪点数据和没有价值的数据,相互关联,刻意的去丰富一些必需的数据字段:比如QQ号和密码、比如手机号、比如身份证号。再刻意的去交换购买补充一些极其有价值的,比如征信报告。
社工库的内容越来越丰富,而M哥和V哥两个人力量还是小,两人刻意的去联合同行,组成利益联盟,把手里面的数据都放到一个社工库,组织力量去维护去分析。
这是一个放大的效应,由于社工库的日益庞大,信息的日益完善,再加上时间的沉淀,很多数据都可以慢慢地浮出水面,可以获得相当多的信息。目前有一些公开的社工库,信息全面性和对于用户隐私的了解以及让人震惊,但是这才是仅仅公开的社工库,对于黑客们来说其实已经是没有价值的信息。真正地下的社工库的数据信息丰富程度要远远更大,也绝对隐匿。
利用社工库,几乎可以暴漏出一个网络用户的全部网络行为、大量的用户隐私,和一些牵扯到个人身份财产的相关的数据信息。
首先让洗库变得更加容易:由于数据量很大信息很全,很多的账号的的虚拟财产的转移就不像之前那么困难,了解到信息之多甚至都可以伪装成这个用户去进行操作了。
其次让各种诈骗变得简单:之前大多数诈骗都是光撒网模式,而社工库的完善后,可以非常有针对性对一些特定的用户进行诈骗。利用数据技术,甚至通过木马分析一些用户QQ聊天的内容,寻找有价值的目标,和相对更信任的关系网络。这种模式风险会更小,而且由于诈骗目标相对较大,收益更大。在这种模式下,完成技术分析工作的一般是黑客,但是最后完成诈骗的却一般不是,黑客把按照客户要求去分析,最后把可以完成某种特定诈骗的目标连通相关信息出售(黑市称脚本)。
最后社工库也成为地下产业链的基础服务商:全面的社工库基础数据,也是精准的流量获取来源,成为流量获取分发的地下产业链的基础服务和大数据服务商。一些特有的黑色产业目前非常依赖社工库,例如精准定位的赌博平台、一些p2p金融类型的诈骗、或者是一些商业骗术。
社工库还可以进行网络的定向攻击,有时候一些不懂行的人进入互联网,糊里糊涂的就被骗的搞的一塌糊涂,互联网并不简单,简单的是那些幼稚的主流科技媒体,真正的中国互联网行业水很深,深到还没有外企可以成功的地步。
而社工库也在不断的扩大,丰富,并且继续沉寂。
社工库的发展:未来趋势
从2013年以后,国内互联网黑市上的数据交易产生了严重的分层:一些大的数据盗窃团伙早已经完成早期的数据积累构建非常完善的社工库,对于一般的数据定制需求都不会再接,会专注于更深度变现更强的金融诈骗;而一些小的数据盗窃团伙还在不断的相互交易、交换数据、而且相对高调的浮出水面,其实危害反而没有那么大。
而且出于用户交互方面的考虑,目前越来越多的移动终端支付或者金融产品的安全策略略浅,再加上更丰富的网络电商活动,导致沉寂在黑产中的数据危害也越来越大。这可能也会是更多的互联网产品的设计时需要考虑的问题所在。
而真正沉浸起来的社工库,一方面已经成为传说,另外还在构建着自己未来的目标,这些才是真正危害,也是对于我们最大的威胁。我们TOMsInsight分析到此很矛盾:在这个主流互联网都在炒作概念玩击鼓传花的骗术,而地下互联网都在积累的年代,也许我们真的应该沉下心去仔细的去研究去分析去洞察,而不是人云亦云。
“暴漏出来的社工库都是小孩玩的,真正有价值的社工库谁也不会暴漏,都在沉寂”, M哥对我们TOMsInsight的调研员说到“有时候真的看不懂现在主流的互联网,拿几百万投资就嘚瑟的不得了,其实就是不入流的卖艺打赏呗,小孩过家家。我们这行很多人都能一天赚出来这个投资数的现金来,反而继续去沉寂,沉下心钻研,为了未来更大的打算。“ M哥的话有些绝对了,但是在某种程度上也值得我们反思。
给我们的启示
江湖的故事会继续,传说也会继续。有些人可以选择视而不见,有些人也会选择去逃避。但是冬天始终都会到来,冷暖自知。我们不能要求每一个互联网人都踏实下来,毕竟一些浮躁的跟风卖艺求打赏也会是很多人的生存之道,但是我们应该知道,江湖并不是由他们构成,那些传说,也都和每一个故事一样的真正的存在我们的身边。
当一个行业的地下产业比主流产业更踏实,看的更长远,也更注重积累的时候,也许很值的我们所有的从业人员反思。毕竟,传说应该属于真正的英雄!
再次验证百度这SB搜索,还是Google搜索靠谱 技术文章
起因是在论坛看到的一个帖子找智者的博客的一篇文章:如何将将多说评论数据转回EMLOG,但是百度搜索到的都是无法访问的,因为智者的网站服务器出问题了样 有可能是自己折腾死了。。。百度和google在搜索这方面差的太远了。。。下面是对比
都是主机宕机了,可是Google的缓存还是可以用的,可是百度的就玩完了。。。百度取消快照之后,发现变得很鸡肋。。。不知道是不是天朝的原因,怕青少年搜索到了一些不该看的缓存东西,所以让百度取消快照。。。当然都是Mrxn自己瞎掰
还有就是百度今年说对https的支持,但是收录还是一直那鸟样,不收录,没使用https之前,收录很快,现在是每天来,但是不收录,他大爷的就是玩。。。google收录很及时,貌似360搜搜都比百度蜘蛛勤快。度娘,赶紧把蜘蛛鞭打一顿,这么懒!
下面附上将多说数据转回emlog或者是其他博客的教程:
刚刚使用emlog时还在习惯性的使用多说评论,不过发现评论无法同步回本地。所以只能百度下解决办法。(只不过最后我放弃了多说)
使用说明:
1.在多说管理页面导出多说评论
2.解压附件,解压导出的多说评论到同一目录
3.打开start.sql
4.[如果你是在emlog上使用本程序,且数据库前缀为emlog_可忽略这步] 修改第六行,例如评论数据表名称(默认emlog_comment)
5.修改多说文章ID前缀和多说页面ID前缀,如果你是直接写文章ID的话就可以忽略这步了
6.运行start.php,会在本目录下生成output.sql
7.导入到数据库即可
因为之前遇到过此类问题不知如何解决。就当备份。
其实附件里面就是一个 start.php 防止附件失效(博客搬家,有可能损坏),我在这里把代码贴出来,以防万一:
<?php $dss = json_decode(file_get_contents('export.json'),true); //前缀,不支持后缀(因为懒) $threadpf = 'blog-'; //多说文章ID前缀,无前缀留空 $pagepf = 'page-'; //多说页面ID前缀,无前缀留空 $inssql = "INSERT INTO `emlog_comment` (`cid`, `gid`, `pid`, `date`, `poster`, `comment`,`mail`, `url`, `ip`, `hide`) VALUES ('%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', 'n');\n"; //SQL语句模板 date_default_timezone_set('Asia/Shanghai'); $threadlen = strlen($threadpf); $pagelen = strlen($pagepf); $thr = array(); $cids = array(); $result = ''; $tempcid = 0; foreach ($dss['threads'] as $val1) { if (strpos($val1['thread_key'], $threadpf) === 0 || strpos($val1['thread_key'], $pagepf) === 0) { $thr[$val1['thread_id']] = substr($val1['thread_key'] , $threadlen); } } //多说你妹的居然不按父子顺序导出评论 foreach ($dss['posts'] as $val3) { $tempcid++; $cids[$val3['post_id']] = $tempcid; } foreach ($dss['posts'] as $val2) { $gid = isset($thr[$val2['thread_id']]) ? $thr[$val2['thread_id']] : ''; if (!empty($gid)) { if (empty($val2['parent_id'])) { $pid = '0'; } else { $pid = isset($cids[$val2['parent_id']]) ? $cids[$val2['parent_id']] : 'FUCKDS'; } $cid = $cids[$val2['post_id']]; $date = strtotime($val2['created_at']); $poster = sqladds($val2['author_name']); $comment = sqladds($val2['message']); $mail = $val2['author_email']; $url = sqladds($val2['author_url']); $ip = $val2['ip']; $result .= sprintf($inssql, $cid , $gid , $pid , $date , $poster , $comment , $mail , $url , $ip); } } file_put_contents('output.sql', $result); echo 'Complete! Author: <a href="http://zhizhe8.net/" target="_blank">Kenvix</a> @ <a href="http://www.stus8.com/" target="_blank">StusGame GROUP</a>'; /** * 使用反斜线引用字符串或数组以便于SQL查询 * 只引用'和\ * @param $s 需要转义的 * @return 转义结果 */ function sqladds($s) { if (is_array($s)) { $r = array(); foreach ($s as $key => $value) { $k = str_replace('\'','\\\'', str_replace('\\','\\\\',$value)); if (!is_array($value)) { $r[$k] = str_replace('\'','\\\'', str_replace('\\','\\\\',$value)); } else { $r[$k] = sqladds($value); } } return $r; } else { return str_replace('\'','\\\'', str_replace('\\','\\\\',$s)); } }
参考:
http://zhizhe8.net/?post=85705
http://www.glr-s.com/em/22.html
http://bbs.emlog.net/thread-40003-1-1.html
让MySQL缺失的ID值自动恢复增长和补全缺失的ID 代码人生
话说,百度知道很强大,自己很弱小呀......才疏学浅.
如下图所示:
想要 cate_id 字段的值 从1开始往下增长 1 2 3 4 5 6 7 8 ....,而不是2 3 4 5 6 7 8 ....
一共有3种修复方法:
第一种手先动修复成1 2 3 4 5 6 7
操作MySQL:输入ALTER TABLE tdb_goods_cates AUTO_INCREMENT = 8
这样往后的资料会从8开始(对于数据量小的可以这么做)
第二种重置表方法
首先--no-create-info,-t仅输出资料
然后把表tdb_goods_cates所有资料使用delete tdb_goods_cates删除
然后输入ALTER TABLE tdb_goods_cates AUTO_INCREMENT = 1
再把输出资料的.sql文件导入就可以了
第三种mysql语法(推荐使用)
UPDATE tdb_goods_cates set cate_id = cate_id-1
然后输入ALTER TABLE tdb_goods_cates AUTO_INCREMENT = 8
这样就可以解决这个问题了.话说,百度知道很强大,自己很弱小呀......才疏学浅.