|
|
|
|
|
最近国外破解组有了一个新的变化。
曾经处过一个软件AIPH,能对部分aspr1.2以前版本加壳软件直接静态patch |
|
关于VB中数据的存储格式和寻址方式 菜鸟献丑了~~~
关于数据“80”,跟踪到一点代码,对80进行一些校验 以下来自msvbvm60.dll 6.0.8964版本 ENGINE:6610ABCE public __vbaVarTstEq ENGINE:6610ABCE __vbaVarTstEq: ENGINE:6610ABCE push dword ptr [esp+8] ENGINE:6610ABD2 push dword ptr [esp+8] ENGINE:6610ABD6 push 0 ENGINE:6610ABD8 call sub_66100017 // enter ENGINE:66100017 push ebp ENGINE:66100018 mov ebp, esp ENGINE:6610001A sub esp, 38h ENGINE:6610001D mov edx, [ebp+arg_8] ENGINE:66100020 mov ecx, [ebp+arg_4] ENGINE:66100023 push ebx ENGINE:66100024 push esi ENGINE:66100025 mov si, [ecx] ENGINE:66100028 push edi ENGINE:66100029 mov di, [edx] ENGINE:6610002C mov eax, 7FFFh ENGINE:66100031 and edi, eax ENGINE:66100033 and esi, eax // esi=8002H, eax=7FFFH ENGINE:66100035 cmp di, 9 ENGINE:66100039 jz loc_66107812 ENGINE:6610003F cmp si, 9 ENGINE:66100043 jz loc_66107812 |
|
关于VB中数据的存储格式和寻址方式 菜鸟献丑了~~~
多谢RoBa文章对此的研究。我因此也看了一下。 用oleview查看msvbvm60.dll,可以看到这样定义 typedef [uuid(ED822010-6D7F-11CF-B949-00AA004455EA), helpcontext(0x0010fe25)] enum { vbEmpty = 0, vbNull = 1, vbInteger = 2, vbLong = 3, vbSingle = 4, vbDouble = 5, vbCurrency = 6, vbDate = 7, vbString = 8, vbObject = 9, vbError = 10, vbBoolean = 11, vbVariant = 12, vbDataObject = 13, vbDecimal = 14, vbByte = 17, vbUserDefinedType = 36, vbArray = 8192 } VbVarType; 上述这些应该是vb数据类型的十进制索引值 Variant变量的第一个字节表示数据的实际类型,后面七个字节不知有什么用,在第九个字节处才是数据的值或数据的地址。 关于“中间的7个字节”,我这样认为 +00 数据类型索引值 01 00或80:00401D1F C78574FFFFFF02800000 mov dword ptr [ebp FFFFFF74], 00008002 ;类型值注意这句,80由此赋值 03 "00" 04 "00", 03、04位置应该都是00,这或许是编译器为了数据对齐而自动生成的 05 -- 08 这里我想是无关数据 |
|
如何破解隐藏在DLL中的注册码,向各位高手请教
基于COM结构的组件,可以通过调用其接口来执行其功能代码 我想asp调用的vb activex dll,也可以由vb程序调用。你可以尝试vb编程来调用,跟踪 |
|
|
|
问一个vb6库的函数,很困惑啊/
Mid(string, start, lenght)函数在汇编中表示如下 push [length] push start push [string] push [Result] call rtcMidCharVar 需要注意的是,push [string]中string实际存放地址位于dword ptr [string+8]处 |
|
请教fly大侠,关于ESP定律的问题~!
转一篇文章,关于win9x下程序启动时各寄存器分析 Win95 structures and secrets by Murkry/IkX Since the start of Win95 many things that virii writers came to accept as easy to get, became harder. Things like the interrupt calls, filename paths to the system files. Well the API calls have replaced interrupts and virii writers have used several tricks to get the address to these calls. As for filename or path to system files, we have hard coded possible ones and also used the API's (of course this added a bit to our code). Of course back in the DOS days if we search the PSP we could find much of this info without relying on API calls. Well as many readers of Windows95 System Programming Secrets are aware there are several tables (or K32 objects) that are available for us but finding these tables requires API (or at least in the book they do). Well as you may have guessed by now the pointers to these tables are readily avaiable. In win95, A and B version as well as some of the earlier version the Registers seem to startup with similiar info. Be warned that this info does not apply to WinNT in the release of Win98 I saw it was true though. (Side note, nice check for win95 to win nt is eax != eip then your probably not in 95 or something was playing with the registers b4 you got them. Hmm make sure your viruses restore all regs or some smart programmers may actually write some self aware programs that check this ;) Anyway all 95 versions I have checked Regs start out with EAX = EIP of startup EBX = ??? ECX = K32OBJ_MUTEX appears EDX = K32OBJ_CRITICAL_SECTION appears ESI = K32OBJ_PROCESS EDI = K32OBJ_THREAD EBP = ESP = Strange info see below Ok b4 all you experts yell (wait,, experts?? hell you write this): EAX is basicaly a fact Ebx 00530000 or similiar number never points to a in processs address though ECX This is a Guess but it seems to point to a table and starts with 03 Read the Book to understand why 03 means something ESI points to a table that starts with 05 and I have used this table to get to the enviroment database which wonders of wonders has things like Full path and file name of executing file Paths and command line Startupinfo. Again reading the book will explain all or if you have access to the ddk you can verify this as I have done. EDI Table starts up with 06 and has all sorts of info in it EBP somewhere I have notes on what this points at, but I can't locate it I think MarkJ may have eaten it when I last babysat for him ;) ESP strange but if you look at a start up there are some very intersting numbers that always show up. now this varies depending on lenght of name, but again we find pointers to locations that when examine are tables or pointers to entries in the tables as well as SEH pointers: +10 = File name of file being excuted format is strange 'Host1',0,'EXE',0 whether or not you enter the extension or not it will be caps and the name will be caps first letter lowercase rest +c = ebp = Dammit what is this number +8 = esi = obj_process database +4 = edi = obj_thread database EsP +0 = pnter into location in Kernel32 What does this mean to us virii/hackers of win95 lets say we want to write a virus that adds info to the end of the host but does not modify the host PE header so while the info is there it is not loaded into memory. (A new LE\Macro infector works like this) Step one we need the file name well check out the code below which will show a MessageBox with the file name in quotes when ran normaly but will show the file name without quotes if in td32 and I assume other debuggers (probaly not SI though) Be warn about this feature since this means if you are running a debugger to test it will work diffrently ie if you used this pointer to try and open the file it will fail since file "c:\filepath\foo.exe" is the file you will try to open not c:\filepath\foo.exe. NOTE this is one way to get the info i could just use esi rather than get the info off the stack mov edi,[esp +8] ; Get the Pointer to process Database mov edi,[edi+040h] ; Within DataBase get pointer to the Enviroment ; DataBase mov edi,[edi+8] ; In Enviroment DataBase get the Pnter to ; Command line call MessageBoxA,large 0,edi, offset tile,large 1 now there are a lot of other info avaiable in the other Database but the Enviroment Table is structured as: Offset 00h Ptr to the enviroment string as you scan through the table you find =C:=C:\tasm\virii\over TEMP=C:\WINDOWS\TEMP PROMPT=$p$g winbootdir=C:\WINDOWS COMSPEC=C:\WINDOWS\COMMAND.COM PATH=C:\BTI\WIN\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UTIL; TMP=C:\WINDOWS\TEMP windir=C:\WINDOWS CMDLINE=td32 host1 * While the ; is used in the path all other items are delimited by 00h 04h unknown Zero as far as I have seen 0Ch pntr to str Current directory note when in td32 C:\TASM\VIRII\OVER\HOST1.EXE Normal "C:\TASM\VIRII\OVER\HOST1.EXE" 10h ptr to a copy of StartupInfo There are other entries but these are the ones I am showing for now since they are the ones I view as nice to have for virii related, See the book or DDK for more info. As you can see the Enviroment database is as useful as the old dos psp oh btw there is still a PSP see Process Database offset 24h of course its the linear address, But exploring info that the stack has to offer is fun as well and as for the infamous FS:[0] seh area this is called (in the book) Thread Information Block TIB point at by edi starting at offset 10h in that database. Strangely this same info is also in the thread database 00 dd pointer to existing Exception handler (see 29A#2 for more info) 04 dd top of stack 08 dd stack low 0ch dw w16tdb 0eh dw StackSelector 16 byte 10h dd Selman list 14h dd User Pointer user accessable ??? 18h dd pnter TIB (book says) to me points to ESI obj process database 1ch dw tibflags 1eh dw win16MutexCount 20h dd DebugContext 24h dd pntr Current Priority 28h dd Message Queue 2ch dd pntr TLS Array Get this grab the top of stack now sub 4 get 0 8 a pnter inside some location in Kernel32 c ? 10 0 14 looks like a copy of the PE header and a NE header of some sort this entry may be important?? not sure Again don't bet the house on this info, while the tables are documented I am sure a number of my fellow PE 32 bit virii friends will point out "Its not documented" when refering to my method od using esi or stack refrence to get the Process database location. I suspect in Win95\98 stays around long enough these items will be documented as people use them more and more. Of course just use the SEH method to protect your code and then feel free to try these ideas out if they SEH catches it then you can exit gracefully. |
|
请大家帮忙解决一个问题啊,我不懂
qq对用户密码是进行md5等单向计算后保存的,它服务器也只是保存密码的hash值而不是用户密码,所以除非事先在计算机中潜伏着“击键记录器”,否则不可能得到用户密码 |
|
我想找一些关于内存映像校验方面的资料
一般内存镜像校验重要用到几个函数 1.createfilea打开需要校验的文件 2.createfilemapping,mapviewoffile创建内存镜像 3.退出用unmapviewoffilemapping 你说只有修改代码段会导致退出,我想除了上面的方法,我还能这样实现 1.对内存镜像代码锁定 2.实现SEH,在内存代码被修改时发生内存读写错误,被seh捕获而退出 |
|
|
|
一个用vb写的程序,研究一下吧
难得见到bf又出现了,呵呵 对于vb的一点理解,使我不认同bf老大的看法 0041DAEF . PUSH ECX 0041DAF0 . PUSH ESI 0041DAF1 . CALL DWORD PTR DS:[EAX+58] 0041DAF4 . FCLEX 0041DAF6 . TEST EAX,EAX 0041DAF8 . JGE SHORT notepadx.0041DB09 0041DAFA . PUSH 58 0041DAFC . PUSH notepadx.004077B8 0041DB01 . PUSH ESI 0041DB02 . PUSH EAX 0041DB03 . CALL MSVBVM60.__vbaHresultCheckObj 0041DB09 > XOR EDX,EDX 以上这段代码实际说得意思,我想是:对某个控件的属性进行操作 这样猜测的理由基于2点 1.注意到0041DB03 . CALL MSVBVM60.__vbaHresultCheckObj,这个vb vm内部函数出现总是意味着前面对某个控件进行操作后的控件校验 2.我的印象中,vb一般不用call相对地址进行功能函数计算,CALL DWORD PTR DS:[EAX+58]更多表示控件的属性,例如x=text1.text就是表示为CALL DWORD PTR DS:[EAX+A0] |
操作理由
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 }}
勋章
兑换勋章
证书
证书查询 >
能力值