Log in

View Full Version : Ollydbg plugin development: Findmemory needs Listmemory?

My Infected Computer
March 28th, 2014, 11:31
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://stats.wordpress.com/b.gif?host=zairon.wordpress.com&blog=448309&post=981&subd=zairon&ref=&feed=1

http://zairon.wordpress.com/2014/03/28/ollydbg-plugin-development-findmemory-needs-listmemory/
Kayaker
March 28th, 2014, 22:21
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:

Quote:

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:

Quote:

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
March 29th, 2014, 01:13
Code:


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:


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:




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:


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
March 29th, 2014, 05:47
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
March 29th, 2014, 19:27
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:


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:


#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
March 30th, 2014, 17:03
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
March 30th, 2014, 17:47
A complete module list is available combining results from module and premod​