Ragnarok ,用AES加密的聊天器

加密聊天器+加密万能文件传输器

服务端

Ragnarok_server\server.py

说明

服务端只做用户合法性验证和双向密文互换，可以放在国内小鸡上。

特别做个服务端出来的原因是考虑到很多宽带都是NAT的内网。所以通过公网小鸡桥接。

有一根长长的网线，一直伸到你家里，你说什么做什么他们都知道的一清二楚。

于是我决定写这玩意，名字随便起的。再也不用担心被视奸了

设置

在config里改端口，对linux了解不太多，所以怎么在服务器上运行还请dalao写个shell加进来（写了个实验版后台shell）

聊天模块

Ragnarok_client\Whisper.py

安装

我在win10 64bit python3.6.4环境下写的。换个别的环境不保证能用。

设置

UserID：你自己的代号，比如9527

TargetID：你想和谁说悄悄话

Local_IP：不用管

Local_Port：用哪个端口去连服务器

Target_IP：其实这个应该是serverIP，小鸡的地址

Target_Port：服务器监听的端口

Blocksize: 发送文件时对文件进行分块(聊天不用管)

使用

只要敲文字进去就能显示在对方的屏幕上了。

加密特性

客户端每次启动都会随机生成一组RSA pair并写入文件。

客户端1输入“如果我是DJ”

随后生成一个AESkey

用AES_EAX模式加密“如果我是DJ”，得到密文和随机数

然后用得到的RSA公钥加密这个AESkey，得到cipherkey

然后把cipherkey和随机数和密文合并到一起发送出去。

接到数据的客户端2用自己的RSA私钥解出AESkey，进而解出明文

除了RSA的秘钥对需要保存到本地进行调用，其他所有信息的加密解密都在内存中完成，不留任何log。

我就不吹有多保密了（量子计算机出来之前，谁都看不到你们说了什么悄悄话）但是有一些人为因素问题后面说。

发送文件模块

Ragnarok_client\File_Tx.py

设置

UserID：你自己的代号，比如9527

TargetID：你想和谁说悄悄话

Local_IP：不用管

Local_Port：用哪个端口去连服务器

Target_IP：其实这个应该是serverIP，小鸡的地址

Target_Port：服务器监听的端口

Blocksize: 发送文件时对文件进行分块加密的大小

加密特性

强制二进制逐block读取文件，加密后的字节串因为TCP协议的限制被分割发包。目标端统计blocksize再进行粘包解码，解出来的字节串直接写入文件

和聊天的时候不太一样，因为考虑到文件产生的大量数据流，AES秘钥仅做一次交换，简化了双线程变成单向发包。

使用

把要传的文件放到根目录下。（复杂地址懒的搞了）两个客户端在建立连接后，一方输入文件名，另一方留空直接回车，开始一系列响应直到数据传输完成。

python3还是不错的，天灭python2，支持的文件大小可以论G算。如果非要传一些小电影也请随意。支持所有格式，只要是个文件，就能传

本机测试的时候用8192的blocksize可以到8Mb/s的加密速度，更大的blocksize没试过了，大概网速跟不上解释器的速度。

测试的RAR大小334Mb

Blocksize: 2048 4096 8192

用时： 165s 86s 44s

人为因素

中间人攻击是个目前没有什么解决办法的事情，所以才有了CA去保证RSA公钥的可靠。一个程序中，最薄弱的环节是人。最迫不得已的办法，显示接收到的秘钥以便在旁路（线下py交易，企鹅vx）上进行公钥可靠性的确认。不过不干坏事也不会招致高科技的中间人攻击……技术无罪。

另外考虑到社工的问题，ID最好不要起自己喜欢的一些字段。因为和服务器交换ID的时候是明文，反正是个隐患。

一点小小的心愿

