I know absolutely *nothing* about Virus and Trojans and
i would like to spend my time at other things that learning
these stupidities.

Please, the great guys, here:

As SpAsm will certainaly gender some files exchanges, i am
searching for a way to absolutely prevent a SpAsm produced
PE from ever being corrupted that way.

Is the Checksum PE record a good way (i could store it with
another algo, if win doesn't care, or somewhere else...).


betov.
Posted on 2001-07-21 09:51:42 by Betov
No answer? May be i asked the question a wrong way...

-It seems that we can do what we want with the CheckSum
PE header record. Is it true?

-Infected EXEs must have something changed inside. When
loading them intirely in memory, we should see this when
recomputing the CheckSum (with an 'unregular' algo, of
course). Is it true?

betov.
Posted on 2001-07-21 18:39:52 by Betov
Betov,

For a binary virus to work, it must branch somewhere before the entry point and I think this is what you need to be able to detect. You have the advantage of setting up your own PE header and sections.

The problem with a preset method of testing is that the virus can overwrite it and branch to where its own code is executed. Perhaps a checksum of the PE header and sections will be of some use but the problem is that it can be bypassed at startup.

I think your idea is a good one in that if the virus attempts to return program execution to the original code after it has run, it should be able to be determined and present a warning to the user about it being modified.

Most of the crude techniques can be detected by heuristic virus scanners these days so if you can get an idea ofd what there capacity is, you may be able to work out a method to protect the rest.

Regards,

hutch@pbq.com.au
Posted on 2001-07-21 19:21:09 by hutch--
betov,

if you still dont solved these problems, email me at vecna@antisocial.com and i can help you in this

ancev
Posted on 2001-07-21 20:55:05 by ancev
Betov, such a scheme would be of more annoyance than good.
First of all, there's no way you can prevent all virii. Second, you
make it impossible for the "normal" user to, for example, use an
exepacker on your files.

False/flawed security (regarding virii) is, imho, worse than no security
at all. Because then you at least know that you're pretty damn
vulnerable.

My advice is to let the end users run antiviral programs. They can
be upgraded easily, and it's then up to the end-user to find a
solution he likes.
Posted on 2001-07-21 21:47:12 by f0dder
Thanks to all. There is a point i may have been missleading:

My intent is not to setup any true anti-virus thing. The
problem i would like to suppress is bound to the fact that
SpAsm users will tend, in the futur, to exchange SpAsm
produced PE (instead of only the code, to have the whole
thing at once).

When Asm programmers exchange PEs, there are a perfect target
for viruses'expand (for all the reasons you all know).

As we can expect that nobody will ever write a virus specificly
designed to target SpAsm produced PEs, i could as well write a
naive and simple CheckSum computation to be done both when
compiling the file and when loading the file. If the results
are different, SpAsm would just print a MessageBox telling it
to the programmer who opens the file (this does absolutely not
concern final users).

This idea has any interrest if, and only if, a corrupted file
have something different, readable, inside. Reversing the
question: If we have 2 versions of one given file, first
not corrupted, second corrupted, is it possible that they
both have the same octets sum when intirely loaded in Memory.
(i hope never...).
Posted on 2001-07-22 00:26:54 by Betov
Hi

dont know if this works...just a idea.

what if the file has inside a copy of itself and when execute it look if the original and the copy inside is the same....if not terminate.

ok ,the size will double...but in asm i think it no problem :)

cu
Posted on 2001-07-22 04:00:43 by CodeMonkey
Or if the virus packs the exe and after loaded it runs the original exe as a different process and hides the original exe ?
That would be a problem .....;)
Posted on 2001-07-22 06:52:48 by Rosky
Well, I think it's possible to do "fancy stuff" when using standard
CRC's. CRC16, CRC32 can be defeated this way. Probably also
microsofts checksum thing :/.
Posted on 2001-07-22 10:27:28 by f0dder
what about custom stub?
Posted on 2001-07-22 14:11:53 by disease_2000
i think that nearly al PE infectors will change either the entry point in the PE header, or will make the e_lfsanew part of the dos header point to a new PE header that the virus copies to the end of the host.

checking both of these should do the trick
Posted on 2001-07-22 18:36:34 by SubHuman
Since there is a helluva lot of ways to do the infections and entrupoint grabbing in a virus i don't really think there is a sure fire way to prevent or detect that part of it... checksums is a good idea but can be defeated... WinNT/2k uses it on some of the corefiles.... user32.dll, kernel32.dll and so on... there are a number of viruses that infect these files and they just update the checksum... same thing with cracks ad patches and stuff... good luck though... it would be nice to see somthing like this that actually works...

P.S ancev.... are you who I think you are? (based on you e-mail)
Posted on 2001-07-23 04:14:27 by NervGaz
what's the problem? the only thing you have to do
is to store the "clean" file-size in the exe file and
i would not use the checksum for this because nt
needs a valid value i think(?)... but there are several
reserved places in the pe-header you can use.
if the user loads a spasm pe just compare the actual
filesize with the clean size in the pe-header.

disease, why should a custom stub help???
Posted on 2001-07-23 18:54:34 by Unregistered
NervGaz,

this depend of who you're thinking i am. but the e-mail addres is correct. :alright:

ancev
Posted on 2001-07-23 21:15:43 by ancev

NervGaz,

this depend of who you're thinking i am. but the e-mail addres is correct. :alright:

ancev


Nevermind doesn't really matter anyhow.. :)

Unregistered... there are ways to infect files without increasing the filesize... overwriting cavities (NULL bytes, large ammounts of NOP's and so on)and stuff like that... so your idea is not exactly foolproof.. and as far as i know NT only checks certain files for the checksum...
Posted on 2001-07-24 02:27:26 by NervGaz
ancev,


.data
name1 db "ancev",0
name2 db " ",0
greet db "Hi ",0
buffr db 32 dup (0)
hello db "Hello",0
.code

invoke revstr,ADDR name1,ADDR name2
invoke szMultiCat,2,ADDR buffr,ADDR greet,ADDR name2

invoke MessageBox,hWnd,ADDR buffr,ADDR hello,MB_OK

Output => Hi vecna


Regards,

hutch@pbq.com.au :alright:
Posted on 2001-07-24 02:44:42 by hutch--
Thanks to all, guys, choice done and applied.

Got time to play the fool Hutch??? ;)

betov.
Posted on 2001-07-24 06:15:08 by Betov
nergaz,
yes it is true that some viruses check the alignment
first and decide if they are small enough to paste
themselves in that section but that is very seldom
i think (hm lord julus did it with rammstein i think).
what if betov stores a checksum of the clean size
instead of the filesize in the pe? this would be very
easy to do and a 100% save virus/manipulation
detection...
Posted on 2001-07-24 07:01:51 by Unregistered
checksum of the clean FILE i meant :(
Posted on 2001-07-24 07:04:44 by Unregistered
there are actually several that use cavity infection... and checksums are good better than filesize stuff.. but in no way foolproof...
Posted on 2001-07-24 09:31:32 by NervGaz