Question about retrieving memory contents

Index > Windows > Question about retrieving memory contents

Author

Thread

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 24 Aug 2007, 20:18

Quick question (This kind of turns into two questions near the end of the post). I've done my best to try to keep it to one question, but if you read the entire post you'll see why the second question is also important to me and how it is relevant, from my end, to answering the first question. So I'll do my best to keep this post categorized.

Side note:
First lemme just apologize for hitting the forums up so much with questions. I've found the fasm pdf file to be very informative but only in terms for looking something up, not really a detailed tutorial on generic sections (no phun intended) of working with asm. Like code layout or how wsprintf format pictures correlate to asm delcarations (It's good for looking up things like syntax on opcodes and declaratoin stuff, db,du,df, etc..

The examples and tutorials that I've downloaded and have been given via the helpful posts have been an invaluable resource, so thanks!

First Question: Memory address contents
Anyhow back to my quick question.. Here's some statements from my procedure in my asm file, some are rem'ed but included anyhow in hopes to get the point across on what I'm trying to achieve. Also, if you look at the rem'ed statemants you can see the evolution of my attempts

Code:

;cinvoke  wsprintf,Byte1,"%c",DLLFunctionAddr1a
     ;mov eax, dword [DLLFunctionAddr1a]
     ;cinvoke wsprintf,tmp_buf2,"%X",DLLFunctionAddr1a
     mov   eax, dword [DLLFunctionAddr1a]
     invoke WriteConsole, [hConsole], word [DLLFunctionAddr1a],8, tmp, 0
     ;cmp   word [eax], $FF8B

here's some declarations so you can see what kind of variables they are

Code:

section '.data' data readable writeable

DLLFunctionAddr1a    rb 64

  ;Byte1  dd ?
  ;Byte1  dw ?
  ;Byte1   db ?
  Byte1   rb 2

  hConsole        dd ?
  tmp             dd ?
  tmp_buf2        db 256 dup(?)

DLLFunctionAddr1a contains the memory location 77DD7DA0. In my other posts you can download the asm code to see that the code does infact enumerate the address locations for the APIs, problem I'm having is retrieving the HEX byte of the opcode located in those memory locations.

(first question leading into) Second Question
Now I did look at another example. The detour example, such a sweet example, absolutely perfect for what I'm looking to do, but problem comes in is, the detour_example program doesn't even remotely match the same layout of my code.. for example

Code:

data import
    dd $0, $0, $0, rva kernel32_name, rva kernel32_table
    dd $0, $0, $0, rva user32_name,   rva user32_table
    dd $0, $0, $0, $0, $0

kernel32_table:
    VirtualProtectEx           dd rva _VirtualProtectEx
    GetProcessHeap             dd rva _GetProcessHeap
    HeapAlloc                  dd rva _HeapAlloc
    ExitProcess                dd rva _ExitProcess
    dd $0

<...>

    kernel32_name db 'kernel32.dll', $0
    user32_name   db 'user32.dll', $0
end data

Here's the closest to what I have in my code

Code:


section '.idata' import data readable writeable
  library kernel32,'KERNEL32.DLL',\
          user32,'USER32.DLL',\
          advapi32,'ADVAPI32.DLL'

  include '\fasm\include\api\kernel32.inc'
  include '\fasm\include\api\user32.inc'
  include '\fasm\include\api\advapi32.inc'

(Noticed there is no end section or anything like that, like in the detours example how it has end data)

I've seen some really bad consistency levels with code-layout and that's got me seriously confused. Let me just clarify, when I say bad consistency levels, please don't take that as in I'm saying bad code or anything like that, just saying that every asm prog seems to follow some other radically different code structure/layout.

I've even seen things where a variable is a label with two or more data declatarions. ex:

Code:

test:
   dd 0,0,0, <whatever>
   dd 0,0,0,0,0

let's go with something simpler:

Code:

testlabel:

   test:  db '<blah>', 0
   test2: db '<blah2>', 0

what in the world is that? How does that relate to something like

Code:

section '.data' data readable writeable
DLLName1   db 'ADVAPI32.DLL', 0

(DLLName1 has no colon after it, and it is also in a section not a label)

-- StakFallT

24 Aug 2007, 20:18

Adam Kachwalla

Joined: 01 Apr 2006
Posts: 150