历时一个月从什么都不懂，到开始盲人摸python，到撸出来这个程序。今天算是瞎猫撞上死耗子撸出来了，差点弃坑。有的时候比较喜欢大开脑洞，比如2100年的一个晚上，K摘下了手表眼睛手机，带着一张写满英文数字的纸条出门了。在一个小巷和一个老哥擦肩而过的时候，仿佛手里的纸条有一点点的不一样。回到家，拿出爷爷的信仰阿苏斯笔记本，打开了Ragnarok，进入了这个cyberpunk时代最后的世外桃源。

如果有大佬用C#重构一个GUI的exe。安装和使用都会更方便。不过命令行更有黑客的感觉，做人不装逼，和咸鱼有什么区别。

做了个文件传输以后，我实在是想不出来还有什么拓展性，如果各位大佬有什么好的建议请fork或者留言。

from https://github.com/haoht/Ragnarok

 

招聘启事歧视非公民，16家私营雇主遭到美国司法部的民事处罚

 

美国司法部星期一(6月27日)宣布签署了和解协议，要求16家私营雇主支付总计832,994美元的民事罚款，以解决有关这些公司在招聘中歧视非美国公民的指称。

司法部说，16家公司中的每一家都在佐治亚理工学院 (Georgia Institute of Technology)的在线招聘平台上至少发布过一则只招美国公民的招聘启事，其中一个雇主发布的这类歧视性的招聘信息多达74条，有几个雇主还在其他大学的招聘平台上发布过这类信息。

司法部的声明说，司法部认定，这些招聘启事阻止了有资格的学生去申请这些工作，而且多数情况是，由于公民身份限制，很多学生不能申请甚至都不能与公司招聘人员见面。

司法部民权司的副助理部长克莉丝汀·克拉克 (Kristen Clarke)在声明中说：“基于公民或移民身份的非法招聘歧视在美国高等教育中是一个普遍问题。民权司致力于落实法律，确保学生和工作申请者——包括合法的永久居民、美国国民、政治避难者和难民——免遭非法歧视。我们将追究以歧视的方式利用校园招聘平台的雇主的责任，并且努力为受害者提供救济。”

在一名美国永久居民向司法部民权司移民和雇员权利处投诉，指控一家公司在佐治亚理工招聘平台上发布的招聘信息只招美国公民之后，司法部展开了调查，随后发现了这个平台和其他大学招聘平台上的其他歧视性的招聘信息。

美国《移民和国籍法》(INA)通常禁止雇主和招聘人员基于公民或移民身份限制岗位的招聘，除非是法律法规、行政令或政府合同所要求的。司法部提到，《移民和国籍法》保护没有美国公民身份的美国国民(美属萨摩亚人)、难民、避难者和永久居民，让他们在应聘过程中不得因为自己不是公民而遭受歧视。

司法部说，不管高校在运营那些招聘平台时是否有违法律，雇主如果在那些平台上发布的招聘启事违反《移民和国籍法》，他们也要负法律责任。

与司法部达成和解的私营雇主包括毕马威(KPMG)、美国运通(American Express)等16家公司，他们支付的和解金为4000多美元到30多万美元不等。

司法部说，除了罚款外，这些公司负责招聘的员工还必须要接受相关的培训，并且确保他们的其它招聘政策和做法符合《移民和国籍法》的非歧视条款。

解放军为求美国芯片无孔不入，美国如何见招拆招？

 

尽管特朗普和拜登政府努力限制中国军方获得源自美国的尖端科技，一项最新研究指出，中国解放军仍在千方百计地通过中间商购买由美国设计的人工智能芯片。专家呼吁，美国必须针对中国更新出口管制战略，采取严厉措施保护人工智能芯片与核心科技，“防止美国技术落入坏人之手”。

美国乔治城大学的安全和新兴技术中心（CSET）本周三发布的最新研究发现，中国军方通过中间商，包括美国官方授权的经销商和空壳公司来购买美国原产芯片设备，而不是直接从美国半导体供应商处购买，从而绕过美国出口管制的限制。

