0%

位运算(C/C++)

[TOC]

概念

运算符

  • 位取反运算符(~)

  • 位与运算符(&)

  • 位或运算符(|)

  • 位异或运算符(^)

​ 将两个数的比特位进行合并,返回一个新数。这两个数相同比特位不同时就返回 1。

  • 位左移运算符(<<)位右移运算符(>>)

​ 把所有位数的数字向左或者向右移动一定位数。
​ 将一个数左移一位,相当于把这个数翻倍;将一个数右移一位,相当于把这个数减半。

​ 已经存在的比特位按指定的位数进行左移或者右移,移动后超出存储边界的位都会被丢弃,用 0 来填充移动后产生的空白位。

原码:原码就是符号位加上真值的绝对值,即用第一位表示符号(0 为正,1 为负),其余位表示值。
反码:正数的反码是其本身;负数的反码是在其原码的基础上,符号位不变,其余各个位取反。
补码:正数的补码就是其本身;负数的补码是在其原码的基础上,符号位不变,其余各位取反,最后+1(也即在反码的基础上+1)。计算机用补码表示负数。

正数三码相同,负数的原码取绝对值,反码除符号位以外各位取反,补码为反码+1。

有符号整数

  1. 有符号整数使用第一位来表示该整数是正数还是负数,0 表示正数,1 表示负数。
  2. 其余位数存储实际的值,有符号的正整数和无符号数的存储方式所一样的,都是从 0 开始算起。
  3. 负数的存储方式为2 的 N(数值位的位数) 次方减去它的绝对值。

位运算的性质:幂等律、交换律、结合律、分配律、德摩根律(对偶律)、取反运算性质、与运算性质、或运算性质、异或运算性质。

逻辑移位:移位不考虑符号位。左移高位丢弃,低位补零,不溢出情况下等价于乘以2;右移低位丢弃,高位补0。

算术移位:移位考虑符号位。左移高位丢弃,低位补零;右移低位丢弃,高位补符号位,等价于除以2,可能发送精度丢失。

格雷码:任意两个相邻的代码只有一位二进制数不同。

技巧

  • a&(a-1)的结果为将a的二进制表示的最后一个1变成0;a&(-a) (与a&(~(a-1))等价)的结果为只保留a的二进制表示的最后一个1,其余的1都变成0。

  • 运算求无符号整数二进制中1的个数

  • 用与运算判断最后一位是否为1,然后向右移位,继续判断。

    进阶:为了简化这个问题,我们考虑只有高位有 1 的情况。例如:11 000 000 ,如何跳过前面低位的 6 个 0 ,而直接判断第七位的 1 ?我们可以设计 11 000 000 和 10 111 111(也就是 11 000 000 - 1)做“与”操作,消去最低位的 1 。如果得到的结果为 0 ,说明我们已经找到/消去里面最后一个 1 。如果不为 0 ,那么说明我们消去了最低位的 1 ,但是二进制中还有其他的 1 , 我们的计数器需要加 1 ,然后继续上面的操作。

    1
    count += num & 1;	num >= 1;
  • 运算判断整数是否为2的整数次幂

    一个整数如果是 2 的整数次方,那么它的二进制表示中有且只有一位是 1 ,而其它所有位都是 0 。 根据前面的分析,把这个整数减去 1 后再和它自己做与运算,这个整数中唯一的 1 就变成 0 了,也就是得到的结尾为 0 。

    1
    return (num & (num - 1)) == 0;
  • 异或运算不借助临时变量,交换两个变量的值

    1
    a=a^b;	b=a^b;	a=a^b; //用两次异或交换变量值
  • 异或运算判断成对数字

​ 两个相等的数异或所得的结果为0,0与任何数字异或得那一数字本身。

C/C++特性

  • 可以移位的数据类型:char,short,int,long,unsigned char,unsigned short,unsigned int,unsigned long
  • 不可以移位的数据类型:double,float,bool,long double
  • 有符号数字左移、右移其符号位受到的影响依照编译器实现而定,即为不确定的。

实例

参考

原文地址:https://nixintel.info/osint/geolocating-mobile-phones-with-an-ip/

文章原名:Geolocating Mobile Phones With An IP

作者: Nixintel

原文发布时间:2020-07-05

}

本文与 *Matthias Wilson (@MWOSINT)*共同撰写,其个人网站也进行了发布。

IP地址在数字取证方面占据着重要地位,但对地理定位有多大用处?事实上,尽管IP地址在侦查方面有许多用处,但在作为定位手段上来说是不可靠的。

IP地址技术本身限制了其成为定位工具。当前的IPv4协议仅允许存在43亿个不同的IP地址,这在设计它的1980年代并不算得上问题,但如今所需的IP地址远超协议所能提供的。

为了解决IP地址短缺问题,ISP在过去的几十年里开发了多种方案。例如,反向代理服务器可以让上千台服务器使用相同的静态IP地址。

网站和服务使用的IP地址通常是固定的。但如果你从家用网络访问这篇文章,你很有可能被你的ISP分配了动态IP。这一IP地址可能在几小时或几天内不变,但ISP商们会经常根据需要调整并重分配IP地址。今天你所拥有的IP地址可能明天就属于这个国家其他地方的人。

在移动互联网方面来说,IP地址短缺问题甚至更加严重。无论你何时连接到3G或4G网络,就可能与几千名其他用户在同一时间分享IP地址。在蜂窝网络中,IP地址也改变的极其迅速,有时甚至几秒一次。

在地理位置与蜂窝网络IP地址之间并不存在真正的相关性。其组织方式并不像老式固定电话一样,而是更取决于ISP的分组方式与服务类型。

有关这一方面的更多细节推荐阅读这两篇论文:

Where’s that Phone?: Geolocating IP Addresses on 3G Networks

Geolocating IP Addresses in Cellular Data Networks | SpringerLink

那对于像 Maxmind 这样的IP地址定位服务如何评价?稍微研究一下它们所提供的数据准确性报告可知,对于其提供的地理信息要谨慎对待。

以德国为例,Maxmind声称其百分之八十三的IP地址与真实地址真正相关,但这是在五十公里半径内,并仅指固定宽带线路。

而对于蜂窝网络IP,其准确性骤降,在五十公里半径中仅有百分之三十八

位置越具体,置信度越低。在德国,IP地址与特定城市关联的置信度仅为百分之十六。而在美国,这一数据为百分之十二,有百分之七十三的IP地址被认为解析不正确。如果说即使是世界领先的IP地址定位公司对于50公里半径定位的精确度也只有如此低的信心,更别说对于具体的城市,那么您还相信蜂窝网络IP定位的准确性吗?

这并不是IP地址定位商的过错,它仅仅是反映了ISP商们按照网络需求而不是地理位置分配IP的现实。

