Ollydbg plugin development: Findmemory needs Listmemory?

[My Infected Computer]

Here is the story of a problem I had yesterday using Ollydbg exported function Findmemory. I’m writing an Ollydbg v2 plugin and at some point I need to access the list of all the allocated memory blocks. To do this I decided to call the function I mentioned, it has a simple prototype: t_memory * […]

http://zairon.wordpress.com/2014/03/28/ ... istmemory/

[Kayaker]

That's a good reminder Zairon. You mention about getting inaccurate results with Findmemory unless Listmemory is used first. I think the explanation is *sort of* given in the Olly v1 help files, but is not really apparent without the evidence you just gave.

From the Olly Help file under What's New and Memory map window:

Listmemory() actualizes list of memory blocks.

Actualize - updates list of allocated memory and removes highlighting from new memory blocks.

From the Plugin API help file:

Listmemory

Function actualizes list of memory blocks and (in case if Windows 95) list of heaps allocated by Debuggee. If memory and/or heap windows are open, also updates windows. Returns 0 if tables are actualized and -1 if some or all of entries may be invalid.

As this operation is time-consuming, OllyDbg usually updates memory tables only if application is paused.
If plugin accesses memory tables "on the fly", it may need to call this function.
Note that reading or writing to the memory does not require actualization of memory tables.

Actually Findmemory does initialize with Listmemory internally in both versions of Olly, but only when some undocumented flag is set.

Like the new blog look btw

[blabberer]

Code: Select all

foo:\>cd
C:\Documents and Settings\Admin\My Documents\ollydbg2beta\odbg201\odbg201

foo:\>cdb -c "uf /c Findmemory ;" ollydbg.exe
0:000> cdb: Reading initial command 'uf /c Findmemory ;'

ollydbg!Findmemory (00458de4)
  ollydbg!Findmemory+0x2b (00458e0f):
    call to ollydbg!Listmemory (00458f4c)
  ollydbg!Findmemory+0x5c (00458e40):
    call to ollydbg!Findsorteddata (00418738)

0:000> ub 458e0f l2
ollydbg!Findmemory+0x22:
00458e06 833d7861580000  cmp     dword ptr [ollydbg!scheme+0x32f4 (00586178)],0
00458e0d 7405            je      ollydbg!Findmemory+0x30 (00458e14)


0:000> u 458e0f l2
ollydbg!Findmemory+0x2b:
00458e0f e838010000      call    ollydbg!Listmemory (00458f4c)
00458e14 8b15445e5d00    mov     edx,dword ptr [ollydbg!memory+0x60 (005d5e44)]


0:000> .echo so 586178 holds the flag for refresh lets check where it gets inite
d must be with a mov lets check mov first

0:000> # mov*586178 401000
ollydbg!Getexportfrommemory+0x34ea:
00416c4a c7057861580001000000 mov dword ptr [ollydbg!scheme+0x32f4 (00586178)],1

0:000> # mov*586178
ollydbg!Cmdinfo+0x2b9d:
0044a3c1 890d78615800    mov     dword ptr [ollydbg!scheme+0x32f4 (00586178)],ecx
0:000>
ollydbg!Getselectorinfo+0x536:
0044fade c7057861580001000000 mov dword ptr [ollydbg!scheme+0x32f4 (00586178)],1

0:000>
ollydbg!Checkfordebugevent+0x56e6:
004569ee c7057861580001000000 mov dword ptr [ollydbg!scheme+0x32f4 (00586178)],1

0:000>
ollydbg!Listmemory+0xb:
00458f57 a378615800      mov     dword ptr [ollydbg!scheme+0x32f4 (00586178)],eax
0:000>
                  ^ Memory access error in '# mov*586178'
0:000>

quit and retart with breaks enabled and a debugee for debugger

Code: Select all

foo:\>cdb -c "bp 416c4a;bp 44fade;bp 4569ee;g;" ollydbg.exe calc.exe

so yes it sets the flag on debug event on case 4 Module Refresh

Code: Select all

0:000> r eip
eip=00416c4a
0:000> .lastevent
Last event: 1378.1530: Hit breakpoint 0
  debugger time: Sat Mar 29 10:59:41.015 2014 (UTC + 5:30)
0:000> bl 0
 0 e 00416c4a     0001 (0001)  0:**** ollydbg!Getexportfrommemory+0x34ea
0:000> u 00416c4a l1
ollydbg!Getexportfrommemory+0x34ea:
00416c4a c7057861580001000000 mov dword ptr [ollydbg!scheme+0x32f4 (00586178)],1

0:000> kb
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0013ae94 00416c9d 02510000 0013aebc 00000000 ollydbg!Getexportfrommemory+0x34ea
0013be6c 0044fac0 02510000 005d5568 02580000 ollydbg!Getexportfrommemory+0x353d
0013be84 00451f03 00000001 14950d32 00000001 ollydbg!Getselectorinfo+0x518
0013f278 004105f2 00000000 004f6198 00151eec ollydbg!Checkfordebugevent+0xbfb
0013ff88 004f1067 00400000 00000000 00151eec ollydbg!Setstatus+0x677e
0013ffc0 7c817077 00000000 00000000 7ffde000 ollydbg!T+0x128a3
0013fff0 00000000 00401000 00000000 78746341 kernel32!BaseProcessStart+0x23
0:000>

disable the first bp (recursive hits ) and g

Code: Select all

0:000> bd 0
0:000> g
Breakpoint 1 hit

0:000> r eip;.lastevent; u eip l1;kb
eip=0044fade
Last event: 1378.1530: Hit breakpoint 1
  
ollydbg!Getselectorinfo+0x536:
0044fade c7057861580001000000 mov dword ptr [ollydbg!scheme+0x32f4 (00586178)],1

ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0013be84 00451f03 00000001 14950d32 00000001 ollydbg!Getselectorinfo+0x536
0013f278 004105f2 00000000 004f6198 00151eec ollydbg!Checkfordebugevent+0xbfb
0013ff88 004f1067 00400000 00000000 00151eec ollydbg!Setstatus+0x677e
0013ffc0 7c817077 00000000 00000000 7ffde000 ollydbg!T+0x128a3
0013fff0 00000000 00401000 00000000 78746341 kernel32!BaseProcessStart+0x23
0:000>

updating memory window does not get us a break either when running or paused even enabling bp 0 does not result in a hit

so this flag is never updated directly it seems at least not with mov

either a bug or we need to branch off and find all referances including mov reg cont mov [reg] ,1 and other esetoric constructs like xor eax,eax , inc eax # times until it is the required const mov [reg] , 1

[ZaiRoN]

I was waiting a reply from both of you of course


The flag_586178 is obscure indeed, it should have a significant meaning for Oleh, but for this specific memory behaviour seems to be almost useless (at least from an external point of view).
I think the most reasonable guess comes from the phrase "If plugin accesses memory tables "on the fly", it may need to call this function.". The fact is this, do you really need to have an updated view of the memory list when the debuggee is running? No because if the debugee is running you can't interact with it. This assumption respects all the attempts I have done along my test.

[blabberer]

the flag is set to 0 when manually updating the memory map window inside Listmemory Function

i couldn't get a hit earlier coz i was checking at all the places where 1 was written and had ignored the places where 0 is written

( i set a ba w4 "condition break" to trap writes) and every time ctrl+r (update ) is done in the memory map window we get a breakpoint hit

Code: Select all

0:001> bl
 1 e 00586178 w 4 0001 (0001)  0:**** ollydbg!scheme+0x32f4 "ub eip l1;.echo ======================; r; .echo =======================; kb;.echo ==================; gc"
0:001> g
ollydbg!Listmemory+0xb:
00458f57 a378615800      mov     dword ptr [ollydbg!scheme+0x32f4 (00586178)],eax
======================
eax=00000000 ebx=080a063f ecx=005d5e28 edx=00001cbb esi=005370f0 edi=005d5de4
eip=00458f5c esp=0013e598 ebp=0013e990 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200246
ollydbg!Listmemory+0x10:
00458f5c 833d10555d0000  cmp     dword ptr [ollydbg!process (005d5510)],0 ds:0023:005d5510=00000764
=======================
ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
0013e990 00457d53 0013ebbc 004253d2 005d5de4 ollydbg!Listmemory+0x10
0013e998 004253d2 005d5de4 0013e9bc 00000000 ollydbg!Checkfordebugevent+0x6a4b
0013ebbc 0041f5c3 005d5de4 0000031a 000001e8 ollydbg!Callmenufunction+0xa9e
0013ef24 7e418734 00790550 00000204 00000002 ollydbg!Setautoupdate+0x117f
0013ef50 7e418816 0041e500 00790550 00000204 USER32!InternalCallWinProc+0x28
0013efb8 7e42a013 00000000 0041e500 00790550 USER32!UserCallWinProcCheckWow+0x150
0013efe8 7e42a039 0041e500 00790550 00000204 USER32!CallWindowProcAorW+0x98
0013f008 5d095e5e 0041e500 00790550 00000204 USER32!CallWindowProcW+0x1b
0013f024 5d09602f 00790550 00000204 00000002 COMCTL32!CallOriginalWndProc+0x1a
0013f080 5d095fe4 00160438 00790550 00000204 COMCTL32!CallNextSubclassProc+0x3c
0013f0a4 5d0e31a2 00790550 00000204 00000002 COMCTL32!DefSubclassProc+0x46
0013f0c0 5d09602f 00790550 00000204 00000002 COMCTL32!TTSubclassProc+0x59
0013f11c 5d0960be 00160438 00790550 00000204 COMCTL32!CallNextSubclassProc+0x3c
0013f170 7e418734 00790550 00000204 00000002 COMCTL32!MasterSubclassProc+0x51
0013f19c 7e418816 5d09607d 00790550 00000204 USER32!InternalCallWinProc+0x28
0013f204 7e4189cd 00000000 5d09607d 00790550 USER32!UserCallWinProcCheckWow+0x150
0013f264 7e418a10 0013f2d4 00000000 0013ff88 USER32!DispatchMessageWorker+0x306
0013f274 0041058d 0013f2d4 00000000 004f6198 USER32!DispatchMessageW+0xf
0013ff88 004f1067 00400000 00000000 00151eeb ollydbg!Setstatus+0x6719
0013ffc0 7c817077 009af6ee 009af720 7ffd4000 ollydbg!T+0x128a3
0013fff0 00000000 00401000 00000000 78746341 kernel32!BaseProcessStart+0x23
==================

ollydbg itself does not seem to update the memory map window either when paused or running

for an updated memory map one needs to manually do an update (ctrl+r) in the window.

and if there are new memory blocks it will shown in red color (valloced by the debugee system etc)

so it seems the behaviour is consistent

try this in your snippet

Code: Select all

#define XXX     	00586178

unsigned long flag = *(unsigned long *)XXX;

if (flag != 0) 
{
Listmemory()
Findmemory()
}
else 
{
Findmemory
}

i think that should provide a consistent answer

[ZaiRoN]

Ok, thx blabberer!

Ah, forgot to mention: I have to investigate a little bit more but seems like module list suffers the same problem too, too bad *Listmodule* doesn't exist.............. I have to find a workaround!

[ZaiRoN]

A complete module list is available combining results from module and premod​