- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
int LoadFunctions() {
HINSTANCE kernel;
decrypt(krn);
if((kernel = LoadLibraryA(decb)) == NULL) {
return 1;
} else {
decrypt(crf);
if((CreateFile = (CreateFileP) GetProcAddress(kernel, decb)) == NULL) return 1;
decrypt(sfpe);
if((SetFilePointerEx = (SetFilePointerExP) GetProcAddress(kernel, decb)) == NULL) return 1;
decrypt(wf);
if((WriteFile = (WriteFileP) GetProcAddress(kernel, decb)) == NULL) return 1;
decrypt(ch);
if((CloseHandle = (CloseHandleP) GetProcAddress(kernel, decb)) == NULL) return 1;
decrypt(ffb);
if((FlushFileBuffers = (FlushFileBuffersP) GetProcAddress(kernel, decb)) == NULL) return 1;
}
HANDLE user;
decrypt(us);
if((user = LoadLibraryA(decb)) == NULL) {
return 1;
} else {
decrypt(mba);
if((MessageBoxA = (MessageBoxAP) GetProcAddress(user, decb)) == NULL) {
return 1; // ну зачем?
}
}
return 0;
}
Бида-бида, MessageBox не загрузилась - повод завершить выполнение. Хотя все важнейшие функции уже на месте.
ну и школокриптография тоже
Круто прибивать 0 и тру друг к другу.
остальное в норме имхо, т.к. по ошибке лучше сразу прерывать исполнение кода, лишая его "структурности" дополнительными else
чем "площе" код, тем проще
а с третьей стороны, пока хакер доберется до последнего декрипта (иначе зачем декрипты нужны) - невозможно будет узнать наверняка, для чего разраб придумал именно такую последовательность действий
в общем суть претензии к коду непонятна в виду отсутствия понимания контекста, в котором код используется