然而,众所周知,可以对手机进行定位。当手机连接到信号塔时,实际上也同时连接到周围所有的信号塔(至少可以监控信号强度)。每个信号塔都存在唯一ID,这一ID可以通过很多方式获取,例如拦截手机与信号塔之间的无线连接,或通过网络反向链接获取连接信息。如果知晓了信号塔的地理位置,就可以通过这些ID粗略定位手机位置。然而,这仅能由强力部门和情报机构在合法情况下实现。那么能用除蜂窝ID以外的信息定位手机吗?

现在大多数手机都一直连接在互联网上。通过智能手机,我们用类似于Signal或Whatsapp的服务访问网站,发送信息,检查并回复邮件。任何这样的连接将依赖于一个关联在我们手机上的IP地址进行传输。在我日用的计算机上,我能通过像 IPLocation的网站查找我的IP地址,它将显示我最有可能所在的地理位置。当然,这仅在我没有使用代理和虚拟专用网络的情况下有用。不同的数据库在地理位置上可能存在细微差别,但正如在下例中所示,根据我的IP地址,我位于慕尼黑附近的某个地方。

为了使这些位置更加直观,我将它们绘制在地图上。在写这篇文章时,我就处于这张图的某个位置上,看起来并不是那么精准,对吧?

这是我使用固定线路的结果,那如果通过IP地址定位手机会怎样?获取手机当前的IP地址并不是听上去那么简单的。就算我收到了从目标手机发送而来的电子邮件,那也有很高的概率其并不包含原始IP地址,尤其是从Gmail或Hotmail这种邮件服务商发来的邮件。那么我们如何获取目标手机的实际IP地址?

在继续阅读之前,请注意:下一步在某些国家可能是非法的,并且非常具有侵略性。我绝不是推荐你必须这样积极的达成目标,我只是使用该技术来证明我的观点。

我向目标发送了一个带有追踪像素(Tacking Pixel)的邮件。别担心,所谓的目标是我的一次性手机。在连接到4G(LTE)的情况下,我打开了这封自己发给自己的邮件。追踪像素,也就是所谓的网页臭虫(Web Beacon),被用于分析一名用户是否访问了位于网页或邮件等内容。这些跟踪器将提供访问时间以及访问内容的 IP 地址等信息。我通过 GetNotify网站来获取追踪像素,然后在手机上打开邮件,结果如下:

由此可见,追踪像素返回了邮件打开的时间,来自我手机浏览器的User Agent字段以及一个IP地址。此IP地址已经注册到Telefonica Germany,该一次性电话的生产商。让我们在IP地址网站上再确认一下:

很好,我们再次看到了慕尼黑,但是还有两个候选城市在地图上。

我就在这附近,但是从地图上来看,另外两个城市距离慕尼黑很远。由此可见,由提供商分配给我手机的IP地址似乎提供了一个相当不准确的位置。4G网络的结构能解释一部分原因。

手机获取到的动态 IP 地址是由所谓的分组数据网关 (P-GW) 分配的。这基本上是互联网的出口节点,IP地址是随机选择的,其来自于地址池。每次重新连接网络时,即使再次连接到同一小区(用于 LTE eNodeB),您也会从此池中获取一个新的随机地址。IP 地址与网络的任何其他元素(例如手机信号塔 (eNodeB))之间没有直接联系。通常,来自 P-GW 的传出流量会为多个已注册的手机分配相同的 IP 地址。虽然来自手机的连接可能会由区域P-GW处理,但在我的情况下,实际位于慕尼黑的P-GW也可以注册到数百公里外的P-GW。我花了一个小时试图找到一个也使用Telefonica/O2的朋友,并请他们协助我。我给她发了一封带有跟踪像素的邮件。以下是返回的内容:

这个IP地址据说也来自于慕尼黑,但我的朋友住在附帕绍近,足足170公里远!请记住,这还是在没有代理和虚拟专用网络的情况下。这是我在LTE上通过比利时IP访问互联网的一次性电话:

总之,通过IP地址对手机进行定位可能会提供一个大致位置(足够幸运的话),但就像其他常规IP地址一样,并不能进行精确定位。我认为,在大多数情况下,固话线路的IP地址所提供的定位比手机IP更加精确。请记住这一点,以便在今后的侦查。

Matthias Wilson & Nixintel 2020年7月5日

github page无法正常实行页面识别

hexo默认生成的页面结构中不包含必须的README.md文件,需要自行添加到source目录中,并将_config.yml文件中的skip_render参数设置为README.md,hexo在渲染时就会跳过该文件。

页面因jsdelivr无法使用打开为空白

因种种原因,jsdelivr无法使用,需要在_config.next.yml中设置plugins参数为custom,并设置相应的custom_cdn_url。

笔者使用了cloudflare代替jsdelivr。

原文地址:https://nixintel.info/osint/website-attribution-cloudflare-v-cloudflair/

文章原名:Website Attribution – Cloudflare v Cloudflair

作者: Nixintel

长时间以来,我一直想写一个关于WHOIS的消亡与调查员在确定隐藏在层层混淆与迷雾后非法网站的运营与所有者时面临困难的文章。没有所谓的完美解决方案,但有很多方法可以帮助网站所有权的鉴别,尤其是在与其他信息链结合后。

任何试图调查可疑网站的人无疑都会在某个时候遇到 Cloudflare 。(我必须强调一下,Cloudflare是一家合法且有用的服务商,它的海量网络资源为网站提供了对DDOS以及其他安全威胁的防护。)用DNSLyticsCentralOps等服务查询托管于Cloudflare的任何域名,你得到的只是Cloudflare服务器的IP地址和无关信息。你无法看到谁是域名的真正主人,或它的真实IP地址是什么。

使用Cloudflair

Christophe Tafani-Dereeper制作的Cloudflair是一款强大的工具,可用于探索隐藏在Cloudflare后的恶意域。其工作原理基于域的SSL证书,每个使用HTTPS的域都有一个唯一的SSL安全证书,通过在互联网上查找证书来确定目标真实IP地址。它还能识别使用同一证书的其他IP地址,无论这些IP地址是否隐藏在Cloudflare后。

假如我运营了一个犯罪网站**www.humantrafficking.org*并使用Cloudflare进行保护,任何进行DNS逆向或WHOIS查询的人只能看到Cloudflare的信息,关于我的域名的真实信息被隐藏了起来。尽管我的真实IP地址是 45.64.244.13 并且我的真实网络主机是 Evildude Web Enterprises,但呈现给调查员的 IP 地址将类似于104.28.13.49(一个真实的 Cloudflare IP)。

尽管如此,类似Censys的网络爬虫将记录其遇到的每一个SLL证书的详细信息和相关的IP地址。这意味着,尽管人们浏览我的邪恶网站或者进行WHOIS/DNS查找只会找到Cloudflare IP 104.28.13.49,Censys也将收录真实的IP地址45.64.244.13,并记录同一域的相同SSL证书链接到两个IP的事实。换句话说,只要网站的真实 IP 地址对 Internet 可见,Censys 就能够找到并记录它,尽管有 Cloudflare。Cloudflair只需获取你感兴趣的域名的详细信息,然后使用Censys进行检查,并显示与特定域名相关的所有IP地址,无论它们是否在Cloudflare后面。在作者的博客上有关于这一切如何运作的更详细的解释。