报告作者之一、美国明德学院“蒙特雷三方对话倡议”研究员（Monterey Trialogue Initiative）徐森凯（Karson Elmgren）告诉美国之音, 美国设计的芯片可能在中国军事系统中得到广泛应用，但是目前没有切实的数据支持。

“例如，使用美国英伟达的GPU，可能会为一些人工智能AI研究进行更有经验的实验，更快地开发新功能。但更取决于解放军是否具备足够的硬件成为一种创新的现代军事力量，处于军事能力的最前沿并不断前进。一般来说，顶级芯片将使这种前景更为可能。”

徐森凯表示，人工智能在军事领域有许多潜在的非常有影响力的应用，例如自主无人机、情报分析， “但现在很难说明（美国的芯片）会如何增强解放军某种特定类型的军事能力。”

尽管中国政府已在人工智能领域投入数百亿美元，美国公司仍主导着人工智能芯片的设计市场，韩国的三星（Samsung）和台湾的台积电 (TSMC)仍然是全球半导体制造业的巨头。

根据安全和新兴技术中心去年十月发布的研究，中国军方可能继续投资人工智能、扩大自主水面和水下装置，以破坏美军信息系统，削弱美军水下作战优势，发展致命自主武器系统等等。

中国军方如何见缝插针获取美国芯片？

该机构获得的中国军方采购招标文件涵盖了2020年3月30日至12月1日期间发布的66321条记录，其中包括21088份授权相关公司向解放军提供设备的合同。

这份研究报告通过分析合同数据确定了97种人工智能芯片，几乎全部都是由美国公司设计，包括英伟达（Nvidia）、赛灵思（Xilinx）、英特尔（Intel）和美高森美（Microsemi）。 买家包括解放军战略支援部队（Strategic Support Force）、海军、中国军事科学院(Academy of Military Sciences)、中国航天科技集团有限公司（CASC）、中航光电科技股份有限公司（AVIC）等等。

相比之下，研究人员没有找到任何解放军或国有国防企业订购由中国公司设计的高端人工智能芯片的公开记录，如海思（华为）、中科曙光（Sugon）、海光（Hygon）或飞腾(Phytium)。

值得注意的是，中国解放军的一些芯片供应商是美国官方授权经销商(officially licensed distributors of U.S. goods)，中国政府和军方也在利用幌子公司（front companies）从美国公司购买芯片。

这份研究点名了七家将美国设计的芯片转手卖给解放军的中间供应商（intermediary suppliers），没有一家被列入美国商务部的实体清单（Entity List）或军事最终用户清单（Military End User List）之中。

报告分析道，“美国半导体公司有时可能不知道其产品最终会为中国军方所使用。美国目前的出口管制体系之下，出售给解放军单位或国防公司的这些芯片，很可能并不需要获得美国政府或任何其他的出口许可证(a license for export)。”

此外，解放军订购的芯片大多由美国公司设计并在台湾和韩国制造，而美国的“军事最终用途”规则不适用于在外国制造和运输的半导体，即使它们是在美国设计的；采购文件中最常见的商品是图形处理器（GPU）芯片 ，该芯片也不属于美国商务部规定的需要出口许可证的管制商品（controlled commodity）。

防不胜防，美国是否该向中国全面禁运芯片？

由于目前基于最终用户的出口管制（end-user export controls）政策不足以限制中国军方从美国获得人工智能芯片或技术，上述报告评估了两种潜在替代方案：“打地鼠”(whack-a-mole)即有针对性地打击解放军的中间供应商（targeted crackdown)；“扣动扳机”（pull the trigger）对中国实行人工智能芯片的彻底禁运（outright embargo），但两种措施都存在一定的操作困难和经济、政治成本。

首先，鉴于追踪芯片的难度、潜在中介机构的多样性以及中国军民融合政策造成的模糊界限，“打地鼠”策略将面临较高的资源和后勤限制。

