Author Topic: crash with uasm  (Read 2135 times)

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #15 on: December 18, 2019, 10:35:21 PM »
IDA is powerfull too, they changed to Qt.
I'm actually redirecting objdump output to a file.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

mabdelouahab

  • Member
  • ***
  • Posts: 454
Re: crash with uasm
« Reply #16 on: December 19, 2019, 03:27:58 AM »
Thanks, mineiro, you confirm what I am saying
  See the result:
rsp aligned = 0
rsp aligned = 0
rsp aligned = 0
rsp aligned = 0
rsp aligned = 0
bash: line 1:  6565 Segmentation fault


it was determined that rsp is aligned for the fifth time, Then it came after this "sub     rsp, 8"
This means that after this line RSP not aligned


0x00401301      mov     rax, rsp
0x00401304      and     rax, 0xf   ; 15
0x00401308      test    rax, rax
0x0040130b      jne     0x401320
0x0040130d      lea     rdi, obj.__0008 ; 0x40414f ; "rsp aligned = %x\n" ; const char *format
0x00401314      mov     rsi, rax
0x00401317      xor     eax, eax
0x00401319      call    sym.imp.printf ; int printf(const char *format)
0x0040131e      jmp     0x401341
0x00401320      lea     rdi, obj.__0009 ; 0x404161 ; "rsp not aligned = %x\n" ; const char *format
0x00401327      mov     rsi, rax
0x0040132a      xor     eax, eax
0x0040132c      call    sym.imp.printf ; int printf(const char *format)
0x00401331      mov     rax, 0x3c  ; '<' ; 60
0x00401338      mov     rdi, 0xffffffffffffffff
0x0040133f      syscall
0x00401341      sub     rsp, 8
0x00401345      mov     rdi, qword [obj.WWatchBuffer] ; 0x404058
0x0040134c      lea     rsi, obj.__ls14102 ; 0x404177 ; "red_foreground"
0x00401353      lea     rdx, obj.__ls50762 ; 0x404186 ; "foreground"
0x0040135a      lea     rcx, obj.__ls2622 ; 0x404191 ; "red"
0x00401361      xor     r8, r8
0x00401364      xor     eax, eax
0x00401366      call    sym.imp.gtk_text_buffer_create_tag      ;<------ crash
0x0040136b      add     rsp, 8

mabdelouahab

  • Member
  • ***
  • Posts: 454
Re: crash with uasm
« Reply #17 on: December 19, 2019, 03:49:44 AM »
Try IDA, probably is the friendliest thing for Linux. (I am talking about the free version, image below)

I use : Cutter-v1.9.0-x64 for linux

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #18 on: December 19, 2019, 04:12:42 AM »
hello sir mabdelouahab;
This sounds strange, that program works fine here. I received 6 stack aligned messages before return. I have used an older and new uasm.
Well, you probably can avoid that error by inserting an "add rsp,8" before "xor eax,eax ret". That's why I have tried main as a main label,  main proc and a main decorated proc. That main as label is usefull if we are playing with "_start" label.
If you insert an "exit" call instead of "ret"I supose that everything goes fine.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

AW

  • Member
  • *****
  • Posts: 2583
  • Let's Make ASM Great Again!
Re: crash with uasm
« Reply #19 on: December 19, 2019, 04:31:13 AM »
Before the first call to gtk_text_buffer_create_tag it does "sub rsp, 8" to keep the stack aligned after the 9 pushes that follow. After the call to gtk_text_buffer_create_tag, it restores the stack by adding 50h, so it works fine.
On the second call to gtk_text_buffer_create_tag it does "sub rsp, 8" for no particular reason, misaligns the stack and causes the fault.
Anything new in what I said? No.

So, it is without doubts a bug.

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #20 on: December 19, 2019, 05:13:35 AM »
This is because that function is using 9 arguments/parameters. An odd number. If just push a foo that will work nice because even. This also happens in windows.

Change to:
          invoke gtk_text_buffer_create_tag,WWatchBuffer, "rtl_quote",\
                                   "foreground", "green",\
                                   "wrap_mode", 2,\
                                   "direction", 2,\
                                   "indent", 30,\
                                   "left_margin", 20,\
                                   "right_margin", 20,\
                                   0,0          ;<-- a foo push inserted to be even
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

mabdelouahab

  • Member
  • ***
  • Posts: 454