安装并运行Cloudflair

Cloudflair在Linux环境下运行最佳,因为其预装了Python。可以通过命令行安装或直接从Docker镜像运行。但我发现,在使用命令行运行时,存在一些Python库冲突和问题,但使用Docker镜像容易的多,因此我建议使用Docker镜像。虽然我对于Docker的使用并不熟练,但我发现Cloudflair运行的很流畅,使用上也很直接。我的标准OSINT环境在Linux Mint 19.1上,并且运行 Cloudflair非常顺利。

Step 1

Censys.io创建一个免费账户,你需要在账户页面获取API KEY与API SERCET以运行程序。

Step 2

克隆Cloudflair Github 存储库

1
$ git clone https://github.com/christophetd/cloudflair.git

Step 3

安装Docker(如果没有安装的话)

1
$ sudo apt install docker.io

Step 4

如果这是第一次安装Docker,当尝试以非root用户身份运行命令时可能会遇到问题。确保所使用的帐户属于docker组。进行这些更改后,需要注销并重新登录。

1
$ sudo useradd -aG docker myusername

(在Mint/Ubuntu系统中你需要切换到root用户执行命令。使用sudo -i命令切换,并在执行后切换回原用户)

Step 5

运行以下命令,将目标域名添加到命令末尾。确保添加 Censys AAPI KEY与API SERCET以供其工作:

1
$ docker run --rm -e CENSYS_API_ID=xxxxxxxxxxx -e CENSYS_API_SECRET=xxxxxxxxxxx christophetd/cloudflair evilwebsite.org

第一次运行此命令时,需要下载 Docker 映像。输出将如下所示(从作者的 GitHub 页面复制)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
[*] The target appears to be behind CloudFlare.
[*] Looking for certificates matching "myvulnerable.site" using Censys
[*] 75 certificates matching "myvulnerable.site" found.
[*] Looking for IPv4 hosts presenting these certificates...
[*] 10 IPv4 hosts presenting a certificate issued to "myvulnerable.site" were found.
- 51.194.77.1
- 223.172.21.75
- 18.136.111.24
- 127.200.220.231
- 177.67.208.72
- 137.67.239.174
- 182.102.141.194
- 8.154.231.164
- 37.184.84.44
- 78.25.205.83

[*] Retrieving target homepage at https://myvulnerable.site

[*] Testing candidate origin servers
- 51.194.77.1
- 223.172.21.75
- 18.136.111.24
responded with an unexpected HTTP status code 404
- 127.200.220.231
timed out after 3 seconds
- 177.67.208.72
- 137.67.239.174
- 182.102.141.194
- 8.154.231.164
- 37.184.84.44
- 78.25.205.83

[*] Found 2 likely origin servers of myvulnerable.site!
- 177.67.208.72 (HTML content identical to myvulnerable.site)
- 182.102.141.194 (HTML content identical to myvulnerable.site)

现在你已经可以绕过Cloudflare,通过获取到的真实IP来进行你的探索!

Step 6

为避免每次都输入冗长的 Docker 命令,请在 bashrc 文件中创建以下别名:

1
$ nano ~/.bashrc

并在 .bashrc 中添加以下内容:

1
alias cloudflair='docker run --rm -e CENSYS_API_ID=xxxxxxxxxxx -e CENSYS_API_SECRET=xxxxxxxxxxx christophetd/cloudflair'

保存并退出nano,退出并重启终端应用更改。

现在你只需要输入:

1
$cloudflair mytargetwebsite.com

*除非另有说明,否则本文中的所有 IP 地址都是虚构的。

原文地址:https://nixintel.info/osint/search-tip-finding-historic-whois-data/

文章原名:Search Tip: Finding Historic WhoIs Data

作者: Nixintel

对于OSINT侦探来说,WHOIS简直是一座金矿。总是能在里面找到网站所有者或注册人的地址、电话号码、email等信息。然而,随着越来越多的域名注册商提供了隐私服务,以及GDPR(通用数据保护条例)的推广,大大降低了WHOIS服务作为OSINT工具的实用性。

不过,可以利用 Wayback Machine的力量来查找在隐私保护和GDPR推广之前的历史WHOIS数据。将 Wayback Machine与Who.is获取到的信息相结合,以确定使用正确的URL来查找WHOIS历史记录。

在此例中,我将查找最近破产的旅行社 thomascook.com的WHOIS信息。这是该域的当前WHOIS信息:

img

如果我们想使用WHOIS开始研究该公司,它并没有真正提供任何有用的信息。有个关于Comlaude的详细联系信息,这是一家为大型企业注册域名的服务商,但没有太多其他有用的信息供开源侦探所用。不要止步于此,Wayback Machine将帮助我们回溯时间到域名隐私保护被重视之前。

从 who.is 查找 WHOIS 的 URL 始终采用以下格式:

1
https://who.is/whois/example.com

当在Wayback Machine 搜索存档页面时,URL始终采用以下格式:

1
https://web.archive.org/web/*/https://example.com

因此,将二者结合就可以得出用于搜索任何给定网站的WHOIS历史记录的URL格式:

1
https://web.archive.org/web/*/https://who.is/whois/example.com

所以,当我想搜索 thomascook.com的历史记录,将使用以下URL:

1
https://web.archive.org/web/*/https://who.is/whois/thomascook.com

不出所料,它返回了GDPR前时代的结果:

img

这是在案的最早WHOIS记录:

img

使用这种技术可以发现一个真实的姓名、一个实际地址和一个常规的固定电话号码——所有这些都是进一步探索的绝佳起点。即使这个人的电子邮件地址是模糊的,但我们已经知道该域名,可以很容易地使用像 Hunter.io 这样的工具来猜测出他们最有可能的电子邮件地址是什么。这与我们仅依赖最新的注册商信息相比,从历史WHOIS得出的结果要好得多。

原文地址:https://nixintel.info/osint/website-attribution-without-whois-reverse-ip-lookup/

文章原名:Website Attribution Without WhoIs – Reverse IP Lookup

作者: Nixintel

如何确定目标站点是哪个组织或者个人运营的?对于大多数网络调查来说,确定域的所有者或者实际控制人是很重要的环节,但当他们刻意隐蔽后就很难做到。查找特定网站的所有者最简单便捷的方式就是通过WHOIS追踪。时常可以通过它找到注册人的姓名、地址和联系方式。

img

实际上,很长一段时间内这都是一种可靠的OSINT手段。不过,注册人可以匿名甚至使用虚假的信息注册域。2018年,GDRR的出台意味着在欧盟地区的网站注册信息强制匿名化。这导致现在WHOIS追踪没有过去那么有用了,以后也不太可能有太多的改变。但这并不意味着WHOIS查询不再是OSINT基础操作,只是并不像之前那样有丰富的价值。

