So i have to find a "thumb print" ID of some programs that
are not allowed to run on some clients PC...

Now the problem is how to sure ID a program without a mistake that will stop a "nice" programm to run and still not alow malitiouse (but not so advanced as Vecna ;) ) users from running "bad" application using easy tricks....


Process name returned by ToolHelp32 functions changes if the user just renames the exe :) doh...

Until now i have had some ideeas like:
===========================
1.Process name
--------------------------
so easy to foul arround with

2.Specific module names (DLL) used by the process
--------------------------------------------------------------------
Is harder to foul but not all applications use specific modules, some just use bare windows API or MFC modules


3.CRC32 or custom CRC
-------------------------------
but any change to the PE even into resources or its headers will foul me

4. CRC in memory
-------------------------
how the hell do i avoid makeing a CRC of variables?

Any other ideeas (even crazy ones) are wellcome ....

Needless to say i need this for a job with one of
my clients that in turn will help us continue the HE project ;)

10x
Bogdan
Posted on 2001-08-04 19:19:08 by BogdanOntanu
Would the best approach be to use many simple things as you have already mentioned and weight each test. If the application scores below 10% or something then allow it to run. The more simple things you use, the more of a picture you will have of a specific application. Yet, still you would allow other applications that are a little like illegal ones to execute.
Posted on 2001-08-04 19:53:09 by bitRAKE
Some other things to check for:
- filesize
- window titles / class names
too tired to think of anything else atm :)
Posted on 2001-08-04 20:02:24 by Tola
i know that these API calls will help when finding/identifying a process

CreateToolhelp32Snapshot
Heap32First
Heap32ListFirst
Heap32ListNext
Heap32Next
Module32First
Module32Next
Process32First
Process32Next
Thread32First
Thread32Next
Toolhelp32ReadProcessMemory

i do not know much about these so consult the API documanetation
Posted on 2001-08-04 20:56:27 by SubHuman
BogdanOntanu,

you can do a crc32 or, better, a md5 message digest, only from the .CODE section of the program...

altought is not very safe, is easy to do, and the .code of a program should never change in normal conditions

ancev
Posted on 2001-08-04 21:12:50 by ancev
Hi anceV

You mean a CRC32 or a md5 of the .code section of the PE file on disk? or in memory?

if on disk i wonder if this will not be too much slow
elseif on memory i wonder if i can still find a .code unaltered section with a ReadProcessMemory Function

i worry also for a simple viri infection, that will change the .code section and so make me "miss" a proggy that even if its infected might still do its original "bad for my client" job...at least for some time ;)
Posted on 2001-08-04 21:26:45 by BogdanOntanu
bogdan, crc32 (or md5 or whatever) of .code will probably be OK.
Most viriis infect in an added section, or the last section, anyways.
If not that, why give a damn? You will end up fighting a never-lasting
battle...
Posted on 2001-08-04 22:44:28 by f0dder
if you are looking for virii then the last section (.reloc?) is often expanded and filled with code, so check the characteristics vle in the secion header to see if it is executable or whatever
Posted on 2001-08-05 00:26:35 by SubHuman
No i am NOT looking for viri... nor am i trying to do antivirus software...

I just want to make sure that i will not allow a "black listed" application to be run as a side efect of its viral infection (this makeing it unrecognizeable by me)
Posted on 2001-08-05 10:42:11 by BogdanOntanu
Like I said, multiple tests will most likely be what you want, that way you can block several versions of the same app very easily, and the black listed proggie could fail the crc, yet still not allowed to run if other characteristics were found to be in the database. I can't see why this solution wouldn't work for you? :)
Posted on 2001-08-05 15:41:36 by bitRAKE
Don't use ToolHelp/32... etc stuff... It is too easily foolable as demonstrated by 29A.

I've tought about md5 over all the code but it would be impossible to make a check based on the sum because it will always change.
ex:
if the md5 sum of
test eax,check_sum
is aa12
when you'll enter the true sum it will change to ba15
( the sums are invented .... )
I've tried to figure out a way but never found one

Jp
Posted on 2001-08-05 18:22:22 by JP?
JP, first of all md5sum is too large to be in a single register. Next,
for a simple 32bit checksum, store the sum in your .data section
and do a "cmp eax, ". That way, if you only sum the .text
section, you are beyond a lot of problems. You shouldn't really ever
checksum the .data of an in-memory application, for obvious reasons...
Posted on 2001-08-05 18:27:47 by f0dder
bitRake,

I will work for me of course, i was thinking to do the same as you said... but its a brainstorm ... i just want to hear all ideeas ;) in order to have as many methods/checks as posiible....

JP3,

I dont worry about ToolHelp32 API because i will not fight pro hacker/cracker just the ocasional medium user ;)

(PS where did 29A made that demo? :D )

Besides where can i find some good examples of CRC32 and md5 algorithms?


Tola,

Filesize? wow....interesting
class name....well yeah but all MFC applications share the same class name, also all Dialog based main windows....

but good ideeas...might work for some files ;)
Posted on 2001-08-05 18:58:10 by BogdanOntanu
Hey Bogdan!
Here's some
MD5 stuff by RudeBoy

Does the URL ring a bell? :)

Latigo
Posted on 2001-08-05 19:22:53 by latigo
Sorry for the error that I made, I wanted to talk of Process32First/Next and I confused with ToolHelp :(

By the way this demonstration used the include that describes the DOS/EXE MZ Format and the PE Format. This include was coded by Jacky Qwerty/29A

And the demo was coded by Vecna ( nice job ;) ) ... so I guess you should ask him ! :)

Jp
Posted on 2001-08-05 19:36:32 by JP?
Just some ideas..
Imho you are going to deal with 2 types of users:
- average user (stupid)
- experienced user ( a cracker)

Dealing with the first type, a rather simple protection would be enough ( i think the majority of type 1 could at max rename the exe). So i think you can search for:
- section's names (if it has a strange one, not 'text' and 'data' obviouvsly
- particular sequence of bytes ( strings and/or code bytes) (like av software does)
In general, software which imports WriteProcessMemory is likely to be a trainer/malicious , but it's really difficult to state if it's a nice prog instead...

If you're going with type 2 user, i would rather protect MY code instead with crc and similar. If general it's easier to nop out a routine than undesrtand it, and a cracker would probably start attaccking YOUR code, searching for your anti-trainers routine and nopping it out

i hope it's understandable, although english isn't my mother language

TheCla|irv0yant
Posted on 2001-08-07 15:53:36 by TheCla|rv0yant
63-bit CRC (C and optimized ASM)

CRC_CON  EQU       77073096H


PROC MY_PROC NEAR

CALL MAKE_CRC

; ... do something

MOV [CRCOD],0
MOV CX,[LENGTH]
LEA SI,[BUFER]
CLD
@@1:
LODSB
MOV EBX,[CRCOD]
SHR EBX,24
XOR BL,AL
MOV EAX,[CRC+EBX*4]
SHL [CRCOD],8
XOR [CRCOD],EAX
LOOP @@1
;Now CRCOD contains CRC-32 of BUFER

; ... do something

RET

ENDP

PROC MAKE_CRC NEAR

PUSH CS
POP ES
LEA DI,[CRC]
XOR DL,DL
@@1:
MOVZX EAX,DL
SHL EAX,24
MOV CX,8
@@2:
SHL EAX,1
JNC @@3
XOR EAX,CRC_CON
@@3:
LOOP @@2
STOSD
INC DL
JNE @@1
RET

ENDP

CRC DD 256 DUP(?)
I have 16 and 48-bit too. :)
Posted on 2001-08-07 17:24:28 by bitRAKE