flat assembler
Message board for the users of flat assembler.

Index > Main > Changing code

Author
Thread Post new topic Reply to topic
l4m2



Joined: 15 Jan 2015
Posts: 674
l4m2 16 Feb 2015, 16:37
Sometimes it goes usually that we change a number in the code so that it would be more easily to program but things come out with bad-looking code:
Code:
  mov [putchr_dat-4],eax
...
  mov al,[ebx+12345678]
putchr_dat:
    

So is there any better way to do this?(Not to use [ebx+esi] for the number of registers is limited)
Post 16 Feb 2015, 16:37
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 16 Feb 2015, 17:33
Simply learn and actively use the named constants...
Code:
Name = 4    

...and data structures:
Code:
struc MyStruc {
  .field1  dd ?
  .field2  dd ?
}    
Post 16 Feb 2015, 17:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 674
l4m2 17 Feb 2015, 08:48
JohnFound wrote:
Simply learn and actively use the named constants...
Code:
Name = 4    

...and data structures:
Code:
struc MyStruc {
  .field1  dd ?
  .field2  dd ?
}    
What?!
Post 17 Feb 2015, 08:48
View user's profile Send private message Reply with quote
Bargest



Joined: 09 Feb 2012
Posts: 79
Location: Russia
Bargest 17 Feb 2015, 10:12
Quote:
Sometimes it goes usually that we change a number in the code so that

In this code you can use eax, because it will be modified anyway by the second mov command (if you don't use ah, of course).
In general you should not modify your code in run-time, because memory containing code should be write-protected for security reasons. It's MUCH better to use different register and/or variables to store needed offsets:
Code:
   mov [offset_var], eax
  ...
   mov eax, [offset_var] ; offset_var is in DATA section
   ; or in stack, in this case use addressing from esp/ebp
   mov al, [ebx + eax]
    
Post 17 Feb 2015, 10:12
View user's profile Send private message Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 674
l4m2 17 Feb 2015, 10:45
Bargest wrote:
Quote:
Sometimes it goes usually that we change a number in the code so that

In this code you can use eax, because it will be modified anyway by the second mov command (if you don't use ah, of course).
In general you should not modify your code in run-time, because memory containing code should be write-protected for security reasons. It's MUCH better to use different register and/or variables to store needed offsets:
Code:
   mov [offset_var], eax
  ...
   mov eax, [offset_var] ; offset_var is in DATA section
   ; or in stack, in this case use addressing from esp/ebp
   mov al, [ebx + eax]
    

I just want to say that these code are in two proc and ah will be used as well as that the latter code will be ran in a loop while the former is run only once.
Post 17 Feb 2015, 10:45
View user's profile Send private message Reply with quote
Bargest



Joined: 09 Feb 2012
Posts: 79
Location: Russia
Bargest 17 Feb 2015, 10:59
In this case you can reserve one register for storing offset or load the offset from variable every time. Modifying code in run-rime is very bad practice.
Also it can be possible to store direct address in ebx without need to add anything every time.
Post 17 Feb 2015, 10:59
View user's profile Send private message Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 674
l4m2 17 Feb 2015, 11:31
Bargest wrote:
In this case you can reserve one register for storing offset or load the offset from variable every time. Modifying code in run-rime is very bad practice.
Also it can be possible to store direct address in ebx without need to add anything every time.

I also know that I can use ebx to store the address but you should know that if it's not allowed to modify the code I would rather use c. Besides you should not see only the scene but also code like mul eax,[ebx],? or worse int ? and for good understanding I did it [/code]
Post 17 Feb 2015, 11:31
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20454
Location: In your JS exploiting you and your system
revolution 17 Feb 2015, 11:51
Some AVs will panic if a program changes its own code. Self modifying code is an old school trick used by much malware.

SMC can also cause some serious performance problems if you don't take care to respect the CPU caching and internal buffers.
Post 17 Feb 2015, 11:51
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 20 Feb 2015, 18:50
revolution,

Methink, caching is OK with SMC, it's prefetching and speculative execution that get in the way.
Post 20 Feb 2015, 18:50
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 20 Feb 2015, 19:43
baldr
You're right except that it happened before Pentium Pro or even Pentium. Since then x86 is very strict about coherence of all the involved buffers, which includes flushing the pipeline in case self-modification happens near the current eip. So now it's just a significant performance penalty.

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Feb 2015, 19:43
View user's profile Send private message Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 674
l4m2 24 Feb 2015, 12:56
In fact,
Code:
shr
    ecx,
  a:?    
will get into at least
Code:
push ecx
mov cl,[a]
shr dword[ecx],cl
pop ecx    
wont it?
Post 24 Feb 2015, 12:56
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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.