免责声明

对于任何方法或者技术,了解其局限性尤为重要。如果没有获得搜查令或者传票,绝对确认谁是域的真正所有者或控制人十分困难。因此,必须认识到,大多数对域的额外信息进行调查的方法并不准确,甚至结果相互矛盾。尽可能地去收集有关目标的信息,并尝试通过不同的信息源进行验证,然后再得出结论,这很重要。

为什么反向IP查询是有用的

什么是反向IP查询?它是怎么帮助OSINT侦探的?反向IP查询可以提供大量关于域托管位置以及同托管空间其他域的信息。这通常是确定多个域是否被同一人所有的有效方法,并能构建目标的互联网画像。

掌握一点互联网基础知识能帮助你更好的理解为什么反向IP追踪十分有用。互联网上的每个域必须有一个IP地址以便流量可以通过路由找到它。当你向访问一个网站时,就在浏览器中输入www.myfavouritewebsite.com。计算机需要知道向哪一个IP地址发送请求来让你浏览网页,所以它将向DNS服务器查询www.myfavouritewebsite.com当前托管在哪个IP地址上。DNS服务器查询后将告知计算机该网站在IP:45.67.131.18*,然后将你的计算机连接到这一地址上。

img

但这种连接不同域的方式存在一个重要问题,IPv4地址的结构方式意味着只有43亿个可用的IP地址。当前使用的IP系统在19世纪80年代早期被发明,那时并不存在这样的问题,但现在已经有超过43亿台服务器、路由器、电话和其他需要 IP 地址才能连接到互联网的设备。

对于网站来说,解决该问题的其中一个手段就是将多个域托管在同一个IP地址上。从OSINT角度来说,这意味着对于拥有多个域的个人或者组织通常会将它们部署到同一个IP地址。因此,不同的域可以通过共享的IP地址建立联系。

反向查找IP工具

有很多工具提供了这种功能,较为常用的有以下几个:

大多数工具都提供了部分免费服务,但会限制搜索次数或者需要付费获得全部信息。

示例 #1 - Osintcuriou.us

这里我选了一个不是很好的目标来展示可从反向IP查询中找到什么。我是故意这样做的,以便为大家说明这种方法的局限性,因为并不是每一次都能从共享IP地址的域之间得到关联。下面我将展示能从 osintcurio.us中找到什么。

首先要获得目标域的IP地址,这并不难,上面提到的几个工具都能获得目标网站的IP。本例中我使用SecurityTrails,当然也可以通过Windows命令行调用nslookup达到相同效果,只需在终端中使用以下命令:

1
nslookup osintcurio.us

将得到类似这样的结果:

img

Linux系统也有相应的命令:

1
dig osintcurio.us

并得到如下结果:

img

如果你不习惯使用命令行,没关系,上面列出的所有站点都会通过 Web 界面显示被查询域的IP地址。在这种情况下,ViewDNS通过GUI给出相同的结果:

img

以上所有结果都显示 osintcurio.us 部署在IP: 192.0.78.24192.0.78.25上。使用 Security Trails可以看到部署在相同IP地址上的其他域名。

img

我们有个小麻烦,在这个IP地址上,部署了2,746,679个不同的域。在这种情况下,可以得出的关于这些域之间关联性的唯一结论,就是它们使用了相同的托管服务提供商!该例很好的说明了反向IP查找作为OSINT工具并不总是有用的,认识到它存在局限性很重要。现在让我们看一看稍微好一些的情况。

例#2 - 一个钓鱼网站

犯罪分子不断创建钓鱼网站,以使他们的钓鱼邮件看起来更可信一些,所有这些都是希望你会被骗,点击安装他们的恶意软件的链接。或者诱骗你在被黑客控制的网站输入你的谷歌密码。 这是一场永无休止的军备竞赛,犯罪分子为网络钓鱼创建域名,而安全公司则识别这些域名并将其列入黑名单。

Phishtank是一个不断更新的钓鱼网站列表,我将随机挑选一个进行反向IP查询。

img

目标是amerewards.net。通过快速WHOIS检查可知,不出所料,注册人选择匿名。那么通过反向IP查找能否找到可能存在的此人控制的其他站点信息?使用DNSLytics查询该IP地址进行反向IP查询。

img

由此可知,amerewards.net由 Hetzner Online GmbH 德国的托管。有趣之处在于,它还显示了五个域名共享同一个IP。让我们看一下它们是干什么的:

img

通过WHOIS查找显示所有这些域名在同一天注册,并同属相同的IP地址。基于概率考虑,可以得出一个结论,那就是它们很有可能是由同一个人控制的。这些域名的名称都带有网络钓鱼的倾向。果然,访问其中之一时会引发火狐的警告:

img

显然其中一个域已被标记为网络钓鱼站点,但在撰写本文时,并非所有域都被标记为网络钓鱼站点。以上过程表明,在一个快速的反向IP查询中,可以通过IP关联简单快速的识别其他同类型的(钓鱼)网站。有许多优秀的商业工具可以自动执行这一过程来进行威胁情报分析,但手动完成它可以更好的了解其工作原理。

例#3 - 一个White Supremacist网站

反向IP追踪还能为传统形式的调查提供帮助,以确定个人或组织之间的关联。本节我以US White Supremacist Stormfront为例说明。重复上述过程以得到Stormfront的托管地址:104.20.32.134

img

该IP属于Cloudflare,我在另一篇文章中提到过如何应对这一挑战,重新聚焦于现在,反向IP追踪可知有五个不同的域托管于此。这再次表明这些不同网站的所有者或运营者之间可能存在关联。通过挖掘WHOIS信息可知这些网站都是多年以来独立注册的,这意味着可以看到该组织在网络上随时间推移的扩大过程。

实际上,Stormfront是一个非常知名的网站,它的运营者并不是一个秘密。但本例还是展示了如何通过简单的反向IP追踪来了解到主体及其关联,即使是在很少或没有公开信息的情况下。有趣的是,尽管 Derek Black 声称已经放弃了他的White Supremacist观点,反向 IP 追踪却暗示了他过去的联系。

在下一篇有关网站追踪的文章中,我将继续介绍Cloudflare以及其带来的一些挑战。

原文地址:https://nixintel.info/osint/website-osint-whats-the-link-between-antifa-com-and-russia/

文章原名:Website OSINT: What’s The Link Between Antifa.com and Russia?

作者:Nixintel

有时候,“OSINT”这个词指代的太宽泛了。OSINT的开源(Open Source)部分很好理解,这有个信息世界,通过足够的挖掘与探索,你几乎可以获取你能想到的任何东西。但这本身并不是OSINT。OSINT 的情报(intelligence)部分经常被忽视,有时会产生相当严重的后果。获取你想要的数据通常很简单,但对这些原始数据进行分析并转化为连贯叙述的过程通常是充满困难和不确定性的。

如果一开始就制定了明确的计划,就能消除很多不确定性。我们必须记住,OSINT并不只是为了自身的利益。它始终是为了实现更广泛的目标,例如进行新闻调查、人员失踪案件侦破或军事行动分析等。你的OSINT目标的性质将最终决定你所进行的研究的范围和形式,以及你提供给客户或老板的结果。从互联网收集原始信息通常是很简单的,但将这些信息制作成有组织、经过验证并可用的报告需要进行更多的工作。

情报循环

img

为了确保OSINT工作的一致性和缜密性,大部分组织都采用了一种类似上图所示的情报循环。这种模型有几种变种,但它们都是相似的。都开始于假设一个初始计划或者目标,然后进行信息收集,并对收集到的信息进行处理与分析,最后将信息传递给预设的接收者。对信息进行处理与分析的阶段是最重要的,因为在这一阶段中,将对收集到的原始信息进行批判性评估、理论检验以及将正确与错误或者模棱两可的信息区分开的地方(译者注:with varying degrees of success可以译为不同程度的成功,但译者不太明白这里用于表达什么)。

这意味着,“我在互联网上找到了大量信息”并不是OSINT。它可能开源,但在被测试、验证与分析之前,并不能称之为有用的情报。你找到的信息能否为最初的问题提供一个有用的答案?你验证过吗?收集到相互矛盾的信息时,你要怎么处理?对于可靠性不确定的信息源给予多大的权重?你向你的客户提供的是OSINT还是狗屁(译者注:原文是BULLSHINT,很巧妙,HHHH)?等等。

Antifa.com 是R国人控制的吗?

那么这一切与Antifa.com有什么关系?我在推特上极力避免政治,但政治总是找上每一个人。最近有人声称,域名Antifa.com将访问者重定向到了乔·拜登的总统竞选网站,而且这个域名是由可疑的R国人注册的,这激起了我的兴趣。难道干预选举的幽灵要再次出现了?

img

对于这个R国链接的核心主张似乎围绕着Antifa.com域的WHOIS历史。我从前总是对仅基于WHOIS得出的结论持怀疑态度,因为它并不是一个明确信息的来源,但这次我决定对域历史做一些深入研究,看看能不能再找到什么。以下是使用情报循环进行有计划的OSINT研究与分析的步骤指南,并看看在这一过程中我们能找到什么。

制定计划-我到底想知道什么?

问题可以很简单,例如:将Antifa.com重定向到拜登的网站是R国人的阴谋吗?这种问法很具有煽动性,而且是只能回复是或者不是的二元问题。该问题也具有诱导性,这种提问方式很可能导致你仅根据政治立场来得出结论,而不是基于任何研究。

一个好的调查性问题不能使用二元与诱导性的提问方式。开放性提问更好一些,并且不易受到我们偏见的影响。例如:Antifa.com 和它的俄罗斯注册商之间有关系吗?如果有的话是什么性质的?这样的提问更好一些。

信息收集-找到我所需要的材料

在情报循环的信息收集阶段,我们要尽可能去收集所有能用于回答在开始阶段所提出的问题的信息。在这种情况下,我想知道Antifa.com域的历史,包括它曾属于谁,它从过去到现在曾显示的内容,以及我们可以找到的任何有关重定向的信息。

我将要尽可能的收集服务器的所有信息来回答这些问题,以让我可以捕捉到任何可能存在的重定向。包括WHOIS记录,证书历史,以及来自于Wayback Machince的任何保留的内容,通过这些信息可以让我知道该网站在过去一段时间内显示过什么内容。

  1. 服务器信息

    Curl仍是我最喜欢的快速获取服务器信息的工具。通过以下命令来抓取Antifa.com服务器的信息:

    $ curl -I http://antifa.com

    标志-I确保我能获得返回的服务器头信息。在这种情况下得到了如下结果:

    1
    2
    3
    4
    5
    6
    HTTP/1.1 302 Found
    Server: nginx
    Date: xxx
    Connection: keep-alive
    Location: https://itsgoingdown.org/
    X-Served-By: Namecheap URL Forward

    有趣的是,它现在还是302重定向的状态,但指向了一个不同的URL。我们还可以知道它使用了Namecheap的URL转发服务,因此我将获取一些有关它如何工作的信息以便于支持我稍后的分析:

    img

  2. WHOIS历史

    我还想尽可能多地了解它的WHOIS历史。毕竟,怀疑该网站与R国有关就是来源于此。这有几个工具可以进行查询,RiskIQWhoisology 可以追溯到2012/2013年的WHOIS数据。但我们知道该域名至少早在 2002 年就已注册(而事实证明,甚至可能更早。),所以我们要尽可能的向前探索。可以通过一些付费服务例如 Domain Tools获取完整的WHOIS报告,但那对一篇简单的blog文章来说有点太贵了。

    幸运的是,有一个可以利用的小技巧,Wayback Machine存档通常记录了WHOIS 本身,因此我们可以使用这种技术来寻找远至2009年的WHOIS记录

    img

    这并不完美,但在不花钱在付费WHOIS记录上的情况下能追溯到最远的地方。RiskIQ所掌握的信息有助于列出更多最近的注册更新或变更日期:

    img

  3. 历史证书

    域的历史证书可以提供对其结构和设置的多种信息,包括所有权和托管更改。 Crt.sh 提供了对站点证书历史的清晰概述,可以使用Censys进行更深入地了解。以下是Antifa.com 的简短历史证书记录:

    img

  4. Wayback Machine

    幸运的是,数年来该站点已被多次存档。最早的捕获可以追溯到1999年1月,最近的捕获是2020年8月17日。自上周以来,该域被大肆更改,产生了如此多的快照并非巧合:

    img

有了这些信息,我们将能够查看网站的历史内容,了解它在不同时间段显示的内容。

处理与分析

通常来说,将原始数据转换为电子表格、图表和关系图将有助于进行分析,尤其是在处理更复杂的任务时。但因为这只是文章中的简短示例,我就不花费大量时间在对收集到的全部信息的处理上了。

因此,我将直接分析收集到的原始数据。我将尝试构造 WHOIS、证书和 Wayback Machine 历史记录的时间线,以了解域如何随着时间的推移发生变化。以及这种变化对有关该域名的原始问题和与其俄罗斯注册商的关系可能意味着什么。

在此之前,看一看一开始抓取的服务器标头:

1
2
3
4
5
6
HTTP/1.1 302 Found
Server: nginx
Date: xxx
Connection: keep-alive
Location: https://itsgoingdown.org/
X-Served-By: Namecheap URL Forward

HTTP302代码标志着所有访问Antifa.com的请求现在都被定向到了另一个站点 :itsgoingdown.org。不出所料,这个网站看起来像是一个left wing political网站。该重定向是通过Namecheap的URL转发服务实现的,通过查看Namecheap有关此过程的文档可知,Antifa.com的管理员需要在Namecheap的控制面板进行相关服务的设置,该域是通过Namecheap管理的。

这不足为奇,因为当前 WHOIS 记录也支持了这种推断:

1
2
3
4
5
6
7
8
9
10
11
12
Domain name: antifa.com
Registry Domain ID: 85915752_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Updated Date: 2019-10-23T14:38:04.00Z
Creation Date: 2002-04-24T12:35:11.00Z
Registrar Registration Expiration Date: 2021-04-24T12:35:10.00Z
Registrar: NAMECHEAP INC
Registrar IANA ID: 1068
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.6613102107
Reseller: NAMECHEAP INC

自 2019 年 10 月 23 日起,该域已在 Namecheap 注册。那么我们感兴趣的R国注册信息在哪?如果我们回顾历史 WHOIS 数据,我们可以看到,在 2009 年(我们可以访问的最古老的 WHOIS 数据)和 2019 年 10 月 23 日切换到 Namecheap 之间,该域注册到了R国圣彼得堡的地址:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Registrar Abuse Contact Phone: +7.8129140281
Domain Status: clientUpdateProhibited
Domain Status: clientTransferProhibited
Domain Status: clientDeleteProhibited
Registry Registrant ID:
Registrant Name: Whois privacy services provided by DomainProtect LLC
Registrant Organization: Whois privacy services, provided by DomainProtect LLC
Registrant Street: c/o Office-Mail processing center Sadovaya, 53
Registrant City: Saint Petersburg
Registrant State/Province: Saint Petersburg
Registrant Postal Code: 190068
Registrant Country: RU
Registrant Phone: +1.8662452838
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: [email protected]

我猜测,Yahoo! 新闻与其他调查者在得到这些信息后就停止调查并公布结果了,但这显然有些为时过早:

img

啧,这对“联系”一词的定义太过宽泛了,这就是在收集信息后直接得出结论而跳过了情报循环的分析部分时发生的情况。R国是一个国家,这与注册人有什么联系?他们什么时候控制了这个域?我们能知道他们用这个域名做了什么吗?他们还持有这个域名吗?在得出结论前,我们必须解决以上问题。慢而准确总好过快而出错。

那么,存在于WHOIS 数据中与R国人的联系到底是什么?在 WHOIS 记录中注册人的姓名与电子邮件被隐藏,街道地址仍然可见。通过查询地址:”c/o Office-Mail processing center Sadovaya, 53” ,我们可以看到它与其他域的数百条其他 WHOIS 记录相关联。

img

这意味着什么?幸运的是,在收集阶段保存的 Wayback Machine 记录会有所帮助。我们可以看到 Antifa.com 在被一个神秘的R国组织注册时的样子。别眨眼……

img

在由不知名的R国组织拥有的整个过程中,该域名只是被标注待出售。虽然我们没有早于2009年的WHOIS记录,但我们可以看到,甚至在2008年该域名仍是被标注待出售。事实上,直到2019年10月23日它才被出售给一个新的主人。

即使在所有权变更之后,在2020年4月14日之前,其内容也没有进行重大更改。我们可以在crt.sh看到证书历史

img

直到2020年4月14日,该域才部署SLL证书。非常有趣,因为这跟Antifa.com网站的推特账户创建的时间是相同的。

img

(值得注意的是,Antifa网站推特账户的个人资料中的URL也重定向到了itsgoingdown.org)

Antifa.com的YouTube频道也在不久之后被创建,即2020年4月18日。

img

果然,2020年4月14日之后的第一次 Wayback Machine 捕获反映了这一变化。 “待售”标志不见了,取而代之的是新内容:

img

注意,以前的R国注册商已经超过8个月没有与该网站有联系了。当8月12日,域名被重定向到乔·拜登的网站时,情况仍然如此:

img

根据我们在有限研究中发现的情况,我们能否确信R国、Antifa和拜登之间存在联系?我不确定。

情报传播

因为这只是一个简单的博客示例,不需要将结果汇报给除读者(也就是你,如果你坚持读到了这里,很不错。)之外的人。现在回顾一下我们最初提出的问题,看看我们所做的信息收集与分析能不能回答–Antifa.com 和它的俄罗斯注册商之间有关系吗?如果有的话是什么性质的?

本文进行了非常简短的练习,当然还有很多其他的研究途径可以探索。那么我们能得出什么结论呢? OSINT 的世界很少是非黑即白的,总会有一些不确定的领域。有一点不确定性并没有错,只要这反映在你的报告中:你必须基于研究得到结论,而不是基于结论进行研究。

img

根据这项研究,我们可以说,这个域名以前是由一个R国组织注册的,而且至少从2009年开始,甚至可能在那之前。我们还可以说,在R国注册者拥有该域名期间,证据表明该域名没有被使用,只是标注出售。没有证据表明,在他们持有域名期间,有任何内容被托管在该域名上,或被重定向到任何网站。该域名的注册在2019年10月发生了变化,在那之后没有与R国注册者的明确联系。该域名的当前所有者使用Namecheap作为注册商,但从收集到的信息来看,不能确定他们是谁。目前的所有者使用该域名的目的与之前与R国有联系的所有者明显不同。在该域名被配置为将流量转到乔-拜登的网站时,距离上次与任何R国实体的明确联系已经过去了近11个月。收集到的证据倾向于不支持将流量从Antifa.com转移到乔-拜登的网站与之前的R国注册者有关的说法。
因此,如果你在情报周期中偷工减料,直接从收集到传播,你很容易错过重要的细节,并做出耸人听闻–但缺乏支持–的假设,即从Antifa.com分流到乔-拜登的竞选网站是一个R国阴谋。走捷径和得出激动人心的结论当然很诱人,但这很少能成为准确的报道。

原文地址:https://nixintel.info/osint-tools/carbon-14-verifying-the-age-of-a-website/

文章原名:Carbon-14: Verifying The Age of A Website

作者: Nixintel

Carbon14(碳十四)是一款用于网站调查和核查的有力Python工具。它让调查员可以确定网页的创建时间以及该页面在首次上传后是否进行了修改。Carbon14会检查网页中图像所包含的数据,以判断它们何时上传与发布。这将有助于确定网页首次创建的可能时间段,或确定网站自创建之后调整或更改的频率。这对于需要进行大量验证工作的OSINT调查员极为有用。

Carbon14将检查图片发布时生成的Last-Modified HTTP参数。这意味着它能确定网页内容的首次创建时间。注意,它检测的是图片发布在网站上的时间,而不是图片实际拍摄的日期,这种检测并不依赖于EXIF数据。

开始使用

Carbon14可以运行在Windows,Mac与Linux操作系统上,并需要Python 2.7运行环境。如果你没有在Windows系统上安装Python2.7,可以参考相关指南。在Mac OS与Linux系统上,Python2.7已被预装。

使用命令行从Github下载或克隆Carbon14库

1
$ git clone https://github.com/Lazza/Carbon14

如果你不习惯使用命令行进行Github库的克隆,参考相关指南将存储库作为ZIP文件下载并手动解压。

一旦下载完成,将工作目录切换到新创建的Carbon14目录

