yes i know, i used to use Hashtab :
http://www.implbits.com/hashtab.aspx
it integrate itself in the file properties and then you can compare the hash from the present exe with its should-be-legit-one.
so FIAS could (already?) do the same job and highlight the said file if difference are found.
all this for make it average Joe Friendly; it is not really vital
Yes by default FMAIS does actually already cross ref those sources but it does not directly outputs them, as its a background task during the generation of the process and log itself.
But what i try to achieve (And it works ^^) is to use HASH as a authority tool or aka another source.
And by doing so i can use the Authority system within the OS to transform its function to log regardless what data to a point where it has the ability to actually see if the data is rogue or not.
Because as it stands it does not care what data or what the code is it just logs them no more no less.
And i want it to be able to class the code as windows, program or rogue.
Keep in mind windows ALWAYS knows if a file is bad, it just does not tell you as the function to do so is sleeping but it is present.
And with a little work around you can actually tell windows to be its own judge.
Alright let me show you something ok?
1:
http://www.microsoft.com/en-us/download/details.aspx?id=11533 Download Microsoft File Checksum Integrity Verifier (Win 7 32b)
2: Extract it in c:\FMA (If you do not have folder then create it manually)
3: Open elevated cmd.exe
4: Type code: c:/fma/fciv c:/windows/ -r -s >>c:/hash.txt (Must be exact!!!)
5: Wait till the command is done.
6: Navigate to c:/fma/hash.txt and open it up.
You will see the exact HASH of each file under %windows% as they SHOULD be as the check does make sure they are integrity wise correct.
dd502a2e7b85ea7a3814c1034e6c23d3 c:/windows/\AppPatch\AcGenral.dll
96c70bd48d49b87475f4572dedc62eb9 c:/windows/\AppPatch\AcLayers.dll
2110ce8cb4c6937200a973ad0b70f33d c:/windows/\AppPatch\AcRes.dll
323e85ec2f18ee5380c7668d4bff832f c:/windows/\AppPatch\AcSpecfc.dll
3cce7c726b88918915a1ef712b9d5f58 c:/windows/\AppPatch\AcXtrnal.dll
59c7dd2eafdbe86b2e23bcdabb575448 c:/windows/\AppPatch\apihex86.dll
2fa8458d3ad94e2393e1a6583293d8dc c:/windows/\AppPatch\drvmain.sdb
feed731d80e4cccc5be0a5308552d178 c:/windows/\AppPatch\en-US\AcRes.dll.mui
87900a56a4391cbc8718b65e7eec5d56 c:/windows/\AppPatch\msimain.sdb
125b25bae163c7ed0887ac66d9ef7b68 c:/windows/\AppPatch\pcamain.sdb
1d8c1280d38c526c7041e72db8d70dc1 c:/windows/\AppPatch\sysmain.sdb
f7f759a5cd40bc52172e83486b6de404 c:/windows/\assembly\Desktop.ini
And you will see output in the log like above.
Now if you have additional information sources like my program has then a example file called: imightbeinfected.exe located in %windows% will have the same hash as it will have in for example %appdata% as location of the file itself is not a factor if the hash changes BUT if you alter the code or create a clone which does happen 9.9/10 times then the files seem to be the same but their hash is totally different as the checksum does not match anymore. As it will have more then one source to validate its very own file source code and check the very route a file might use to execute its commands and functions.
There is no way you can fake all that.
So each string, path, name, source and so on has to be the same in order to validate.
And if injected, corrupted or hacked or whatever alteration it will FAIL and it will show in the log making it 100% failsafe and accurate.
I know that due to my limited english i might be explaining this a bit wrong, but i am sure you can visualize what i mean.
So its not a one way check it a series of checks and each check MUST be validated if just one fails?
Then you know the file is bogus.
Cheers
