LC-3 operation TRAP IN - lc3

What function does IN do? The textbook says it "Print prompt on console, read (and echo) one character from keybd. Character stored in R0[7:0]". Does it mean that IN can print out the input character on the console? Also, I wonder if I use GETC and OUT together, can it have the same effect as IN ?

I suggest testing it in a simulator. You can just write a program like the below, run it in the simulator (make sure to load the OS also!) and you can answer your own question...
.orig x3000
TEST_IN IN
TEST_GETCOUT GETC
OUT
BR TEST_IN
.end

Related

HEX Substraction in Windows ASM Shellcode returns wrong values

I'm working on some shellcoding, and have this weird result on my Windows VM. The idea is, starting from Zero, carve out some value. In this case, I need that the value is equals to: 0x50505353
(gdb) print /x 0 - 0x38383536 - 0x77777777
$1 = 0x50505353
In Python, GDB, OSX, Linux and everything else, this operation works as expected. On the Windows VM, when I perform the PUSH on OllyDBG or Immunity the result is: 0x52535051
So the question is, WHY? What I'm missing here?
This is the operation done in ASM:
AND EAX,65656565
AND EAX,1A1A1A1A
SUB EAX,38383536
SUB EAX,77777777
PUSH EAX
The first couple of AND transform EAX = 0x00000000. Then I can subtract from that. Just to be clear, I cannot use XOR on this test.
This is because you are not subtracting 0x38383536, you are subtracting 0x36353838, which gives the result you stated.
I just found the problem. When I do the calculations outside the Debugger, forgot the small detail that in order to use them in the shellcode, I should use the same values in reverse Endian Order.
Mental note: Always remember to check the order that you are working.
Thanks to all.
To be clear, are you saying error happens on the gdb command line as well as in your windows VM program? If gdb is giving rubbish then something is wrong with the VM.
Do you have gdb or another debugger working on the Windows VM? I'm a little confused about your runtime environment where you are seeing the error
If you have gdb where the error is occurring then here is how to debug.
If it is the program only then use stepi and info regs to see what is going on. The value of $eax before that last subtraction is likely the one of interest but check each instruction. If $eax has the correct value at the push then look around $sp in memory for the value. If it is still correct then follow the return from the function and look for the corresponding pop or stack read and check the value there. Perhaps the stack is getting corrupted before you actually print/use the value?

Using a custom LC-3 trap routine

I wrote a subroutine to be used as a Trap call via Trap x26. My code for my subroutine is at address x3300. I cannot figure out how to jump from x26 to my actual instructions for the subroutine at x3300, since the gap is greater than JSR's PC offset parameter allows. I know I could add some code in near x26 to make it possible to jump all the way to x3300, but I don't think that's how I am supposed to do it. I think I'm missing something with understanding traps in general.
Here's my understanding/confusion of traps: So from x0000 - X00FF is the trap vector table. For example, if you call TRAP x20, then the PC goes to x20 and continues execution with the instruction at x20. (Please let me know if this is incorrect!) At this point I am confused because at the address x20 in the LC-3 is a BRZ x0021 command, which takes the PC to x21. At x21, there is a BRZ x52command. When this branch gets executed to go to x52 plus the PC, the command there is TRAP x00. Most of the Trap 20's commands seem to go to these (what look like) nonsense trap commands. After the trap x00 is executed, the program goes to xFD79. This is really confusing me since at x00 in memory, there is just another TRAP x00. To me, it seems like the program should go to x00 instead of xFD79.
Can someone help explain this to me please? What exactly is going on when a trap is called? I thought it just went to another address in memory where the actual code for the instruction was and executed that, but what I have seen doesn't reflect that. Any help is greatly appreciated as this is preventing me from completing a school project right now.
Thanks!
"So from x0000 - X00FF is the trap vector table. For example, if you call TRAP x20, then the PC goes to x20 and continues execution with the instruction at x20. (Please let me know if this is incorrect!)"
This is correct, however the next sentence...
"At this point I am confused because at the address x20 in the LC-3 is a BRZ x0021 command, which takes the PC to x21"
The command you see which looks like a BRz is not, in fact, an instruction. It is an address! x0400 would be a fairly useless command - it the PC offset is zero, so it just goes to the next line. If you interpret it as an address instead, and go to that address as part of the trap call, you will find the rest of the trap instructions.

how to force gdb to stop right after the start of program execution?