Adam Kachwalla 24 Aug 2007, 23:37

StalkFallT wrote:

let's go with something simpler:
Code:
testlabel:

   test:  db '<blah>', 0
   test2: db '<blah2>', 0    
what in the world is that? How does that relate to something like
Code:
section '.data' data readable writeable
DLLName1   db 'ADVAPI32.DLL', 0    
(DLLName1 has no colon after it, and it is also in a section not a label)

I guess over here you want to know the difference between putting it in .data and DB'ing it anywhere:

Putting it in .data allows your program to be smaller in size (when using RBs), because it then loads the data at runtime. Also reduces the need for JMPs. It is similar to placing it right at the end, except memory space for the variables/data is created at runtime..

As for the colon:

Code:

test: db 'Pneumonoultramicroscopicsilicovolcanoconiosis',0

is exactly the same as

Code:

test db 'Pneumonoultramicroscopicsilicovolcanoconiosis',0

The colon is used for writing things like:

Code:

test:
    DB 'Pneumono'
    DB 'ultra'
    DB 'microscopic'
    DB 'silico'
    DB 'volcano'
    DB 'conio'
    DB 'sis'

24 Aug 2007, 23:37

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 24 Aug 2007, 23:53

Awesome, thanks! Nice explanation! So I guess my follow up question is, is using labels to declare stuff considered sloppy, and placing things inside "section"s the better approach, on average? Like when would you really actually need to declare something in a label?

On a slightly side note, I'm picking through the Detours example, it's slow but it's helping a little (so many labels and jumping all around and it sooo hard to tell what can be placed into a proc). I tend to really dislike labels. I really don't like the program having the ability to have it's code-flow flow right into something else without you realizing it. My father is good with that stuff in VB, he'll do labels and jump around all over the place, when I'd prefer to just put something in it's own separate sub or function if necessary and just call it when I need to. This way I don't have pages and pages of code to pass through before I get to look at something I need to. I figure once I've worked with the detours example enough, I should be able to get a better grip on what is actually happening, right now it's so hard to tell..

24 Aug 2007, 23:53

Adam Kachwalla

Joined: 01 Apr 2006
Posts: 150

Adam Kachwalla 25 Aug 2007, 03:41

Quote:

Awesome, thanks! Nice explanation! So I guess my follow up question is, is using labels to declare stuff considered sloppy, and placing things inside "section"s the better approach, on average? Like when would you really actually need to declare something in a label?

It is preferable to use the .data section - only if you want your app to work under Windows and Windows only. You can place labels if you want, but be aware that you will need to do something like:

Code:

JMP endLbl
startLabel DB 'Pneumonoultramicroscopicsilicovolcanoconiosis',0
endLbl

if you dump it somewhere random in the middle of your code. You wouldn't need the JMPs if the labels were placed somewhere at the end.

It is not a big deal to use labels, though, if you are like me and want to make different ports of your application for different operating systems.

Beware that it is very easy to execute the contents of variables! I have, several times, made that mistake of executing a variable!
This is why buffer overflow attacks are so common. The original code:

Code:

JMP eLabel
sLabel RB 16
eLabel:
;Some other code

can be changed with a buffer overflow attack if the program allows more data into it than it can handle to:

Code:

JMP eLabel
sbLabel DB 'Pneumonoultramic'
eLabel:
DB 'roscopicsilicovolcanoconiosis'

Dangerous security fault Sad

25 Aug 2007, 03:41

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 25 Aug 2007, 03:56

You mean by executing labels, have code-flow flow into the label that's really meant to declare the variable (or you accidentally jump to the label without realizing it was a label used to declare something) right? lol That's exactly what I'm trying to avoid, because I could see how easy it is to do that Wink

So what's with the "data import" line I found in the detours example? A normal line I'm used to seeing is something like this:

section '.data' data readable writeable

which is usually at the top, I usually have something like this
section '.idata' import data readable writeable

on the bottom.. But in the detours example, I don't see the "section'.idata' I see this:
(just this) "data import"
with some code below it

is that the same as "section '.data' data readable writeable" ?

25 Aug 2007, 03:56

Adam Kachwalla

Joined: 01 Apr 2006
Posts: 150

Adam Kachwalla 25 Aug 2007, 06:01

Quote:

You mean by executing labels, have code-flow flow into the label that's really meant to declare the variable (or you accidentally jump to the label without realizing it was a label used to declare something) right? lol That's exactly what I'm trying to avoid, because I could see how easy it is to do that

Yes, that is exactly what I am talking about.

The section '.data' data readable writeable line that you see tells FASM to compile the code directly under the line (until it hits section '.code' code readable executable).

Also, about your question about the data import line:

Code:

section '.idata' import data readable writable

This is a line that tells FASM what API functions are used, and in which DLL file to find them in.

25 Aug 2007, 06:01

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 25 Aug 2007, 08:32

but is

Code:

data import

the same as

Code:

section '.idata' import data readable writeable

25 Aug 2007, 08:32

Adam Kachwalla

Joined: 01 Apr 2006
Posts: 150

Adam Kachwalla 25 Aug 2007, 09:11

Yes.

Code:

data import
  library kernel,'KERNEL32.DLL',\
          user,'USER32.DLL',\
          gdi,'GDI32.DLL',\
          dwmapi,'DWMAPI.DLL'

  import kernel,\
         GetModuleHandle,'GetModuleHandleA',\
         ExitProcess,'ExitProcess',\
         GetLastError,'GetLastError'

  import user,\
         RegisterClass,'RegisterClassA',\
         CreateWindowEx,'CreateWindowExA',\
         DefWindowProc,'DefWindowProcA',\
         SetWindowLong,'SetWindowLongA',\
         RedrawWindow,'RedrawWindow',\
         GetMessage,'GetMessageA',\
         TranslateMessage,'TranslateMessage',\
         DispatchMessage,'DispatchMessageA',\
         SendMessage,'SendMessageA',\
         PostQuitMessage,'PostQuitMessage' ,\
  import dwmapi,\
         ApplyGlass,'DwmExtendFrameIntoClientArea'
end data

is exactly the same as

Code:

section '.idata' import data readable writeable
  library kernel,'KERNEL32.DLL',\
          user,'USER32.DLL',\
          gdi,'GDI32.DLL',\
          dwmapi,'DWMAPI.DLL'

  import kernel,\
         GetModuleHandle,'GetModuleHandleA',\
         ExitProcess,'ExitProcess',\
         GetLastError,'GetLastError'

  import user,\
         RegisterClass,'RegisterClassA',\
         CreateWindowEx,'CreateWindowExA',\
         DefWindowProc,'DefWindowProcA',\
         SetWindowLong,'SetWindowLongA',\
         RedrawWindow,'RedrawWindow',\
         GetMessage,'GetMessageA',\
         TranslateMessage,'TranslateMessage',\
         DispatchMessage,'DispatchMessageA',\
         SendMessage,'SendMessageA',\
         PostQuitMessage,'PostQuitMessage' ,\
  import dwmapi,\
         ApplyGlass,'DwmExtendFrameIntoClientArea'

The use of one over another really depends on one person or another. The latter line has more control over the former line, because it allows you to specify read/write/execute priveleges. Used in conjunction with Data Execution Prevention in Windows XP SP2 and Longhorn Server, you can build yourself one secure application!

I wouldn't recommend giving an '.import' section write and/or execute permissions at all, so the best lines to use for data, code, and imports are:

Code:

section '.data' readable writeable'
section '.code' readable writeable executable
section '.idata' readable

25 Aug 2007, 09:11

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 25 Aug 2007, 17:09

gotcha, thanks Smile

25 Aug 2007, 17:09

FrozenKnight

Joined: 24 Jun 2005
Posts: 128

FrozenKnight 25 Aug 2007, 21:13

Quote:

The use of one over another really depends on one person or another. The latter line has more control over the former line, because it allows you to specify read/write/execute priveleges. Used in conjunction with Data Execution Prevention in Windows XP SP2 and Longhorn Server, you can build yourself one secure application!

I wouldn't recommend giving an '.import' section write and/or execute permissions at all

untill you learn about VirtualProtectEX(). it doesn't matter how secure your application is Hackers can find a way around it. and btw Data Execution Prevention is computer specific so it can be turned off. (quite easily too)
At best you might slow down a hacker for about 10 seconds.

but if your at that then you should not give write permissions to the .code section either.

25 Aug 2007, 21:13

< 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