#16
|
||||
|
||||
@vic4key
To avoid the application crash you need to allocate/align the stack... Compiled and tested (MSVC 2017 15.7.3) PHP Code:
__________________
Computer Forensics |
The Following User Says Thank You to Insid3Code For This Useful Post: | ||
niculaita (07-19-2018) |
#17
|
||||
|
||||
Hi Insid3Code. Not used any local variables inside. So the allocation is unnecessary I think. Even it can be shorter. Eg.
F1 PROC PUSHAD LEA RCX, TXT_F1 CALL puts POPAD F1 ENDP More, your edited code should be: F1 PROC PUSH RBP MOV RBP, RSP SUB RSP, 40 ; Allocate space on the stack (8 for alignment and 32 for shadow space); Below of MOV RBP, RSP, this instruction already saved RSP to RBP. LEA RCX, TXT_F1 CALL puts LEAVE ADD RSP, 40 ; Cleanup the stack... ; Not needed. The LEAVE instruction did it. RET F1 ENDP |
The Following User Says Thank You to vic4key For This Useful Post: | ||
niculaita (07-21-2018) |
#18
|
||||
|
||||
Hi Vic,
Are you already tested your snippets ? Attached, both snippets (allocate/align) and binaries (one crash the other works fine) I don't know if you can download the attachment from this topic, here external link: PHP Code:
__________________
Computer Forensics |
#19
|
|||
|
|||
Quote:
Quote:
mov rsp, rbp pop rbp lose "add rsp, ..." |
#20
|
|||
|
|||
This discussion is majorly lacking a hugely important point:
Calling convention in x64 always uses the RCX, RDX, R8, R9 registers for passing the first 4 arguments (anything up to 64 bit values or pointers), while additionally to those 4 registers, RAX, R10 and R11 are considered volatile. The return value is in the RAX or possibly for a 128-bit return value would be in the RAX:RDX. This is opposed to x86 where the prior scheme is closest to fastcall which used the ECX and EDX for argument passing before resorting to the stack with additionally the EAX volatile. However in cdecl (caller clean-up stack) calling convention, arguments are all passed on the stack, EAX, ECX and EDX are considered volatile, and the return value in EAX or EAX:EDX. syscall is the same except without the 3 registers being considered volatile. stdcall is also almost the same except the callee cleans up the stack. If mixing C with external asm, it would be extremely wise to be familiar with all these details. For more details which are too lengthly to include, refer to: Quote:
|
#21
|
|||
|
|||
Microsoft x64 calling convention
Quote:
PHP Code:
Last edited by chants; 07-22-2018 at 01:08. |
#22
|
||||
|
||||
Yes, right. In x64 arch, we always need to allocate the space for which called "shadow space". So, the above code should be:
Code:
F1 PROC PUSH RBP MOV RBP, RSP SUB RSP, 0x30 ; Just need to add this instruction. LEA RCX, TXT_F1 CALL puts LEAVE RET F1 ENDP Last edited by vic4key; 07-23-2018 at 00:39. |
The Following User Says Thank You to vic4key For This Useful Post: | ||
niculaita (07-21-2018) |
#23
|
|||
|
|||
It should be:
Code:
F1 PROC PUSH RBP MOV RBP, RSP SUB RSP, 32 ; Allocate space on the stack 32 for shadow space AND RSP, -16 ; Align on 16 bytes LEA RCX, TXT_F1 CALL puts LEAVE RET F1 ENDP |
#24
|
|||
|
|||
You normally don't align stack like that.
You know that the caller has (according to the calling convention) taken care of its stack alignment and therefore the RSP on entry ends by 8 (the stack was 16B aligned before and then the return address has been pushed there by the CALL). So the initial PUSH RBP has aligned the stack to 16B again, SUB RSP, 32 didn't break the alignment - and the AND instruction is useless, RSP is already aligned there. |
#25
|
||||
|
||||
I have to say thank you to all of you guys thank you for your solutions I learned a lot of things.
|
#26
|
||||
|
||||
Quote:
The extra 8 bytes comes from having called your own function within proper convention asm already or the return address in case of Windows ABI invocation. CALL F1 in an improperly aligned routine of course adds 8 bytes to the stack and then adding 8 again would misalign it (hence the code examples leaked out there and above which show 40 byte assuming misalignment by an internal call already from ASM despite not having this in examples). The safest assumption is to assume any caller, and realign the stack with an AND RSP, -16 or even to just do it on just the lower 32-bit ESP. Linux has the same issue even with 32-bit code for late GCC versions as seen in this discussion: Calling printf in extended inline ASM Quote:
Quote:
Quote:
Last edited by chants; 07-22-2018 at 02:26. |
The Following User Gave Reputation+1 to chants For This Useful Post: | ||
niculaita (07-22-2018) |
The Following User Says Thank You to chants For This Useful Post: | ||
niculaita (07-22-2018) |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
inline patche | hp3 | Source Code | 3 | 06-04-2021 14:48 |
X64 inline asm | Fyyre | x64 OS | 48 | 08-10-2014 16:50 |
Inline Patching | MaRKuS-DJM | General Discussion | 1 | 01-24-2004 23:03 |