I just wrote a pretty crappy encrytion algorithm... 2 questions though:

1) How can I tell if my encryption algorithm is any good? How do people actually crack an encryption algorithm anyway? Not sure how I'd even begin to wirte a bruteforce program to test my program... So if that is the only way (how do you write one)

2) I want the program to encrypt/decryp the file "itself" when it is opened (so it can't be patched -- at least easily)... This is because I have a string "Register" in the program that anyone with a debugger can find... :(

As for part 2 -- you use a delta offset and then encryt the size of the file? I really want to learn this to protect my files so any help will be appreciated

Sliver
Posted on 2002-01-23 22:39:04 by Sliver
Bruteforcing? Loop through all the available keys. Usually not much
fun. Only useful if you have some idea what the original data is,
otherwise you'll have to look through too much data. A CRC is
perfect, but if you know that it's eg english text, there are some
possbilities as well.

If the algorithm is lame, it can be attacked in other and much more
efficient ways. This, however, is more or less advanced, and I haven't
bothered to read much on it as I'm not going to do cryptanalysis.

As for protecting your application, there is an old saying: "If it runs,
it can be cr4cked". If you want to encrypt/decrypt stuff in your executable,
you will obviously need to have the decryption key somewhere as well.
Posted on 2002-01-24 07:46:48 by f0dder
have the file encrypted by the application itself will prevent "some" people from hacking the serial number... You are right that some people might be able to debug the active process, but it will be harder for them to patch it :-)

So the question is again:

How do you write an application that will encrypt some of its internal data? Inotherwords:



Start:

invoke decrypt from offset main to end_main

Main:

....
...
....
...

End_Main:

invoke encrypt from offset main to end_main

end start


I've now seriosuly looked everywhere on the internet for something like this and all I've pulled up were virus's... hasn't anyone implemented this for an application?

If not how hard would it be to do a simple XOR encryption? Such as I've described?

Sliver
Posted on 2002-01-24 18:02:01 by Sliver
It's very easy for data. A bit more annoying for code, as you need
to deal with page permissions and stuff. And if you use a wrapper
scheme and encrypt everything... well, it's not very hard to trace
to OEP and do a process dump :=).
Posted on 2002-01-24 18:07:53 by f0dder
So how do virus writers do it so freely... even within the bounds of 32 bit protected mode? I really don't want to have to learn virus techniques just to solve this silly problem...

Sliver

ps. But I thought it was possible to have a program that can modify it's own code at runtime... or is this something that was left back in the days of 16bit?
Posted on 2002-01-24 18:18:46 by Sliver
I know of a basic way to encrypt. if you xor a byte with a number and then xor it with that number again it goese back to the origonal so you would xor all the bytes that contain your data with the encryption key and then to decrypt xor them again. A real encryption algorythum would be much more complex
EDIT


I have sean vuris code that modifies its code. it dosen't modify the code on disk untill it writes the next copy of itself.
Posted on 2002-01-24 18:22:40 by Quantum
Quantum,
I already have an encryption procedure... I just wanted to see if someone had an encrytion routine that "encrypted code within the application itself"...

The edited part of your respons relates to opcode alteration... which is out of the scope of the question...

I just want to learn to code a program that encrypts its own code... The encryption it uses is superfluous to that end...

So the quuestion is: How do I start?

Sliver
Posted on 2002-01-24 21:12:13 by Sliver
I just want to learn to code a program that encrypts its own code... The encryption it uses is superfluous to that end...


I think to do this you have to aulter the programs opcodes so they are unreadable to somone using a disassembler and this is done by putting there values thru your algorythum. Why don't you try something like this, create a small procedure that you want to eycrypt then use your algorythum to encrypt all of the bytes that make up that procedure and then create another program that starts with the decrypter wich would work on the bytes following the decrypter code. After your decrypter do
encryptedcode db ...... and put in the encrypted procedures code.
I hope I have made sense and I hope I have understood what you wanted
Posted on 2002-01-24 21:51:47 by Quantum
I once saw a program that decrypted ever proceedure on the stack before executing it. ;)
Posted on 2002-01-24 22:25:37 by bitRAKE
Ok, found 1 and only 1 program after all my searching of the internet...

I'm including the source and program itself... (since it was released by the programmer)

