Why wont my registers work?

Index > Windows > Why wont my registers work?

Goto page 1, 2 Next

Author

Thread

NanoBytes

Joined: 02 Jun 2011
Posts: 57
Location: Iowa, United States

NanoBytes 26 Jan 2012, 02:55

Code:

MOV EAX,dword[EBP+-8];Move the parameters address into the source pointer

        cinvoke  wsprintf,String1,'%d',EAX
        invoke   WriteConsole,[outhandle],String1,EAX,0,0; ---Prints string

        cinvoke  wsprintf,String1,'%c',10
        invoke   WriteConsole,[outhandle],String1,EAX,0,0; ---Prints string

        MOV EAX,dword[EBP+-8];Move the parameters address into the source pointer

        cinvoke  wsprintf,String1,'%d',EBX
        invoke   WriteConsole,[outhandle],String1,EAX,0,0; ---Prints string

[EBP+-8] (named by my compiler) holds the address of a heap location. The firs time I try to print the results everything works perfectly, the program output the address on the heap. But the second time I try to output the address it actualy outputs the data stored at the address.
eg.

Code:

     0x000210304 = 1; the heap memory     
     [EBP+-8] = 0x000210304; pointing to the heap memory
     first output = 0x000210304; correct
     second output = 1; wrong

why does it do that?

_________________
He is no fool who gives what he cannot
keep to gain what he cannot loose.

26 Jan 2012, 02:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 26 Jan 2012, 03:31

EAX is not preserved by the API calls. Read about the "standard call" convention. EAX, ECX, EDX, EFLAGS are freely clobbered and you should not expect them to have the same value after you call an API function.

26 Jan 2012, 03:31

NanoBytes

Joined: 02 Jun 2011
Posts: 57
Location: Iowa, United States

NanoBytes 26 Jan 2012, 03:39

I realize that, but if EAX where to change, that should not change the value in [EBP+-8]

26 Jan 2012, 03:39

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 26 Jan 2012, 03:42

Code:

cinvoke  wsprintf,String1,'%d',EBX

EAX maybe, not EBX?

26 Jan 2012, 03:42

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 26 Jan 2012, 03:43

Well you should at least match the registers then

Code:

        MOV EAX,dword[EBP+-8];Move the parameters address into the source pointer

        cinvoke  wsprintf,String1,'%d',EBX

Did you want EAX or EBX?

Last edited by revolution on 26 Jan 2012, 04:09; edited 1 time in total

26 Jan 2012, 03:43

NanoBytes

Joined: 02 Jun 2011
Posts: 57
Location: Iowa, United States

NanoBytes 26 Jan 2012, 03:55

I used both, to make sure that the problem was not comeing from just EAX, or just EBX

26 Jan 2012, 03:55

NanoBytes

Joined: 02 Jun 2011
Posts: 57
Location: Iowa, United States

NanoBytes 26 Jan 2012, 12:27

Ok, i figured out the problem, but I cant figure out why it is doing it

Code:

        MOV EAX,dword[EBP+-8]
        cinvoke  wsprintf,String1,'%d',EAX 
        invoke   WriteConsole,[outhandle],String1,EAX,0,0
        cinvoke  wsprintf,String1,'%c',10 
        invoke   WriteConsole,[outhandle],String1,EAX,0,0

        MOV EAX,dword[EBP+-4]; <---------------- CHANGED

        cinvoke  wsprintf,String1,'%d',EBX 
        invoke   WriteConsole,[outhandle],String1,EAX,0,0

the address ate [EBP+-8] is moved up by 4, so now the address is stored in [EBP+-4] and I cant figure out why?

_________________
He is no fool who gives what he cannot
keep to gain what he cannot loose.

26 Jan 2012, 12:27

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 26 Jan 2012, 14:15

NanoBytes wrote:

the address ate [EBP+-8] is moved up by 4, so now the address is stored in [EBP+-4] and I cant figure out why?

That means your stack is not being restored properly. I suggest that you have some more code (more than you are showing) that alters EBP. This is why we always suggest to show ALL your code, since the problem is often in code that someone does not show.

26 Jan 2012, 14:15

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 26 Jan 2012, 14:40

@NanoBytes:
This line:

Code:

cinvoke wsprintfA,buf,'%d',eax

produces a strange code in debugger, which you should use btw.
Stepping over this line produces Access Violation - which it should.
I think it is because of '%d' used on the line.
Try to declare it beside the 'buf' and pass the address like so:

Code:

str_Format db '%d',0
str_Buf rb 16
...
cinvoke wsprintfA,str_Buf,str_Format,eax

26 Jan 2012, 14:40

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 26 Jan 2012, 15:05

AsmGuru62 wrote:

@NanoBytes:
This line:
Code:
cinvoke wsprintfA,buf,'%d',eax    
produces a strange code in debugger, which you should use btw.
Stepping over this line produces Access Violation - which it should.
I think it is because of '%d' used on the line.

This depends upon which version of win32[a[x[p]]].inc is included. Just another reason that people should post ALL the code to avoid confusion and wasting time.

26 Jan 2012, 15:05

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 26 Jan 2012, 17:37

So, which version of win32.inc will produce proper code?

26 Jan 2012, 17:37

NanoBytes

Joined: 02 Jun 2011
Posts: 57
Location: Iowa, United States

NanoBytes 27 Jan 2012, 03:34

See, my program was made using my (very flaud) compiler, and includes several inclusion file, and is entwined with all of them, it would take longer to decipher what the code does, than it would to fix the problem. BTW, EBX stays the same, i checked, which means that the stack itself is being modified, which makes no sense because 'wsprintf' shouldn't affect the stack.

27 Jan 2012, 03:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 27 Jan 2012, 03:37

NanoBytes: Don't blame the wrong thing, wsprintf does not affect the stack or EBP. Indeed the entire Windows API does not alter the stack or EBP. You need to look elsewhere to find your problem.

27 Jan 2012, 03:37

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 27 Jan 2012, 04:55

As I mentioned - see what wsprintf does in debugger - the call itself isn't right with '%d' passed as parameter. But if you pass it as a variable - it works.

27 Jan 2012, 04:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 27 Jan 2012, 05:29

AsmGuru62 wrote:

As I mentioned - see what wsprintf does in debugger - the call itself isn't right with '%d' passed as parameter. But if you pass it as a variable - it works.

And as I mentioned above it depends upon which version of win32[a[x[p]]].inc is included. win32ax will automatically convert string parameters into pointers.

27 Jan 2012, 05:29

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 27 Jan 2012, 15:33

@revolution: so, where then the string '%d' gets allocated? On stack, on heap or inside code section?

27 Jan 2012, 15:33

mindcooler

Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden

mindcooler 27 Jan 2012, 15:41

Right in the code where its address is pushed (called) onto the stack.

27 Jan 2012, 15:41

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 27 Jan 2012, 17:24

So, it mixes data and code?

27 Jan 2012, 17:24

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 27 Jan 2012, 18:10

AsmGuru62,
This is what the x/xp versions of the includes do:

Code:

;cinvoke printf '%d', eax
push eax
call @f
db '%d', 0
@@: ; It actually doesn't use an anonymous label but a local label (but the code has exactly this same pattern)
call [printf]
add  esp, 8

27 Jan 2012, 18:10

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 27 Jan 2012, 19:29

Cool, but...
Intel says that it is bad for performance to mix it.

27 Jan 2012, 19:29

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