how do i do that?

Index > Windows > how do i do that?

Goto page 1, 2 Next

Author

Thread

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 02:24

i declare dword:
memory dd ?

then i fill it with memory pointer (returned by HeapAlloc).
i fil this memory with something.

then, mov eax, [memory] << in eax i should have pointer to memory

mov eax, [memory]
push dword [eax+25]
crash Sad

i want to access 25th dword in my memory

19 Jan 2008, 02:24

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 19 Jan 2008, 02:25

25*4

19 Jan 2008, 02:25

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 02:45

i mean dword starting from 25 byte.

19 Jan 2008, 02:45

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 19 Jan 2008, 03:11

What crash? What does a debugger say?

Not enough info.

19 Jan 2008, 03:11

edfed

Joined: 20 Feb 2006
Posts: 4353
Location: Now

edfed 19 Jan 2008, 03:29

alignment problem?

19 Jan 2008, 03:29

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 03:44

i need correct syntax for this. it just dont work, debugger say nothing.

19 Jan 2008, 03:44

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 19 Jan 2008, 03:53

But seems to be correct, but since we have no idea what you want we can't know "the correct syntax" for you. You code pushes onto the stack the C equivalent of *(long)((char *)memory+25) (perhaps this is incorrect C syntax Razz

).

Try posting some code with at least the parts related to this problem.

19 Jan 2008, 03:53

ic2

Joined: 19 Jan 2008
Posts: 75

ic2 19 Jan 2008, 04:23

memory dd ?

You are walking through and including other data with a single dword...

You need something like what sinsi was indicating ...

memory [100] :BYTE

Not sure of the syntax for DWORD. This is the only thing I found in the fasm.pdf. I'm new to FASM..

BTW, how would you use DWORD instead of BYTE here?

Last edited by ic2 on 19 Jan 2008, 04:34; edited 3 times in total

19 Jan 2008, 04:23

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 04:24

@up
not a buffer, just a pointer to it. Thats why are functions to allocate memory - save file size.

Code:

section '.code' code readable executable
push 0x00000004
push 0x00002000
push mem_size
push 0
push mem_addr
push 0xFFFFFFFF
call [NtAllocateVirtualMemory]
;here is a huge function that fills a structure pointed by mem_addr
mov eax, [mem_addr]
push dword [eax+25]
push f
call [printf]; i should get 25-28 uninitilized bytes formatted as integer
add esp,8
push 0x00008000
push mem_size
push mem_addr
push 0xFFFFFFFF
call [NtFreeVirtualMemory]
retn 0
section '.data' data readable writeable
mem_addr dd 0
mem_size dd 20480
f db '%i',0

19 Jan 2008, 04:24

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 19 Jan 2008, 04:46

Why use NtAllocateVirtualMemory? Undocumented stuff is OK, but it is undocumented for a reason...it can change from SP1 to SP2 for example.

19 Jan 2008, 04:46

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 19 Jan 2008, 05:24

Quote:

not a buffer, just a pointer to it. Thats why are functions to allocate memory - save file size.

However if you declare uninitialized vars at the end of a section it does not take any single byte of disk space, the section is simply marked with a virtual size bigger than its raw size.

Code:

format pe console
include 'win32wx.inc'

PAGE_READWRITE = 4

section '.code' code readable executable

invoke NtAllocateVirtualMemory, -1, mem_addr, 0, mem_size, MEM_COMMIT, PAGE_READWRITE

mov eax, [mem_addr]
cinvoke printf, f, dword [eax+25]


mov eax, [mem_addr]
mov dword [eax+25], $DEADBEEF
cinvoke printf, f, dword [eax+25]

invoke NtFreeVirtualMemory, -1, [mem_addr], mem_size, 0x00008000

retn

section '.data' data readable writeable
mem_addr dd 0
mem_size dd 20480
f db '%X', 10, 0

data import
  library ntdll, 'ntdll.dll',\
          crtdll, 'crtdll.dll'

  import ntdll,\
         NtAllocateVirtualMemory, "NtAllocateVirtualMemory",\
         NtFreeVirtualMemory, "NtFreeVirtualMemory"

  import crtdll,\
         printf, "printf"
end data

So the program WAS crashing, you have a NULL pointer access because your call to NtAllocateVirtualMemory does not work and GetLastError says ERROR_ACCESS_DENIED. I wonder why you want this particular function, I think that VirtualAllocEx also fits your needs (if you are wanting to allocate memory at arbitrary processes, otherwise more simpler functions can be used)

PS: BTW, you was not using heap at all.

[edit]Code corrected and simplified[/edit]

Last edited by LocoDelAssembly on 19 Jan 2008, 05:42; edited 1 time in total

19 Jan 2008, 05:24

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 05:27

