|
|
|
[原创]NDIS中间层透明加密系统设计文档
这东西这么搞太复杂了 只需要在中间层截获需要加解密的包,然后把包内容传到应用层: 1、对于发送出去的包,应用层对整个以太网包直接加密后,以socket方式发送到网络对端;网络对端收到数据包后,直接解密得到原始以太网包,然后还是通过中间层驱动,直接向本机转发这个以太网包就够了。 2、中间层收进来的数据包,可以不管。。。。只需要监听指定端口发来的数据(上述步骤1来的socket数据),然后解密,解密后通过中间层驱动提交到协议栈(这一步实际在步骤1说了) 总结一句就是,加解密以及规则什么的,这些都在应用层做,不要搞到内核去了。 |
|
监控文件上传思路,跪求!!
不是不简单,是根本没有实现的可能性……发送数据到网络,那个纯粹是buf操作,根本没有任何可能与之前的某个读或者写关联起来……人家这个buf可能是经过n个地方处理,转了n个进程以及线程,最后才走到发送这一步……然后发送,人家也未必按照读写的顺序发送接收……根本就是一件异想天开的事情 某句话还是不错的……什么样的基础就问的出什么样的问题……所以一般我要是面试,我很少问别人问题,我一般让别人问我问题 又忍不住感叹了下,虽然与这篇帖子的初衷关系不大了……实际上现在太多人过于急功近利了,刚学了改写只读属性的内存,马上想着做挂钩,写外挂了,然后还可以很不屑的,”xxx也不过如此尔尔” |
|
监控文件上传思路,跪求!!
怎么总是会有这种nc的想法……根本不可能实现的功能……还n多人会有这种想法,太多人连基本常识都没了 举例来说,你凭什么就知道一个程序读了一个文件后,它读出来的数据就是网络传出去了?你凭什么就认为某个数据包里的数据就是传的文件里的数据,就不是我自己构造的数据? |
|
|
|
|
|
[求助]x64 如何拦截驱动加载?
麻烦搞清楚人家通知是串行的好不好……又不是并行异步消息……而且按你说的是并行异步消息的话,前面说的系统卡爆了………异步的话卡毛线啊 |
|
[原创]原创读写锁,求测试
[QUOTE=sjh_pediy;1257654] 附上测试代码[/QUOTE] 给你修改过的 同时把之前的wait函数改成了带ex版本,避免线程被APC意外唤醒, 同时改了提醒方式,打印出的是当时读和写线程的个数 理论上,每次打印出的数字,读或者写必有一个为0,而且如果写不为0那一定只能是1,否则锁逻辑有问题 |
|
[原创]原创读写锁,求测试
[QUOTE=sjh_pediy;1257654] 附上测试代码[/QUOTE] 不要主动去unlock 因为你的类里面主动去调用了一次unlock,析构时又再调用一次。。。。。这个为啥不挂。。。 正常的用法是: WLock WriteLock(g_RwLock); 如果要限制锁生效的范围,直接使用{}做控制就是了。。。。。 而且C++编码习惯一般也推荐像我说的这么做。。。。比如boost那些锁,基本上都是不需要你主动去unlock的,只要你自己控制锁变量的作用范围就够了 |
|
[求助]x64 如何拦截驱动加载?
驱动直接patch掉PE入口不就是了 |
|
[原创]原创读写锁,求测试
再给个不考虑重入问题的,一样很简单: PVOID __stdcall CreateRWLock() { PRW_LOCK pLock=NULL; do { pLock=(PRW_LOCK)malloc(sizeof(RW_LOCK)); if (!pLock) { break; } RtlZeroMemory(pLock,sizeof(RW_LOCK)); pLock->iNowReaderCount=0; pLock->hShareLock=CreateEvent(NULL,FALSE,TRUE,NULL); if (pLock->hShareLock) { InitializeCriticalSection(&pLock->ExclusiveLock); break; } free(pLock); pLock=NULL; } while (FALSE); return (PVOID)pLock; } VOID __stdcall DeleteRWLock(PVOID pLock) { PRW_LOCK pRwLock=(PRW_LOCK)pLock; if (pRwLock->hShareLock) { DeleteCriticalSection(&pRwLock->ExclusiveLock); CloseHandle(pRwLock->hShareLock); } free(pLock); } VOID __stdcall AcquireShareLock(PVOID pLock) { PRW_LOCK pRwLock=(PRW_LOCK)pLock; EnterCriticalSection(&pRwLock->ExclusiveLock); if(InterlockedIncrement(&pRwLock->iNowReaderCount)==1) { WaitForSingleObject(pRwLock->hShareLock,INFINITE); } LeaveCriticalSection(&pRwLock->ExclusiveLock); } VOID __stdcall ReleaseShareLock(PVOID pLock) { PRW_LOCK pRwLock=(PRW_LOCK)pLock; if(InterlockedDecrement(&pRwLock->iNowReaderCount)==0) { SetEvent(pRwLock->hShareLock); } } VOID __stdcall AcquireExclusiveLock(PVOID pLock) { PRW_LOCK pRwLock=(PRW_LOCK)pLock; EnterCriticalSection(&pRwLock->ExclusiveLock);//占用写锁,使得其它线程不可读(后续所有想获取读锁和写锁的操作,都会卡在这里) WaitForSingleObject(pRwLock->hShareLock,INFINITE);//等待所有已经获取读锁的线程完成操作(一定只有一个想获取写锁的线程在这里等待,因为其它想获取写锁的线程会卡在上面一行) SetEvent(pRwLock->hShareLock); } VOID __stdcall ReleaseExclusiveLock(PVOID pLock) { PRW_LOCK pRwLock=(PRW_LOCK)pLock; LeaveCriticalSection(&pRwLock->ExclusiveLock); } 一旦引入重入,复杂度就会几何级数增长了 这个代码,貌似都不到100行 |
|
[原创]原创读写锁,求测试
我是说,我这种do...while的习惯,内存泄露这种问题的可能性还是很小的 |
|
[原创]原创读写锁,求测试
你反应错地方了吧……我那个每次都是记录最后一个节点,同时把上一个节点放到pre里 删除时做反向操作,同时把最后一个删掉(pLastType->pPre=pRwLock->pLastAcquireType,然后pRwLock->pLastAcquireType=pLastType)……哪里有问题了…… 不过之前到真有个地方有问题,就是我说的那个基本没可能走到的逻辑……我还以为你看到了呢……原来没有 |
|
杀毒公司员工还原真实的熊猫烧香毒王李俊
呵呵,当年都只是因为觉得它与其他什么病毒没啥特别高明之处,所以没出来炒作一把……现在就更没这个必要了 |
|
[原创]原创读写锁,求测试
嗯,刚下飞机,才看到……虽然你说的那个地方,基本没可能会走到……不过理论上是这样……笔误吧……手机号私信给我 |
|
[原创]原创读写锁,求测试
至于复杂与简单,还是要看具体需求,没有什么绝对标准……比如,只要不考虑重入逻辑,这份代码长度至少减一半……之前没没考虑重入问题时候,我这个锁确实就只有一百来行就搞定……看起来只加了个重入的需求,但是逻辑会马上复杂很多 |
操作理由
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 }}
勋章
兑换勋章
证书
证书查询 >
能力值