1
$ cd Carbon14

现在安装额外的软件运行依赖。你可能需要在管理员(root)权限下安装一些软件插件,在这种情况下,在命令前添加sudo(Mac与Linux)。

1
$ python2.7 -m pip install -r requirements.txt

当依赖安装完成时,你可以通过以下命令来调出Carbon14的帮助菜单(这个菜单很短)。

1
$ python2.7 carbon14.py -h

在这里指定了 Python 2.7,因为我系统上的默认 Python 版本高于 2.7,并且无法正确运行 Carbon14。

使用如下命令检查网页的年龄:

1
$ python2.7 carbon14.py https://examplewebsite.com

可以选择将你的姓名添加到 Carbon14 使用 -a 生成的简短报告的标题中,如下所示:

1
$ python2.7 -a NixIntel carbon14.py https://examplewebsite.com

示例-检查页面的变更

我将以我最近写的文章作为示例,看看Carbon14能做些什么。发布日期显示它在2019年10月5日被发布,但据我所知,在最终版本发布之前,我曾上传了一些草稿并编辑了许多照片。Carbon14能检测到这些变化并指出我何时进行了这些操作吗?

检测博客文章的命令如下所示:

1
$ python2.7 carbon14.py https://nixintel.info/osint/digital-shadows-seeking-sector035-quiztime-26th-september-2019/

结果如下图所示。Carbon14 抓取了我插入在文章中的所有图片的URL与最初上传时的时间和日期。你能通过查看图片的发布日期来发现我何时进行了编辑吗?

img

根据这些信息,可以确定我是在伦敦时间2019年 10月5日大约19:34到21:32之间撰写这篇文章的。Carbon14按时间顺序显示结果,这意味着可以计算出我何时对文章进行了编辑并添加了新的图片。

img

虽然博客显示的发布时间为10月5日,但Carbon14发现了我在2019年10月6日09:51对文章进行了编辑,添加了更多的图片。直接查看网页并不会发现这种情况,但我的所作所为通过图像发布的时间戳暴漏了。这种技术适用于各种网页,显然你可以使用它来确定作者何时添加或替换文章图片,以及该文章最有可能的首次发布时间。网站图书馆通常也不会检测这类更改,因此这种方法将有效且精确的了解在过去的一段时间内网站所发生的变化。

Carbon14与推特

Carbon14对推特有用吗?推特并不允许已发布的内容被修改,所以Carbon14并不能显示任何更改发生的时间。然而,基于其检测网页的方式,它仍能返回一些有用的图片信息。就在我写这篇文章的时候,我注意到Marko Bereth有一篇新的 Quiztime帖子,所以我打算测试一下。

他发布在推特上的原始图片URL为:

https://twitter.com/mahrko/status/1185220029224280065/photo/1

使用Carbon14对其进行检测:

1
$ python2.7 carbon14.py https://twitter.com/mahrko/status/1185220029224280065/photo/1

它返回了几个有趣的结果:

img

这一结果不仅显示了在推文中图像的URL,还显示了图像的增强更高分辨率版本的URL(由large后缀表示)。

它还返回了Marco个人资料图片的三个URL,最大尺寸为400×400像素。

我们可以发现,Marco在2019年9月22日14:12:33 UTC发布了他最新的个人资料图片。显示,通过这种方式获取推特个人资料图片的发布时间将有助于了解该账户是否处于活跃状态或账户创建后有无进行个人资料图片的更改。

Instagram

我也注意到,Carbon14可以自动地从Instagram获取高分辨率图像并精确的展示图像的发布时间。比如巴西足球传奇人物 Ronaldo的最新发布:

img

使用Carbon14检查帖子的URL将返回一个简短结果:

img

这将告诉我们图片被发布Instagram在上的精确时间(13年10月19日16:24:39 UTC),这可比Instagram显示在页面上的5天前不知道高到哪里去了。它还提供了比浏览器中显示的图像更高分辨率版本的URL (从技术上讲,它是相同的图像,只是呈现方式不同)。你也可以通过开发者控制台进行完整图像URL的挖掘来获取这些信息,但Carbon14更加的方便。

Happy Carbon dating!

考古快乐!

译者注:

该篇为《How To Find Timestamps For Verification》所提到的进行图片时间戳提取的文章。

原文地址:https://nixintel.info/osint/how-to-find-timestamps-for-verification/

文章原名:How To Find Timestamps For Verification

作者: Nixintel

对于网络侦探(internet investigator)来说,能准确证明数据是什么时候发布在互联网上属于一种核心技能。如果你想能证实某个视频何时第一次上传,某个账户何时创建,或者是某个网站何时进行了编辑更改,那你就需要尽可能的精确确定时间。

这似乎很简单,因为当一篇文章被发布时或一张照片被上传时,发布时间和日期将被展示在网站页面上,但是这种可见的时间信息通常达不到详细分析或验证工作所需的精度。幸好网页源代码中通常隐藏着额外的时间戳数据,它们并不直接显示在浏览器中。通过获取这些隐藏的信息来创建非常精确的时间表,准确的证明或反驳某些事情发生的时间,这将显著的提升调查的准确度。

每个平台都采取独有的方式进行时间信息的存储。这意味着要经过一些试错才能发现不同平台的时间存储方式,但大体上有两种方法进行这些数据的获取。一种是查找嵌入在网页源代码中的信息,另一种是查找网站数据库向浏览器发送的JSON内容中的信息。第一种方式比第二种稍微简单一些,所以让我们从一个查找youtube直播的详细时间戳为例进行说明。

YouTube 直播时间信息

YouTube可以很好的展示浏览器中展示的少量时间信息与隐藏在网页源代码中的详细时间信息的差异。

这有一场我们在上周也就是2022年1月27日的直播:OSINT Curious livestream video 。视频下方展示了首次直播的状态信息。

但我们并不能知道直播是在那天的什么时候开始的。YouTube只为我们提供了日期,没有准确的时间,所以我们需要通过挖掘页面源代码来寻找更多明确的信息。

想要查看页面源代码,你需要右键单击浏览器,然后单击“查看源代码”或“查看页面源代码”。你会看到这样的东西:

它们是你从Youtube获取到的原始HTML和javascript,浏览器会将它们翻译成你所看到的页面。你的浏览器并不是将获取到的所有数据呈现在页面上,这些未使用的数据我们依旧可以访问。通过快捷键Ctrl+F 调出搜索栏,搜索类似“uploaded ,time, date, published, created” 等关键字通常可以找到额外的时间相关信息。

果然,通过搜索”published“我们发现了一些有用的信息。

我对代码进行了美化以方便阅读:

1
2
3
4
5
6
7
8
<meta itemprop="interactionCount" content="441">
<meta itemprop="datePublished" content="2022-01-28">
<meta itemprop="uploadDate" content="2022-01-28">
<meta itemprop="genre" content="Entertainment">
<span itemprop="publication" itemscope itemtype="http://schema.org/BroadcastEvent"><meta itemprop="isLiveBroadcast" content="True">
<meta itemprop="startDate" content="2022-01-27T19:59:36+00:00">
<meta itemprop="endDate" content="2022-01-27T20:35:05+00:00">
</span></div>