I've tried to set breakpoint on every function that makes any sense but program exit before reaching any of those. Is there a way to make program run in step-by-step mode from the start so I can see what's going on?
I'm trying to debug /usr/bin/id if it's important (we have custom plugin for it and it's misbehaved)
P.S. Start command doesn't work for me here(it should be a comment, but I don't have enough rep for it)
Get the program entry point address and insert a breakpoint at that address.
One way to do this is to do info files which gives you for example "Entry point: 0x4045a4". Then do "break *0x4045a4". After run-ning program, it will immediately stop.
From here on you can use single stepping instructions (like step or stepi) to proceed.
You did not tell what system you are trying to debug. If code is in read-only memory you may need to use hardware breakpoints (hbreak) if they are supported by that system.
Use start command
The ‘start’ command does the equivalent of setting a temporary breakpoint at the beginning of the main procedure and then invoking the ‘run’ command.
e.g.
a program with debug info main, and usage like this: main arg1 arg2
gdb main
(gdb) start arg1 arg2
Use starti. Unlike start this stops at the actual first instruction, not at main().
You can type record full right after running the program. This will record all instructions and make them possible for replaying/going back.
For main function, you'd need to type this before reaching the breakpoint so you can set an earlier one by break _start -> _start is a function always called before the standard main function. (apparently applies only to the gcc compiler or similar)
Then continue to main breakpoint and do reverse-stepi to go exactly one instruction back
For more info about recording look here: link

Assembly: What is the best way to print something to screen (to command line)

I've been doing some research, but I only find more and more ways to do what I want and I don't understand any of them.
What code do I need to assemble into an .exe to return 5 to the command line?
I want an exe that, when called, prints 5 .
Research:
printf "5", 0
It requires to link with 2 libraries, and I want to keep it simple.
move ebx, 5 ; or move ax, 5
ret
Why would this print 5 ? This loads a register whith a value 5 and returns. Nothing else.
Could someone explain me the difference between those ways of returning 5?
What would be most appropiate for a very simple Windows EXE executable?
I couldn't get the answers in the questions already asked in StackOverflow.
NOTE, I use: Win 7, WinAsam, MASM
THANKS!
Why not use printf? On windows, it is part of the MS C Runtime that is part of windows now.
Using the Windows API, you would use:
GetStdHandle
And one of the following:
WriteConsole
WriteConsoleOutput
WriteConsoleOutputAttribute
WriteConsoleOutputCharacter
WriteFile
All depends on how you want to do it.
moving something into a register does not print anything, you have to tell the OS to print it.
If you find something that you don't understand, do some research on it, read the documentation, code comments, play around with the code changing things and see how it works.

gdb: how to print the current line or find the current line number?

list commands prints a set of lines, but I need one single line, where I am and where an error has probably occurred.
The 'frame' command will give you what you are looking for. (This can be abbreviated just 'f'). Here is an example:
(gdb) frame
\#0 zmq::xsub_t::xrecv (this=0x617180, msg_=0x7ffff00008e0) at xsub.cpp:139
139 int rc = fq.recv (msg_);
(gdb)
Without an argument, 'frame' just tells you where you are at (with an argument it changes the frame). More information on the frame command can be found here.
Command where or frame can be used. where command will give more info with the function name
I do get the same information while debugging. Though not while I am checking the stacktrace. Most probably you would have used the optimization flag I think. Check this link - something related.
Try compiling with -g3 remove any optimization flag.
Then it might work.
HTH!
Keep in mind that gdb is a powerful command -capable of low level instructions- so is tied to assembly concepts.
What you are looking for is called de instruction pointer, i.e:
The instruction pointer register points to the memory address which the processor will next attempt to execute. The instruction pointer is called ip in 16-bit mode, eip in 32-bit mode,and rip in 64-bit mode.
more detail here
all registers available on gdb execution can be shown with:
(gdb) info registers
with it you can find which mode your program is running (looking which of these registers exist)
then (here using most common register rip nowadays, replace with eip or very rarely ip if needed):
(gdb)info line *$rip
will show you line number and file source
(gdb) list *$rip
will show you that line with a few before and after
but probably
(gdb) frame
should be enough in many cases.
All the answers above are correct, What I prefer is to use tui mode (ctrl+X A or 'tui enable') which shows your location and the function in a separate window which is very helpful for the users.
Hope that helps too.

Resources