[U] Update channel content
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-cn">
|
||||
<id>https://aza.moe/life</id>
|
||||
<title>小桂桂的回忆录 📒</title>
|
||||
<updated>2024-10-02T08:11:29.056031+00:00</updated>
|
||||
<updated>2024-10-02T10:10:50.866877+00:00</updated>
|
||||
<link href="https://aza.moe/life" rel="alternate"/>
|
||||
<generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator>
|
||||
<logo>https://aza.moe/meru_256px.png</logo>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -61507,7 +61507,7 @@
|
||||
"id": 4489,
|
||||
"date": "2024-09-29T05:10:34",
|
||||
"text": "<a href=\"##RF\">#RF</a> 关于我今天不小心刷砖了一张 Mifare 卡又救回来了的这件事:\n\n众所周知 Mifare 卡的序列号或者 ID 是生产出厂的时候写入进分区 0 里面,之后就变成了只读的信息。但是我们常说的 CUID 卡 (又名 Mifare Classic DirectWrite Gen2) 支持一些让程序覆盖 0 分区的魔法指令,这样复制卡的时候就可以作为白卡覆盖序列号了,让新卡和旧卡数据完全一样 <i class=\"custom-emoji\" emoji-src=\"emoji/5443042995165209696.tgs\">🧙♂</i>\n \n...然后今天我发现它覆盖 0 分区的时候没有任何验证,既没有验证 0 分区数据合不合理,也没有防止溢出... 然后蠢蠢桂桂把 7-byte ID 的 mifare 4k 数据写到这张 4-byte ID 卡里让它变砖了,无论是手机还是 pm3 都读不到 <i class=\"custom-emoji\" emoji-src=\"emoji/6170424195260877091.webm\">🤗</i>\n\n...原本以为没救了去 rf 群里感叹一下,然后群友说其实是有救的,pm3 可以 <code>--force</code> 强行重写 0 分区 <i class=\"custom-emoji\" emoji-src=\"emoji/6170139473288890346.webm\">🤩</i> 好耶,得救了",
|
||||
"views": 76,
|
||||
"views": 77,
|
||||
"forwards": 1,
|
||||
"media_group_id": 13820693072131581,
|
||||
"images": [
|
||||
@@ -61537,7 +61537,7 @@
|
||||
"id": 4491,
|
||||
"date": "2024-09-29T07:09:31",
|
||||
"text": "<a href=\"##RF\">#RF</a> <a href=\"##TIL\">#TIL</a> 收到了复制小区门卡的委托,扫了一下发现是没见过的 Mifare Plus X 2k/4k (SL1) 卡,和 Classic 1k 不一样的地方是它有 7-byte 的 ID,40 个数据分区。\n\n原本以为这种加强安全性的卡会很难解,试试幸运吧跑一下 <code>mf autopwn</code>,发现 0-15 分区的密钥全都在默认字典里 🌚 即 dump\n\n但是尝试写入新卡的时候发现我这里并没有可以存下 7-bit ID 也没有可以存下 40 个数据分区的卡,不过看到它除了 0-15 分区以外其他分区的密钥都是 FFFFFFFF,群友猜可能它没有用剩下的 24 个分区... 然后朋友回去试了一下把它的 1-15 分区数据写进普通的 Classic 1k 卡里发现居然真的能用 🌚\n\n唉,RF 安全真是巨大的草台",
|
||||
"views": 75,
|
||||
"views": 76,
|
||||
"forwards": 0,
|
||||
"images": [
|
||||
{
|
||||
@@ -61567,7 +61567,7 @@
|
||||
"id": 4493,
|
||||
"date": "2024-09-30T15:38:54",
|
||||
"text": "用开源软件就是在尝试理解为什么硬盘 uuid 获取不到的时候在 GPT 分区表头里看到一个不知道谁写的 \"Hah!IdontNeedEFI\" 🌚",
|
||||
"views": 119,
|
||||
"views": 123,
|
||||
"forwards": 3,
|
||||
"images": [
|
||||
{
|
||||
@@ -61586,14 +61586,14 @@
|
||||
"id": 4494,
|
||||
"date": "2024-10-02T04:32:22",
|
||||
"text": "今天见到了光量子 <a href=\"https://t.me/lightquantum01\">@lightquantum01</a>,好可爱!\n\n不过居然光量子今天才知道我在 UofT 上本科 quq 我在别人眼里是什么网络神秘人吗,明明已经很实名了的",
|
||||
"views": 57,
|
||||
"views": 60,
|
||||
"forwards": 0
|
||||
},
|
||||
{
|
||||
"id": 4495,
|
||||
"date": "2024-10-02T05:14:24",
|
||||
"text": "今天计网课上讲了 BGP (边界网关协议),感觉学到了很不得了的东西 <i class=\"custom-emoji\" emoji-src=\"emoji/6170139473288890346.webm\">🤩</i>\n\n在层级网络的最顶端,运营商和国家级别的自治系统「AS」之间,也和我们自己家里的路由器交换机一样用了平等的分布式共识机制,互相通过 BGP 按照复杂的规则交换路径表,花上几个小时来聚合到共识的最短路径\n\n但是和路由器交换机不同的是,它非常的不自动,反而每个 AS 都会专门雇人配置很复杂的 BGP 规则,为什么这样呢?并不是因为技术上不能,而是因为人类的不完美... 在这个网络上的,有时候互相是竞争对手,有时候是客户和供应者,有时候是国家,有时候是国家立场的黑客...\n\n每个 AS 都在白嫖和被白嫖、信任和谎言之间微调规则,真的是一种好不完美的美 <i class=\"custom-emoji\" emoji-src=\"emoji/6170139473288890346.webm\">🤩</i>",
|
||||
"views": 45,
|
||||
"views": 49,
|
||||
"forwards": 0,
|
||||
"images": [
|
||||
{
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
<link>https://aza.moe/life</link>
|
||||
</image>
|
||||
<language>zh-cn</language>
|
||||
<lastBuildDate>Wed, 02 Oct 2024 08:11:29 +0000</lastBuildDate>
|
||||
<lastBuildDate>Wed, 02 Oct 2024 10:10:50 +0000</lastBuildDate>
|
||||
<item>
|
||||
<title>小桂桂的回忆录 📒 #4495</title>
|
||||
<link>https://aza.moe/life?post=4495</link>
|
||||
|
||||
Reference in New Issue
Block a user