Re: crash with uasm
« Reply #21 on: December 19, 2019, 05:32:24 AM »
This is because that function is using 9 arguments/parameters. An odd number. If just push a foo that will work nice because even. This also happens in windows.

Change to:
          invoke gtk_text_buffer_create_tag,WWatchBuffer, "rtl_quote",\
                                   "foreground", "green",\
                                   "wrap_mode", 2,\
                                   "direction", 2,\
                                   "indent", 30,\
                                   "left_margin", 20,\
                                   "right_margin", 20,\
                                   0,0          ;<-- a foo push inserted to be even

:biggrin: It really works
Code: [Select]
        invoke gtk_text_buffer_create_tag ,WWatchBuffer,"red_foreground","foreground", "red", 0   ,0,0                             
0x004011f1      sub     rsp, 8
0x004011f5      mov     rdi, qword [obj.WWatchBuffer] ; 0x404058
0x004011fc      lea     rsi, obj.__ls14102 ; 0x4040af ; "red_foreground"
0x00401203      lea     rdx, obj.__ls50762 ; 0x4040be ; "foreground"
0x0040120a      lea     rcx, obj.__ls2622 ; 0x4040c9 ; "red"
0x00401211      mov     r8, 0
0x00401218      xor     r9, r9
0x0040121b      push    0
0x0040121d      xor     eax, eax
0x0040121f      call    sym.imp.gtk_text_buffer_create_tag
0x00401224      add     rsp, 0x10

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #22 on: December 19, 2019, 06:16:44 AM »
Yes, the point is:
We are building a function to other users. We know that rsp need be aligned, so user will use a "call' to invoke our function and at entrance of our function rsp will be unaligned by 8 (call subtracted 8 from rsp).
If our function uses static 9 or 5 or 7 parameters, thats ok, because thats static, we can predict rsp. But the point are functions that use variable parameters, how they can know how many parameters have been passed?

---edit---
that function use pairs parameters.
« Last Edit: December 19, 2019, 09:59:37 AM by mineiro »
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #23 on: December 19, 2019, 01:01:49 PM »
hello sir mabdelouahab;
Please, can I ask 2 questions?
I tried last source code and removed -no-pie command line in gcc to be able to compile. Is that working to you? I see too -fno-pie, this I preserved.

Your disassembly differs from mine, I was not able to find any "add rsp, 0x10" in that source code.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

AW

  • Member
  • *****
  • Posts: 2583
  • Let's Make ASM Great Again!
Re: crash with uasm
« Reply #24 on: December 19, 2019, 02:36:21 PM »
mabdel added 2 zeros, that's the trick  :biggrin:

Hopefully, Johnsa will appear and fix this and other issues.

I tried Asmc and this builds and runs fine:
Code: [Select]
;test : test.o
; gcc -no-pie -o test test.o `pkg-config --cflags --libs gtk+-3.0`
;test.o : test.asm
; ./asmc -elf64 test.asm

include stdio.inc
LPVOID typedef ptr

    gtk_init                    PROTO SYSCALL  :ptr,:ptr
    gtk_text_view_new           PROTO SYSCALL
    gtk_text_view_get_buffer    PROTO  SYSCALL :ptr
    gtk_text_buffer_create_tag  PROTO  SYSCALL :ptr,:ptr,:ptr,:VARARG
.DATA
        WWatch                  LPVOID    0
        WWatchBuffer            LPVOID    0
.CODE
    main PROC
       invoke gtk_init,0,0
       invoke gtk_text_view_new
       mov WWatch              ,rax
       invoke gtk_text_view_get_buffer,WWatch
       mov WWatchBuffer ,rax
       gtk_text_buffer_create_tag(WWatchBuffer,"rtl_quote","foreground","green", "wrap_mode", 2,"direction", 2,"indent", 30,"left_margin", 20,"right_margin", 20,0)
       gtk_text_buffer_create_tag (WWatchBuffer,"red_foreground","foreground", "red",0,0)
       xor rax,rax
       ret
    main ENDP
end

Not all is well, though:  :sad:


« Last Edit: December 19, 2019, 05:38:30 PM by AW »

nidud

  • Member
  • *****
  • Posts: 1980
    • https://github.com/nidud/asmc
Re: crash with uasm
« Reply #25 on: December 19, 2019, 11:35:57 PM »
Not all is well, though:  :sad:

