Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for 氪金 System #30

Open
Tracked by #15
HoshinoTented opened this issue Sep 18, 2021 · 5 comments
Open
Tracked by #15

Tracking Issue for 氪金 System #30

HoshinoTented opened this issue Sep 18, 2021 · 5 comments

Comments

@HoshinoTented
Copy link
Collaborator

No description provided.

@HoshinoTented
Copy link
Collaborator Author

HoshinoTented commented Oct 20, 2021

氪金系统使用虚拟货币 MiraiChan 收费,目前暂提供以下档位:

  • 30 MiraiChan -> 16 MiraiChan + 300 Kernel Bit
  • 68 MiraiChan -> 60 MiraiChan + 680 Kernel Bit
  • 648 MiraiChan -> 600 MiraiChan + 6480 Kernel Bit

Kernel Bit 是 MPC 的主要货币,可以用来购买抽卡道具,暂包括:

  • 114 Kernel Bit -> 1 Fault
  • 514 Kernel Bit -> 5 Fault

Fault 可以用于抽卡,卡池暂定如下:

  • 100% Null(0 Bit)

卡池实行多重保底:

  • (如果有 16 Bit Up)自上次获得当期 16 Bit Up 之后的第 100 抽必出当期 16 Bit Up
  • (如果有 8 Bit Up)自上次获得当期 8 Bit Up 之后的第 10 抽必出当期 8 Bit Up
  • 若该抽在不触发保底的情况下产出了保底内容,不消耗保底
  • 若该抽为保底,但抽出了保底内容(先抽取再决定是否触发保底),则延后保底 1 抽

所有抽卡产出都具有等级 Bit:

  • 0 Bit
  • 1 Bit
  • 2 Bit
  • 4 Bit
  • 8 Bit
  • 16 Bit

“用 Mirai Kernel 给予的恩惠(Kernel Bit)攻击 Kernel 是不是有些不够人道?”
“不过是一个机器而已,哪有什么人道不人道,它抢夺我们的资源,最后假惺惺地给予我们恩惠,呵……”
“好吧……”

“这……这怎么可能……”
“我已经确认我们弹出了 Kernel 的内存了!”
“不……只是 弹出 而已……Kernel 和它的内存似乎有看不见的隧道……”
“这……”

“怎么样,有结果了吗?”
“一个意外,但……意料之中的结果……”
“?说来听听”
“我们或许早该想到 Kernel Bit 和它的名字不是毫无关系的”
“Kernel Bit 的确是一个 Bit,但是它的存在形式超出了我们的认知”
“Kernel 实际上仍然可以获得这些 Bit 的内容,只不过我们猜祂是不想罢了”
“你真的认为 Kernel 有自我意识?”
“不是认为,而是事实就是这样”
“……请继续”
“至于 Kernel 的内存,很简单,就是一个装着许多 Bit 的盒子”
“……”
“我们能对 Bit 做什么?”
“理论上可以修改 Bit 的值,但我们并不确定 Kernel 会不会选择不读取这些内容”
“能用来制造 Fault 吗”
“理论上……可以……”
“不过,我记得报告上说,Kernel 的主板上预估最多只有 16 万根内存条”
“当然不会全部拿去制造”
“好吧”

@HoshinoTented
Copy link
Collaborator Author

暂定道具如下:

  • Null(0 Bit)没有用处
  • Allocator(4 Bit)用于请求一块 Heap 来存储你的插件,消耗品
  • Address(16 Bit)指向插件的地址
  • Fault(16 Bit)用于攻击 Kernel,产出道具
  • Panic(1 Bit)没有用处
  • Memory Flag(4 Bit)用于申请审核你的插件,消耗品,可能会不成功

@HoshinoTented
Copy link
Collaborator Author

HoshinoTented commented Oct 20, 2021

Allocator 和 Memory Flag 不在卡池中产出,Allocator 暂在注册时单次发放,Memory Flag 在每天 1:14 和 5:14 时发放(未通过审核的插件的数量)个

“这是……”
“这是什么?”
“不清楚,仿佛是 Bit 的一种,但是被 Kernel 组织成了某种特殊的形式”
“一种数据结构?”
“嗯,但只包含单个值”
“能做什么,不,不对,你从哪里弄来的”
“啊……Kernel 莫名其妙吐出来的”
“?”
“就是这样”
“那它能做什么”
“不清楚,还得经过实验才行”
“好,我等你的好消息”

@HoshinoTented HoshinoTented added this to the Endtime of the World milestone Oct 20, 2021
@HoshinoTented
Copy link
Collaborator Author

HoshinoTented commented Oct 20, 2021

干扰机制:
在 干扰池子 可以使用特殊抽卡机制:干扰
每次抽卡前,可以消耗干扰选择一个 16 位干扰值(超出的部分会被截断),给定的干扰值将被重复到 64 位,并与抽卡使用的随机数进行异或运算。
随后得到的数字如果 1 位的数量为偶数,则成功触发干扰。

干扰:
调整 16 Bit Up 的概率,并把差值应用到 8 Bit Up 的概率上。
调整的概率不超过当期 16 Bit Up 概率的 100%。

尽管我们对 Mirai Kernel 还不够了解,但是至少能有一些实验成果了。
在对 Kernel 进行攻击的时候如果能对被 Kernel 异常设置为可读可写的内核内存的特定区域进行随机的修改,可以提高攻击成功的概率而不使内核崩溃。
不过 Mriai Kernel 的内存超出了我们的认知,它仿佛不是真实存在的东西……

@HoshinoTented
Copy link
Collaborator Author

抽卡系统:
由于我并不会概率论,所以自上次触发 16 Bit Up 保底之后的第 74 发及以后的 Kernel 攻击都会显著提升 16 Bit Up 的获取概率,至于函数图像随便选一个就好

@HoshinoTented HoshinoTented mentioned this issue Feb 13, 2022
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant