|
[求助]如何添加资源
“茴香豆的“茴”字有四种写法……” |
|
[求助]文本文件编码的问题
推荐->XML |
|
[求助]什么是CPU的分配粒度?????
delete |
|
对windows NT tss的困惑
NT系列为了兼容各种硬件平台,用自己的的方法保存进程环境的 你关心的应该X86下的地址空间和线程上下文、IO位图之类。 线程上下文在KTHREAD(或者ETHREAD?自己去看吧)的CONTEXT与中保存 地址空间说白了就是个页表。页表地址是在EPROCESS中保存,线程切换的时候会替换。 IO位图也是在线程切换的时候被COPY到TSS的。 只是凭记忆说的,可能有错,具体还是自己看WRK。可以从KeAttachProcess入手看。 TSS在WINDOWS中应该基本上是跟WINDOWS的任务切换的实际实现是没关系的。 |
|
[原创]Base64编码解码算法 Cpp+sdk 源码
————标准C |
|
[原创]Base64编码解码算法 Cpp+sdk 源码
这是我在第一次看BASE64编码规则后花1小时写的 /* 编码表 A B C D E F G H I J K L M N O P Q 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 R S T U V W X Y Z a b c d e f g h 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 i j k l m n o p q r s t u v w x y 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 z 0 1 2 3 4 5 6 7 8 9 + / (pad) = 51 52 53 54 55 56 57 58 59 60 61 62 63 */ int Base64_Encode(char *Src, int SrcLength, char *OutputBuffer, int OutputBufferLength) { int GroupCount; int GroupResidualLength; int EncodeResultLength; int i; unsigned char *SrcData; unsigned char PaddingBuffer[3]; static char Base64_EncodeTable[64]={"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"}; /*将原始数据分为3个字节一组*/ GroupCount = SrcLength / 3; GroupResidualLength = SrcLength % 3; EncodeResultLength = GroupCount * 4; if(0 != GroupResidualLength) EncodeResultLength = EncodeResultLength + 4; if(EncodeResultLength > OutputBufferLength) { /*输出缓冲区不足*/ return 0; } /*编码分组*/ SrcData = (unsigned char *)Src; for(i = 0; i < GroupCount; i++) { OutputBuffer[i*4 + 0]= Base64_EncodeTable[ ( SrcData[i*3 + 0]&0xFC )>>2 ]; OutputBuffer[i*4 + 1]= Base64_EncodeTable[ ((SrcData[i*3 + 0]&0x03)<<4) + ((SrcData[i*3 + 1]&0xF0)>>4) ]; OutputBuffer[i*4 + 2]= Base64_EncodeTable[ ((SrcData[i*3 + 1]&0x0F)<<2) + ((SrcData[i*3+ 2]&0xC0)>>6) ]; OutputBuffer[i*4 + 3]= Base64_EncodeTable[ SrcData[i*3 + 2]&0x3F ]; } /*编码未分组的剩余字节*/ if(0 != GroupResidualLength) { PaddingBuffer[0] = 0; PaddingBuffer[1] = 0; PaddingBuffer[2] = 0; for(i = 0; i < GroupResidualLength; i++) PaddingBuffer[i] = SrcData[GroupCount*3 + i]; OutputBuffer[GroupCount*4 + 0]= Base64_EncodeTable[ ( PaddingBuffer[0]&0xFC )>>2 ]; OutputBuffer[GroupCount*4 + 1]= Base64_EncodeTable[ ((PaddingBuffer[0]&0x03)<<4) + ((PaddingBuffer[1]&0xF0)>>4) ]; OutputBuffer[GroupCount*4 + 2]= Base64_EncodeTable[ ((PaddingBuffer[1]&0x0F)<<2) + ((PaddingBuffer[2]&0xC0)>>6) ]; OutputBuffer[GroupCount*4 + 3]= Base64_EncodeTable[ PaddingBuffer[2]&0x3F ]; } return EncodeResultLength; } int Base64_Decode(char *Src, int SrcLength, char *OutputBuffer, int OutputBufferLength) { int GroupCount; int GroupResidualLength; int EncodeResultLength; int i,j; unsigned char *SrcData; unsigned char PaddingBuffer[4]; unsigned char DecodeBuffer[4]; static unsigned char Base64_DecodeTable[256] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x00, 0x00, 0x00, 0x3F, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; /*将原始数据分为4个字节一组*/ GroupCount = SrcLength / 4; GroupResidualLength = SrcLength % 4; EncodeResultLength = GroupCount * 3; if(0 != GroupResidualLength) EncodeResultLength = EncodeResultLength + 3; /*解码分组*/ SrcData = (unsigned char *)Src; for(i = 0; i < GroupCount; i++) { DecodeBuffer[0] = Base64_DecodeTable[ SrcData[i*4 + 0] ]; DecodeBuffer[1] = Base64_DecodeTable[ SrcData[i*4 + 1] ]; DecodeBuffer[2] = Base64_DecodeTable[ SrcData[i*4 + 2] ]; DecodeBuffer[3] = Base64_DecodeTable[ SrcData[i*4 + 3] ]; OutputBuffer[i*3 + 0]= (DecodeBuffer[0]<<2) | ((DecodeBuffer[1]&0x30)>>4); OutputBuffer[i*3 + 1]= ((DecodeBuffer[1]&0x0f)<<4) | ((DecodeBuffer[2]&0x3c)>>2); OutputBuffer[i*3 + 2]= ((DecodeBuffer[2]&0x03)<<6) | (DecodeBuffer[3]&0x3f); } /*解码未分组的剩余字节*/ if(0 != GroupResidualLength) { PaddingBuffer[0] = '='; PaddingBuffer[1] = '='; PaddingBuffer[2] = '='; PaddingBuffer[3] = '='; for( i = 0; i < GroupResidualLength; i++ ) { PaddingBuffer[i] = SrcData[GroupCount*4 + i]; } DecodeBuffer[0] = Base64_DecodeTable[ PaddingBuffer[0] ]; DecodeBuffer[1] = Base64_DecodeTable[ PaddingBuffer[1] ]; DecodeBuffer[2] = Base64_DecodeTable[ PaddingBuffer[2] ]; DecodeBuffer[3] = Base64_DecodeTable[ PaddingBuffer[3] ]; OutputBuffer[GroupCount*3 + 0]= (DecodeBuffer[0]<<2) | ((DecodeBuffer[1]&0x30)>>4); OutputBuffer[GroupCount*3 + 1]= ((DecodeBuffer[1]&0x0f)<<4) | ((DecodeBuffer[2]&0x3c)>>2); OutputBuffer[GroupCount*3 + 2]= ((DecodeBuffer[2]&0x03)<<6) | (DecodeBuffer[3]&0x3f); } return EncodeResultLength; } |
|
[原创]软件保护壳技术专题 - 反汇编引擎的构建
他是“黑社会”的~~~~ |
|
[求助]怎样使自己的程序有出错转储文件的功能
搜 MiniDumpWriteDump |
|
[原创]一种新的杀毒思路
懒得再扯了。 |
|
[原创]一种新的杀毒思路
商业上的运用不需要什么“揭示程序的结构”,要的是能解决实际问题、资源投入小于产出、要能适用于各种复杂环境。 CPU对于虚拟机的支持远没传说的那么强大,受限于CPU的设计初衷也不可能提供强大而复杂的支持。实际上,想实用现在INTEL CPU提供的恶心的虚拟化接口做出通用且稳定虚拟化支持,其难度不亚于开发与一个完整的操作系统内核,只有操作系统厂商或者专业的虚拟化公司才有这种实力。 如果不是对CPU虚拟化支持的实现复杂度有了解,还是不要随便寄托于“CPU怎么怎么样” |
|
[原创]一种新的杀毒思路
1)反病毒的虚拟机是在特征扫描的结果符合一定条件的情况下才启用的,并不是像某些SB厂商炒作的那样一直在用,你这种思路跟虚拟机不是同一层次的。你想要对于每个被点击的程序执行 2)我就想你会说在客户端加CACHE,不过如果不动态与服务器群取得联系,这种模式的优势在什么地方?跟文件执行前的特征扫描对比有什么优势?速度上要甚至要慢一些的(如果你了解当前通用的特征扫描的优化手段,我想不用我说原因) 算喽~不扯了。 反正我的看法:无论是重新定制反病毒软件体系还是在现有体系上添加此模式,投入/产出不成比例 饿了,吃饭区 |
|
[原创]一种新的杀毒思路
还有个问题,实际应用的情况下,绝对不仅仅是CPU支持就能了事,操作系统的也必须支持,而且为了实际效率,那个EIP序列要忽略OS的代码(子集SINGLE-STEP一下记事本,看下OS代码的比例就知道必要性了),那么就带来两个问题 1)对于泛意义的病毒来说,并不是所有的病毒都是感染可执行文件的,还有宏病毒、脚本蠕虫、还有内嵌在网页中的恶意代码。此模式对这种病毒应该是没有对抗能力的(你要记录人家的解析器的EIP??) 2)对于已经执行的病毒,这种模式是没有任何的对抗能力的。 3)需要操作系统厂商合作。桌面系统,依据微软的一贯作风,恐怕微软会直接打包这种安全功能,不会分享给普通的反病毒厂商用的。实际上会极大挤兑第三方安全厂商的生存空间。不会有人愿意自杀的或者被杀的。 实际上,针对1)、2)夺得原因,考虑这种模式消耗太多资源,已经成为不适用的理由 |
|
[原创]一种新的杀毒思路
思路可以 不过在当前甚至未来数10年的有限存储、带宽和计算能力情况下不可行 楼主可以尝试用调试API SINGLE-STEP一下记事本,你就知道数据量。倘若每个用户随便点个程序都要记录,且都要产生对若干服务器的请求(按楼主的意思,其实是并发对N个服务器请求),说白了,最终的通讯情况是 M(桌面系统数量) <-> N中的X个(N为服务器总数量、X为其中的子集,比如楼主说的10) 考虑到实际应用时M非常非常大,而且以上通讯将会非常频繁(用户没每个操作都可能触发),另外服务器上做的其实是最消耗计算能力的对比、检索操作,再多高性能服务器恐怕都难以满足。 就算是引入P2P机制,P2P所带来的附加网络通讯流量恐怕极高,效果就像现在在低带宽线路开BT一样。 而且还要考虑到实际应用,安全管理是个问题。考虑到复杂网络情况,P2P是根本不适用的,比如企业的多个内网与互联网是隔离的、多个内网一般有访问控制。就算是不用P2P,这种模式是需要企业内部办公系统能直接访问外部网络的(否则谁来承担额外的服务器开销?),这本身就是不现实的情况 |
|
|
|
|
|
|
|
|
|
|
|
[求助]关于SOCKET发送文件大小不一的问题[已经附上源码]
楼上各位:TCP编程中没有“包”的概念! 用UDP编程的方法写TCP程序,简单网络或许没问题,在稍微复杂的网络中,比如跨网段、使用中介代理服务、跨介质等情况,会出现乱七八糟的问题的。 如果你们为了实现应用协议非要用“包”,请不要嫌麻烦,在发送和接收时参照TCP的特性处理好块大小、块确认、块接收,否则有你们受罪的时候。 一点建议,认为我说错了,就当我放屁吧 |
|
[求助]请教获取线程句柄问题
都在内核了还要句柄干嘛! |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值