OpenRCE

📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Topic created on: March 28, 2007 09:22 CDT by JLeCours .

I am debugging code that is executing before the System startup breakpoint. When I look at Olly's Memory map window, I can identify some of the dlls, but they do not display any of their section names, don't have their "Names" (imports/exports) listed yet, etc. I'm guesssing they've been mapped to memory but not yet "loaded"? As I debug some of the code, I come across to a CALL that I identified as a GetProcAddress call. Whenever I attempt to step over the call, OllyDbg just sits there... displaying "Running" in the corner, but never breaking at the expected instruction. I can step in deeper and deeper, but I end up with the same problem down the line. If I set a breakpoint immediately after the call, and let Olly rip.. it will break on breakpoint and all is well. However, the GetProcAddress call is somehow loading a few other dlls into memory and executing code that I'm trying to find and debug. Why is OllyDbg dying when I try and step over certain calls? Has anyone else ever come across this?

anonymouse		March 28, 2007 09:51.11 CDT
if any calls use WaitForSingle## WaitForMultiple### apis single stepping them with f8 will always run a single thread and the thread that wakes it up isnt active (it is not scheduled something jargon by task scheduler) so ollydbg doesnt break or stop (thats how it works on others debuggers as well afaik) when you run it the system takes over and schedules appropriate time to every thread to perform its duties so it looks like ollydbg froze when you are single stepping

JLeCours		March 28, 2007 09:56.51 CDT
Ah thanks, that makes sense!

anonymouse		March 28, 2007 10:05.05 CDT
well if you see it is showing running you can hit f12 or esc and pause and look at call stack the stack will most probably be in kernel land and the top most frame will consist of a call from KiDispatch, NtWait apis and most probably will be a RETN statement if you then press f7 (real single step ) ollydbg will still show running and be frozen but if you set a break point on next frame and hit f9 ollydbg will break there

JLeCours		March 28, 2007 10:22.22 CDT
Unfortunately, because this is all before the dll's are fully mapped and their import/export names and symbols are loaded properly, the stack is tough to decipher (?maybe I'm wrong?). Call stack of main thread Address Stack Procedure Called from Frame 001359A8 7C90DC61 Includes 7C90EB94 7C90DC5F 00135A9C 001359AC 7C91C3DA 7C90DC55 7C91C3D5 00135A9C 00135AA0 7C916071 ? 7C91C53F 7C91606C 00135A9C 00135D60 7C9162DA ? 7C916329 7C9162D5 00135D5C 00136008 7C801BB9 ? 7C80E069 7C801BB4 00136004 00136070 7C80AE5C ? 7C801AF1 7C80AE57 0013606C 00136084 7CA27284 ? 7C80AE4B 7CA2727E 00136080 001360BC 7C9E7493 ? 7CA2725A 7C9E748E 001360B8 001360C8 7CA2723D ? 7C9E747E 7CA27238 001362FC 7CA271AF ? 7CA271C0 7CA271AA 0013651C 7CA270ED 7CA27175 7CA270E8 00136518 00136530 7CA270AA ? 7CA270BE 7CA270A5 0013652C 00136540 7C9E73AE ? 7C9E7328 7C9E73A9 0013653C Memory Map Memory map Address Size Owner Section Contains Type Access Initial Mapped as 00010000 00002000 Priv RW RW 00020000 00001000 Priv RW RW 00030000 00001000 Priv RW RW 00131000 00001000 Priv RW Guar RW 00132000 0000E000 stack of mai Priv RW Guar RW 00140000 00001000 Priv R E RW 00150000 00001000 Priv RW RW 00160000 00002000 Priv RWE RW 00170000 00003000 Map R R 00180000 00001000 Priv RWE RWE 00190000 0000A000 Priv RW RW 00290000 00006000 Priv RW RW 002A0000 00003000 Map RW RW 002B0000 00016000 Map R R \Device\HarddiskVolume1\WINXP\system32\unicode.nls 002D0000 0003D000 Map R R \Device\HarddiskVolume1\WINXP\system32\locale.nls 00310000 00041000 Map R R \Device\HarddiskVolume1\WINXP\system32\sortkey.nls 00360000 00006000 Map R R \Device\HarddiskVolume1\WINXP\system32\sorttbls.nls 00370000 00008000 Priv RW RW 00380000 00003000 Map R R \Device\HarddiskVolume1\WINXP\system32\ctype.nls 00390000 00001000 Priv RW RW 003A0000 00001000 Priv RW RW 003B0000 00010000 Priv RW RW 003C0000 00001000 Priv RWE RWE 003D0000 00005000 Priv RW RW 003E0000 00001000 Map RW RW 003F0000 00003000 Map RW RW 00400000 00019000 Imag R RWE 00420000 00004000 Map RW RW 0081E000 00002000 Map RW RW 00820000 0000B000 Map R E R E 008E0000 00002000 Map R E R E 008F0000 00103000 Map R R 00A00000 00124000 Map R E R E 00D00000 00008000 Priv RW RW 00E00000 00003000 Priv RW RW 00E45000 000F0000 Map R R 01750000 00002000 Map R R 20000000 001C7000 Imag R RWE 41000000 00027000 Imag R RWE 48000000 0002E000 Imag R RWE 62000000 0009D000 Imag R RWE 71A50000 0003F000 Imag R RWE 71AA0000 00008000 Imag R RWE 71AB0000 00017000 Imag R RWE 77120000 0008C000 Imag R RWE 771B0000 000A6000 Imag R RWE 773D0000 00103000 Imag R RWE 774E0000 0013D000 Imag R RWE 77A80000 00094000 Imag R RWE 77B20000 00012000 Imag R RWE 77C10000 00058000 Imag R RWE 77D40000 00090000 Imag R RWE 77DD0000 0009B000 Imag R RWE 77E70000 00091000 Imag R RWE 77F10000 00047000 Imag R RWE 77F60000 00076000 Imag R RWE 7C800000 000F4000 Imag R RWE 7C900000 000B0000 Imag RW RWE 7C9C0000 00815000 Imag R RWE 7F6F0000 00007000 Map R E R E 7FFB0000 00024000 Map R R 7FFDE000 00001000 data block o Priv RW RW 7FFDF000 00001000 Priv RW RW 7FFE0000 00001000 Priv R R

anonymouse		March 28, 2007 11:13.19 CDT
hehe a little bit of googling could land you information about all those address even without having symbols im not on xpsp2 at the moment but i fed google with 7c90dc61 and it returns me 0012f1c8 7c90dc61 ntdll!KiFastSystemCallRet metasploit says ntdll.dll 5.1.2600.21802 Microsoft Corporation English 0x7c900000 ntdll.dll 5.1.2600.21802 Microsoft Corporation German 0x7c910000 it matches your 7c9000 lets explore whats in there Type Base Address Size Writable Readable Executable .reloc 0x7c900000 11912 No Yes No .text 0x7c901c00 501502 No Yes Yes .data 0x7c97d400 18912 Yes Yes No .rsrc 0x7c984200 179832 No Yes No looking around you can locate lamost all those address NtMapViewOfSection 0x7c90dc55 196 and so on

JLeCours		March 28, 2007 11:21.21 CDT
Using PEBrowse, LordPE, or the like... I can look at other process which typically have kernel32.dll and ntdll.dll mapped in the same address range. Since they were the same mapping, I wasn't sure it was possible to copy one mapping from one session to another. Thanks again for the help.

Note: Registration is required to post to the forums.

There are 31,328 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06
Question about memor...	Dec/12

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

View Gallery (11) / Submit