Code:

because your call to NtAllocateVirtualMemory does not work

sorry, but try to push eax instead of [eax+25] . It worked at 100%.

Code:

invoke NtAllocateVirtualMemory, eax, mem_addr, 0, mem_size, PAGE_READWRITE

whers AllocationType?

Quote:

I wonder why you want this particular function

Im trying to learn all about system, not code fast. So native apis are on my way.
And i dont care it crash on windows 9X, its a diffrent os. Diffrence between nt-9x is almost like nt-unix.

19 Jan 2008, 05:27

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 19 Jan 2008, 05:48

Quote:

whers AllocationType?

hehe, I'm blind Razz

I've corrected the code and also removed the kernel32 calls since -1 as process handle is enough.

This is the output I get with the new program:

Code:

C:\Documents and Settings\Hernan\Escritorio>test2.exe
0
DEADBEEF

Sorry for my mistake.

PS: Just in case it is not obvious, by doing [eax+25] you are not accessing the 25th dword but a dword 25 bytes ahead of the base address ([eax+25..eax+28]).

19 Jan 2008, 05:48

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 06:26

i compared codes, and... why MEM_RESERVE cause this error? I was using it for long time, and it was ok.

19 Jan 2008, 06:26

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 19 Jan 2008, 06:37

Quote:

i compared codes, and... why MEM_RESERVE cause this error? I was using it for long time, and it was ok.

Oh, I though you was using MEM_COMMIT, the problem with MEM_RESERVE is that it just reserves the address space but the memory is not allocated. With MEM_RESERVE you ensure that any future memory allocation will not use your reserved range but as I've said it is still not allocated (there is no page table entries representing the address range*, nor physical RAM nor swap space occupied by the reservation).

*Well, actually a guess from my part, but I think that Windows takes note of reserved ranges elsewhere instead of polluting the memory with many page table entries marked all as invalid.

PS:

VirtualAlloc documentation (only a part) wrote:

flAllocationType

Specifies the type of allocation. You can specify any combination of the following flags:

Flag Meaning

MEM_COMMIT Allocates physical storage in memory or in the paging file on disk for the specified region of pages.
An attempt to commit an already committed page will not cause the function to fail. This means that a range of committed or decommitted pages can be committed without having to worry about a failure.

MEM_RESERVE Reserves a range of the process's virtual address space without allocating any physical storage. The reserved range cannot be used by any other allocation operations (the malloc function, the LocalAlloc function, and so on) until it is released. Reserved pages can be committed in subsequent calls to the VirtualAlloc function.

MEM_TOP_DOWN Allocates memory at the highest possible address.

19 Jan 2008, 06:37

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 19 Jan 2008, 07:00

so if i commit the page, other process/thread/function can overwrite it?

19 Jan 2008, 07:00

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 19 Jan 2008, 14:51

Yes, though for other process to access it the mecanism is not very direct, you need APIs like WriteProcessMemory to reach them. Threads within the process that commited the pages can access them directly, so no matter the thread that allocated the memory any thread can access it later.

19 Jan 2008, 14:51

AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.

AlexP 19 Jan 2008, 23:38

Well, I've seen techniques for injecting a DLL inside another process. That could lead normal code to call a presumably legit function in it's process space, and turn command over to the rogue code.

Code:

call [NtAllocateVirtualMemory] 
;here is a huge function that fills a structure pointed by mem_addr 
mov eax, [mem_addr] 
push dword [eax+25] 
push f 
call [printf]; i should get 25-28 uninitilized bytes formatted as integer 
add esp,8 
push 0x00008000 
push mem_size 
push mem_addr 
push 0xFFFFFFFF 
call [NtFreeVirtualMemory] 
retn 0 
section '.data' data readable writeable 
mem_addr dd 0 
mem_size dd 20480 
f db '%i',0

WTF? First of all, you screw up the API call majorly, your instruction mov eax, [mem_addr] seems to be perfectly backwards. Secondly, the %i flag to printf takes a pointer to memory, not an actual value! that could explain an access fault to whatever lives at that address. you should use lea then a push.

19 Jan 2008, 23:38

asmrox

Joined: 19 Jan 2008
Posts: 160

asmrox 20 Jan 2008, 00:09

Quote:

WTF? First of all, you screw up the API call majorly

no, i used MEM_RESERVE instead MEM_COMMIT.

Quote:

Secondly, the %i flag to printf takes a pointer to memory

no, it print what is on stack, and %s take address.

20 Jan 2008, 00:09

AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.

AlexP 20 Jan 2008, 01:22

I've used %d as integer, thought %i takes the same. And I did see the MEM_RESERVE thing, was just wonderin' why you destroyed eax after the call.

20 Jan 2008, 01:22

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum