djalex777 писал(а):VB всё таки намного упрощает (если не использовать обфускацию) реверс-инжиниринг, храня tlb и все методы и свойства классов, мало того сохраняя даже имена параметров.
Уф. Во-первых, если тебе мешает спать TLB, убери её. Делов-то.
Во-вторых: я считаю, что в неэлементарной программе знание имени метода, имён и типов всех его параметров играет ну совсем ничтожную роль.
Один из моих любимых трюков: пример из моего flncgx86.dll.
Функция ничего не возвращает, называется
NcdCreateOp1SegRegDecoder, имеет два параметра: первый (byref)
rPrimaryOrTertiaryRouter типа
T_ROUTER_ENTRY и второй (тоже ByRef)
Instr типа
X86IKDTABLEENTRY.
Теперь скажи мне, много ли дала тебе эта информация? Можешь ли ты из этого открыть для себя, что именно делает эта функция? Я думаю, что нет.
Я думаю, что ты не сможешь, даже увидев дизасм.
Да куда там, я думаю, что ты не сможешь, даже увидев её исходник:
- Код: Выделить всё
void NcdCreateOp1SegRegDecoder(T_ROUTER_ENTRY *rPrimaryOrTertiaryRouter,
X86IKDTABLEENTRY &Instr)
{
T_ROUTER_ENTRY *SecondaryRouter;
T_ROUTER_ENTRY *Writer;
UCHAR ActiveOpcodeByte;
UCHAR *ByteFieldWriter;
ActiveOpcodeByte = (Instr.OpCodeSize == 1 ? X86_OPCODE_BFIRST(Instr.OpCode) :
X86_OPCODE_BSECOND(Instr.OpCode));
SecondaryRouter = NcdEnsureTransition5To3(rPrimaryOrTertiaryRouter, X86_HI_PENTA_PART(ActiveOpcodeByte));
Writer = DfaAddChildRouter(SecondaryRouter,
X86_LOW_OCTET_PART(ActiveOpcodeByte),
ROUTER(NcdInstructionWriters::Op1::PushPopSegWriter),
NULL);
NcdDecoderRtSetInstructionId(Writer, Instr.InternalCode);
NcdDecoderRtSetReturnToRoot(Writer);
ByteFieldWriter = (UCHAR*)(Writer->Router + Routers::NcdInstructionWriters::Op1::PushPopSegWriter::RegFieldOffset);
switch(Instr.OperandTypeMask[0])
{
case X86_ASM_OPERAND_TYPEMASK_REG_CS:
*ByteFieldWriter = X86_REG_CS;
break;
case X86_ASM_OPERAND_TYPEMASK_REG_FS:
*ByteFieldWriter = X86_REG_FS;
break;
case X86_ASM_OPERAND_TYPEMASK_REG_ES:
*ByteFieldWriter = X86_REG_ES;
break;
case X86_ASM_OPERAND_TYPEMASK_REG_GS:
*ByteFieldWriter = X86_REG_GS;
break;
case X86_ASM_OPERAND_TYPEMASK_REG_DS:
*ByteFieldWriter = X86_REG_DS;
break;
case X86_ASM_OPERAND_TYPEMASK_REG_SS:
*ByteFieldWriter = X86_REG_SS;
break;
}
}
Прочитав его, будут ли какие-то попытки рассказать, что делает функция (просто перевести название и сказать «создаёт декодер» — не катит)?
Мало какой программист будет называть свои функции заведомо так, чтобы запутать взломщика...
Вот я, например, называю свои функции очень понятными (в рамках проекта) именами. И вообще, очень
трепетно отношусь к названиям функций, не допуская даже намёков на двоякое толкование имени, или имя, вводящее в заблуждение.
Предлагаю тебе по названиям понять, что делают функции из той же оперы:
- NcgGetInstructionKDN,
- NcgTrySizeTranslation,
- NcdCreateModRmDecoder,
- NcdCreateIKProcessingTree,
- NcgCreateComplexOperand,
- NcgCreateSimpleModRM,
- NcgInitOpDescriptorPointerInternal,
- NcgConvertIKDTypemasks32to16,
- NcgCheckSegmentOverriden,
- NcdEnsureTransition3ToOCER,
- TknTransitionSelectorExclToToken,
- TsInsertSubsequenceAfter,
- ScInitializeSCSS,
- DfaInternalBreakRouterBackJumps,
- PmCreatePoolingArea,
- PmAllocatePool,
- ScGetTokenSequenceCrossingLinesRange.
Хотя бы парочку повезёт угадать?
Это к вопросу о том, насколько знание имён функций облегчает жизнь.
Далее, VB-компилятор имеет свои реализации определенных языковых конструкций типа for и т.д., и ничего не мешает их с легкостью восстанавливать (что собственно тот же VBDecompiler и делает).
Ну, не то что бы уже имеет, но если имеются в виду некоторые __vba функции которые выдают границы циклов, то циклы легко вычислить и без всего этого.
Кроме того, все работы со строками, массивами осуществляются посредством функций из MSVBVM60.dll и так же легко восстанавливаются.
Не все. А только те, где ты сам полагаешь на рантайм. Полагаясь на него, чего же ты хочешь?