Preview only show first 10 pages with watermark. For full document please download

Golden Oaks Software

   EMBED


Share

Transcript

Description of encrypting an ‘EXE’ file to prevent reverse engineering GOLDEN OAKS SOFTWARE Description of encrypting an ‘EXE’ file to prevent reverse engineering Golden Oaks Software 7524 Soquel Way Citrus Hts, CA 95610 Dr. Joe Butler [email protected] (916) 220 1654 26 March 2005 PROPRIETARY STATEMENT This document contains commercial or financial information, or trade secrets, of Golden Oaks Software, which are proprietary and exempt from disclosure to the public under the Freedom of Information Act, 5 U.S.C. 552(b)(4), and unlawful disclosure thereof is a violation of the Trade Secrets Act, 18 U.S.C. 1905. Public disclosure of any such information or trade secrets shall not be made without the written permission of Golden Oaks Software. This document includes data that shall not be disclosed outside the Government and shall not be duplicated, used or disclosed, in whole or in part, for any purposes other than to evaluate the information. If however, a contract is awarded to this offeror as a result of, or in conjunction with, the submission of this data, the Government shall have the right to duplicate, use, or disclose, the data to the extent provided in the resulting contract. The restriction does not limit the Government’s right to use information contained in this data if it is obtained from other sources without restriction. The data subject to this restriction is contained in all sheets. cbncrypt.doc 1 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering At present, there is no effective way to protect a programmer’s working code from an unauthorized user that wants to hack or reverse engineer your code. This unauthorized person can use a variety of tools (eg: Debug, Hex Editor, etc.) to view the programmer’s code and either steal or change that code without authorization. How does the programmer then protect his code from unauthorized viewing? The answer is to encrypt the code with a registered key. Every time the program is executed, the end user must have the same registered key to decrypt the code, before the EXE program can execute properly. The method of encrypting an EXE file described in this paper, uses a nine (9) digit registered key, but that’s not to say that the key can’t be changed to another size, nor is there any reason that alpha characters can’t be used in the registered key as well. Also, there could be an alternate encryption scheme added to this encryption method, but that is not addressed in this paper. The encryption method described here is for the small and tiny program models. By studying the flowcharts presented here, a programmer can change the code to fit the other program models accordingly. Basically, what has to be accomplished to encrypt the EXE file, is to change the EXE header block, and add code to the end of the EXE program to decrypt the encrypted EXE file. Encryption and decryption is done with a known registered key. Using the stated nine (9) digit registered key, one can see that there are at least 999,999,999 digit possibilities to decrypt the EXE program. That should be more than enough security for the programmer to protect his EXE program from reverse engineering techniques. cbncrypt.doc 2 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering Brief description of the EXE header block: At the beginning of every EXE file, there is a 512 byte area called the EXE file header. Out of this 512 byte area, only the first 27 bytes are used – which contains the header information. The structure of an EXE file header is given below: Offset Size 00 02 04 06 08 0A 0C 0E 10 12 14 16 18 1A word word word word word word word word word word word word word word Description "MZ" - Link file .EXE signature length of file mod 512 size of file in 512 byte pages number of relocation items following header size of header in 16 byte paragraphs, used to locate start of load module min # of paragraphs needed to run program max # of paragraphs the program would like offset in load module of stack segment (in paragraphs) initial SP value to be loaded negative checksum of pgm used while EXEC loads pgm program entry point, (initial IP value) offset in load module of the code segment (in paragraphs) offset in .EXE file of first relocation item overlay number (0 for root program) The encryption/decryption method described here, changes the: Length of file mod 512 word, and the size of file in 512 byte pages word. Nothing else needs to be changed, except the Jump location at the beginning of the EXE file. It needs to be redirected to the trailing code, which is the decryption software. cbncrypt.doc 3 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering The flowchart behind the EXE encryption: Open decryption file code Input Filename N Add data to end of new file Filename exists? Change new EXE file header Y N Get file size Close new file Get Reg Key Good Number? Y Xlat to Hex Number Open filename, read only. Create new file Get char from old file EOF? N Set x to first pos of Reg key Encrypt char with reg key[x] & put in new file N Y Pos of Reg Key > len of Reg key? Y Close old file cbncrypt.doc 4 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering The flowchart behind the EXE decryption: Run encrypted EXE pgm Input Reg Key Print ‘Wrong!’ on screen N Good Number? Y End EXE pgm Xlat to Hex Number Get char from memory[y] EOF? N Decrypt char with reg key[x] & put in memory[y]. Increment y N Set x to first pos of Reg key Y Y Pos of Reg Key > len of Reg key? Get check word Is compare with internal value good? Y Print ‘Wrong!’ on screen N Run EXE pgm End EXE pgm cbncrypt.doc 5 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering The code for the end of the EXE decryption program: PUBLIC REGKEY CODE CSEG REGKEY: push push push push push push pushf RK1: ds es bx cx dx di ; ; ;save ;save ;save ;save ;save push push pop pop cs cs ds es ;save cs ;again ;ds = cs ;es = cs mov mov mov add bx,0001h bx,cs:[bx] di,bx di,3 ; ;get offset of JMP here ; ;make it right address mov call xor mov add inc dx,offset RG1 RK7 cx,cx bx,offset RG0 bx,di bx ;get addr of Reg Key ;print msg ;zero out cx ;get addr of storage no ; ;make first one = 0 mov int cmp jg cmp jl mov mov call inc inc cmp jl ax,0001h 016h al,0039h RK5 al,0030h RK5 cs:[bx],al dx,offset RG2 RK7 cx bx cx,9 RK1 ; ;get kb char ;gt 9 ? ;yep ;lt 1 ? ;yep ;save good char ;get addr of asterisk ;print msg ;cx = cx + 1 ;bx = bx + 1 ;do we have 9 char ? (this can be chgd *) ;nope ;xlat ASCII numbers to hex values cbncrypt.doc bx reg cx reg dx reg di reg flags 6 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering RK2: dec mov dec mov call dec mov and add inc inc mov dec cmp jne sub mov bx al,byte ptr [bx] bx ah,byte ptr [bx] HX2BCD bx dl,byte ptr [bx] dx,000fh ax,dx bx bx byte ptr [bx],al cx cx,1 RK2 bx,02h dx,03h ;decrement bx reg to true place ;get first number in al ;decrement bx ;get second number in al ;xlat to hex ;get third char ;store number here ;get rid of ASCII ;add together ;put back to original spot ; ;put hex value back ;cx = cx - 1 ;are we done yet ? ;nope ;get start addr of new string ;get starting address of encrypted pgm RK3: mov cx,09h ;get starting pos of reg key (*) RK4: cmp je push add mov mov mov xor mov pop inc dec cmp je jmps dx,di RK9 bx bx,cx al,byte ptr [bx] bx,dx ah,byte ptr [bx] ah,al byte ptr [bx],ah bx dx cx cx,1 RK3 RK4 ;are we done yet ? ;yep ;save start pos ;bx = bx + cx ;get reg key char ;bx = dx ;get pgm char ;decrypt ;put decrypted char back in pgm ;restore start pos ;dx = dx + 1 ;cx = cx - 1 ;is cx = 1 ? ;yep ;keep looping RK5: mov call dx,offset RG3 RK7 ;get addr of wrong ;print msg RK6: mov jmps ax,04c01h RK8 ; ;exit to DOS w/ error RK7: add mov dx,di ah,09h ;dx = dx + di ; RK8: int ret 021h ;print msg ;return to code RG0 RG1 RG2 RG3 RG4 db db db db db 0000000000 0ah,'Reg Key: $' '*$' 0ah,'Wrong!' 0dh,0ah,'$' ; (*) cbncrypt.doc 7 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering RK9: RK99 mov call popf pop pop pop mov mov pop pop pop cmp jne dx,offset RG4 RK7 di dx cx bx,0003h ax,es:[bx] bx es ds ax,09090h RK6 ;print lf ;print msg ;restore flags ;restore regs ; ; ; ;get value @ loc 0003 ; ; ; ;are they nops ;nope db 0e9h,0f6h,0ffh ; jmp 0000h ;goto orig pgm ax,0f0fh cx ch,al cl,0ah al,ah ah,ah cl al,ch cx ;get rid of ASCII ;save cx ;save units number ;*10 decimal ;put tens number in al ;zero out ah ;mult al by cl ;add them together ;restore cx ;return HX2BCD: and push mov mov mov xor imul add pop ret C0 db db 'Copyright Golden Oaks Software (C) 2005 –' ' All Rights reserved' This program was written using RASM86, but it can be translated into any other assembler language. cbncrypt.doc 8 PATENTED & PROPRIETARY 03/11/2005 Description of encrypting an ‘EXE’ file to prevent reverse engineering Commercial and Government/Military Use: Encryption Techniques Security of programs on embedded chips For further explanations or whatever, please email me with a subject line, to the following email address: [email protected] cbncrypt.doc 9 PATENTED & PROPRIETARY 03/11/2005