Hi Everybody,
I am doing a bit of very basic cryptography within an assembler program, but my code crashes when I run it. This code is on the current limit of my assembler knowledge, can anyone point me in the right direction...
I am working with two strings of data defined in the .inc file
sPlain db 256 dup(?)
sCrypt db 256 dup(?)
; these are handles for the widgets on the dialog box...
hCrypt dd ?
hPlain dd ?
When a button is pushed on the dialog box, the 'encryption' runs....
invoke GetWindowTextLength, hPlain ; how long is my target string?
mov txtLen, eax ; keep it for later
invoke GetWindowText, hPlain, addr sPlain, txtLen ; grab my text from the widget
mov ecx, txtLen + 1 ; move the string length into ECX
push bp ; push bp to the stack
xor bp, bp ; 0 bp
Loop1:
mov ah, sPlain[bp] ; move a character into AH
add ah, 1 ; actual encrytion - adding one.
mov sCrypt[bp], ah ; write the result into a string
inc bp ; inc BP to get the next char in the string
dec ecx ; dec ECX for next char in source string
jz OutLoop ; if CX hits 0 then we are done.
jmp Loop1 ; else go around the loop again.
OutLoop:
pop bp ; pop BP back off the stack
invoke SetWindowText, hCrypt, addr sCrypt ; display the crypted text
And yes... I know the 'Cryptography' is super-lame... :bg
Sorry for the rubbish formatting, I copied the code from RadASM
Regards,
Lightman
to begin with, i'd avoid the bp crap...
mov esi, offset sPlain
mov edi, offset sCrypt
mov ecx, txtLen ; you dont check for overflow, you should...
crypt_loop:
lodsb ; load 'clean' byte
inc al
stosd ; save 'encrypted' byte
loop crypt_loop
is a 'cleaner' version of your encryption...
invoke GetWindowTextLength, hPlain ; how long is my target string?
mov txtLen, eax ; keep it for later
invoke GetWindowText, hPlain, addr sPlain, txtLen ; grab my text from the widget
that part has so many issues... firstly you are not checking the txtLen to see if its bigger than your buffer for example...
but thats more a design flaw than a crash issue (unless of course somehow the text you're entering is > 255 chars?)
mov ecx, txtLen + 1 ; move the string length into ECX
that is most likely the cause of the problem...
txtLen is a dword you're using to store the length into...
you can not do a +1 on it...
it would have to be..
mov ecx, [txtLen]
inc ecx
also.. why the inc ?
best advice i can give would be for you to adjust the code and debug through it to see whats going on.. i suspect its the line i pointed out though :)
In 16-bit code indirect memory operands must use a base (BP or BX) or index (SI or DI) register, or one of each. In 32-bit code you can use any general-purpose 32-bit register (EAX, EBX, ECX, EDX, ESI, EDI, EBP, or ESP with certain restrictions), and you can use addressing modes that were not supported in 16-bit code. Some examples from the MASM Programmer's Guide:
add edx, [eax]
mov dl, [esp+10]
dec WORD PTR [edx][eax]
cmp ax, array[ebx][ecx]
mov eax, darray[edx*4]
mov eax, [esi*8][edi]
mov ax, wtbl[ecx+2][edx*2]
Also, in 32-bit code you cannot store an address in a 16-bit register, because the addresses are 32 bits in length.
well he's using win32 api's from the looks of it, so the 16 bit 'lesson' is quite redundant no?
Quote from: evlncrn8 on March 07, 2008, 12:38:48 PM
well he's using win32 api's from the looks of it, so the 16 bit 'lesson' is quite redundant no?
A beginner, use BP in 32-bit code, and using it, and no other register, for indirect memory operands, is IMO likely to be coming from, or at least influenced by, 16-bit DOS code. You recommended avoiding "the bp crap", with no explanation, and while you did point out some potential problems, you failed to point out the obvious, and definite problems.
hmm, fair enough i did take it for granted that seeing the 32 bit code the poster should have had some understanding of 32 bit concepts, registers and addressing.. i should have seen that from how 'bad' the encryption was...