-
If you find a fix for a bug, please feel free to submit a pull request and I'll review it. Also note that there are binaries posted on the releases section of the github repository, so you don't NEED to build it yourself.
-
Member
Originally Posted by
namreeb
If you find a fix for a bug, please feel free to submit a pull request and I'll review it. Also note that there are binaries posted on the releases section of the github repository, so you don't NEED to build it yourself.
Hello. Can you help? In release build have error.
"Failed to find LdrpCallTlsInitializers"
-
Originally Posted by
SilentGamzee
Hello. Can you help? In release build have error.
"Failed to find LdrpCallTlsInitializers"
What version of the game are you trying to make a dump of?
-
Member
Originally Posted by
namreeb
What version of the game are you trying to make a dump of?
9.0.2.37474
-
Contributor
Did you read the title of this thread by chance? The part that says [Classic]....
-
Post Thanks / Like - 1 Thanks
SilentGamzee (1 members gave Thanks to aeo for this useful post)
-
Member
Originally Posted by
aeo
Did you read the title of this thread by chance? The part that says [Classic]....
F. Thanks man. But my error appeared before injection or something. The program simply does not find the function by patterns in ntdll.dll.
-
Member
I used this to dump 1.13.6.37497. It seems to have worked well. I get a WowClassic_unpacked.exe. It can load into IDA, and it looks good. e.g., its easy to locate FrameScript_Register, etc.
I get these messages when the tool runs.
Bad thunk ea RVA: 0x1ee4010 thunk_ea: 0x80000143055555
Bad thunk ea RVA: 0x1ee4018 thunk_ea: 0x4385555500000002
Bad thunk ea RVA: 0x1ee4028 thunk_ea: 0x10000344055555
Bad thunk ea RVA: 0x1ee4030 thunk_ea: 0x4505555500000010
Bad thunk ea RVA: 0x1ee4180 thunk_ea: 0x6e6569726f736944
Bad thunk ea RVA: 0x1ee4188 thunk_ea: 0x6173694400000074
Bad thunk ea RVA: 0x1ee4198 thunk_ea: 0x7463617274736944
Bad thunk ea RVA: 0x1ee41a0 thunk_ea: 0x7261654600000000
Is it safe to ignore these messages?
Thanks for the great tool!
-
Originally Posted by
SilentGamzee
F. Thanks man. But my error appeared before injection or something. The program simply does not find the function by patterns in ntdll.dll.
My guess is that the pattern for finding that function isn't valid for your version of Windows. What version are you using?
Originally Posted by
thateuler
Is it safe to ignore these messages?
Yes.
-
Established Member
Great work!!! You inspired me.
Why not do it all in IDA Python? Using C++ introduces too much complexity.
-
Contributor
Originally Posted by
SilentGamzee
Hello. Can you help? In release build have error.
"Failed to find LdrpCallTlsInitializers"
Most likely you using Windows 7, dumper does not work on this OS, use Win10.
Last edited by Mr.Sergey; 03-19-2021 at 05:33 AM.
-
Member
Originally Posted by
oiramario
Great work!!! You inspired me.
Why not do it all in IDA Python? Using C++ introduces too much complexity.
I think that the main strategy of this unpacker is to start wow, let it unpack itself, and save enough information (pe header?) to reconstruct a new unpacked exe. To do it in ida_python, one would need to reimplement the unpacking code in idapython.
Reading through the code, here's my clumbsy attempt to understand how it works.
The main program does the following:
- launch wow. but suspended
- disable tls callbacks (prevents dll injection or they clobber the PE header?)
- inject a dll
- call the dll's Initialize function. it is probably called inside the wow processes address space.
- restore the tls callbacks
- resume the thread
- wait for the wow process to exit
The dll does the following
- hook some stuff
- CallTLSCallbacks
- to pass DLL_PROCESS_ATTACH rather then DLL_THREAD_ATTACH (i wonder why) - BaseThreadInitThunk
- the main call to dump out the process memory is here "do_dump".
- probably this hook gets called when wow has finished unpacking and is about to call its entry_point. - SetInformationThread
- to prevent enabling ThreadHideFromDebugger
- this suggests that some of the dumping code uses debugger features??? some of the code in concolic.cpp appears to be tracking the instruction pointer.
- the program flow is managed through these hooks.
- when wow is ready to start, the hook catches it and dumps out the processes to file.
- i'm not that confident about exactly when the dumping starts.
Some comments.
- That HadesMem library seems to be very powerful. e.g., PatchDetour, DLL Injection, rpc (hadesmem::Call).
- I've dumped wow running under wine, with gdb. When trying to load it into IDA, IDA complains that its an Itanium binary. My guess is that this part of the pe clobbering that wow does. EDIT: This appears to be specific to linux/wine, and not part of any pe obfuscation.
- i should send a pull request to rename "conclic_begin" to "concolic_begin". haha. (kidding) then i can brag that i'm a contributor to the project.
Last edited by thateuler; 04-07-2021 at 02:27 PM.
-
★ Elder ★
Originally Posted by
thateuler
[*] I've dumped wow running under wine, with gdb. When trying to load it into IDA, IDA complains that its an Itanium binary. My guess is that this part of the pe clobbering that wow does.[/LIST]
You can dump wow straight from memory. the PE header is just fine there. NO issues. Only the imports wont be resolved
-
Member
Originally Posted by
king48488
the PE header is just fine there. NO issues.
Must be specific to linux/wine then.
Code:
remapped segments
140000000-1422b0000 r-xs 00000000 08:03 22282396 /tmp/.wine-1000/server-803-8114b/anonmap.GwROnb (deleted)
1422b0000-142a40000 rwxs 022b0000 08:03 22282396 /tmp/.wine-1000/server-803-8114b/anonmap.GwROnb (deleted)
142a40000-142c68000 r-xs 02a40000 08:03 22282396 /tmp/.wine-1000/server-803-8114b/anonmap.GwROnb (deleted)
use gdb to dump.
(gdb) dump memory wow.exe 0x140000000 0x1422b0000
$ od -x wow.exe | head -22
0000000 5a4d 0090 0003 0000 0004 0000 ffff 0000
0000020 00b8 0000 0000 0000 0040 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0158 0000
0000100 1f0e 0eba b400 cd09 b821 4c01 21cd 6854
0000120 7369 7020 6f72 7267 6d61 6320 6e61 6f6e
0000140 2074 6562 7220 6e75 6920 206e 4f44 2053
0000160 6f6d 6564 0d2e 0a0d 0024 0000 0000 0000
0000200 3001 1932 5145 4a5c 5145 4a5c 5145 4a5c
0000220 3336 4b58 516f 4a5c 3336 4b5f 5167 4a5c
0000240 3336 4b59 5197 4a5c 3917 4b5f 515e 4a5c
0000260 3917 4b58 5161 4a5c 38df 4b58 500e 4a5c
0000300 3336 4b5a 5146 4a5c f1db 4a9b 5142 4a5c
0000320 294c 4ad8 5144 4a5c 9762 4a31 5144 4a5c
0000340 294c 4adf 514f 4a5c 35a3 4b58 5177 4a5c
0000360 5145 4a5c 514f 4a5c 3917 4b59 517e 4a5c
0000400 3336 4b5d 5166 4a5c 5145 4a5d 537a 4a5c
0000420 38df 4b59 5a28 4a5c 38df 4b5f 5144 4a5c
0000440 38df 4b5c 5144 4a5c 38df 4aa3 5144 4a5c
0000460 5145 4acb 5147 4a5c 38df 4b5e 5144 4a5c
0000500 6952 6863 5145 4a5c 0000 0000 0000 0000
0000520 0000 0000 0000 0000 4550 0000 0200 0008
- MZ header at 0x00 (5a4d)
- NT sig at 0x530 (0x00004550)
- machine type at 0x538 (0x200) <-- IA64
ida also identifies it as IA64. If I use a hex editor to change to 8664, then ida can load it. seems strange i know.
-
Member
-
Member
Originally Posted by
0xd5d
but it doesn't when using Ghidra.
I'm no java expert. but if you want to just get it working, try changing line 94 here
ghidra/TLSDataDirectory.java at Ghidra_10.1.2_build . NationalSecurityAgency/ghidra . GitHub
to this
Code:
if (nextCallbackAddr == null || nextCallbackAddr.getOffset() == 0) {
The code for getAddressValue clearly returns null in some cases.
ghidra/PointerDataType.java at Ghidra_10.1.2_build . NationalSecurityAgency/ghidra . GitHub
namreeb's code is still very much out of my league. It does something with TLS callbacks here: dumpwow/dumper.cpp at 0.3 . namreeb/dumpwow . GitHub
Last edited by thateuler; 04-17-2022 at 11:27 AM.