HTB academy intro to assembly language skills assessment task 1

I've been pulling my hair out for 3 days trying to figure this out.

I have successfully added the loop and xor decoded the code on the stack, but I have no idea how to run it once it's there. I have tried everything from writing a "print" syscall to copy and pasting the code and just using pwntools to run it. Nothing works. I cant get the shell code to excecute. Please help

This is my code:

global _start
section .text
_start:
mov rax,0xa284ee5c7cde4bd7
push rax
mov rax,0x935add110510849a
push rax
mov rax,0x10b29a9dab697500
push rax
mov rax,0x200ce3eb0d96459a
push rax
mov rax,0xe64c30e305108462
push rax
mov rax,0x69cd355c7c3e0c51
push rax
mov rax,0x65659a2584a185d6
push rax
mov rax,0x69ff00506c6c5000
push rax
mov rax,0x3127e434aa505681
push rax
mov rax,0x6af2a5571e69ff48
push rax
mov rax,0x6d179aaff20709e6
push rax
mov rax,0x9ae3f152315bf1c9
push rax
mov rax,0x373ab4bb0900179a
push rax
mov rax,0x69751244059aa2a3
push rax
mov rbx,0x2144d2144d2144d2
mov rcx, 14
lea rdx, [rsp]
loopfun:
xor [rdx], rbx
add rdx, 8
loop loopfun

Comments

  • Like a Neanderthal, I dumped the memory in question in the debugger, copy/pasted it into a text editor, and manually cleaned it up. (I'm sure more patient/efficient people wrote the asm commands to print it out though :blush: ). After that I did use a script presented earlier in the module to run it.

  • Type your comment> @PartyGolbez said:

    Like a Neanderthal, I dumped the memory in question in the debugger, copy/pasted it into a text editor, and manually cleaned it up. (I'm sure more patient/efficient people wrote the asm commands to print it out though :blush: ). After that I did use a script presented earlier in the module to run it.

    I tried that too after a while and It didn’t work. Did you have to reverse the byte order (because it’s little endian)? Did you put it in backwards (because by the end rsp is the last set of instructions given) ?

  • Good question about the little-endianness. I did not reverse the order and I dumped "giant" (8-byte) words. However I just tried dumping smaller units and yeah, they are reversed to some extent. I need to wrap my head around why the giant size is the only view that dumps the memory exactly "in order" - it's definitely confusing.

    As far as the range of memory (the above notwithstanding), write it out from the lower address to the higher address, just as a CPU would read it. (don't get confused by the way the stack grows "down").

    I wonder if there's a way to run this straight from memory (or if that's what's intended) vs dumping it out and running it later. I'm definitely not a magician when it comes to this :)

  • Type your comment> @PartyGolbez said:
    > Good question about the little-endianness. I did not reverse the order and I dumped "giant" (8-byte) words. However I just tried dumping smaller units and yeah, they are reversed to some extent. I need to wrap my head around why the giant size is the only view that dumps the memory exactly "in order" - it's definitely confusing.
    >
    > As far as the range of memory (the above notwithstanding), write it out from the lower address to the higher address, just as a CPU would read it. (don't get confused by the way the stack grows "down").
    >
    > I wonder if there's a way to run this straight from memory (or if that's what's intended) vs dumping it out and running it later. I'm definitely not a magician when it comes to this :)

    Finally got it. Thank you!
  • That's awesome you got it, congrats! I am compelled to correct something I said though. I implied that dumping "giant" words in gdb shows the actual order of the bytes in memory. This is incorrect - the way to show the true order of the bytes in memory is to dump them one byte at a time (x/16xb [address]) for example. Dumping larger sizes (e.g. halfwords, etc) causes the debugger to "interpret" them as that size and reverse the bytes within the individual units . So dumping giant words (x/2xg [address]) shows each set of 8 bytes in reverse order.

    So how did me copying and pasting these giant words into a text editor produce a valid result? I honestly have no idea. Maybe the lab was set up that way, assuming we'd be looking at the values in 64-bit (aka 8-byte aka giant-word aka register-sized) chunks. But I would love someone to explain that to me.

    Sorry if I've confused everyone :) Would love a True Expert to weigh in!

  • Type your comment> @PartyGolbez said:
    > That's awesome you got it, congrats! I am compelled to correct something I said though. I implied that dumping "giant" words in gdb shows the actual order of the bytes in memory. This is incorrect - the way to show the true order of the bytes in memory is to dump them one byte at a time (x/16xb [address]) for example. Dumping larger sizes (e.g. halfwords, etc) causes the debugger to "interpret" them as that size and reverse the bytes within the individual units . So dumping giant words (x/2xg [address]) shows each set of 8 bytes in reverse order.
    >
    > So how did me copying and pasting these giant words into a text editor produce a valid result? I honestly have no idea. Maybe the lab was set up that way, assuming we'd be looking at the values in 64-bit (aka 8-byte aka giant-word aka register-sized) chunks. But I would love someone to explain that to me.
    >
    > Sorry if I've confused everyone :) Would love a True Expert to weigh in!

    There must be a way to iterate through the stack and print the result as shell code
  • Definitely, after xor-ing you could probably write a similar loop and use printf (covered in the "functions" part of the module) to format the memory as hex and print it out.

Sign In to comment.