Unix will assume a foreslash as a directory so this is removed from the Linux version.
Try this: ./asmc -?

AW

  • Member
  • *****
  • Posts: 2583
  • Let's Make ASM Great Again!
Re: crash with uasm
« Reply #26 on: December 20, 2019, 12:55:37 AM »
Thank you nidud.  :thumbsup:

This is a reviewed version without the include file:

Code: [Select]
OPTION WIN64:AUTO
LPVOID typedef ptr
    gtk_init                    PROTO :ptr,:ptr
    gtk_text_view_new           PROTO
    gtk_text_view_get_buffer    PROTO  :ptr
    gtk_text_buffer_create_tag  PROTO  :ptr,:ptr,:ptr,:VARARG
.DATA
        WWatch                  LPVOID    0
        WWatchBuffer            LPVOID    0
.CODE
    main PROC
        invoke gtk_init,0,0
        invoke gtk_text_view_new
        mov WWatch              ,rax
        invoke gtk_text_view_get_buffer,WWatch
        mov WWatchBuffer        ,rax
       gtk_text_buffer_create_tag(WWatchBuffer,"rtl_quote","foreground","green", "wrap_mode", 2,"direction", 2,"indent", 30,"left_margin", 20,"right_margin", 20,0)
        gtk_text_buffer_create_tag (WWatchBuffer,"red_foreground","foreground", "red",0,0)
        xor rax,rax
        ret
    main ENDP
end

May be WIN64:3 is enough. Yeah, WIN64 is valid for Linux as well.

mineiro

  • Member
  • ****
  • Posts: 615
Re: crash with uasm
« Reply #27 on: December 20, 2019, 01:36:36 AM »
I was able to check this error, so you're right sir mabdelouahab.
the code bellow works fine:
Code: [Select]
;uasm -elf64 tagex.uasm
;gcc -o out tagex.o `pkg-config --cflags --libs gtk+-3.0`
;./out ; echo $?

.X64
OPTION LITERALS:ON

    gtk_init                    PROTO  :QWORD,:QWORD
    gtk_text_view_new           PROTO
    gtk_text_view_get_buffer    PROTO  :ptr
    gtk_text_buffer_create_tag  PROTO  :ptr,:ptr,:ptr,:VARARG
    exit proto status:dword
.DATA
        WWatch                  qword    0
        WWatchBuffer            qword    0
.CODE
    main PROC
       invoke gtk_init,0,0
       invoke gtk_text_view_new
       mov WWatch              ,rax
       invoke gtk_text_view_get_buffer,WWatch
       mov WWatchBuffer ,rax
       invoke gtk_text_buffer_create_tag,WWatchBuffer,"rtl_quote","foreground","green", "wrap_mode", 2,"direction", 2,"indent", 30,"left_margin", 20,"right_margin",20,0,0
       invoke gtk_text_buffer_create_tag, WWatchBuffer,"red_foreground","foreground","red",0
       invoke exit,2
    main ENDP
end
If that line change to:
invoke gtk_text_buffer_create_tag,WWatchBuffer,"rtl_quote","foreground","green", "wrap_mode", 2,"direction", 2,"indent", 30,"left_margin", 20,"right_margin",20,0
So stack gets unaligned into next call. Odds and even.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

nidud

  • Member
  • *****
  • Posts: 1980
    • https://github.com/nidud/asmc
Re: crash with uasm
« Reply #28 on: December 20, 2019, 01:42:57 AM »
May be WIN64:3 is enough.

W64F_AUTOSTACKSP (2) is used for alignment in ELF64 so OPTION win64:2 should work or maybe win64:auto but yes, the default defined in the header files is 3.

Quote
Yeah, WIN64 is valid for Linux as well.

The result of the rewrite of the INVOKE directive enables VECTORCALL and FASTCALL in Linux but more to the point: you may now use SYSCALL in Windows. The assembler defines _WIN64 for 64-bit and (in addition) _LINUX(2) for ELF64 and _LINUX(1) for ELF.

AW

  • Member
  • *****
  • Posts: 2583
  • Let's Make ASM Great Again!
Re: crash with uasm
« Reply #29 on: December 20, 2019, 02:57:14 AM »
Asmc is done with great attention to details and has more to offer than most people is aware of (including myself).  :thumbsup: