i am trying to write a tool that simply encrypts a file via xor.
i am already as far as this, 2 files are opened and the 1st is read out like this:
but the de/encryption loop doesn't work properly. anybody any ideas?
moreover, the final call for WriteFile sometimes only writes the 1st byte and nothing more. your help would be appreciated.
Thnx, Phueghy
Phueghy, use the square brackets when you post code, it preserves the formatting correctly. hutch.
i am already as far as this, 2 files are opened and the 1st is read out like this:
call GetFileSize, fhandle, 0
mov fsize, eax
call ReadFile, fhandle, offset buffer, fsize, offset bread, 0
push ecx
xor ecx, ecx
decrypt_loop:
mov al, byte ptr [buffer+ecx]
xor al, 000000ffh
mov byte ptr[buffer+ecx], al
inc ecx
cmp ecx, fsize
je ende
jmp decrypt_loop
but the de/encryption loop doesn't work properly. anybody any ideas?
moreover, the final call for WriteFile sometimes only writes the 1st byte and nothing more. your help would be appreciated.
Thnx, Phueghy
Phueghy, use the square brackets when you post code, it preserves the formatting correctly. hutch.
You can xor the buffer directly, like this :
INVOKE ReadFile, fhandle, offset buffer, fsize, offset bread, 0
decrypt_loop :
xor DWORD PTR buffer[4*ecx], 0FFFFFFFFh
inc ecx
cmp ecx, fsize
jne decryptLoop
INVOKE WriteFile, fhandle, offset buffer, fsize, offset bread, 0
INVOKE CloseHandle, fhandle
Hi.
I've just a little advice for you.
You read all the file in your buffer directly.
How is your buffer defined ?
In .data? section ?
What would happen if the file is really HUGE ?
It can cause buffer overflow, and "interfere" with other variables that are after your "buffer" one.
I would recommend you to allocate memory with an allocation API.
(according to MSDN, HeapAlloc is the best one) a "small" buffer.
(64 kb in exemple).
After, read the file sequentially, do some operations on the buffer, write the buffer to the destination file, and again until the end of the file.
Unallocate your memory buffer.
That's all
Your app will eat lot less memory and will be as faster (of course it's faster to work on a huge buffer directly instead to read sequentially, but i've never seen any notifiable performance hurt).
Cya.
Read.
I've just a little advice for you.
You read all the file in your buffer directly.
How is your buffer defined ?
In .data? section ?
What would happen if the file is really HUGE ?
It can cause buffer overflow, and "interfere" with other variables that are after your "buffer" one.
I would recommend you to allocate memory with an allocation API.
(according to MSDN, HeapAlloc is the best one) a "small" buffer.
(64 kb in exemple).
After, read the file sequentially, do some operations on the buffer, write the buffer to the destination file, and again until the end of the file.
Unallocate your memory buffer.
That's all
Your app will eat lot less memory and will be as faster (of course it's faster to work on a huge buffer directly instead to read sequentially, but i've never seen any notifiable performance hurt).
Cya.
Read.
right, 1st thanx to hutch regarding the
thank ya all. i'll try both versions out and tell you if it worked ;-)
cya, Phueghy
CODE SECTIONthank ya all. i'll try both versions out and tell you if it worked ;-)
cya, Phueghy
right, it works now. indeed, the problem was with the allocated memory. thank you all once again for your support.
cya, Phueghy
cya, Phueghy