CreateFileA, the mother of all self-checks

[MaRKuS-DJM]

as you know, nearly every program which uses a self-check on file (on harddisc, not in ram) needs to use the API CreateFileA to open it.

so my question: is it a good solution, first to create a copy of the file called <originalexe>.dat
and then do in the exe following:
hook the API CreateFileA

the hook does
Check if CreateFileA is used on main-exe
if used on main-exe, patch <originalexe>.exe in memory to <originalexe>.dat
then call real CreateFileA
so the program would think every CRC is ok because it checked the original file.

[diablo2oo2]

which protectors can be patched so?

but maybe sometime the app use thd createfile to open other file,and do other thing,that will cause problem.

I think the convenient way is to nop the checking code.

[taos]

No, I think Markus-DJM is right, you can filter in the parameter of createfile if the name of the file to open is the EXE file, then you must change this parameter to the dat file.

But when you use a system wide hook like cretatefile your system perfomance is down (it's an api very often used) and you must remember that other apps uses this hook (antivirus apps).
To launch the hook you must use a app that when finished your original app must unhooked the func. Bufff!
you can add a new section in the original app,change the entrypoint and then make an application hook to createfile and you don't need to hook ALL the processes in the system, but bufff again. :-)


I think it's less agressive using NOP patch.

If you can make a program that can add a new section in a exe and add a call to a func (with loadlibrary of course) in this section, I can make the hook for you or I can make a system wide hook with a app to test how it's affect system perfomance.

Bye

[MaRKuS-DJM]

well for asprotect it would be possible. it uses it's own IAT, and so i hooked it only for this file, ASProtect thought it isn't modified and let me change what i want.

Originally Posted by lordor

but maybe sometime the app use thd createfile to open other file,and do other thing,that will cause problem.

I think the convenient way is to nop the checking code.

of course there must be a 100% working filter which only affects the loaded file.
i don't want to hook the complete system, i think this would be a bit too hard, and like taos said, not good for system performance.

Originally Posted by diablo2oo2

which protectors can be patched so?

i was able to modify nearly all files which had a self-check this way. Protector? ASProtect for example.

Originally Posted by taos

you can add a new section in the original app,change the entrypoint and then make an application hook to createfile and you don't need to hook ALL the processes in the system, but bufff again. :-)

where's the bufff in this case?

[taos]

you are right, there's not a lot of job in this case, only if you can make a generic add new section program that adds the func to execute the hook.

can you make this?

if the answer is yes then you can make a generic tool that patch ALL the CRC checks.
Even if you can call a DLL func without parameters (like void func() then you can use the generic hook DLL from validtec like I posted some time ago and you can HOOK ANY API FUNC in the program. (for example getwindowsdate for trial, or get windows title to avoid olly debug, or createfile to avoid SICE too,etc...)

I worked in a project to change entry point to redirect to my func last year, but I did not think in this possibility, can be a cool tool...

[diablo2oo2]

hmm, asprotect has also an process checksum check. how you killed it?

i know a little trick that its possible to kill the crc check from aprotect when u create a loader which patch the process after the crc check is done. maybe a nice feature for dup?

[taos]

simple, hooking createprocess too.
You can hook anything.

[gigaman]

Some applications perform the self-check also in memory (i.e. simply reading the memory of some sections) - it won't be easy to hook, as it doesn't use any API functions.

Not all applications implement self-checking code by checking themselves on the file system. Others do their checking in memory.

Shade

For Asprotect and sure for Armadillo as well i saw 2 inline patchers made by GlObAl that uses the .bak method to kill asprotect and armadillo crc checks... i'm sure he could help us to understand how this work.. maybe someone who knows him would like to contact him and ask him gently to share information for this with us ...

Asprotect Inline Patch Helper v01.05.2002 (AIPH) has the following info.

""So i began to try inlinepatching ASPR targets with some help from Silberfuchs.
He was at this time able to IP it but his patches didn't work on other systems so we worked
together on it and figured out a method to IP ASPR programs by using an *.bak file
so the protected programs checked the CRC on that file instead of the patched file.
I began to make the IP more combatible and optimized it more and more
so it worked without *.bak file and on w9x / nt / w2k / xp !""

btw i'm not sure if GlObAl and Silberfuchs are members of this board but you can catch them at RCE board ...

also so far i know the owner ( [NtSC]) of this site---> hxxp://mitglied.lycos.de/ntsc2k2/ knows GlObAl if bad don't remember one of his last work was to make Asloader (generic loader for asprotected targets) which mem. patch asprotect without using any special trick.. it just patch it.

Regards

[MaRKuS-DJM]

Originally Posted by ShadeOfRed

Not all applications implement self-checking code by checking themselves on the file system. Others do their checking in memory.

Shade

yeah, that's right. but most of this can be found through a breakpoint > memory > on access and then it is done.

Regarding ASProtect inline patches: BetaMaster informed me that Revenge Crew did an Inline Patch for ISO Commander 1.4.091 without a bak-file or anything. they were able to fix the checksum and so inline-patch it.

for those who still don't have latest version of AIPH , the one was build win2k compatible.. here it is...btw i see Global also mention a tool to inline patch Neolite 2.0 .. which i have never seen or neither find any reference to it.. is it a private tool?? does anyone knows about it?

''Main idea is born to make an ASPR inlinepatching helper like NIS (Neolite Inline Spacer) !"

this is wrote on the History.txt file included in the zip archive.

to find OEP + End of unpacking routine is very easy .. but has some crc checks which crash the archive to avoid inline patch ... anyone has successfull inline patch neolite manually ?

Regards

[MaRKuS-DJM]

yeah, i inline patched it.

first i set a BP on VirtualProtect, you have to find the point where pages are protected again after program is fully unpacked or your inline patch will fail. save it and then you can inline patch it like other programs

[Michel]

I don't know if I understand all this topic, but relatively at the .bak method, there is a well knowed way to bypass the CRC-check on disk : simply leave the original exe as it is and start the patched one, renamed, in the same folder... What more is needed ?