Converting String to DWORD (Assembly x86) - string

I am trying to learn how to convert a string to an integer. I think I am pretty close. My code works for numbers under 260. Once the numbers entered are greater than or equal to 260, then it just converts them to 0. I think it might have something to do with the size of a BYTE, but I'm not sure how to fix it. Any suggestions?
Some Irvine functions are included, but I'm trying to write my own ReadInt function.

I can see the problem. Rather than giving away the answer completely, here's a hint:
The lodsb instruction loads one byte into al (which is the low 8 bits of eax). The rest of eax is unchanged. What might cause eax to contain extra bits that aren't changed by lodsb?

Related

Building XOR bruteforce python

I solved a simple bruteforce XOR challenge using cyberchef.
Of course, I wanted more and build a script that do it.
The script should perform XOR test against a specific string.
I don't understand how to manipulate binary in python and this is my issue so far.
ciph = "q{vpln'bH_varHuebcrqxetrHOXEj"
for decim in range(256):
print(decim, ": ", ''.join([chr(ord(char) ^ decim) for char in ciph]))
Of course 'decim' is not a bit so it's not working properly.
I have read stuff about bytearray but no sure how to handle it and if it's relevant here.
Any idea?
Well, my bad, it is working well.
The flag is there but not at the same position as Cyberchief indicated because it performed a XOR bruteforce with Hexadecimal key.
Here I'm doing a XOR bruteforce with Decimal key, so yeah of course the flag is not at the same position ...

Taking a string as input and then display it in assembly 8086

I know how to take single character input and string input. Also I know how to display a self-chosen string using DOS functions with INT 21h. But I was wondering about how to take a string input and display the same string.
When taking string input using:
MOV AH, 0Ah
INT 21h
Where does the string get stored? In case of a single character input and output, the character is stored in the AL register. So knowing the address of the stored string, I can load the address of it in the DX register and display it, right?
Any help is appreciated, thanks in advance...
Where does the string get stored?
The string is stored starting at the third byte of the input buffer for which you provide a pointer in DS:DX.
For a very detailed explanation, with examples you can study, see
How buffered input works
But I was wondering about how to take a string input and display the same string.
The examples in the linked post do exactly that.
For INT 21, AH=0Ah, the caller passes in the buffer in which to store the string in DS:DX.
See Ralf Brown's interrupt list for full information about using interrupts. One of many places you can find it is http://www.ctyme.com/rbrown.htm.

ASM (Gnu AS): How to split a FLOAT variable into parts?

I got a small problem: that I want to split a float variable into parts and then compute these parts (add / subtract etc.). My main problem is that I don't know how to get that splitted parts/variables from the float type variable. I want to operate on those parts using rax / eax registers and b,c,d etc.
Is there somebody who can help me to acquire some knowledge about this and eventually lead me to some code that can do the trick? One restriction of mine is: I can't operate on FPU commands.

Declaring variables in NASM

I am just learning NASM and I am kind of struggling to figure this out. How do you declare variables in NASM? For example, how would you declare unsigned int i in NASM? Thanks
there is no such thing as unsigned int in assembly language (as far as I know).
In NASM you can only declare memory locations and put contents in it.
example:
section .data
abyte: db 15
aword: dw 452
adword: dd 478569
; etc etc see Nasm manual for more 'types'
The way you treat the variables will make you to use signed or unsigned values. When you need signed values the keep in mind that div and mul only works for unsigned values. (The MSB is not the sign bit). In that case you should use idiv and imul (integer division or signed division).
Also keep in mind that the negative of a value will be shown as two's complement. You will see for 5 (in AX as example) : 0000000000000101 binary but for -5 you will see 1111111111111011 which is the two's complement of 5.
both added gives 5 + (-5) or 0000000000000101 + 1111111111111011 = 0000000000000000. The overflow flag will be set appropriatly to indicate that there is an overflow when both numbers are treated as unsigned, so sometimes you can ignore this. A good practice is to debug and check often the flag status.
To check if AX is negative or not you can and ax, ax and the sign flag will be 1 if the MSB is 1 otherwise 0. (js and jns instructions)
The answer is a bit late but for those who have the same question.....

How do I take operands as registers from the byte value?

I have a fairly simple program so far to start off my emulation experience. I load in an instruction and determine how many (if any) operands there are, then I grab those operands and use them. For things like jumps and pushes it's somewhat straightforward until I get to registers.. How do I know when an operand is a register? Or how can I tell if it's the value at an address instead of just an address (i.e when they use something like ld (hl),a)
I'm rather new to emulation and all, but I have a decent bit of experience with assembly, even for the z80.
Question
How do I tell the difference between what is meant as a register and what is meant as an address or dereference of an address?
Because you decode the instruction. For example in ld (hl), a, which is 0x77, or 0b01110111, the first 01 tell you it's an ld reg8, reg8 and that you have to decode two groups of 3 bits, each a reg8. So 110 and 111, and you look them up in the reg8 decoding table, where 110 means (hl) and 111 means a. Alternatively you could just make a Giant Switch of Death and directly decode 0x77 to ld (hl), a, but that's more of a difference in implementation than anything deep or significant.
The instruction completely specifies what the operands are, so this "how do I tell" question strikes me as a bit silly - the answer is already staring you right in the face when you're decoding the instruction.
See also: decoding z80 opcodes

Resources