“这些芯片没有直接出售给解放军或国防公司，而是出售给这些经销商，经销商自己不是军事终端用户，不需要出口许可证。”徐森凯解释说，“很明显，我们可以去确认并专门拦截那些为解放军供货的公司。但可能很难识别所有这些公司，数量上可能有很多。而且他们不难建立一些新渠道，这些渠道更像是黑市(black market)，例如中国学术机构购买许多相同类型的科学计算芯片。他们可能购买更多，然后在类似的情况下出售给解放军。”

另一方面，该报告指出，突然对AI芯片出口实施禁运的极端政策可能将疏远韩国、台湾等地区合作伙伴，并危及美国半导体行业的长期生存能力。中国市场占全球AI芯片消费量的25%，2021年向中国出售的AI芯片价值估计在25亿至50亿美元之间。美国证券交易委员会的年度文件表明，全面禁运将使美国芯片设计公司每年损失数十亿美元。

徐森凯补充道，目前尚不清楚切断芯片出口是否会影响中国的军事能力。“如果美国今天切断对中国的所有半导体出口，中国明天决定入侵台湾，那么解放军在试图维修和更换设备、升级时得不到新的半导体，可能会成为问题。但现在就切断的话，可能不会有立竿见影的效果，时机的选择非常微妙。”

报告最终的建议是，美国应扩大对开源情报的收集，更好地了解中国的人工智能国防工业基础；并根据高端芯片特性采取一种新的出口管制措施，基于出口到中国的芯片的物理和技术特征，而不是基于最终用户或用途（end-users or end-uses）。

美国夏威夷东西方中心(East-West Center)关注人工智能竞争的资深研究员迪特·恩斯特（Dieter Ernst）对美国之音表示，对中国实行芯片出口禁运，将会附带损害美国及其伙伴国家的半导体工业和学术研究、侵蚀全球半导体创新体系，而且将在执行层面面临巨大挑战。

“随着供应链复杂性的增加，对中国实施有效的供应链监控变得更加困难和昂贵。在国内，美国政府将需要创建新的流程来提高监管流程的透明度、加强机构间的协调并解决执法漏洞、招聘问题和预算要求。此外，由于半导体供应链受到多重瓶颈的限制，导致芯片严重短缺，现在是对地缘政治竞争对手实施区别性供应链控制的最糟时机。”

但是，新美国安全中心（CNAS）科技与国家安全项目专注人工智能和国防科技创新的副研究员亚历珊卓·西摩（Alexandra Seymour)对美国之音强调，“美国必须确保采取最强有力的措施来限制解放军实体的获取权限，特别是对像人工智能芯片这样重要和需求旺盛的技术，这些技术可以被中国用于专制目的。”

她说，“美国最强大的战略优势之一是其创新能力。当像中国这样的竞争对手可以使用美国设计的技术时，这种优势就会被削弱，因为这使中国能够加快本国的开发和采用，缩小能力差距。所以，美国国家安全的一个关键目标必须是技术保护（technology protection）。”

西摩指出，具体措施包括，改善美国及其盟国和合作伙伴之间在商业技术出口方面的沟通和协调，以确保他们能够识别并且更密切地监控潜在的“军民两用”芯片；美国公司还必须认识到与中国开展业务可能会危及国家安全，从自身做起保护关键和新兴技术，早在研发阶段就要改善公私营机构之间的伙伴关系和信息共享，防止美国技术落入坏人之手。

ixy-languages

 A high-speed network driver written in C, Rust, C++, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python.

Overview

Ixy is an educational user space network driver for the Intel ixgbe family of 10 Gbit/s NICs (82599ES aka X520, X540, X550, X552, ...). Its goal is to show that writing a super-fast network driver can be surprisingly simple, check out the full description in the main repository of the C implementation to learn about the basics of user space drivers. Ixy was originally written in C as lowest common denominator of system programming languages, but it is possible to write user space drivers in any programming language.

