flat assembler
Message board for the users of flat assembler.
Index
> High Level Languages > C++ and ASM routine. Goto page 1, 2, 3, 4, 5 Next |
Author |
|
revolution 20 Oct 2010, 02:59
|
|||
20 Oct 2010, 02:59 |
|
DarkAlchemist 20 Oct 2010, 03:16
The global is defined in the C++ files and I am only using it from within the ASM section I am trying to write.
Another question that I have is how to deal with class variables as defined in the C++ .h? |
|||
20 Oct 2010, 03:16 |
|
Tyler 20 Oct 2010, 03:51
Within reasonable amounts of effort, you can't. If you're interested in investing "unreasonable amounts of effort", get the idea out of your head now. I'm not even sure it's possible. If it is, you'd have to learn the naming convention for the specific version of your compiler and for any non-static member function, you'd have to figure out how to emulate passing the "this" parameter, plus a shitload of stuff I can't think of(If there's anything big, revolution will tell you ).
Long story short, just NO!!! |
|||
20 Oct 2010, 03:51 |
|
LocoDelAssembly 20 Oct 2010, 04:09
If you mean class variable rather than instance variable, you could define a helper function in an - extern "c" - block which has a way more simple name mangling, and then make your assembly routine call it. In the case of accessing instance variables, I'm not sure if you could still have a pointer to class instance parameter, so in that case you may be forced to use a "void *" parameter and then cast to the supposed class instance it should be receiving.
|
|||
20 Oct 2010, 04:09 |
|
baldr 20 Oct 2010, 09:07
Tyler wrote: …you'd have to learn the naming convention for the specific version of your compiler… Tyler wrote: …for any non-static member function, you'd have to figure out how to emulate passing the "this" parameter… For real challenge, look at constructors/destructors and object lifetime management. If compiler can produce code to do something, you always can do the same in assembly language. Compilers don't invent, they just apply known patterns (zillion of times if needed). |
|||
20 Oct 2010, 09:07 |
|
vid 20 Oct 2010, 10:58
Quote: I have a global variable that I use inside a function in C++ but if I wanted to rewrite the routine in ASM how do I address the local variables that the function is called with Function is not called with "local variables", it is called with "arguments", or "parameters". Local variables are those which are defined inside function body. Code: void function( int a, char *b //these are arguments ) { int c, d; // these are local variables ... Which of the two did you mean? Quote: Another question that I have is how to deal with class variables as defined in the C++ .h? baldr wrote: If compiler can produce code to do something, you always can do the same in assembly language. Compilers don't invent, they just apply known patterns (zillion of times if needed). Of course it is possible, but still it is a very bad idea to do. Especialy to someone just starting. |
|||
20 Oct 2010, 10:58 |
|
DarkAlchemist 20 Oct 2010, 13:35
I meant the second one as the first one will be on the stack when the function is called.
See, I have int x = base + 1000; in C++ and base is a class variable while, as we can see, the x is a local variable. As far as the class variable I suppose I can just pass it as a parameter on the stack when I call the function so nothing major there just a few clock cycles. |
|||
20 Oct 2010, 13:35 |
|
vid 20 Oct 2010, 14:06
For the second one, you will do it like this:
Code: my_proc: push ebp ;preserve caller's value of ebp mov ebp, esp ;point ebp to this place on stack sub esp, 8 ;reserve space on stack for local variables label .loc1 dword at ebp-4 ;declare variables where on stack they are label .loc2 dword at ebp-8 ;here just use ".loc1" and ".loc2" as any variables ... .end_of_proc: mov esp, ebp ;reset esp back pop ebp ;restore callers ebp retn I suggest you to read about "stdcall" and "ccall" calling standards, and/or try to trace procedure code in OllyDbg |
|||
20 Oct 2010, 14:06 |
|
DarkAlchemist 20 Oct 2010, 15:20
What if one of the locals is an ASCII string (8 bits to a byte xx length of bytes)?
|
|||
20 Oct 2010, 15:20 |
|
baldr 20 Oct 2010, 15:22
DarkAlchemist,
Don't be shy, post some C++ source that will show us the problem explicitly. |
|||
20 Oct 2010, 15:22 |
|
DarkAlchemist 20 Oct 2010, 15:54
I don't have an example of the ASCII string question.
Last edited by DarkAlchemist on 21 Oct 2010, 01:26; edited 1 time in total |
|||
20 Oct 2010, 15:54 |
|
baldr 20 Oct 2010, 19:35
DarkAlchemist,
It doesn't help. Looks like you don't understand break completely. |
|||
20 Oct 2010, 19:35 |
|
DarkAlchemist 20 Oct 2010, 20:29
That routine works without fail in C++.
Maybe you aren't understanding the routine and are trying to pass it off because, as I said, it works and has worked for me for the last 3 years. Let me simplify it for you. While loop and I readprocessmemory of 8k length. I scan the 8k length looking for a match of XX bytes and if no match scanning those bytes I then break out of the innermost for loop that will increment the offset by one but if the bytes matched up then it will break out of the the loop and break out of the while returning the status that it had a match while lpAdd is now equal to where the match began otherwise add 8k to lpAdd and loop back around reading the next chunk of processor memory. Oh, the lpAdd is a global if you didn't catch on about it. Very simple really. |
|||
20 Oct 2010, 20:29 |
|
vid 20 Oct 2010, 22:59
baldr was probably hinting at fact that you could simply return value right in from inside of loop body, instead of setting proxy variable, breaking out of loop, and returning the variable from there.
Anyway, my advice is: if you want to create arrays (such as string buffer) on stack, I sugest you first understand plain variables first. Pick some simpler C proc without local arrays, and try to convert that to Asm. |
|||
20 Oct 2010, 22:59 |
|
LocoDelAssembly 20 Oct 2010, 23:23
Your inner for-loop is not ensuring dwBuffer references are always inside the array. You probably never noticed this because exceeding the array bounds would make your code read local variables, parameters, return address and whatever was in the stack already so no access violation could occur easily here since it would require a large sizeofcode and also be so unfortunate that the latest dwBuffer bytes plus the stack contents past the dwBuffer together match your search pattern.
Since I think I did a mess above trying to explain, I think I better give an example: dwbuffer[4091] == 'L' and s_codeSearch = {'L', 'O', 'C', 'O'}. When attempting to match the first 'O', your code will read outside the dwBuffer. PS: An extra flaw in your program, and perhaps more important than the one above, is that it won't find a match if the pattern crosses an 8 KB boundary. |
|||
20 Oct 2010, 23:23 |
|
DarkAlchemist 21 Oct 2010, 01:31
You are right Loco but it is my bad for posting an old version of the code (removed that now). The first part of your two part was correct for that code but later I changed it to "<NumberOfBytesRead - sizeofcode" so it would never go outside of bounds.
As far as your second point it is a valid point and if L fell at 8192 there is no checking for "OCO" when I load up the next 8192 bytes of memory but this never seemed to be an issue though it could be. Fact is this entire thread seems to have went off on a tangent instead of the question at hand though I thank you for showing me point #2 since I had never thought about that. Oh, and vid, if that is what he meant then I will tell you it is considered EXTREMELY bad practice to have more than one return per routine in C++. Two different instructors and a few books I have read pushed that into my head. |
|||
21 Oct 2010, 01:31 |
|
Tomasz Grysztar 21 Oct 2010, 09:13
DarkAlchemist wrote: Oh, and vid, if that is what he meant then I will tell you it is considered EXTREMELY bad practice to have more than one return per routine in C++. |
|||
21 Oct 2010, 09:13 |
|
vid 21 Oct 2010, 11:22
Quote: Fact is this entire thread seems to have went off on a tangent instead of the question at hand though I thank you for showing me point #2 since I had never thought about that. Have you already succeeded in converting simpler procedure (without arguments/locals, then without locals, then without local arrays, ...) to asm? If so, we can move on to explaining arrays, but one step at a time please. Trying to explain more complicated things while we are not sure you understand more basic things could easily turn out being pointless. Quote: Oh, and vid, if that is what he meant then I will tell you it is considered EXTREMELY bad practice to have more than one return per routine in C++. Two different instructors and a few books I have read pushed that into my head. And what did they say about reason why this is is an EXTREMELY bad practice? |
|||
21 Oct 2010, 11:22 |
|
DarkAlchemist 21 Oct 2010, 11:56
Vid, they just said it was bad practice and shows a lack of programming knowledge (like using goto) of the language. The general rule is one return per function (I still call functions routines from my old asm days).
I have managed to compile a c++ test program inserting my fasm obj file in msvc. The function was called with 3 parameters and I grabbed those. This is what I have so far just testing by calling in the c++ program with 3 ints (1,2,3) Code: ;(int sizeofcode, BYTE *s_codeSearch, int &lpAdd) ; int x = base + 0x3fd000; ; BYTE dwBuffer[8192]; ; SIZE_T NumberOfBytesRead = 0; ; int dwMax = (x - sizeofcode); ; bool found = true; pushad mov eax, [esp+0x2c] mov [lpAdd], eax mov eax, [esp+0x28] mov [s_codeSearch], eax mov eax, [esp+0x24] mov [sizeofcode], eax mov ebp, esp ;point ebp to this place on stack sub esp, 16 ;reserve space on stack for LOCAL variables label x dword at ebp-4 label NumberOfBytesRead dword at ebp-8 label dwMax dword at ebp-12 label found dword at ebp-16 mov [x],0x3fd000 mov [NumberOfBytesRead], 0 mov eax, [x] sub eax, [sizeofcode] mov [dwMax], eax mov [found], 0 mov esp,ebp popad add esp, 16 retn The above worked when I used Olly to debug it. |
|||
21 Oct 2010, 11:56 |
|
Goto page 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.