News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

VARARG

Started by Biterider, November 20, 2017, 07:10:26 AM

Previous topic - Next topic

aw27

It produces the warnings when you BUILD.
IT does not produce warnings when you press F5 to debug-run, because it is assumed that you already know what you are doing (which is not case  :badgrin:).

jj2007


aw27

We already know that you always use all sorts of magic tricks to defend your unrealistic  theories.  :lol:


1>------ Rebuild All started: Project: ConsoleApplication1, Configuration: Release x64 ------
1>  ConsoleApplication1.cpp
1>ConsoleApplication1.cpp(16): warning C4305: 'initializing': truncation from '__int64' to 'long'
1>ConsoleApplication1.cpp(16): warning C4309: 'initializing': truncation of constant value
1>ConsoleApplication1.cpp(27): warning C4305: 'argument': truncation from '__int64' to 'long'
1>ConsoleApplication1.cpp(27): warning C4309: 'argument': truncation of constant value
1>  stdafx.cpp
1>  Generating code
1>  All 6 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>  Finished generating code
1>  ConsoleApplication1.vcxproj -> C:\Users\Jose\Documents\Visual Studio 2015\Projects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe
1>  ConsoleApplication1.vcxproj -> C:\Users\Jose\Documents\Visual Studio 2015\Projects\ConsoleApplication1\x64\Release\ConsoleApplication1.pdb (Full PDB)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

jj2007

Quote from: aw27 on November 21, 2017, 08:22:33 PM
We already know that you always use all sorts of magic tricks to defend your unrealistic  theories.  :lol:

I use default settings, inter alia -W3. Glad to see that it works for you :icon_mrgreen:

aw27

Quote from: jj2007 on November 21, 2017, 08:35:13 PM
IGlad to see that it works for you :icon_mrgreen:
Quote
000000013FF71100 | 49 B9 88 88 88 88 88 88 88 88 | movabs r9, 8888888888888888 | correct!
I have the strange feeling that you are cheating all the time. Since when does Visual Studio use GAS instructions, I mean movabs?  ::)

jj2007

Of course, I love cheating. And feeding trolls :icon_mrgreen:
000000013F4610AC | BA 66 06 00 00                    | mov edx, 666                       |
000000013F4610B1 | 49 B9 88 88 88 88 88 88 88 88     | movabs r9, 8888888888888888        |
000000013F4610BB | C7 44 24 20 11 01 00 00           | mov dword ptr ss:[rsp+20], 111     |

aw27

Quote from: jj2007 on November 21, 2017, 10:57:43 PM
Of course, I love cheating. And feeding trolls :icon_mrgreen:
000000013F4610AC | BA 66 06 00 00                    | mov edx, 666                       |
000000013F4610B1 | 49 B9 88 88 88 88 88 88 88 88     | movabs r9, 8888888888888888        |
000000013F4610BB | C7 44 24 20 11 01 00 00           | mov dword ptr ss:[rsp+20], 111     |


I got it now, you are using one of those crappy disassemblers from github.   :lol:
mov dword ptr ss:[rsp+20], 111 is also lovely.  :badgrin:

jj2007

Quote from: aw27 on November 21, 2017, 11:10:40 PMI got it now, you are using one of those crappy disassemblers from github.   :lol:
mov dword ptr ss:[rsp+20], 111 is also lovely.  :badgrin:

You shouldn't underestimate these tools. Actually, these crappy debuggers (not disassemblers) emulate a whole fake CPU: When they reach that address, and you step through the code, r9 fills magically with 8888888888888888, and memory at [rsp+20] fills with 111. Imagine what a giant programming effort is behind such an emulator 8)

aw27

Quote from: jj2007 on November 21, 2017, 11:24:35 PM
You shouldn't underestimate these tools. Actually, these crappy debuggers (not disassemblers) emulate a whole fake CPU: When they reach that address, and you step through the code, r9 fills magically with 8888888888888888, and memory at [rsp+20] fills with 111. Imagine what a giant programming effort is behind such an emulator 8)
I am not an aficionado of magic debugger/emulators for fake CPUs.  :dazzled:

hutch--

Ha ha, the last disassembler I really liked was 1990 CodeView and used to write code formatted the same way. Now ALA 1998 - 2000 NuMega SoftIce was the genuine boys toy but later versions of Windows were pigs to get any form of debugger working because of their protected mode architecture. What I really need is a post mortem debugger which tells you where an app crashes which is far more use to me. The old DrWatson worked really well at this task but the later Win7 and 10 versions want to dump a pile of high level chyte and send if back to Microsoft.

These days I rarely ever use one, they are easy enough to defeat in security terms and are a lot slower than console output or even message boxes. The real use I have is for a decent disassembler that outputs plain text, ArkDasm barely does the job but it was really useful when I was designing the stack layout and call automation (invoke) macros for 64 but MASM.

jj2007

Quote from: hutch-- on November 22, 2017, 01:23:10 AMWhat I really need is a post mortem debugger which tells you where an app crashes

That is actually possible with x64dbg: Options/Preferences/Misc/Set x64dbg as Just In Time Debugger (as usual, they have ruthlessly stolen that feature from OllyDbg).

When the code crashes e.g. because of an idiv 0, see screenshot below, the grey box to the right appears; click on debug and hit F8 a couple of times, and voilĂ , here it is:
0000000140001089   | 33 C9              | xor ecx,ecx                             |
000000014000108B   | F7 F9              | idiv ecx                                |
000000014000108D   | 48 8D 15 A5 1F 00  | lea rdx,qword ptr ds:[140003039]        | 140003039:"Wow, it works!!"
0000000140001094   | 49 C7 C1 00 00 01  | mov r9,10000                            |
000000014000109B   | 4C 8D 05 A7 1F 00  | lea r8,qword ptr ds:[140003049]         | 140003049:"Hi"
00000001400010A2   | 33 C9              | xor ecx,ecx                             |
00000001400010A4   | FF 15 B6 20 00 00  | call qword ptr ds:[<&MessageBoxA>]      |

aw27

Quote from: jj2007 on November 22, 2017, 01:53:21 AM
That is actually possible with x64dbg: Options/Preferences/Misc/Set x64dbg as Just In Time Debugger (as usual, they have ruthlessly stolen that feature from OllyDbg).

Ahaha  :lol:
But this is not Post-Mortem, the program is still alive. What these github debugger/emulators do is go through the stack trace till where the exception happened.
Windbg does not even let the program crash, it quietly breaks where the exception happened (so they are called 2nd chance exceptions, the debugger gets the second chance to see it live).
This is the difference between a professional tool and a colorful toy downloaded from github.
  :biggrin:
Post-Mortem is working through crash dumps. Here again, only Windbg can do it.

jj2007

Quote from: aw27 on November 22, 2017, 02:36:52 AM.... till where the exception happened.

Which is usually the only aspect that I am interested in :bgrin:

Biterider

Hi
Coming back to VARARG, I noticed that floating point arguments passed as VARARG are stored in GP-Registers and not, as I would expect, in XMM regs. Is that the intended way it should work?



.xmm
option casemap:none
option dotname     
option frame:auto   
option win64:8     
option stackbase:rsp




.code


Test1 proc Arg1:QWORD, Args:VARARG
    mov rax, Arg1
    ret
Test1 endp




start proc
    invoke Test1, 102.54, REAL4 ptr 1.234, REAL8 ptr 1.234
    ret
start endp


end start




Test1 proc Arg1:QWORD, Args:VARARG
mov         qword ptr [Arg1],rcx 
mov         qword ptr [Args],rdx 
mov         qword ptr [rsp+18h],r8 
mov         qword ptr [rsp+20h],r9 
    mov rax, Arg1
mov         rax,qword ptr [Arg1] 
    ret
ret 
Test1 endp

The disassembly looks like

start proc
sub         rsp,28h 
    invoke Test1, 102.54, REAL4 ptr 1.234, REAL8 ptr 1.234
mov         r8,3FF3BE76C8B43958h 
mov         edx,3F9DF3B6h 
mov         rcx,42CD147Bh 
call        Test1 (0811000h) 
    ret
add         rsp,28h 
ret 



I'm not sure why the callee is saving all regs into the homing area. Has it something to do with the VARARG feature?


Biterider

johnsa

Yes it is. the items in vararg are effectively untyped, so they're passed in register and then stored in home-spaces and further stack spaces for consistency.
So it would be the first argument that in some way would be required to determine the count and type of the variable arguments, which could then be found and processed from stack locations.