flat assembler
Message board for the users of flat assembler.

Index > Windows > where dose getchar return to?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 00:00
pretty simple question, where dose getchar return the char to, al? im trying to make a brainfuck compiler that compiles to FASM (i guess that really means it's translator). im trying to use nothing but registers with the exception of a string to use for the pause msg.
Post 26 Sep 2010, 00:00
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 26 Sep 2010, 00:06
Values returned by MSVCRT (and the whole Windows API also) are in EAX.
Post 26 Sep 2010, 00:06
View user's profile Send private message Visit poster's website Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 00:13
ok so how do i move and 4 byte value to be stored at a 1 byte place? i want to move eax to byte[edx], movsx works the other way around, so how do i do it this way?
Post 26 Sep 2010, 00:13
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 26 Sep 2010, 00:27
Code:
mov byte[edx],al    
Post 26 Sep 2010, 00:27
View user's profile Send private message Visit poster's website Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 00:36
ok then how do i move eax to al becuase mov al, byte eax dose not work.

here is my code in case it helps
Code:
format PE console
entry main

include 'INCLUDE\MACRO\import32.inc'

section '.data' data readable writeable

pausemsg db 'pause>nul',0

section '.code' code readable executable

main:
     push 30000              ;pass 30000 to malloc          
     call [malloc]           ;call malloc
     mov edx,eax             ;get the retured pointer 
     add esp, 4              ;adjust the stack
     
     call [getchar]          ;call getchar
     mov byte[edx],byte eax  ;<--here, how do i move char(eax) to *edx 

     movsx edi,byte[edx]     ;move value of edx to esi so it can be pushed
     push edi                ;pass esi to putchar
     call [putchar]          ;print the char to console 

     push edx                ;pass edx to be freed
     call [free]             ;call free
     push pausemsg           ;push "puase>nul"
     call [system]           ;pass call system
     push 0                  ;pass o to exit
     call [exit]             ;call exit

section '.idata' import data readable
library msvcrt,'msvcrt.dll'

import msvcrt,\
putchar,'putchar',\
getchar,'getchar',\
system,'system',\
malloc,'malloc',\
free,'free',\
exit,'exit'
    
Post 26 Sep 2010, 00:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 26 Sep 2010, 00:39
Just change byte eax to al.

BTW: most of your calls to the MSVCRT library (putchar, free, system) are not adjusting the stack. If you use that code in a loop, or subroutine, then it will likely crash or do unexpected things.
Post 26 Sep 2010, 00:39
View user's profile Send private message Visit poster's website Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 04:19
ok so my code crashes, i took out the stack adjustment and replaced byte eax with al. why would i just replace byte eax with al? if the value is returned to eax then how dose al work at all here?

here is my current code that im working on as a bases for my little compiler:
Code:
format PE console
entry main

include 'INCLUDE\MACRO\import32.inc'

section '.data' data readable writeable

pausemsg db 'pause>nul',0

section '.code' code readable executable

main:
     push 30000              ;pass 30000 to malloc          
     call [malloc]           ;call malloc
     mov edx,eax             ;get the retured pointer 
     
     call [getchar]          ;call getchar
     mov byte[edx], al  ;<--here, how do i move char(eax) to *edx 

     movsx edi,byte[edx]     ;move value of edx to esi so it can be pushed
     push edi                ;pass esi to putchar
     call [putchar]          ;print the char to console 

     push edx                ;pass edx to be freed
     call [free]             ;call free
     push pausemsg           ;push "puase>nul"
     call [system]           ;pass call system
     push 0                  ;pass o to exit
     call [exit]             ;call exit

section '.idata' import data readable
library msvcrt,'msvcrt.dll'

import msvcrt,\
putchar,'putchar',\
getchar,'getchar',\
system,'system',\
malloc,'malloc',\
free,'free',\
exit,'exit'
    
Post 26 Sep 2010, 04:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 26 Sep 2010, 05:17
ishkabible: You will likely need the stack adjustment if you use this code anywhere else.

Also, the cdecl spec (used by MSVCRT) states that registers eax, ecx, edx and eflags are volatile. So you can't store the address from malloc in edx. You can use another register like esi or ebx.
Post 26 Sep 2010, 05:17
View user's profile Send private message Visit poster's website Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 18:51
ok so im confused by what you have said about stack adjustments, one post you say that adjusting the stack will make it crash and the next you say it is necessary for the program to not crash. so witch is it? im sure that im just not understanding what your saying but im telling you how i interpreted what you said and it is very conflicting. still im puzzled over how to store a truncated 4 byte value in a 1 byte register. im gona compile some simple c programs to see the GCC syntax for how to do this.
Post 26 Sep 2010, 18:51
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA
bitshifter 26 Sep 2010, 19:12
I fix it 4u...
Code:
format PE console
entry main 

include 'INCLUDE\MACRO\import32.inc'

section '.data' data readable writeable 

pausemsg db 'pause',0

section '.code' code readable executable 

main: 

     push 30000
     call [malloc]
     mov edi,eax
     add esp,4

     call [getchar]
     mov byte[edi],al

     movzx esi,byte[edi]
     push esi
     call [putchar]
     add esp,4

     push edi
     call [free]
     add esp,4

     push pausemsg
     call [system]
     add esp,4

     push 0
     call [exit]

section '.idata' import data readable 
library msvcrt,'msvcrt.dll' 

import msvcrt,\ 
putchar,'putchar',\ 
getchar,'getchar',\ 
system,'system',\ 
malloc,'malloc',\ 
free,'free',\ 
exit,'exit' 
    

Note: exit function cleans up stack internally...
Post 26 Sep 2010, 19:12
View user's profile Send private message Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 26 Sep 2010, 19:31
ok how on earth dose mov byte[edi],al work here? i thought that it returned it's value to eax, so how dose al work? o and i think i understand what revolution meant about stack adjusting, i wasn't adjusting the stack for all my calls right.
Post 26 Sep 2010, 19:31
View user's profile Send private message Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler 26 Sep 2010, 20:01
When calling cdecl functions, you must push arguments on the stack, then remove them after the call returns. revolution was trying to tell you that you need to remove them. bitshifter did it for you.

The []s tell it to store the value from al into the memory pointed to by edi, as oppose to without the []s, it would be telling it to store the value from al in edi itself.
Post 26 Sep 2010, 20:01
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 26 Sep 2010, 20:54
ishkabible,

Don't forget that getchar() returns int (signed by default), it can return EOF sometimes.
Post 26 Sep 2010, 20:54
View user's profile Send private message Reply with quote
ishkabible



Joined: 13 Sep 2010
Posts: 54
ishkabible 27 Sep 2010, 00:54
no is answering my question, i thought that getchar returned to eax not al so why dose mov byte[edi],al work here. i know it works as i have tested it (also i finished the Brainfuck compiler Smile ) but i lack the understanding of why the value is being returned to al instead(or maybe both) eax. mabey i should ask "where all dose getchar return to". this was answered by revolution ("Values returned by MSVCRT (and the whole Windows API also) are in EAX.") but i guess it is also returning to al?
Post 27 Sep 2010, 00:54
View user's profile Send private message Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler 27 Sep 2010, 01:07
al is part of eax, it's the lowest byte of it. The cdecl calling convention specifies eax is to be used to return values, it just happens that chars only take up one byte, so the return value is in the lowest byte of eax, aka al.
Post 27 Sep 2010, 01:07
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 27 Sep 2010, 02:26
revolution wrote:

Values returned by MSVCRT (and the whole Windows API also) are in EAX.
Just small clarification, if the data type size is less than 4 bytes, you shall no assume higher bits are cleared, so if the function returns char, you can't expect '0' to be received as $00'00'00'30 but as $xx'xx'xx'30. (The x's can't be assumed to be "value previous to call" neither)
Post 27 Sep 2010, 02:26
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 27 Sep 2010, 05:47
ishkabible wrote:
no is answering my question, i thought that getchar returned to eax not al so why dose mov byte[edi],al work here. i know it works as i have tested it (also i finished the Brainfuck compiler Smile ) but i lack the understanding of why the value is being returned to al instead(or maybe both) eax. mabey i should ask "where all dose getchar return to". this was answered by revolution ("Values returned by MSVCRT (and the whole Windows API also) are in EAX.") but i guess it is also returning to al?
You are not listening. Here is the prototype:

int getchar(void);

It returns int, not char!!! int perfectly fits in eax.
Post 27 Sep 2010, 05:47
View user's profile Send private message Reply with quote
guignol



Joined: 06 Dec 2008
Posts: 763
guignol 27 Sep 2010, 11:51
LocoDelAssembly
Really, give the source of any function?
Post 27 Sep 2010, 11:51
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA
bitshifter 27 Sep 2010, 12:19
Sure i could of store EAX but i was only interested in first byte of it...
You could save all four bytes if you wish...
Code:
mov dword[edi],eax    

Also, i dont think the dword cast is needed if use32
Post 27 Sep 2010, 12:19
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 27 Sep 2010, 14:22
guignol,

You can try it yourself: signed char a() { return -1; } compiles to or al, -1 / ret in VS 2008.

----8<----
bitshifter,

fasm tries to match operand sizes, dword operator is indeed superfluous (this behavior doesn't depend on current default operand size).
Post 27 Sep 2010, 14:22
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.