Here is what the author says it does (it is also rated 4 in the crackme's hall of fame -- whatever that means)... I'm still trying to piece together it all :( I'm afraid it may be over my head... I didn't know how hard this would be... It's also for tasm





; Title: : CrueMe v1.0
; Author : Cruehead
; Creation date : 98-06-02
; Source release date : 99-02-13
;
; Description:
; This is the source code for yet another "CrackMe" program. This one
; has proven to be fairly hard to beat, and it took approx 8 months before
; I received five solutions. The most interesting among those solutions is the one I got
; from "MerCuur". He wrote a generic brute forcer based on mutations and life forms.
; I included his source code (in C) in this zip archive...It's really interesting.
;
; The crackme features some polymorphic code to hide the real
; encryption and check routine. As soon as the real check has been executed
; the code will be overwritten with useless code, and a fake
; encryption/check routine will be executed. Every time the "Check It!"
; button is pressed the real encryption/check routine is beeing written
; to the correct place again. Before the real encryption/check routine is executed
; the string is fetched through the GetText message beeing sent.
; A breakpoint detection is made on the "GetDlgItemTextA" function as this
; is the routine that is used to fetch the string and then execute the fake test.
; All of this just to confuse the cracker into thinking he's on the right path
; when seeing the "No breakpoint allowed..." message. Also the file called "CRUEME.DAT" has
; nothing to do what so ever with the real check - it's only used as a red herring.
; Knowing this one can easily figure out that the "FileMon" detection is also only
; used as a red herring to distract the user from the real interesting piece of
; the code.
; Another thing is that all the functions used in the program are stored in a
; separate place thus making it a lookup table. This is only to confuse
; dead-listing crackers (and perhaps to cause some headaches for Sice users as well).
; Conclusion: Alot of things to draw the cracker's attention to other useless
; pieces of the code. Also the ability to hide the real psw checking routine so the
; cracker wont see anything suspicious when browsing through the program using softice.
;
; I wont comment much of the code, and it might be a bit hard to follow everything
; but the program works as I described above and that is - if you ask me - the really
; interesting thing to know.
;
;
;
; Oh yeah! Perhaps you'd be interested to know that the password I choosed was
; "Cracking4U". Alot of other passwords will pass as well though, and I doubht
; that it's even possible to find the password I had in mind.
;-----------------------------------------------------------------------------------


Now I don't need the program to be this complicated, but well I still would like to know how it works...

Sliver
Posted on 2002-01-24 22:34:22 by Sliver
Silver,
That Hall of Fame site's: http://crackmes.host.sk/halloffame.htm
is pretty neat-----Thanks, B
Posted on 2002-01-25 00:20:35 by BradB
RealRoutine db 052h,06ah,00eh,06ah,00dh,068h,0eah,003h,000h,000h,0ffh,075h,008h,0b0h,025h
db 0ffh,015h,064h,023h,040h,000h,0e8h,035h,009h,000h,000h,050h,0bfh,001h,000h
db 000h,000h,0e8h,0fdh,008h,000h,000h


I guese this is an encrypted routine that is decrypted when needed wich makes things a lot harder
Posted on 2002-01-25 02:27:42 by Quantum
sorry if i misunderstood something (iv didn't had the
time to read every post in thiis thread) but, you CAN
modify you code very easy... becuase of read-write
permissions you have to set a few linker options to
prevent windows from making gpf's... in my opinion
it was like:

ml /c /coff %1.asm <-compile as usual
Link /SUBSYSTEM:WINDOWS /SECTION:.text,CERW %1.obj

.text (code section):
C - contains Code
E - code is Executable
R - you've got Read access
W - Write access

you only need RW but then... who cares :)

a simple xor encryption does it as follows...
the first generation is encrypted with xor - 0, that
means nothing happens coz the encryption key is zero...
if someone runs this thing, the will add a value to
it's xor-key, say 10... then it copys itself into a buffer and
encrypts itself with xor-10... next thing to do is generating
a decryptiong routine (xor-10, too) in front of the
encrypted ... this whole mess is transfered into other
executables... and every time a new file will be infected the
xor-key will be changed again... this method can be used
for security-solutions, too... but like i stated above... this
method is very simple... so i could be cracked very fast...
you could add polymophism, metamorphism, more encr-
layers... whatever you need...

Posted on 2002-01-25 04:19:46 by mob

this method can be used for security-solutions, too... but like i stated above... this method is very simple... so i could be cracked very fast...


This is exactly what I want to learn... Do you know of any applications that use some form of simple xor encryption so I can learn from it?

The code doesn't have to be portable so I shouldn't have to determine the offsets for anything except the portion of the code that is to be xor encrypted...

I just don't want to have to use a virus to learn how it does it... Too risky... I just want to find out how to write the technique it uses...

Sliver
Posted on 2002-01-25 04:32:16 by Sliver
Sliver, a way to do it... in your executables, insert a special tag dword
before a block of code you want encrypted. Or perhaps 8 bytes -
enough that this sequence will not appear randomly in your file.
Place the length of the block after the tag (can be calculated with
some labels and simple OFFSET stuff).

Then, write a little tool that scans your executable for these tags,
and does the encryption.
At runtime, you need to decrypt the code blocks before executing.

You could also do a google search for "pe crypter source", it ought
to come up with something... at least there's more than a few PE
crypters with released source.
Posted on 2002-01-25 05:58:30 by f0dder
ok, time for pseudo-code :)



