using strings in memory - basic encryption

[Lightman]

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

[evlncrn8]

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 :)

[MichaelW]

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:

Code Select Expand


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.

[evlncrn8]

well he's using win32 api's from the looks of it, so the 16 bit 'lesson' is quite redundant no?

[MichaelW]

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.

[evlncrn8]

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...