Check out our research paper "The Case for Writing Network Drivers in High-Level Languages" [BibTeX] or watch the recording of our talk at 35C3 to learn more.

Yes, these drivers are really a full implementation of an actual PCIe driver in these languages; they handle everything from setting up DMA memory to receiving and transmitting packets in a high-level language. You don't need to write any kernel code to build drivers! Some languages require a few lines of C stubs for features not offered by the language; usually related to getting the memory address of buffers or calling mmap in the right way. But all the core logic is in high-level languages; the implementations are about 1000 lines of code each.

Language	Code	Status	Full evaluation
C	ixy.c*	Finished	Paper
Rust	ixy.rs*	Finished	Thesis, Rust vs. C performance comparison
C++	ixy.cpp	Finished	(WIP)
Go	ixy.go	Finished	Thesis
C#	ixy.cs	Finished	Thesis
Java	ixy.java	Finished	(WIP), GC comparison
OCaml	ixy.ml	Finished	Documentation
Haskell	ixy.hs	Finished	Thesis
Swift	ixy.swift	Finished	Documentation
Javascript	ixy.js	Finished	(WIP)
Python	ixy.py*	Finished	(WIP)

*) also features a VirtIO driver for easy testing in VMs with Vagrant

This repository here is only a short summary of the project, check out the repositories and full evaluations linked above for all the gory details.

Performance

Our benchmarking script for the MoonGen packet generator loads the forwarder example application with full bidirectional load at 20 Gbit/s with 64 byte packets (29.76 Mpps). The forwarder then increments one byte in the packet to ensure that the packet is loaded all the way into the L1 cache. Correct functionality of the forwarder is also tested by the script by validating sequence numbers.

A main driver of performance for network drivers is sending/receiving packets in batches from/to the NIC. Ixy can already achieve a high performance with relatively low batch sizes of 32-64 because it is a full user space driver. Other user space packet processing frameworks like netmap that rely on a kernel driver need larger batch sizes of 512 and above to amortize the larger overhead of communicating with the driver in the kernel. Running this on a single core of a Xeon E3-1230 v2 CPU yields these throughput results in million packets per second (Mpps) when varying the batch size.

Notes on multi-core: Some languages implement multi-threading for ixy, but some can't or are limited by the language's design (e.g., the GIL in Python and OCaml). However, this isn't a real problem because multi-threading within one process isn't really necessary. Network cards can split the traffic at the hardware level (via a feature called RSS), the traffic can then be distributed to independent different processes. For example, Snabb works like this and many DPDK applications use multiple threads that do not communicate (shared-nothing architecture).

Latency

Average and median latency is the same regardless of the programming language as latency is dominated by buffering times, the evaluation script can sample the latency of up to 1000 packets per second with hardware timestamping (precision: 12.8 nanoseconds). This yields somewhat interesting results depending on queue sizes and NUMA configuration, see the ixy paper for an evaluation.

Latency spikes induced by languages featuring a garbage collector might not be caught by the test setup above. We have a second test setup to catch this: we also capture all packets before and after the device under test with fiber optic taps and use MoonSniff to acquire hardware timestamps (25.6 nanosecond precision) for all packets.

Running the forwarder on an Intel Xeon E5-2620 v3 at 2.4 GHz yields the following results for the forwarding latency.

from  https://github.com/ixy-languages/ixy-languages

 

 

CloudFlair

Find origin servers of websites behind CloudFlare by using Internet-wide scan data from Censys. 

https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/

CloudFlair is a tool to find origin servers of websites protected by CloudFlare who are publicly exposed and don't restrict network access to the CloudFlare IP ranges as they should.

The tool uses Internet-wide scan data from Censys to find exposed IPv4 hosts presenting an SSL certificate associated with the target's domain name. API keys are required and can be retrieved from your Censys account.

