GalgameOl设计笔记

2017-07-23 00:08

直接提供图片算了,简单粗暴
乱做的示意图.png


2017-07-21 23:15

重大更新,因为不考虑ons引擎,只考虑自己的了,所以得先设计语法,明天zai'shuo


结构如下:

PY后端:

  • manage.py 用户处理websocket事件
  • resolve.py 用于处理引擎

前端就是基础三件套。
目前支持语法
["mov","goto","dwave","bgm","bgmstop","bg","if","SEL","end","fin","gosub"]

可识别语法:
["mov","goto","dwave","print","bgm","lsp","bgmstop","wait","textclear","bg","if","SEL","end","fin","gosub","br"]

通信通过WebSocket通信。

过程:

前端->{dat:游戏脚本路径或者特殊标号}
->后端:

  • 是否第一次运行? 找到第一个游戏段,解析;解析段地址为前端给予的地址

  • 解析

-返回成指定数据格式`
->前端:

  • 数据格式拆包
  • 显示给用户
  • 遇到SEL/END ->发送下一个章节的代码段(代码段在SEL语句里有)->跳转到最上方

后端解析方式:

更具前端返回,判断是否有cs?
有:读取指定的cs段 ; 没有:从第一个cs段开始解析
读入cs端,逐行解析

两个for迭代循环命令,判断语句是否带有上面的可识别命令

遇到执行命令,append到指定的列表中去(bgm,bg,voice等等),并记录文字列表的长度(好让前端知道什么时候显示

如果全都不是,那么认为为文字(文字之前没有任何命令,print什么的都没有,就直接显示)

append到文字列表

持续到逐行全部解析结束
打包成指定数据格式
通过websocket发送给前端

指定数据格式结构:

一段json:

{
    "str":[文本i,文本j....文本n],
    "flag":{用户所包含的文本地址},(这个参数请下一次请求时也请原封不动的传递上来)
    "bgm":{int:资源地址,int:'资源地址'},
    "voice":{int:'资源地址',int:'资源地址'}, 
    "Dwave":{同上},
    "bg":{同上},
    "Next":下一章节标题名,
}

dict格式{int:资源地址},其中int和list 显示文本一一对应。
后期扩展(如特效等等):延长json长度,后面加入更多的特效指令和list对应。
其中,Next一般是SEL语句或者是直接下一章的章节名,如果是SEL语句请更具用户的选择来返回对应的Next。

完整流程:

第一次运行游戏请用ws传递json {"dat":游戏脚本}
同时,ws端将会返回一大段的

{
    "str":[文本i,文本j....文本n],
    "flag":{用户所包含的文本地址},(这个参数请下一次请求时也请原封不动的传递上来)
    "bgm":{i:资源地址,j:'资源地址'},
    "voice":{k:'资源地址',n:'资源地址'},    (ijkl均为int,对应着文本i,j,k,l..)
    "Dwave":{同上},
    "bg":{同上},
    "Next":下一章节标题名,  (这个也请原封不动的传递上来)
}

不同的是Next有时候并不会返回章节名,也许会返回选择支,例如

SEL "敲门","今天这先这样吧","*CA_0","*CA_1"

请更具用户的选择修改给函数传递的cs内容。当然,也有会其他类型的文本

error 说明脚本编写错误,请直接停止游戏,因为脚本无法继续运行下去了

GameEnd/End/Fin 说明已经通关到达结局

传递消息
第二次运行时请传递json {"flag":上一次返回的,"cs",也是上一次返回的} 均为上次返回的值
注意cs可能更具SEL的选择支进行改变
返回的内容同上


2017/5/30更新

程序项目新地址:https://git.oschina.net/gaoshi_team/galgame_server

如你们所见基本没怎么动。

把那个很蠢的函数判断方法换了,用了你个略魔幻的方法
QQ图片20170530181645.png

Tags: 笔记

python-IAT HOOK

难的不是HOOK,而是各种类型的转换。
先占坑。考完试再填。如果你们发现这个文章消失了的话估计就是弃坑了HHHH


2017/7/15
终于填完了,贼难受。头晕晕的,使用方式如图
IAT HOOK:
TIM截图20170714170055.png
LOAD IAT:
TIM截图20170714170432.png
代码在这里iat.rar

Tags: iat, hook

基于免杀马的永久防上报的实现以及工具

首发于 http://mapers.net/t/topic/328

两年前的一个点子,今天正好有时间。

前提:
你得马得免杀,而且我的工具是花几分钟随手写的,可能不靠谱。
其中增大文件我用的是在文件尾部增加空白数据,我记得这会被360给提示的,如果不想提示就自己写个添加随机数据的吧。反正winrar也能压缩

原理:
原理很简单,说出来可能会被笑。就是利用winrar的压缩+自解压把扩大体积后的免杀木马文件给怼成一个压缩包,因为被压缩了所以体积很小,再加上设置了密码所以即使被上报了360的云也无法自动检测出什么来。然后把压缩包追加到一个解压的壳后面又壳释放运行/
缺点:
虽然壳体积才6kb,但是加上winrar.exe体积就大了,至少300kb,所以你的文件最终体积可能是 你的木马体积+6kb壳的体积+200+winrar.exe体积,300+kb体积可是非常大的,可能某些条件下很难接受
怕手工分析,手工分析立刻翻水水。

P.S : 我只考虑防上报,免杀和过主防不在此考虑范围。壳是随便写的,所以压缩包内木马文件名称得是server.exe,不然无法启动木马,并且压缩包密码只支持coinkboom(逃

下面正式开始,首先,先找到我们的免杀马(好早之前写的,貌似不过主防),增大体积,并且给测试查杀
ed3bade92bb229aad997f654f31d9e489a018d35_1_690x410.png
然后打包为压缩文件并添加密码2.png
最后体积只有121kb,hhhhhhh
3.png
最后拉出我们的壳:
4.png
惨不忍睹啊惨不忍睹,壳本身6kb,加上rar.exe瞬间这么大了。有机会我写一个把rar.exe弄成远程下载的把。
最后利用cp把两个文件合并,得到最终的木马文件。
5.png
最后丢到虚拟机执行并且开启上报,成功执行木马。
6.png
查看上报区,空空如也7.png

毕竟40mb的东西也不好上报。
基本就这样啦。

壳在这里:链接: http://pan.baidu.com/s/1qXZh9zI 密码: wt92

就是这样辣,一个没啥用的小玩意(:з)∠)

Tags: 免杀
文章总数:76篇 分类总数:3个
Title - Artist
0:00