flat assembler
Message board for the users of flat assembler.

Index > Main > "Virtual" ... beautiful directive !

Author
Thread Post new topic Reply to topic
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji 13 Jan 2009, 20:48
Code:
struct   INFOµP
   Flop dd ?
   Glop dd ?
ends
------------------------
virtual at TOTO
   Boum INFOµP
end virtual
=================
format PE native
section '.main'
...
mov eax , [Boum.Glop] <---- !!! = mov eax , dword [offset TOTO + 4] 
...
proc
           code
TOTO: cmp edx , .... 
           code
endp    


be able to define a structure in the code

wonderful !!! Very Happy
Post 13 Jan 2009, 20:48
View user's profile Send private message Send e-mail Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder 13 Jan 2009, 22:21
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:53; edited 1 time in total
Post 13 Jan 2009, 22:21
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 14 Jan 2009, 01:36
well, the directive *was* really smart indeed, to solve many issues with single directive...
Post 14 Jan 2009, 01:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji 14 Jan 2009, 11:05
Yes ... only syntax, it's true !
But, it's impossible to do with many other assembler. Place a structure in the code, or relating to an address in the kernel ... imposible with MASM. This directive "Virtual" is really specific Fasm and allows great flexibility.
(sorry for my English, I'm French)
Post 14 Jan 2009, 11:05
View user's profile Send private message Send e-mail Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth 14 Jan 2009, 12:42
ouadji wrote:
Yes ... only syntax, it's true !
But, it's impossible to do with many other assembler. Place a structure in the code, or relating to an address in the kernel ... imposible with MASM.

Nonsense!

Here's one variant how this could be done in Masm syntax:

Code:
INFOuP struct
   Flop dd ?
   Glop dd ?
INFOuP ends

...
mov eax , [Boum.Glop] <---- !!! = mov eax , dword [offset TOTO + 4] 
...
main proc
           code
Boum label INFOuP
TOTO: cmp edx , .... 
           code
main endp
    
Post 14 Jan 2009, 12:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 19872
Location: In your JS exploiting you and your system
revolution 14 Jan 2009, 13:02
I think the main advantage of virtual is in combination with load and store.
Post 14 Jan 2009, 13:02
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji 15 Jan 2009, 10:11
ok Wink

but ...

Code:
virtual at FFDFF040h

virtual at ebx + eax    


with Masm ?
Post 15 Jan 2009, 10:11
View user's profile Send private message Send e-mail Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder 15 Jan 2009, 14:08
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:53; edited 1 time in total
Post 15 Jan 2009, 14:08
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3892
Location: vpcmipstrm
bitRAKE 15 Jan 2009, 16:17
As others have said, virtual solves many problems with one keyword. MASM has assume and label to solve some of those problems, but cannot make decisions at assemble-time based on opcode generation, and code length decisions are limited and cumbersome.
Post 15 Jan 2009, 16:17
View user's profile Send private message Visit poster's website Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth 15 Jan 2009, 18:07
ouadji wrote:

Code:
virtual at FFDFF040h

virtual at ebx + eax    


with Masm ?


I'm unsure what you want to achieve. Perhaps

Code:
    .386
    .model flat

s1 struct
    org 0ffdff040h
v1 dd ?
v2 dd ?
s1 ends

    .code
    
    mov eax, ds:[s1.v1]

    end
    


should be somewhat similar to "virtual at 0ffdff040h".

However, it won't be easy for Masm to emulate virtual in conjunction with load.
Post 15 Jan 2009, 18:07
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 15 Jan 2009, 21:02
Japheth wrote:
However, it won't be easy for Masm to emulate virtual in conjunction with load.

Hello Japheth, I thought there is no way in MASM to load anything at assemble-time. Can you give me an advice?
Post 15 Jan 2009, 21:02
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 15 Jan 2009, 21:16
What about named addressing spaces and scope operator? No more single-byte load/storeWink

Japheth,

virtual at m32 is unbeatable. Wink

_________________
"Don't belong. Never join. Think for yourself. Peace." – Victor Stone.
Post 15 Jan 2009, 21:16
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth 16 Jan 2009, 09:11
Hi MazeGen,

MazeGen wrote:
Japheth wrote:
However, it won't be easy for Masm to emulate virtual in conjunction with load.

Hello Japheth, I thought there is no way in MASM to load anything at assemble-time. Can you give me an advice?


Yes, for Masm the code buffer is "write-only", the <load> directive is probably a unique Fasm feature. Tastes a bit "hackish", though, but that might be because I'm biased...
Post 16 Jan 2009, 09:11
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1898
DOS386 16 Jan 2009, 14:50
> the <load> directive is probably a unique Fasm feature.

I love it Smile
Post 16 Jan 2009, 14:50
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3892
Location: vpcmipstrm
bitRAKE 17 Jan 2009, 04:51
Japheth wrote:
the <load> directive is probably a unique Fasm feature. Tastes a bit "hackish", though
I actually believe FASM didn't go far enough, and should allow code to be executed at assemble-time (i.e. no macro language), but I am slightly crazy. Mainframe (big iron) coders have stated that IBM had a macro assembler which worked similiarly.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 17 Jan 2009, 04:51
View user's profile Send private message Visit poster's website Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth 17 Jan 2009, 05:32
DOS386 wrote:
> the <load> directive is probably a unique Fasm feature.

I love it Smile

Congratulations! But may be you should consider to cool down your emotion a bit. Love makes blind, and you will need sharp eyes to find a useful application for this feature ... Confused
Post 17 Jan 2009, 05:32
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 17 Jan 2009, 19:36
bitRAKE,

Injecting code in fasm? This feature could be useful, but it will add another easy way to screw up… Debugging macros is already hard enough. Wink

_________________
"Don't belong. Never join. Think for yourself. Peace." – Victor Stone.
Post 17 Jan 2009, 19:36
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3892
Location: vpcmipstrm
bitRAKE 18 Jan 2009, 02:46
baldr, nah - it'd be easy - just use the same debugging method used on other code. Deciding what and how to expose the internals would be the real challenge. Well, there is the whole security problem, but let us assume we all have the best intentions (trust must begin somewhere).
Post 18 Jan 2009, 02:46
View user's profile Send private message Visit poster's website 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-2023, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.