News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Need help with Hash

Started by mineiro, November 21, 2011, 03:36:53 PM

Previous topic - Next topic

mineiro

Yes Sr Farabi, but not only MD5, can be other (maybe you have some algo or formula in your mind that can be usefull).
In previous example , 32 bits generated 21 bits. To have compression, I need represent their positions in a little form, I have less than 11 bits to play to represent 8 nibbles positions.
If I represent each position(*) with 2 bits, so I do not have compression (21+16). I can ignore the first nibble position of that sequence, because it will be static.

Puting this with numbers, and knowing that this one is progression (walks to front by 1 position every time if happened best compression (3 bits shared), or if not compress occurs, I can walk 3 positions), I can express with:
Final result(compressed):
110100001010111101001
*   *  **   **  **
X   3  20   30  20   

To decompress, I ignore the first nibble. The next number is 3, so I know that I need walk 3 positions after start position(X) plus one.
If some table (I called this hash,but can be crc, or ...) store that positions in a little form, can be done. So, to represent the positions, I thinked in some division table, to generate a big real number.
In better words, I(we) need one formula to represent X3203020.
If you think this in chemicall way, all elements like to be a nobble gas. How express that an element need 3 electrons, the next need 2 electrons, the next does not need,... in a minimum way.

edited after: Oh, I forget to say, thank you Sr.

Farabi

Well talked about encryption I think I got a simple one.

Quote
Hello guys, I guess there is no point to keep this for my self, I got no benefit if my harddisk is broken.
Even this function is just a simple one, at least it will be hard do decrypt if you are smart enough like, double the encryption, or not specifying the extension of your file, or even worse, the encrypted data, is wrote on your own file format, it will halt the cracker and wasting their precious time for a week (I Hope).

Have fun with this, and dont ask me anything if you forget the password since I had no idea to breaking it.



mAlloc proc nSize:dword

add nSize,4
invoke GlobalAlloc,GMEM_ZEROINIT or GMEM_FIXED,nSize
.if eax==0
invoke PERR
invoke MessageBox,NULL,addr mem_error,NULL,MB_OK
.endif

ret
mAlloc endp

fEncrypt proc uses esi edi lpData:dword,nDataSize:dword,lpKeys:dword
LOCAL data:dword
LOCAL keysz:dword
LOCAL cntr:dword
LOCAL key:word

mov ecx,nDataSize
shl ecx,1

invoke mAlloc,ecx
mov data,eax

invoke lstrlen,lpKeys
mov keysz,eax

mov esi,lpData
mov edi,lpKeys

xor ecx,ecx
mov cntr,ecx
loop_encrypt:
push ecx
movzx edx,byte ptr [esi+ecx]
ror dl,4
mov eax,cntr
mov key,dx
movzx edx,byte ptr[edi+eax]
add key,dx
mov eax,data
shl ecx,1
mov dx,key
mov [eax+ecx],dx

inc cntr
mov eax,keysz
.if cntr>eax
push 0
pop cntr
.endif

pop ecx
inc ecx
cmp ecx,nDataSize
jl loop_encrypt

mov eax,data

ret
fEncrypt endp

fDecrypt proc lpData:dword,nDataSize:dword,lpKeys:dword
LOCAL data:dword
LOCAL keysz:dword
LOCAL cntr:dword
LOCAL key:word

mov ecx,nDataSize
shr ecx,1

invoke mAlloc,ecx
mov data,eax

invoke lstrlen,lpKeys
mov keysz,eax

mov esi,lpData
mov edi,lpKeys

shr nDataSize,1

xor ecx,ecx
mov cntr,ecx
loop_encrypt:
push ecx
shl ecx,1
mov dx,[esi+ecx]
mov key,dx
shr ecx,1
mov eax,cntr
movzx dx,byte ptr[edi+eax]
sub key,dx
mov dx,key
ror dl,4
mov eax,data
mov [eax+ecx],dl

inc cntr
mov eax,keysz
.if cntr>eax
push 0
pop cntr
.endif
pop ecx
inc ecx
cmp ecx,nDataSize
jl loop_encrypt

mov eax,data

ret
fDecrypt endp


Here is how I used it

.if wParam==0
invoke OpenFileDialog,hWnd,hInstance,CADD("Pilih Berkas"),0
movzx ecx,byte ptr [eax]
.if ecx!=0
push eax
invoke filesize,eax
mov fsz,eax
invoke mAlloc,fsz
mov data,eax
pop ecx
push ecx
invoke read_disk_file,ecx,addr data,addr fsz2
invoke GetTextInput,hWnd,hInstance,0,CADD("Input Password"),0,addr buff
invoke fEncrypt,data,fsz,addr buff
mov data2,eax
invoke GlobalFree,data
shl fsz,1
invoke GetAppPath,addr buff
invoke SetCurrentDirectory,addr buff
pop ecx
invoke write_disk_file,CADD("Test.fef"),data2,fsz

; invoke fEncrypt,CADD("Farabi Onan"),11 ,CADD("1234567")
; mov data,eax
; invoke fDecrypt,data,22,CADD("1234567")
; invoke write_disk_file,CADD("Test.txt"),eax,11
.endif
.elseif wParam==1
invoke OpenFileDialog,hWnd,hInstance,CADD("Pilih Berkas"),addr fef
movzx ecx,byte ptr [eax]
.if ecx!=0
push eax
invoke filesize,eax
mov fsz,eax
invoke mAlloc,fsz
mov data,eax
pop ecx
invoke read_disk_file,ecx,addr data,addr fsz2
invoke GetTextInput,hWnd,hInstance,0,CADD("Input Password"),0,addr buff
invoke fDecrypt,data,fsz,addr buff
mov data2,eax
invoke GlobalFree,data
invoke GetAppPath,addr buff
invoke SetCurrentDirectory,addr buff
invoke GetTextInput,hWnd,hInstance,0,CADD("Name of File"),0,addr buff
shr fsz,1
invoke write_disk_file,addr buff,data2,fsz
.endif
.endif


Sorry cant post any project for this, I got no time so I just copy-pasted from my current code, and it is too complex for you guys. It is very embarasing if you see how bad Im coding.
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"

Farabi

Im no good about compresion but if you are talked about picture compression, I think you can separate the RGBA channel and then each 5 channel you create a formula, is the channel used to gradually down or gradually up, that is what comes to  my mind. I think it will work for Red channel with Red channel, and blue with blue, as long as you did not done it for a whole pixel. But if you talked about something else, I know nothing, you are far more better than me. It is out of my logic.
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"

mineiro

Thank you Sr Farabi, I give it a try.
Be in peace.

Farabi

If you able to do that, I bet you can compress a file fifth of it. Most of Alpha channel only had 255 or 0 value. You can just for example, encode it someting like this, 01 00 00 00 00 FF which mean, x1 is for the "OPCODE" for fill, and xFF is the alpha channel value should be filled. I bet for only this it should reduce the file decently.
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"