EP: ; ENTRY-POINT
CALL DELTA
DELTA: POP EBP
SUB EBP, DELTA ; EBP = DELTA OFFSET

XOR_KEY:MOV DH,0 ; WILL BE PATCHED LATER!
LEA ESI, [ EBP + E_START ]
PUSH ESI ; LIL' TRICK TO RETURN...
MOV ECX, E_END - E_START ; TO E_START AFTER...
; DECRYPTION

;________________ _ _ _ [ -ENCRYPT- ] _ _ _ __
ENCRYPT:XOR BYTE PTR [ ESI ], DH ; ESI = OFFSET
ROL DH, 1 ; DH = XOR KEY
INC ESI ; ECX = SIZE
DEC ECX
JNZ ENCRYPT
RET

E_START:
;// HERE STARTS YOUR REAL ENCRYPTED CODE

;// OK, A [badword] WOULD DO THE FOLLOWING

;// 0) CHANGE XOR-KEY

ADD BYTE PTR [ EBP + XOR_KEY + 1 ], 10

;// 1) CREATE A BUFFER

;// 2) COPY EVERYTHING FROM "EP" - "E_END"
;// INTO IT, THAT MEANS THE WHOLE PROG!

;// 3) ENCRYPT THE BUFFER WITH THE NEW XOR-KEY

MOV DH, BYTE PTR [ EBP + XOR_KEY + 1 ]

LEA ESI, BufferPointer
MOV ECX, E_END - E_START
CALL ENCRYPT ; yup, this routine above :)

;// 4) WRITE THE ENTIRE BUFFER CONTENT INTO SOME
;// SOME OTHER FILES...


;// 5) EXIT...


VARIABLES:
BLA DD 0
BLUB DD 1

E_END:


ok, note that if you use this way YOU MUST RECALCULATE
your offsets... you can't use regular api's, too... write me
if you want some routines to use api's anyhow...

btw... to hiro, hutch and all the others... plaese note that
this i definitively not v1rus related... it's just a simple SMC
xor encryption...

Posted on 2002-01-25 06:26:31 by mob
mob, SMC is all peachy and stuff, but please don't use "that word
you know", as the pages on this messageboard might get indexed
by search engines and turn up when not wanted.
Posted on 2002-01-25 06:44:16 by f0dder
:) ok thank you...
Posted on 2002-01-25 06:47:03 by mob

you can't use regular api's, too... write me
if you want some routines to use api's anyhow...


Jumping in the thread, since I'm interested into this kind of stuff too.

For hiding purposes, I don't want to statically link with any DLL. Currently I *must* link though with LoadLibrary, and (although I could avoid it if I wanted) also GetProcAddress.
Then I LoadLibrary() e.g. KERNEL32.DLL and USER32.DLL, and GetProcAddress the functions that I need. This way they won't show up in my PE (this is only half of the story though, since there are debuggers out there too).

Anyway, the reason why I'm writing is that from what you wrote it may seem that you know e.g. how to get LoadLibrary's address without importing it in your PE.. is it right? If so, how do you do it?

Moreover, perhaps I've already asked it in this forum (but got no answer anyway).. if I LoadLibrary KERNEL32.DLL (or others), do I have to use FreeLibrary to not leave memory leaks? Or when my program calls ExitProcess the OS will automagically Free all the libraries that I've opened through LoadLibrary?

The SDK didn't really clear my doubts.. I wouldn't like to leave memory leaks around, but still I don't want to call FreeLibrary if it's redundant, because I'm also gonna write 4KB intros, and space is precious..

Greets,
Maverick
Posted on 2002-01-25 16:06:58 by Maverick
When you call ExitProcess all libraries are freed.
Well if you using LoadLibrary and GetProcAddress to get your functions, thse functions are in the Kernel32 so to call them you would have to have kernel32 imported allready. Well actually there is a way of getting Kernel32 without linking but I think this can only be used by viruses because it relies on kernel32 allready being n the address space of the program so I don't think I'll mention it.
Posted on 2002-01-25 16:51:29 by Quantum