|
[招聘]安络科技重庆分公司招逆向开发工程师
重庆,扎起。 |
|
|
|
[讨论]Windows是如何得知硬件信息的 如显卡网卡
应用层用API比较方便。 1. CPU,cpuid(8楼) 2. 硬盘,kernel32.CreateFile/kernel32.DeviceIoControl(8楼) 3. 显卡,读注册表 4. 网卡,iphlpapi.GetAdaptersInfo 底层驱动级的请楼下回答。 |
|
[求助]socket 客户端connect 失败,错误10061
就是服务端太忙,客户端被拒绝10061。等服务端处理完一个请求再Recv时,那边客户端已经断掉了,所以报10054。 这个gh0st的IOCP最大的问题在于void CIOCPServer::OnAccept()中用的是accept(),要真正发挥IOCP的作用应该用AcceptEx()。 OnAccept()在线程ListenThreadProc里,一次处理一个连接请求,返回一个Socket,再Recv、处理数据、Send结果。 用AcceptEx()的话,可以预先post多个accept等待客户端的连接,以及时响应客户端的连接请求。 另外,WorkerThread线程ThreadPoolFunc不应进行有大量计算、数据处理耗时的工作,应放到另外的线程去处理,处理完成后再把结果post到Send队列。ThreadPoolFunc只负责IOCP相关的事情。 建议看看《Network Programming for Microsoft Windows, Second Edition》里第6章的那个IOCP例子。 服务端 [FONT="Courier"]C:\Temp\MyProjects\NPMW\chapter06>iocpserver.exe Buffer size = 4096 (page size = 4096) Worker threads: 4 T1516 (Main) T2152 (Worker) T2200 (Worker) T2196 (Worker) T3984 (Worker) Local address: 127.0.0.1; Port: 8833; Family: 0 Listening address: [127.0.0.1]:8833 Listen Socket: S1928 Accept #1 [S1928:S1912] Accept #2 [S1928:S1908] Accept #3 [S1928:S1904] Accept #4 [S1928:S1900] Accept #5 [S1928:S1896][/FONT] 4个工作线程,预先post了5个accepts。listen一旦侦听到注册的FD_ACCEPT事件后,再post 100个accepts。 客户端连接测试 [FONT="Courier"]C:\Temp\MyProjects\ApacheBench>ab.exe -n 1000 -c 500 -s 10 -H "Connection: Close" 127.0.0.1:8833/ServPath/AppServlet?req=2abf0f0ef3d3de84 This is ApacheBench, Version 2.3 <$Revision: 1638069 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Apache-Coyote/1.1 Server Hostname: 127.0.0.1 Server Port: 8833 Document Path: /ServPath/AppServlet?req=2abf0f0ef3d3de84 Document Length: 42 bytes Concurrency Level: 500 Time taken for tests: 0.328 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 203000 bytes HTML transferred: 42000 bytes Requests per second: 3047.62 [#/sec] (mean) Time per request: 164.063 [ms] (mean) Time per request: 0.328 [ms] (mean, across all concurrent requests) Transfer rate: 604.17 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.2 0 16 Processing: 47 130 34.8 141 172 Waiting: 31 82 31.1 94 141 Total: 47 130 34.8 141 172 Percentage of the requests served within a certain time (ms) 50% 141 66% 156 75% 156 80% 156 90% 172 95% 172 98% 172 99% 172 100% 172 (longest request)[/FONT] 这里连接1000个,并发500个,用时0.328秒,全部成功完成。平均每秒处理3047个请求。 当然,作为例子,服务端并没有进行数据处理,接到请求后,简单的返回Http Header和42字节固定长度的数据。 |
|
[下载]Exeinfo PE - ver 0.0.3.3 680 sign 测试版[多语言支持]
. Exeinfo PE v.0.0.4.4 prev.3 with 963+53 signatures . Ext_detector.dll v.0.3.9.9 with 399 signatures . + 4513 signatures in userdb.txt . Fix for HI-RES screen - Windows 10 From EXETOOLS |
|
RSA加密密文的长度不是固定的吗?
RSA的计算公式: C = (M^E) MOD N 无论是加密或解密,运算的最后一步都是对N取模,所以结果的位数一定小于、等于N的位数。 一个256位的N,结果为255位或256位都很正常。计算出来的,没法固定为256位! 这个与PADDING完全不相干。 为什么需要PADDING? 因为明文信息的长度有可能与“模”不同:如果明文位数小于“模”的长度,那么解密出来后怎么还原出原来的明文长度、有用的信息?需要某种规则来定义,这就是PADDING。 如果明文长度大于N,则需要按“模”的长度“分组”,最后一组可能同样需要PADDING。 “补足”可以自己定义,但加密和解密必须遵守相同的PADDING“协议”,否则就会解密不出原文。已经有好几种符合工业标准的PADDING规范,比如PKCS1.5: [FONT="Courier"]/* RFC 2313 - PKCS #1: RSA Encryption Version 1.5 https://tools.ietf.org/html/rfc2313 EB = 00 || BT || PS || 00 || D EB - Encryption Block BT - Block Type :: 00 or 01 for private-key operation; 02 for public-key operation PS - Padding String :: length = k-3-||D|| BT 00: all 00 BT 01: all FF BT 02: pseudorandomly generated and nonzero D - Data k - length of modulus in octets */[/FONT] 请注意填充块类型(Block Type)为02时,使用了伪随机数进行填充,所以相同的输入,每次加密结果都会不一样。 在私钥的情况下,通常用于服务端,出于性能考虑,用固定字节填充BT 00/01。 在公钥时,用于客户端,用伪随机数填充BT 02。 |
|
[分享]IDR和ResourceHacker的窗体资源显示修补
奇怪,我在"Windows 7 x64 SP1 CHS"和"Windows XP SP3 CHS"测试,gwb.exe(v08.05.15)RCData里的Forms全都正常。 很有可能是你gwb.exe的Forms编码不是UTF-16LE。 2015-08-05 11:52 2,510,336 gwb.exe MD5: 520153e82e6da61f357c96f149983449 比如,Form22的Caption"注册公文标准格式制作软件"这个字符串的UTF-16LE编码在gwb.exe里偏移RVA 005B002D 处(0x18字节): 005B002D: E8 6C 8C 51 6C 51 87 65 07 68 C6 51 3C 68 0F 5F 005B003D: 36 52 5C 4F 6F 8F F6 4E 如果是下面之一,说明gwb.exe已经被修改过,显示就会出现乱码。 ANSI编码(0x18字节): 00000000: D7 A2 B2 E1 B9 AB CE C4 B1 EA D7 BC B8 F1 CA BD 00000010: D6 C6 D7 F7 C8 ED BC FE UTF-8编码(0x24字节) 00000000: E6 B3 A8 E5 86 8C E5 85 AC E6 96 87 E6 A0 87 E5 00000010: 87 86 E6 A0 BC E5 BC 8F E5 88 B6 E4 BD 9C E8 BD 00000020: AF E4 BB B6 我的Patch只改了一个分支:将Forms里面的UTF-16LE用kernel32.WideCharToMultiByte转为ANSI,即只处理UTF-16LE编码的情况。 但是,Resource Hacker有个问题,在显示之前对字符串有个检查,转好的MultiByte字符被误判,按UTF-8显示,会出现整页空白。我把那个跳改为强制ANSI显示。 |
|
[分享]IDR和ResourceHacker的窗体资源显示修补
[QUOTE=obma;1449135]下载了楼主和FeiXJ的,测试发现UTF-8页显示不正常,简体中文版(吕X汉化)UTF-8页空白。ResScope无论ASCII、UTF都显示正常,且界面可视,最为亲切。 [/QUOTE] 弄错了吧,貌似没有任何问题。 PS:IDR的Form也有文本模式和图形模式,不过它不是一个资源工具,而是Delphi程序的分析工具。 |
|
[讨论]我有个正版的Winlicense KEY,能去掉限制别的电脑用吗
只有Key还不行,需要与Key对应的Release版本,官方下载的Demo版没用。 LPK只是改RSA密钥。Bypass应该可以,但非常麻烦,不如keygen来得方便。 有Release和Key就能够Keygen。 |
|
[求助]脱壳后程序带的自校验如何过去?
试了一下,用《UPX完美脱壳脚本》可以脱,包括附加数据。 需要修改原脚本文件"UPX.Unpacker.for.Dummies.osc"第154行,将原来的: [FONT="Courier New"] mov SigUnpackingDone, #5E89F7#[/FONT] 改为: [FONT="Courier New"] mov SigUnpackingDone, #5039CC#[/FONT] |
|
[求助]哪位大侠能帮忙看一下这个期货软件是什么壳?感谢
壳代码后的程序入口: [FONT="Courier"]00401000 /EB 10 JMP SHORT 00401012 ; OEP / Near OEP 00401002 |66:623A BOUND DI, [EDX] ; "fb:C++HOOK", 0x90 00401005 |43 INC EBX 00401006 |2B2B SUB EBP, [EBX] 00401008 |48 DEC EAX 00401009 |4F DEC EDI 0040100A |4F DEC EDI 0040100B |4B DEC EBX 0040100C |90 NOP 0040100D |E9 70E97500 JMP 00B5F982 00401012 \A1 63E97500 MOV EAX, [0x75E963] 00401017 C1E0 02 SHL EAX, 0x2 0040101A A3 67E97500 MOV [0x75E967], EAX 0040101F 52 PUSH EDX 00401020 6A 00 PUSH 0x0 00401022 E8 67C33500 CALL 0075D38E ; JMP to kernel32.GetModuleHandleA 00401027 8BD0 MOV EDX, EAX 00401029 E8 CE241700 CALL 005734FC 0040102E 5A POP EDX 0040102F E8 CECB3500 CALL 0075DC02 ; JMP to OFFSET Cc3250mt.___CRTL_MEM_UseBorMM 00401034 E8 07251700 CALL 00573540 00401039 6A 00 PUSH 0x0 0040103B E8 6C261700 CALL 005736AC 00401040 59 POP ECX 00401041 68 0CE97500 PUSH 0075E90C 00401046 6A 00 PUSH 0x0 00401048 E8 41C33500 CALL 0075D38E ; JMP to kernel32.GetModuleHandleA 0040104D A3 6BE97500 MOV [0x75E96B], EAX 00401052 6A 00 PUSH 0x0 00401054 E9 75CC3500 JMP 0075DCCE ; JMP to OFFSET Cc3250mt.__startup 00401059 > E9 9A261700 JMP 005736F8 0040105E 33C0 XOR EAX, EAX 00401060 A0 55E97500 MOV AL, [0x75E955] 00401065 C3 RETN 00401066 A1 6BE97500 MOV EAX, [0x75E96B] 0040106B C3 RETN 0040106C 60 PUSHAD 0040106D BB 0050B0BC MOV EBX, 0xBCB05000 00401072 53 PUSH EBX 00401073 68 AD0B0000 PUSH 0xBAD 00401078 C3 RETN 00401079 B9 9C000000 MOV ECX, 0x9C 0040107E 0BC9 OR ECX, ECX 00401080 74 4D JE SHORT 004010CF 00401082 833D 63E97500 00 CMP DWORD PTR [0x75E963], 0x0 00401089 73 0A JNB SHORT 00401095 0040108B B8 FE000000 MOV EAX, 0xFE 00401090 E8 D7FFFFFF CALL 0040106C 00401095 B9 9C000000 MOV ECX, 0x9C 0040109A 51 PUSH ECX 0040109B 6A 08 PUSH 0x8 0040109D E8 10C33500 CALL 0075D3B2 ; JMP to kernel32.GetProcessHeap 004010A2 50 PUSH EAX 004010A3 E8 52C33500 CALL 0075D3FA ; JMP to ntdll.RtlAllocateHeap 004010A8 0BC0 OR EAX, EAX 004010AA 75 0A JNZ SHORT 004010B6 004010AC B8 FD000000 MOV EAX, 0xFD 004010B1 E8 B6FFFFFF CALL 0040106C 004010B6 50 PUSH EAX 004010B7 50 PUSH EAX 004010B8 FF35 63E97500 PUSH DWORD PTR [0x75E963] 004010BE E8 63CB3500 CALL 0075DC26 ; JMP to OFFSET Cc3250mt.___CRTL_TLS_SetValue 004010C3 FF35 63E97500 PUSH DWORD PTR [0x75E963] 004010C9 E8 52CB3500 CALL 0075DC20 ; JMP to OFFSET Cc3250mt.___CRTL_TLS_InitThread 004010CE 5F POP EDI 004010CF C3 RETN 004010D0 B9 9C000000 MOV ECX, 0x9C 004010D5 0BC9 OR ECX, ECX 004010D7 74 19 JE SHORT 004010F2 004010D9 E8 2ACB3500 CALL 0075DC08 ; JMP to OFFSET Cc3250mt.___CRTL_TLS_Alloc 004010DE A3 63E97500 MOV [0x75E963], EAX 004010E3 83F8 00 CMP EAX, 0x0 004010E6 73 91 JNB SHORT 00401079 004010E8 B8 FC000000 MOV EAX, 0xFC 004010ED E8 7AFFFFFF CALL 0040106C 004010F2 C3 RETN 004010F3 833D 63E97500 00 CMP DWORD PTR [0x75E963], 0x0 004010FA 72 28 JB SHORT 00401124 004010FC FF35 63E97500 PUSH DWORD PTR [0x75E963] 00401102 E8 13CB3500 CALL 0075DC1A ; JMP to OFFSET Cc3250mt.___CRTL_TLS_GetValue 00401107 0BC0 OR EAX, EAX 00401109 74 19 JE SHORT 00401124 0040110B 50 PUSH EAX 0040110C 6A 08 PUSH 0x8 0040110E E8 9FC23500 CALL 0075D3B2 ; JMP to kernel32.GetProcessHeap 00401113 50 PUSH EAX 00401114 E8 E7C23500 CALL 0075D400 ; JMP to ntdll.RtlFreeHeap 00401119 FF35 63E97500 PUSH DWORD PTR [0x75E963] 0040111F E8 EACA3500 CALL 0075DC0E ; JMP to OFFSET Cc3250mt.___CRTL_TLS_ExitThread 00401124 C3 RETN 00401125 C3 RETN 00401126 833D 63E97500 00 CMP DWORD PTR [0x75E963], 0x0 0040112D 72 10 JB SHORT 0040113F 0040112F E8 BFFFFFFF CALL 004010F3 00401134 FF35 63E97500 PUSH DWORD PTR [0x75E963] 0040113A E8 D5CA3500 CALL 0075DC14 ; JMP to OFFSET Cc3250mt.___CRTL_TLS_Free 0040113F C3 RETN 00401140 A1 63E97500 MOV EAX, [0x75E963] 00401145 64:67:8B16 2C00 MOV EDX, FS:[0x2C] 0040114B 8B0482 MOV EAX, [EDX+EAX*4] 0040114E C3 RETN[/FONT] 注意头部的TAG:"fb:C++HOOK",为Borland C++ 1999的签名。 阻止Themida的API保护后,导入函数被“还原”,否则没法看懂程序: [FONT="Courier"]Target ====== "C:\徽商期货博易大师交易版\pobo5\system\pobo.exe" CodeBase: 00401000 CodeSize: 004E3000 Align: ED060014 Shadow kernel32.dll at: 012E0000 Encrypted Imports at: 00C20F31 Imported Libraries: 40000000 Vcl50 402F0000 Vclx50 50800000 bcbie50 41000000 Borlndmm 77DA0000 advapi32 7C800000 kernel32 77BD0000 version 71A40000 wsock32 77180000 comctl32 76320000 comdlg32 77EF0000 gdi32 7D590000 shell32 77D10000 user32 76B10000 winmm 76990000 ole32 770F0000 oleaut32 32500000 Cc3250mt 03000000 dbghelp 10000000 PBMsgBox 762F0000 msimg32 0075BDB4 FF25 70058C00 JMP NEAR [0x8C0570] ; Vcl50.@System@initialization$qqrv 0075BDBA FF25 74058C00 JMP NEAR [0x8C0574] ; Vcl50.@System@Finalization$qqrv 0075BDC0 FF25 78058C00 JMP NEAR [0x8C0578] ; Vcl50.@System@LoadResString$qqrp20System@TResStringRec 0075BDC6 FF25 7C058C00 JMP NEAR [0x8C057C] ; Vcl50.@System@UnregisterModule$qqrp17System@TLibModule ... 0075D2B0 FF25 A8218C00 JMP NEAR [0x8C21A8] ; advapi32.AdjustTokenPrivileges 0075D2B6 FF25 AC218C00 JMP NEAR [0x8C21AC] ; advapi32.LookupPrivilegeValueA 0075D2BC FF25 B0218C00 JMP NEAR [0x8C21B0] ; advapi32.OpenProcessToken 0075D2C2 FF25 B4218C00 JMP NEAR [0x8C21B4] ; advapi32.RegCloseKey 0075D2C8 FF25 B8218C00 JMP NEAR [0x8C21B8] ; advapi32.RegOpenKeyExA 0075D2CE FF25 BC218C00 JMP NEAR [0x8C21BC] ; advapi32.RegQueryValueExA 0075D2D4 FF25 50238C00 JMP NEAR [0x8C2350] ; kernel32.Beep 0075D2DA FF25 54238C00 JMP NEAR [0x8C2354] ; kernel32.CloseHandle 0075D2E0 FF25 58238C00 JMP NEAR [0x8C2358] ; kernel32.CopyFileA 0075D2E6 FF25 5C238C00 JMP NEAR [0x8C235C] ; kernel32.CreateDirectoryA 0075D2EC FF25 60238C00 JMP NEAR [0x8C2360] ; kernel32.CreateFileA 0075D2F2 FF25 64238C00 JMP NEAR [0x8C2364] ; kernel32.CreateFileMappingA 0075D2F8 FF25 68238C00 JMP NEAR [0x8C2368] ; kernel32.CreateProcessA 0075D2FE FF25 6C238C00 JMP NEAR [0x8C236C] ; kernel32.CreateThread 0075D304 FF25 70238C00 JMP NEAR [0x8C2370] ; ntdll.RtlDeleteCriticalSection 0075D30A FF25 74238C00 JMP NEAR [0x8C2374] ; kernel32.DeleteFileA 0075D310 FF25 78238C00 JMP NEAR [0x8C2378] ; ntdll.RtlEnterCriticalSection 0075D316 FF25 7C238C00 JMP NEAR [0x8C237C] ; kernel32.FileTimeToLocalFileTime 0075D31C FF25 80238C00 JMP NEAR [0x8C2380] ; kernel32.FileTimeToSystemTime 0075D322 FF25 84238C00 JMP NEAR [0x8C2384] ; kernel32.FindClose 0075D328 FF25 88238C00 JMP NEAR [0x8C2388] ; kernel32.FindFirstFileA 0075D32E FF25 8C238C00 JMP NEAR [0x8C238C] ; kernel32.FindNextFileA 0075D334 FF25 90238C00 JMP NEAR [0x8C2390] ; kernel32.FreeLibrary 0075D33A FF25 94238C00 JMP NEAR [0x8C2394] ; kernel32.GetACP 0075D340 FF25 98238C00 JMP NEAR [0x8C2398] ; kernel32.GetCommandLineA 0075D346 FF25 9C238C00 JMP NEAR [0x8C239C] ; kernel32.GetCurrentDirectoryA 0075D34C FF25 A0238C00 JMP NEAR [0x8C23A0] ; kernel32.GetCurrentProcess 0075D352 FF25 A4238C00 JMP NEAR [0x8C23A4] ; kernel32.GetCurrentProcessId 0075D358 FF25 A8238C00 JMP NEAR [0x8C23A8] ; kernel32.GetCurrentThreadId 0075D35E FF25 AC238C00 JMP NEAR [0x8C23AC] ; kernel32.GetDiskFreeSpaceA 0075D364 FF25 B0238C00 JMP NEAR [0x8C23B0] ; kernel32.GetExitCodeThread 0075D36A FF25 B4238C00 JMP NEAR [0x8C23B4] ; kernel32.GetFileSize 0075D370 FF25 B8238C00 JMP NEAR [0x8C23B8] ; kernel32.GetFileTime 0075D376 FF25 BC238C00 JMP NEAR [0x8C23BC] ; kernel32.GetFullPathNameA 0075D37C FF25 C0238C00 JMP NEAR [0x8C23C0] ; ntdll.RtlGetLastWin32Error 0075D382 FF25 C4238C00 JMP NEAR [0x8C23C4] ; kernel32.GetLocalTime 0075D388 FF25 C8238C00 JMP NEAR [0x8C23C8] ; kernel32.GetModuleFileNameA 0075D38E FF25 CC238C00 JMP NEAR [0x8C23CC] ; kernel32.GetModuleHandleA 0075D394 FF25 D0238C00 JMP NEAR [0x8C23D0] ; kernel32.GetPrivateProfileIntA 0075D39A FF25 D4238C00 JMP NEAR [0x8C23D4] ; kernel32.GetPrivateProfileSectionA 0075D3A0 FF25 D8238C00 JMP NEAR [0x8C23D8] ; kernel32.GetPrivateProfileSectionNamesA 0075D3A6 FF25 DC238C00 JMP NEAR [0x8C23DC] ; kernel32.GetPrivateProfileStringA 0075D3AC FF25 E0238C00 JMP NEAR [0x8C23E0] ; kernel32.GetProcAddress 0075D3B2 FF25 E4238C00 JMP NEAR [0x8C23E4] ; kernel32.GetProcessHeap 0075D3B8 FF25 E8238C00 JMP NEAR [0x8C23E8] ; kernel32.GetSystemInfo 0075D3BE FF25 EC238C00 JMP NEAR [0x8C23EC] ; kernel32.GetSystemTime ... 0075DE6C FF25 90318C00 JMP NEAR [0x8C3190] ; Cc3250mt._vsnprintf 0075DE72 FF25 94318C00 JMP NEAR [0x8C3194] ; Cc3250mt._wcscpy 0075DE78 FF25 A4318C00 JMP NEAR [0x8C31A4] ; dbghelp.MiniDumpWriteDump 0075DE7E CC INT3 0075DE7F CC INT3 0075DE80 FF25 B8318C00 JMP NEAR [0x8C31B8] ; PBMsgBox.PBMsgBoxEx_Initialize 0075DE86 FF25 BC318C00 JMP NEAR [0x8C31BC] ; PBMsgBox.PBMsgBoxEx_MessageBox 0075DE8C FF25 CC318C00 JMP NEAR [0x8C31CC] ; msimg32.AlphaBlend 0075DE92 CC INT3 0075DE93 CC INT3 ... 008C2E68 325012B0 OFFSET Cc3250mt.@$bdele$qpv 008C2E6C 325012C0 OFFSET Cc3250mt.@$bdla$qpv 008C2E70 325012E4 OFFSET Cc3250mt.@$bnew$qui ... 008C318C 325800CC OFFSET Cc3250mt._time 008C3190 32565A30 OFFSET Cc3250mt._vsnprintf 008C3194 32550A4C OFFSET Cc3250mt._wcscpy 008C3198 00000000 008C319C 00000000 008C31A0 5D424E5A 008C31A4 0305C560 dbghelp.MiniDumpWriteDump 008C31A8 00000000 008C31AC 00000000 008C31B0 00000000 008C31B4 381FE9D5 008C31B8 10009F30 PBMsgBox.PBMsgBoxEx_Initialize 008C31BC 1000A0B0 PBMsgBox.PBMsgBoxEx_MessageBox 008C31C0 00000000 008C31C4 00000000 008C31C8 5D5483C5 008C31CC 762F119B msimg32.AlphaBlend 008C31D0 00000000 008C31D4 00000000[/FONT] 不懂Borland的VCL,所以就帮不上了。 |
|
[求助]关于VMP的pacth hash的问题
VMProtect的校验有四部分。 1. 文件校验(File Check) 有个表,通常这个表只有4条记录。每个记录的字段依次为:校验的文件偏移Offset、校验的长度Length及校验和Hash。 这3个字段都是加密的,算法被V了,需要读懂反虚拟化的代码才能找出各自的算法。 对这个表本身没有校验。 通过APIs:CreateFile, CreateFileMapping, MapViewOfFile来定位校验的位置。 2. 内存校验(Memory Check #1) 这个与文件校验基本相同,当前被载入模块(Exe或Dll)的内存映像作为校验内容,所以各记录的第一个字段为加密的RVA。 各VMP版本,表的长度不同。若加密的RVA解密后为-0x1,则校验表结束,其它为垃圾表项。 这个表本身是有校验的,Hash保存在壳段的某个地方,可以改。 另外,校验发生在目标原来的各区段解密、解压缩之前,所以本质上仍然是“文件校验”。 3. 内存校验(Memory Check #2) 表结构与上面一样,但校验发生在目标解密、解压缩之后,这是真正意义上的内存校验。 即表项的内容用于校验壳代码和用户代码、数据。 这个表比第一个内存校验要大很多,同样以解密后的RVA为-0x1表示表结束。 最关键的是,表本身的校验Hash是Handler压栈的一个IMM32,没法直接修改。所以最简单的办法就是Patch一下GetHash Handler。 上面三种校验构成了VMProtect的一个SDK函数:VMProtectIsValidImageCRC。 即壳代码部分会隐式调用VMProtectIsValidImageCRC()来进行目标的完整性检查。 这部分很多人都知道,也讨论得比较多。 4. 随机内存校验(Random Memory Check) 这个对应于VMProtect的一个功能“VM Integrity Check”。 校验表与上面的不同:第一字段仍然为加密的RVA,第二字段为未加密的一字节长度,第三字段为Hash的NEG。 表项个数不定,由vPushImm2压栈。表本身没有校验。 这个校验发生在用户代码中被虚拟化的函数或代码片段里,每次用vRdtsc“随机”取一条记录来进行校验。主要用来保护用户的代码和数据。 校验未通过的话,不会报错,目标直接崩溃。好象以前只有SE的作者提到过这个校验。 更详细的讨论和具体例子可参阅我在t4y的回复。 [InlineMe] VMProtect IsValidImageCRC() 和 [DevirtualizeMe] VMProtect 2.13.5 祝各位春节快乐! |
|
|
|
平安夜幸福快乐!
祝各位圣诞节快乐! |
|
[讨论]RSA512大数分解速度GGNFS
谢谢 FLYZHU 回覆,感谢 readyu 提供。 |
操作理由
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 }}
勋章
兑换勋章
证书
证书查询 >
能力值