代码分析文档怎么写
Trinoo DDOS 攻击软件分析一、软件组成Trinoo DDOS 工具有两个程序组成,1、master 主控端程序,主要功能是通过telnet协议接收远程控制者的指令,向被控肉鸡端发送攻击指令。
该程序的源代码共由5个文件组成。
分别是:(1)、strfix.h 通过宏定义的方式,变相定义了strcpy和strcat 两个函数(2)、blowfish.h和 blowfish.c 用来实现blowfish加密算法的程序代码(3)、bf_tab.h 定义了blowfish加密算法所用到的多个数据表(4)、master.h 实现DDOS主控功能的核心实现代码。
2、 daemon肉鸡端被控程序,主要功能是:接受攻击指令,对目标电脑发起DDOS攻击。
该程序源代码只有一个文件组成。
ns.c 文件,实现功能,接收并解析攻击指令,发起DDOS攻击,这里有一个局限性是,Trinoo所支持的DDOS攻击种类只有基于UDP数据包一种。
二、网络拓扑结构三、 Trinoo的使用方法其中:红色部分为控制台输出,蓝色部分为输入的指令,绿色部分为相应部分的解释1、主控端程序的使用。
2、肉鸡端被控程序的启动,被控端启动非常简单,无论采用什么方式,只要成功运行,被控端的deamon程序即可。
在试验阶段可以直接运行3、ddos网络控制者使用telnet控制整个网络的方法四、Trinoo工具的操作指令1、die 指令功能:关闭主控程序 思考:可以考虑通过该指令,来关闭有trinoo工具构建的DDOS网络。
优点: 擒贼擒王,终止主控程序后,其下面的被控程序将不能进行有效的 攻击,缺点:对DDOS网路的破坏不彻底,很容易死灰复燃。
2、quit指令功能:退出主控端的登录3、mtimer 指令功能:设置dos攻击的时间,有一个参数,参数的合法值是1至2000的整 数,如果设置的值超过2000,系统会自动设为500,如果设置的值 小于1,则系统自动设置为300, 其中:表示攻击的时间由主控程序转换后发给肉鸡的指令是:bbb 【PASS】 4、dos IP 指令功能:设置发动DOS攻击的目标计算机的IP,参数为:IP地址命令格式:dos 5、mdie pass 指令功能:终止使所有肉鸡端的受控程序。
参数为一验证密码,这里使用的密码 和master程序运行时的验证密码不同,也和telnet登录时的验证 密码不同,是一个单独的密码。
验证密码三命令格式:mdie思考:一但掌握了DDOS网络的控制权,就可以通过指向该指令,使整个ddos 网络中的ddos攻击程序全部终止,使该网络彻底被破坏。
但是这需要一 个前提条件是,必须知道着第三个验证密码,也正是因为该指令有如此 大的威力,所以才需要令设一个验证指令来验证,以防止该命令被乱用。
6、mping 指令功能:命令肉鸡向主控程序所在计算机发送ping指令命令格式:mping7、mdos 指令功能:发送的是多IP攻击指令,特点是有多个攻击目标,攻击目标个数没 有具体限制命令格式:mdos 8、msize指令功能:设置DoS攻击时使用的UDP数据包的长度。
命令格式:msize 9、nslookup 指令功能:对指定的主机进行域名查询。
命令格式:nslookup 10、killdead 指令功能:用是清除已经死掉的肉鸡,更新肉鸡信息列表文件,无参数命令格式:killdead11、usebackup 指令功能:切换到由"killdead"命令建立的广播主机备份文件。
12、bcast 指令功能:获取被控端计算机IP地址列表,返回到telnet端,13、help 指令功能: 服务器或命令的帮助信息,命令格式:help 14、mstop 指令功能:停止一个DoS攻击(此现在尚未实现,但在help命令中列出。
)守护 程序命令15、Info指令功能: 返回ddos攻击攻击版本信息的zhiling命令格式:info五、通信端口特征1. 攻击者到主服务器: 27665/TCP;2. 主服务器到守护程序:27444/UDP;3. 守护程序到主服务器:31335/UDP。
六、软件的构架设计1、主控端master程序总流程图2、主控程序端,使用telnet通讯子模块的流程图3、主控程序端,与肉鸡端通信子模块的流程图这个足够详细吧
哪里有讲解关系数据库软件内部构造原理和源代码分析的资料不是设计...
?就笔者的观点来看:软件设计是采用编程或脚本语言优雅地表达并解决现实需求的一门科学和艺术。
优雅地表达想传递的意思是,所设计出来的软件应当能容易被人理解、方便扩展和维护。
从这一定义可以看出软件设计首先是一门科学,是一门解决用户需求的软件科学。
既然是科学,不可避免的要掌握相关的科学知识,比如数据结构、计算机组成原理、编程语言等等,而这些内容也正是大学计算机相关专业所传授的知识。
科学知识或许更加容易被量化,拿数据结构为例,一种算法比另一种算法是否更优可以从算法的时间冗余度和空间冗余度进行衡量。
除了科学的部分,软件设计还涉及艺术的范畴。
既然是一门艺术,那就一定存在欣赏的问题,也就意味并不是每个从业人员都能欣赏这种艺术,而只有达到了一定的层次且形成了自己的思想后才能欣赏它。
由于设计中艺术的非直观性,造成其在现实中不容易被量化,因此难以形成相应的评估准则,进而造成在软件行业容易被忽视。
试想想,大学课程有多少内容是在教我们将软件设计当作艺术进行欣赏并追求?好的软件设计能相对方便(甚至是很方便)地实现新的需求问题。
需求分析是告诉我们做什么,其显然非常的重要,而设计更多地涉及怎么做更好。
既然对于设计的好坏不能完全通过量化的方式进行衡量,那如何去评价一个软件设计的好坏呢?或者在进行软件设计时,如何去思考以做出一个好的设计呢?这可以通过对一些软件设计原则的把握来做到。
设计原则可能有很多,但并不是每一个项目都要同时满足所有的设计原则,另外,不同的项目其特性有可能使得有些设计原则并不适用。
另外,设计原则也不是一成不变的,可能因项目的特点又可以抽取出另外的设计原则。
笔者将在后续的文章中阐述日常工作中所遵守的软件设计原则。
软件设计是一个不断提炼和抽象的过程。
说它是一个提炼的过程,是因为在设计之初会想到很多需要考虑的因素,这些因素在设计工作没有深入之前,并不能发现它们有些是重叠的,或者有些根本就不需要考虑。
随着设计的深入,会从众多的因素中得到其中的关键因素并将这些因素付之于实践。
设计也是一个抽象过程,需要从众多的表象中找到它们的共性,通过表达共性从而最终描述每个个性,而不应当局限于直接去描述每一个个性。
设计的深入过程并不只是一味地思考,除非设计者以前有过类似的设计经验,否则设计过程通常需要进行一定的代码编写工作,以辅助思考,这一点对于开发软件架构师(系统架构师不包括在内)也应当是一样的。
软件设计是一个创造模型的过程。
通过对需求的理解和抽象,好的设计将最终构造出一个模型,而且这个模型与现实世界的某样东西可能是相类似的。
这个模型除了实现了用户的需求,还向他人展示了她自己是什么模样以及可能会如何行事。
打个比方,如果有人发明了一种新的交通工具,他如何最为有效地表达这一新的交通工具到底是什么样的呢?是直接拿一张图纸给他人并说你看看图纸就知道了好呢?还是打一个大家都耳熟能详的比方好呢?显然,后者更好。
如果他说这个新的交通工具与现在的轿车很像,只不过,如此一来,听众马上就会想,这个新的交通工具有四个轮子、也有方向盘等等。
显然,后者能很快地让听众利用其生活经验快速的接收信息,而好的软件设计也应当做到这一点。
软件设计时的模型创造过程,其实就是赋予软件代码生命的过程,由此看来一个好的设计应当是 有生命的。
软件设计是一个做选择的过程。
人有时没有选择反而轻松。
一个刚毕业的大学生如果只拿到了一个offer,他可能没有选择单位的烦恼,不论单位好坏都去报道就是了。
但是,如果他拿了两个offer,选择的烦恼也就有了 是去A单位好呢?还是B单位好?不幸的是,软件的设计过程往往存在大量的选择。
是用空间换时间好呢?还是用时间换空间好?是现在考虑可扩展性呢?还是将来?等等。
因此,毫不夸张地说,设计是痛苦的,除非设计主题很简单或直接了当。
有苦当然也就有乐,在设计没有最终定下来时,需要痛苦地思考和选择,往往是一个觉得这个也不行、那个也不好的过程。
但是,一旦设计最终定稿,会发现这就是我想要的设计,随之而来的是三百六十度的大转变,觉得这个也应当就是这样,那个也应当是这样,其结果是设计者能从中体会到一种美,并从中收获乐趣。
软件设计是一个在有限理性范围内追求完美的过程。
有限理性非常重要,设计者需要在各种条件允许的情况下做出合理的设计选择。
另外,促使设计者用心并痛苦地进行设计的动力是设计者追求完美的品德。
如何从软件开发的角度分析一个软件并将软件开发说明写出来?
首先,你需要明白为什么需要文档。
你要理解文档和代码一样重要,都是开发人员的劳动成果(artifact)。
其次,你要确定你采用的周期模型和开发方法。
不同的模型或方法会有不同的文档需求,这需要你自己裁剪直到适合你的开发团队,别忘了,文档也是为了提高开发效率、质量用的,让开发人员过多的写一些无味的文档,反而会降低效率。
再次,你要作出一些文档模板,模板中对文档的用途和结构做出明确的说明。
最后,就可以填充啦。
附一个RUP的需求描述文档模板 1.0 简 介 [介绍本文档的整体结构。
] 1.1 目的 [说明本软件需求规格说明书的目的。
软件需求规格说明书不仅需要完整的描述系统的行为,还需要说明非功能性的需求、设计约束以及其它相关的因素。
] 1.2 范围 [简要介绍本需求规格文档适用的项目/应用程序及其主要特性或其它子系统、相关的用例模型和受其影响的其它任何事物。
] 1.3 定义、术语和缩写 [详细定义正确地理解本文档的相关术语,包括定义、首字母缩写词和缩略语。
可以通过引用术语表说明。
] 1.4 参考资料 [说明本文档引用的任何其它相关文档。
要列出文档的标题、文档编号、日期、和出版单位并说明文档的来源。
] 1.5 概要 [说明本文档余下部分包含的内容及组织方式。
] 2.0 说 明 [本节列出影响产品和需求的一般因素,但不需列出具体的需求,只需描述将在第3节中详细描述的需求的背景,以便于理解需求。
这包括:产品总体效果,产品功能,用户特征,约束、假设和依赖,以及需求子集等。
特别关键的是除了需要说明产品是或说解决什么,还要说明产品不是或不是解决什么。
] 2.1 用例模型 [如果使用了用例模型,本小节概述适用于本系统的用例模型或子模型,包括所有用例和角色的名称和简要说明及用例图和关系。
可将用例报告作为附件在此引用。
] 2.2 假设与依赖 [说明所有重要的技术可行性、子系统或组件的可用性或可作为此说明书所描述的软件的基础的其它相关假设。
] 3.0 需求描述 [详细描述软件的需求。
其详细程度能够使设计人员设计出满足这些需求的系统;测试人员能够测试此系统是否真的满足这些需求。
在使用用例建模时,这些需求采用用例和可用的其它补充文档捕获 。
] 3.1 用例报告 [用例模型通常定义了系统的主要功能性需求和一些非功能性需求。
对用例模型中的每个用例都需要在此引用或附上用例报告。
保证清晰的标明每个需求。
] 3.2 补充说明 [描述没有包含在用例中的其它需求。
此处应包含补充需求说明中适用于此系统的具体需求说明或特征,并重新提炼以足够详细地说明此系统。
这些信息可直接记录在此文档中,也可以作为附件引用到单独的补充说明文档。
同样要保证需求被清晰的定义。
] 4.0 辅助信息 [辅助信息使此文档更容易使用。
这可以是目录、索引、附录、用例示意图、用户界面原型等。
如果包含附录,要明确说明此附录是否是需求的一部分。
]
转载请注明出处51数据库 » 代码结构怎么分析软件