出现了个问题，游戏进去就这样。runtime error。求解决。_穿越火线吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：6,045,138贴子：
MH4G正版卡 没用过烧录...
又该如何解决？
中间一直有个红点 怎么...
2017年在职研究生有没有取消，具体的政策有什么变化
TGP游戏修复了也不行
我也是 这样
手动置顶，求解决方法。
把它移到最下面…
2017年在职研究生专科报考条件、本科报考条件
我也是，求科普
我卸载了重新下一个
特么的 我也是的
TGP修复后也不行
同，我现在卸载了，从新下一个试试。　　　--我随手一打就是标准的十五个字啊！！
我也刚出现，什么情况
游戏重装，不行系统重装，一定有用
不管他，我也是，一样玩
哈哈，看来都是这个点出的问题
我也有过这种情况
不要用tgp启动，直接启动游戏就行
很多人都是这个情况
贴吧热议榜
使用签名档&&
保存至快速回贴下载作业帮安装包
扫二维码下载作业帮
1.75亿学生的选择
弹出runtime error 32 at 00405cf6怎么处理
血刺_迷离394
为您推荐：
扫描下载二维码调试逆向 dll脱壳后主程序加载出现Runtime error!怎么修复啊？ [文字模式]
- 看雪安全论坛
查看完整版本 : 调试逆向
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
/2870219.html
软件脱壳后运行错误软件在这里下载，请高手看看怎么解决，谢谢。
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
是什么原因导致的啊？
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
怎么解决啊？
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
dll重定位了好多次，老样子啊？
kanxue用关键字Runtime 搜索论坛
/custom?domains=%&q=runtime&sa=Google%E6%90%9C%E7%B4%A2%E6%9C%AC%E8%AE%BA%E5%9D%9B&sitesearch=&client=pub-1261&forid=1&channel=&ie=UTF-8&oe=UTF-8&cof=GALT%3A%BGL%3A1%3BDIV%3A%BVLC%3ABAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3ABALC%3A0000FF%3BLC%3A0000FF%3BT%3ABGFNT%3A0000FF%3BGIMP%3A0000FF%3BLH%3A42%3BLW%3A100%3BL%3Ahttp%3A%2F%%2Fimages%2Fpediy_style%2Fmisc%2Fpediylogo.gif%3BS%3Ahttp%3A%2F%%3BLP%3A1%3BFORID%3A1&hl=zh_CN
你参考一下：
/showthread.php?t=81974
/showthread.php?t=69099
Anplando谢谢看雪老大，找到一篇
【原创】浅谈程序脱壳后的优化
作 者: CCDebuger
/showthread.php?t=28402
我试试看行不行。
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
重建原始区段还那样怎么办啊？
luckxiao我以前脱一个EXE时也出现过这样的问题，并在论坛发帖求助，不知为何，没两天帖子就被删了，汗，对于我的那个EXE的问题，已经完美解决，/54clown/blog/item/8adcbb1eefab5e6bf724e422.html
这里有老外的解释已经解决步骤，希望能帮到你！
Anplando我以前脱一个EXE时也出现过这样的问题，并在论坛发帖求助，不知为何，没两天帖子就被删了，汗，对于我的那个EXE的问题，已经完美解决，/54clown/blog/item/8adcbb1eefab5e6bf724e422.html (&http://hi...
能翻译下吗？
看不太懂，请问你是怎么处理你那个exe的问题的啊？谢谢
sessiondiy发出来看看.
Anplando发出来看看....
老外解释如下：
==============================================================================
See, I felt there was something wrong going on back when I first managed to divert the running dump process to the 'correct' branch at that ntdll routine...
So I cracked open the latest UPX source in order to analyze the entire UPX packing process (would also make good practice, I thought...). Finding that unUPXing and reUPXing the target with the latest version of UPX produced the following UPX alayzing it piece by piece with the source code I came up with this (comments after semicolons):
CODE12E43EC0 &
BE 00B01412
MOV ESI, flt-bio-.
8DBE 00607BFE
LEA EDI, DWORD PTR DS:[ESI+FE7B6000]
JMP SHORT flt-bio-.12E43EDA start long NRV2B decompression...
MOV AL, BYTE PTR DS:[ESI]
MOV BYTE PTR DS:[EDI], AL
MOV EAX, DWORD PTR DS:[EDX]
ADD EDX, 4
MOV DWORD PTR DS:[EDI], EAX
ADD EDI, 4
SUB ECX, 4
JA SHORT flt-bio-.12E43F94
ADD EDI, ECX
^ E9 2CFFFFFF
JMP flt-bio-.12E43ED6 end NRV2B decompression
MOV EDI, ESI
B9 BB9B6600
MOV ECX, 669BBB
start AddFilters32() CALLTR10 cjt
MOV AL, 0E8
REPNE SCAS BYTE PTR ES:[EDI] CALLTR11
JNZ SHORT flt-bio-.12E43FCF
CMP BYTE PTR DS:[EDI], 6D CTCLEVE2
JNZ SHORT flt-bio-.12E43FB4
MOV EAX, DWORD PTR DS:[EDI] CALLTR12
66:C1E8 08
ROL EAX, 10
XCHG AH, AL
SUB EAX, EDI
ADD EAX, ESI
STOS DWORD PTR ES:[EDI]
JMP SHORT flt-bio-.12E43FB2 end AddFilters32()
8DBE 00F05302
LEA EDI, DWORD PTR DS:[ESI+253F000] PEIMPORT // lea
edi, [esi + compressed_imports]
MOV EAX, DWORD PTR DS:[EDI] // next_dll:
OR EAX, EAX
JE SHORT flt-bio-.12E44020
MOV EBX, DWORD PTR DS:[EDI+4] // iat
8D2 LEA EAX, DWORD PTR DS:[EAX+ESI+2550204] ; // lea
eax, [eax + esi + start_of_imports]
ADD EBX, ESI
ADD EDI, 8
FF96 F8035502
CALL DWORD PTR DS:[ESI+25503F8] // call
[esi + LoadLibraryA]
XCHG EAX, EBP
MOV AL, BYTE PTR DS:[EDI] // next_func:
JE SHORT flt-bio-.12E43FD5
MOV ECX, EDI
JNS SHORT flt-bio-.12E44004 PEIBYORD
MOVZX EAX, WORD PTR DS:[EDI] PEIMORD1 // not_kernel32:
B9 5748F2AE
MOV ECX, AEF24857
FF96 FC035502
CALL DWORD PTR DS:[ESI+25503FC] // call
[esi + GetProcAddress]
OR EAX, EAX
JE SHORT flt-bio-.12E4401A
MOV DWORD PTR DS:[EBX], EAX // next_imp:
ADD EBX, 4
JMP SHORT flt-bio-.12E43FF2
FF96 0C045502
CALL DWORD PTR DS:[ESI+255040C] PEIEREXE // imp_failed: call
[esi + ExitProcess]
MOV EBP, DWORD PTR DS:[ESI+2550400] PEIMDONE, PEDEPHAK // mov
ebp, [esi + VirtualProtect]
8DBE 00F0FFFF
LEA EDI, DWORD PTR DS:[ESI-1000]
MOV EBX, 1000
ebx, offset vp_size
// 0x1000 or 0x2000
// provide 4 bytes stack
// &lpflOldProtect on stack
// PAGE_READWRITE
// call VirtualProtect
8D87 B7020000
LEA EAX, DWORD PTR DS:[EDI+2B7] // lea
eax, [edi + swri] // in this case -- lea eax, [0+2B7==]
AND BYTE PTR DS:[EAX], 7F // marks UPX0 non writeable
AND BYTE PTR DS:[EAX+28], 7F // marks UPX1 non writeable
// restore protection
// call VirtualProtect
// pedep9: // restore stack
LEA EAX, DWORD PTR SS:[ESP-80] CLEARSTACK
CMP ESP, EAX
JNZ SHORT flt-bio-.12E44054
SUB ESP, -80
- E9 D3ACF5FD
JMP flt-bio-.10D9ED35 PEMAIN21 // reloc_end_jmp: // PEDOJUMP // jmp
original_entry
Well, the problem I had in the beginning, in redefined form, is this:
PROBLEM: Manually dumping as regular UPX (jump OEP + dump + fix IAT) creates a runtime problem (program quits). (Post factum, this isn't occuring in manually dumped MSVS&8 exes, only MSVC=8 ones. Explanation will follow...)
OK, seeing as unUPXing+reUPXing works, I'm led to believe that the problem lies within either the UPX decompression/DEPHACK/IAT-rebuilding OR a later SecuROM check on sections/header/IAT.
First, a little bit on the DEP(Data Execution Prevention/Protection)HACK (from UPX source p_w32pe.cpp pack() function):
CODE... if (use_dep_hack)
// This works around a &protection& introduced in MSVCRT80, which
// works like this:
// When the compiler detects that it would link in some code from its
// C runtime library which references some data in a read only
// section then it compiles in a runtime check whether that data is
// still in a read only section by looking at the pe header of the
// file. If this check fails the runtime does &interesting& things
// like not running the floating point initialization code - the result
// is an R6002 runtime error.
// These supposed to be read only addresses are covered by the sections
// UPX0 & UPX1 in the compressed files, so we have to patch the PE header
// in the memory. And the page on which the PE header is stored is read
// only so we must make it rw, fix the flags (i.e. clear
// PEFL_WRITE of osection[x].flags), and make it ro again.
// rva of the most significant byte of member &flags& in section &UPX0&
const unsigned swri = pe_offset + sizeof(oh) + sizeof(pe_section_t) - 1;
// make sure we only touch the minimum number of pages
const unsigned addr = 0u - rvamin +
linker-&defineSymbol(&swri&, addr &
// page offset
// check whether osection[0].flags and osection[1].flags
// are on the same page
linker-&defineSymbol(&vp_size&, ((addr & 0xfff) + 0x28 &= 0x1000) ?
0x2000 : 0x1000);
// 2 pages or 1 page
linker-&defineSymbol(&vp_base&, addr &~ 0xfff); // page mask
linker-&defineSymbol(&VirtualProtect&, myimport + get_le32(oimpdlls + 16) + 8);
Ah, the runtime does indeed fail somewhere around MSVCR80 calls in the dump...
Let's see if this works: mark UPX0 & UPX1 as read only access rights at both the header and before the OEP via VirtualProtect... but first let's test a bit...
-- Making progress: Tested DUMP in DEBUGGING ('DUMP'=run to OEP, dump, fix IAT... 'DEBUGGING'=open in Olly, change section header access rights at
and 109002DF to non-write (&=7f), and run.) AND FOUND TO BE WORKING!
Conclusion &&& CULPRIT IS THE MSVC8 DEP HACK!
Now trying to inline patch this in the dump (after the now unused UPX stub) and changing the entry point to it (0254406C raw address):
CODE12E4406C &
patch based on UPX's DEPHACK:
MOV ESI, newdump_.
MOV EBP, DWORD PTR DS:[ESI+2550400] VirtualProtect
8DBE 00F0FFFF
LEA EDI, DWORD PTR DS:[ESI-1000]
MOV EBX, 1000
ebx, offset vp_size
// 0x1000 or 0x2000
// provide 4 bytes stack
// &lpflOldProtect on stack
// PAGE_READWRITE
// call VirtualProtect
8D87 B7020000
LEA EAX, DWORD PTR DS:[EDI+2B7] // lea
eax, [edi + swri] // in this case -- lea eax, [0+2B7==]
AND BYTE PTR DS:[EAX], 7F // marks UPX0 non writeable
AND BYTE PTR DS:[EAX+28], 7F // marks UPX1 non writeable
// restore protection
// call VirtualProtect
// restore stack
- E9 8EACF5FD
JMP newdump_.10D9ED35; jump to OEP
Granted, this patch may be just a tad bit idiotic, but hey, ...
Saving... Running... &&& THE PATCHED DUMP WORKS!
So, this appears to be an MSVC8 (M*cro$oft Visual C++/Visual Studio 2005) related issue for binaries that use MSVCRT80, and this is why it didn't occur in the earlier release I was talking about (the one that managed to unpack regulary) as it was MSVC7 based. Also, this is but one possible way to solve it... Who knows, might come useful in unpacking irregular UPXed MSVC8 targets...
Right, so... what about those 2 MOV inline-patching instructions before the jump to OEP that I had noticed back in the original UPXed exe? Well, about those 2 -- they aren't restored if you take on this using &upx -d& as Human suggested... leaving you without a missing piece in this puzzle... (meaning -- they aren't &already applied to the code& in a &upx -d& unpack (as opposed to the manual unpack), and neither do they remain as patches before the OEP -- they are completely gone.)
I don't know about you, but I definitely learned something from all this.
Thanks again for reading, and thank you for all the help.
==================================================================================
sessiondiy不用假设你的情况是否为别人文章中的情况
dll放到网盘, 大家应会帮你看一下.
Anplando不用假设你的情况是否为别人文章中的情况
dll放到网盘, 大家应会帮你看一下....
dll 在这：，
谢谢了，先说明一下这是个狗软件，狗壳为Anti007 V1.0-V2.X -& NsPacK Private *
软件总大小50MB左右，软件的所有加了狗壳的DLL和主程序都脱掉了壳，现在就是运行出上图错误，应该不需要狗了。
sessiondiy缺少 cdsdk.dll
看来帮不了你了
unpackcn你好像也有发帖
若所有人的建议你都试过无效的话
刚好符合流行的一句话
无文件无真象
luckxiaoCODE12E4406C &
patch based on UPX's DEPHACK:
MOV ESI, newdump_.
MOV EBP, DWORD PTR DS:[ESI+2550400] VirtualProtect
8DBE 00F0FFFF
LEA EDI, DWORD PTR DS:[ESI-1000]
MOV EBX, 1000
ebx, offset vp_size
// 0x1000 or 0x2000
// provide 4 bytes stack
// &lpflOldProtect on stack
// PAGE_READWRITE
// call VirtualProtect
8D87 B7020000
LEA EAX, DWORD PTR DS:[EDI+2B7] // lea
eax, [edi + swri] // in this case -- lea eax, [0+2B7==]
AND BYTE PTR DS:[EAX], 7F // marks UPX0 non writeable
AND BYTE PTR DS:[EAX+28], 7F // marks UPX1 non writeable
// restore protection
// call VirtualProtect
// restore stack
- E9 8EACF5FD
JMP newdump_.10D9ED35; jump to OEP
照着这个 Patch，应该会解决你的问题！
Anplando缺少 cdsdk.dll
看来帮不了你了
unpackcn你好像也有发帖
若所有人的建议你都试过无效的话
刚好符合流行的一句话
无文件无真象...
整个软件正在上传，谢谢你的支持，一定有办法解决的，我相信。
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
/2870219.html
软件脱壳后运行错误在这里下载，请高手看看怎么解决，谢谢。
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
还没搞定，求高手帮忙，谢谢！
Anplando/attachment.php?attachmentid=24466&stc=1&d=
如上图所示，是dll脱壳，修复了重定位，主程序加载出现上图现象，
这应该是那的问题啊，如何修复？
http://...
请高手帮忙，谢谢
sessiondiy那么大, 连下都不想下了.
自己动手丰衣足食.
Anplando那么大, 连下都不想下了.
自己动手丰衣足食.
恩，我很赞同，这个问题我是解决了20多天，没解决成功才来求助高手的。}