For more detail about this common misconfiguration and how CloudFlair works, refer to the companion blog post at https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/.

Here's what CloudFlair looks like in action.

$ python cloudflair.py myvulnerable.site

[*] 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)

(The IP addresses in this example have been obfuscated and replaced by randomly generated IPs)

Setup

1. Register an account (free) on https://search.censys.io/register
2. Browse to https://search.censys.io/account/api, and set two environment variables with your API ID and API secret

$ export CENSYS_API_ID=...
$ export CENSYS_API_SECRET=...

3. Clone the repository

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

4. Install the dependencies

$ cd cloudflair
$ pip install -r requirements.txt

5. Run CloudFlair (see Usage below for more detail)

$ python cloudflair.py myvulnerable.site

Usage

$ python cloudflair.py --help

usage: cloudflair.py [-h] [-o OUTPUT_FILE] [--censys-api-id CENSYS_API_ID]
                     [--censys-api-secret CENSYS_API_SECRET]
                     domain

positional arguments:
  domain                The domain to scan

optional arguments:
  -h, --help            show this help message and exit
  -o OUTPUT_FILE, --output OUTPUT_FILE
                        A file to output likely origin servers to (default:
                        None)
  --censys-api-id CENSYS_API_ID
                        Censys API ID. Can also be defined using the
                        CENSYS_API_ID environment variable (default: None)
  --censys-api-secret CENSYS_API_SECRET
                        Censys API secret. Can also be defined using the
                        CENSYS_API_SECRET environment variable (default: None)

from https://github.com/christophetd/CloudFlair 

 

rssbot

Lightweight Telegram RSS notification bot. 用于消息通知的轻量级 Telegram RSS 机器人.

t.me/rustrssbot

 

Other Languages: English

Telegram RSS 机器人 @RustRssBot

支持:

• RSS 0.9
• RSS 0.91
• RSS 0.92
• RSS 0.93
• RSS 0.94
• RSS 1.0
• RSS 2.0
• Atom 0.3
• Atom 1.0
• JSON Feed 1

使用

/rss       - 显示当前订阅的 RSS 列表
/sub       - 订阅一个 RSS: /sub http://example.com/feed.xml
/unsub     - 退订一个 RSS: /unsub http://example.com/feed.xml
/export    - 导出为 OPML

下载

可直接从 Releases 下载预编译的程序（带 zh 的为中文版）, Linux 版本为 musl 静态链接, 无需其他依赖

编译

请先尝试从上面下载, 如不可行或者有其他需求再手动编译

先安装 Rust Nightly 以及 Cargo (推荐使用 rustup), 然后:

cargo build --release

编译好的文件位于: ./target/release/rssbot

运行

USAGE:
    rssbot [FLAGS] [OPTIONS] <token>

FLAGS:
    -h, --help          Prints help information
        --insecure      DANGER: Insecure mode, accept invalid TLS certificates
        --restricted    Make bot commands only accessible for group admins
    -V, --version       Prints version information

OPTIONS:
        --admin <user id>...        Private mode, only specified user can use this bot. This argument can be passed
                                    multiple times to allow multiple admins
    -d, --database <path>           Path to database [default: ./rssbot.json]
        --max-feed-size <bytes>     Maximum feed size, 0 is unlimited [default: 2097152]
        --max-interval <seconds>    Maximum fetch interval [default: 43200]
        --min-interval <seconds>    Minimum fetch interval [default: 300]

ARGS:
    <token>    Telegram bot token

NOTE: You can get <user id> using bots like @userinfobot @getidsbot

<token> 请参照 这里 申请

环境变量

• HTTP_PROXY: 用于 HTTP 的代理
• HTTPS_PROXY: 用于 HTTPS 的代理
• RSSBOT_DONT_PROXY_FEEDS: 设为 1 使所有订阅的 RSS 不通过代理（仅代理 Telegram）
• NO_PROXY: 暂不支持，等待 reqwest#877