标签meta itemprop中包含了比之前我们看到的更加精确的时间信息。startDate标签说明了直播在1月27日19:59:36(UTC时间)开始,endDate标签说明了直播在当天20:35:05结束。注意,标签uploadDate说明了并不是在直播结束立刻进行了上传,这可能是由于一些延迟造成的。但仍然能从给出的开始与结束时间精确的确定直播时段。

如果你想知道这种技巧在现实世界调查中的使用,你可以看看Brecht Castel是如何通过直播的时间信息去确定近期一次street demonstration的时间线。

推特账户创建时间信息

挖掘时间戳数据的第二种技巧涉及到对网站数据库所传递的信息进行捕获。当你通过你的浏览器访问网站时,你将向网站服务器发送请求以获取存储在站点数据库内的数据。服务器将响应你的请求,返回数据库中匹配的信息。通常情况下,数据库以JSON格式传递数据,浏览器将响应的JSON数据渲染成你所见的的网页。

通过使用浏览器的开发者模式,就能看到所有这些请求和响应的内容。这通常包含了很多在页面源代码中并不总是可用的有趣额外信息。让我们看看这些内容在推特账户创建时间戳上是怎样的。

The OSINT Curious Project的推特账户是什么时候创建的? 很明显答案是2018年12月,就在个人资料页上。对于一般推特用户来说,这就足够了。但如果你正在调查一个魔怔人账户,或者是一系列由外国政府所设立用于传播虚假信息的账户,这样的信息并不精确。

当你只有按年、月记的账户创建时间时,你很难精确的说明一个账户何时创建,或者证明一系列可疑的账户恰好在同一时间内创建。

通过检索网站的请求与响应信息,我们可以找到许多关于账户何时创建的特殊信息。首先按F12进入浏览器的开发者模式。在这里我使用了Firefox,不过在Chrome上的操作流程是一样的。

1
2
1. 按下**Ctrl + R**重载页面
2. 点击**Network** 选项卡,你就能看到:

这里你可以看到你的浏览器与推特服务器之间所有的请求与响应。这里有非常多的信息,人工筛选比较困难。幸好我们可以像之前在处理Youtube页面源代码时一样,通过像time, posted, published, created这类关键字进行过滤。点击放大镜图标(在“initiator”列的正上方)将调出搜索栏,输入关键字进行搜索。

并不是所有信息都是相关的,但在”twitter.com”下找到的条目都指向来自推特的JSON数据,这其中包含的有关推特账户个人资料的信息可比在网页中可见的信息多得多。注意,因为推特在同一页面上展示了很多其他人的个人资料(“你可能喜欢…”),你将获得不止一个账户的信息。

点击其中一条结果将打开如下所示的用于显示响应的面板。取消”raw”选项来让原始数据以可读格式显示,就像下图所示:

img

created_at 字段显示了账户创建时的完整时间戳。我们之前仅知道该账户在2018年12月创建,但现在能准确的知道精确到秒的创建时间,这对调查来说非常有用。

Instagram 帖子和评论的时间信息

一旦你熟悉了如何在网页源代码或服务器响应中进行检索,那么想获取其他类型的数据也很容易。Instagram是出了名的难搞,但还是能找到一些有用的数据片段。调查员在Instagram上遇到的第一个挑战就是随着时间而变得模糊的时间戳信息。最近的帖子时间显示的很具体(例如“9小时前”),但随着时间的推移,帖子发布的时间将仅显示日期而没有具体时间,评论的时间戳信息仅以周为单位。对于Instagram用户来说当然不成问题,但对于想要精确的复现事件何时发生的调查员来说,问题很大。

所幸,Instagram的服务器响应中也隐藏了一些有趣的信息供我们所用。让我们看看能从Rock的账户中找出什么吧。

img

在我写这篇文章时(2022年2月6日 星期日),Rock最近发布的文章展示了他在健身房锻炼。我可以看到它是在9小时前发布的。

img

现在看起来没什么问题,但如果我想对数月甚至数年前发布的内容分析时会发生什么?这篇2015年发布的内容展示了信息是如何随着时间推移变得模糊的。虽然它仍有时间戳(2015年8月19日),但只有日期没有具体时间。评论的信息更加模糊,它们甚至只显示了在多少周之前发布的,这种信息的用处不大,没法获得具体的发布时间。

不过一定会有一些有用的数据。除非它有额外的时间戳信息可供参考,不然Instagram 怎么能告诉我评论是在 216 周前发表的。如果我们能找到这些额外信息,我们应该能够获取到更准确的时间戳数据。

为了查找特定 Instagram 帖子的时间戳信息,要像 上面的Twitter 示例一样在开发人员模式下打开页面。通过搜索PostPage条目将找到一些有用的JSON数据,包含了有关发布内容的额外信息,其中还有时间戳数据。可能会找到很多与PostPage相匹配的信息,你所需要的信息将列在正在研究的贴子的主URL下。当URL是https://www.instagram.com/p/6kvP6Hoh5q/ 时,下图就是相关信息所在的位置。根据检索的结果可知,“PostPage”信息可以在响应内容的第 21、28、266、269 和 276 行找到

img

在第266行可以找到:

img

taken_at条目存储了UNIX格式的时间戳。使用UNIX timestamp convertor我们可知1440006804即为2015年8月19日星期三 17:53:44。这可比单纯的日期精确多了。

你可能已经注意到了还有一个被叫做device_timestamp的UNIX时间戳。在本例中,它记录的时间是同一天的17:37:30,大约比taken_at字段存储的时间早了16分钟,这是怎么回事?在对此的研究中,我注意到device_timestamp字段记录的时间总是在taken_at字段之前。目前对此我最好的解释是device_timestamp基于图像或视频在设备上实际创建的时间,而taken_at字段反映了实际的上传时间。我需要做一些额外的研究来验证我的假设,但目前来说这是个合理的推断。

img

获取评论时间戳信息的流程也是相同的。Instagram 显示 mrdannybee 对 Rock 帖子的评论是在 216 周前发布的,但在回复中搜索“mrdannybee”会找到与他评论相关的 JSON数据,其中包含更具体的时间戳:

img

果然 1513315605 指的是 2017 年 12 月 15 日星期五 05:26:45 UTC,也就是 在216 周前。可以使用DateTimeGo 进行核查,它将为你计算出 x 周或数月前的实际日期。

本文只是对从网站内容中检索更详细的信息的几种技术的简要概述,但一旦你学会了如何通过这种方式寻找额外的数据,它就为寻找有用的数据提供了更多的机会。

如果你觉得这篇指南很有用,那你还可能很喜欢我之前关于从网站上发布的图片中提取时间戳(extracting timestamps from images posted on websites)的文章。