从旧的 RSSBot 迁移

对于 原先 Clojure 版本的 Bot, 可以使用以下脚本转换数据库

#!/bin/bash

DATABASE=$1
TARGET=$2

DATA=$(echo "SELECT url, title FROM rss;" | sqlite3 $DATABASE)
IFS=$'\n'

echo -e "[\c" > $TARGET
for line in ${DATA[@]}
do
    IFS='|'
    r=($line)
    link=${r[0]}
    title=${r[1]}

    echo -e "{\"link\":\"$link\"," \
            "\"title\":\"$title\"," \
            "\"error_count\":0," \
            "\"hash_list\":[]," \
            "\"subscribers\":[\c" >> $TARGET

    subscribers=$(echo "SELECT subscriber FROM subscribers WHERE rss='$link';" | sqlite3 $DATABASE)
    IFS=$'\n'
    for subscriber in ${subscribers[@]}
    do
        echo -e "$subscriber,\c" >> $TARGET
    done

    echo -e "]},\c" >> $TARGET
done
echo "]" >> $TARGET
sed -i "s/,]/]/g" $TARGET

参数 1 为旧数据库地址, 2 为结果输出地址

需要注意的是已推送的 RSS 记录不会保留, 如果直接使用转换后的数据库, 会重复推送旧的 RSS.

from https://github.com/iovxw/rssbot

 

Stupid-Chat

 A simple P2P instant messaging desktop application relying on stun protocol and UDP. 利用 STUN 协议和 UDP 实现的简单 P2P 聊天客户端。

利用 STUN 协议和 UDP 实现的简单 P2P 聊天客户端。

Download | 下载

You can click the link below to download the program:

你可以点击下面的链接，下载来玩一玩：

DOWNLOAD

Introduction | 介绍

The program works fine between users behind less strict NAT types since in those cases UDP hole-punching is very efficient. But when symmetric NAT and port restricted NAT are both involved, things get a lot trickier.

当聊天双方的 NAT 类型不严格时，UDP 打洞十分有效，因此程序往往运行得十分顺利。但当端口限制型 NAT 和对称型 NAT 出现时，事情就麻烦了。

To achieve NAT traversal in those obnoxious situations a user needs to predict or guess the public port number of the other who is behind symmetric NAT and in the world of computer science by guess we usually mean brutal force. The program would simply scan the port numbers close to the one the STUN server returns to the other user.

当聊天中的一方处在对称型 NAT 后时，另一方需要去预测或者猜测其端口号。而所谓猜测，说白了就是暴力破解。程序在猜测端口时，会在对方通过 STUN 服务器获取的公网端口的附近扫描。

For example, when port number 8000 is shown on the other user's initialization interface and we input that port number into our program, it automatically sends UDP packets to ports like 8000, 8001, 7999, 8002, 7998 until it receives UDP packets from some certain port and mark it as the available port.

譬如说，当对方的初始化界面显示 NAT 分配的公网端口为 8000 时，我方则会尝试往 8000、8001、7999、8002、7998 这些端口发送心跳报文。而当我方收到对方的心跳报文时，就把这个报文的源端口标记为对方实际可用的端口。

The maximum number of ports to be scanned is set to 4000. It works when one user is behind port restricted NAT and the other one is behind symmetric NAT but I am not sure if it does when both users are behind symmetric NAT.

程序最多会猜测 4000 个端口，当双方有一方在端口限制型 NAT 后而另一方在对称型 NAT 后时，这种暴力猜测的方法一般是能成功的。但当双方都在对称型 NAT 后时，这种方法就未必有效了。

There are still a lot of problems waiting to be solved in this pile of terrible code.

这坨糟糕代码里还有许多需要改进的地方。

from https://github.com/dec32/Stupid-Chat

https://github.com/dec32/Stupid-Chat/releases