EXE протектор

[Хакер]

Разработчики руководствуются тактикой: сделать взлом дороже покупки лицензии. При упомянутом тобой подходе можно эту тактику использовать против них же: сделать установление личности «предателя» дороже, чем обытки, которое оно покроет.

[arthur2]

Разработчики же сами разрабатывали свою программу - можно сделать, чтобы какая-нибудь из функций программы кроме своего прямого назначения сообщала бы имя предателя, если её об этом попросить заранее условленным образом.

[Хакер]

Сообщала? По подпространнственному телепатическому каналу?

[arthur2]

Если некий предатель выложил взломанную программу, значит разработчики могут взять эту взломанную программу, и вместо того, чтобы распаковывать замысловатые упаковщики, запустить её прямо нераспакованной и вызвать эту заранее оговоренную функцию...

Ну или я чего-то не понял в предложенных способах защиты и обхода защиты

[Хакер]

Наличие такой функции выдаёт весь метод. Тогда дешевле не замучить разработчиков расшифровкой, а всё же заменить ключ на послание.

[iGrok]

Предположим, что функция сродни пасхальному яйцу - вызывается строго определённой комбинацией действий в окне "О программе" (али ещё где)?

Предположим, что это у нас ActiveX exe, и ключ(и) возвращае(ю)тся при вызове одного из методов одного из экспортируемых классов с определённым параметром?

Предположим, что файл-отчёт создаётся при запуске программы с определённым параметром?

Предположим, таких функций несколько, и каждая возвращает свой ключ(мы же сделали несколько хранящихся по-разному и в разных местах копий ключа)?

[Хакер]

Ты говоришь так, как будто пасхально-яйце-подобные фишки сложно заметить.

[arthur2]

Предположим, что функция сродни пасхальному яйцу - вызывается строго определённой комбинацией действий в окне "О программе" (али ещё где)?

Или даже - для запуска этой функции нужен какой-нибудь компонент-ключ, который в поставке для юзеров просто не присутствует.

Добавлю: предположим, что это какая-то важная для работы функция, про которую никто и не подумает, что при определенных параметрах она занимается совсем не тем, чем ей, казалось, положено было бы заниматься

А пасхальные яйца просто заметить, потому что их в принципе и делают для того, чтобы кто-нибудь заметил

[djalex777]

Тут вот понял, почитав статьи и форумы:
По-поводу реверс-инжиниринга и взлома - VB всё таки намного упрощает (если не использовать обфускацию) реверс-инжиниринг, храня tlb и все методы и свойства классов, мало того сохраняя даже имена параметров. В самом начале топика Хакер писал, что это не намного упрощает реверс (или вобще не упрощает). Но ведь цель реверс-инжиниринга понять принцип работы чего-либо в программе. И обычно он начинается с исследования программы на то, какие компоненты используются и т.д., т.е. создается общее представление о программе. Мало какой программист будет называть свои функции заведомо так, чтобы запутать взломщика... Далее, VB-компилятор имеет свои реализации определенных языковых конструкций типа for и т.д., и ничего не мешает их с легкостью восстанавливать (что собственно тот же VBDecompiler и делает). Кроме того, все работы со строками, массивами осуществляются посредством функций из MSVBVM60.dll и так же легко восстанавливаются. Так что я слабо себе представляю как можно обмануть взломщика реализовав в функции, то что её несвойственно делать. Естественно нет никакого смысла привязывать программу по различным параметрам типа - на кого оформлена программа и т.д. Результаты работы программы отправлять куда-либо тоже нет смысла - всё это либо изменяется в программе, либо на выходе из программы.
В общем, получается мне ещё везет - специфика работы моих программ обязывает пользователя иметь постоянное подключение к интернету (по-крайней мере во время работы с программой). И эффективней следующей связки я ничего придумать и не смог:
1. Сервер лицензий - осуществляется проверка данных (данные приходят из программы), реализация некоторых функций программы на сервере (естественно результаты работы функций выдаются только тем, кто прошел проверку "лицензионности")
2. Исходный код программы - обфускация перед компиляцией основных методов и свойств классов, встраивание функций сбора информации о пользователе в логику работы программы.
3. Протектор - выбрал Themida - хорошие отзывы в инете, хорошая тех.поддержка, регулярное обновление.

[Хакер]

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 и так же легко восстанавливаются.

Не все. А только те, где ты сам полагаешь на рантайм. Полагаясь на него, чего же ты хочешь?

[djalex777]

Хакер, к чему твой пример? Я не говорил что по имени одной функции или её исходному коду можно понять что происходит в процессе в целом, что происходит, например, при нажатии кнопки и т.д. Но видя всю программу целиком - названия функций, последовательности вызовов, знать чем занимается сама программа (её результаты, исходные данные) - можно понять чем занимается твоя функция. Далее, твой пример на C++, что сравнивать с VB-кодом не много не правильно (даже в дизасме) (или я ошибаюсь?). Ты пишешь, про Runtime, а вот скажи что такое VB без рантайма? Естественно я рассматриваю применительно к большинству. По-поводу того, смогу ли я сказать, что делает твоя функция - будь за моей спиной годы опыта в области дизасемблирования, исследования чужих программ, реверс-инжиниринга - будь уверен - я бы дал ответ на твой вопрос. Но я этим не занимаюсь, поэтому могу тупо пытаться "логически-угадывать".

я считаю, что в неэлементарной программе знание имени метода, имён и типов всех его параметров играет ну совсем ничтожную роль.

Согласен с первой половиной предложения ровно до слова "знание". По-поводу второй - в VB ты знаешь не просто имя метода, а все, подчеркиваю, все методы и свойства всех объектов в приложении. А применительно к первой части твоего предложения, готов поспорить что твоя функция используется узконаправленно и помимо того в очень специфической области. Могу предположить для разбора чего-либо, возможно строит дерево. Возможно участвует в управлении или построении динамического кода.

[Хакер]

Мой пример к тому, что бояться TLB-шек, в которых (о ужас) осталась информация о членах публичных классов — как-то неоправданно. К тому же TLB-шное TypeInfo не привязано к самому коду. Метод-то у интерфейса есть, а ты ещё попробуй его реализацию найди. Не найдёшь, пока не создашь объект.

Далее, твой пример на C++, что сравнивать с VB-кодом не много не правильно (даже в дизасме) (или я ошибаюсь?)

Пример был немного о другом: даже исходный код иногда мало что даёт. В этом плане язык не важен.

Ты пишешь, про Runtime, а вот скажи что такое VB без рантайма?

А с C/C++ ситуация не лучше. Там тоже есть стандартная библиотека, а также библиотеки шаблонов, которые как-бы надо использовать. И всё это в отличие от VB-рантайма ещё и документировано. В принципе, никто тебя не ограничивает: можешь не использовать стандартную библиотеку, а реализовывать все функции сам. В принципе, в VB у тебя есть такой же выбор, за исключением маленьких ограничений. Но так зато рантайм недокументирован. И, ты по ищи, что пишут в интернете про __vbaNew2. Один дурак её исследовал через неправильное место, и пришёл к выводу, что она создаёт диалоги (wtf?). Куча последователей скопировало эту дезинформацию. Это к вопросу о том, насколько недокументированность может сбивать с толку.

По-поводу того, смогу ли я сказать, что делает твоя функция - будь за моей спиной годы опыта в области дизасемблирования, исследования чужих программ, реверс-инжиниринга - будь уверен - я бы дал ответ на твой вопрос.

По одним лишь названиям, я непоколебимо уверен: не дал бы. А при наличии кода, уверен, если и дал бы, то уверен, что дал бы и без наличия названий. Пример то всё-таки был о том, насколько страшно наличие TLB.

Согласен с первой половиной предложения ровно до слова "знание". По-поводу второй - в VB ты знаешь не просто имя метода, а все, подчеркиваю, все методы и свойства всех объектов в приложении.

Ну не всех, а только публичных членов публичных классов. Для приватных (или для Public Not Creatable) тоже что-то там создаётся без нашего на тожелания, но это легко обходится.

А применительно к первой части твоего предложения, готов поспорить что твоя функция используется узконаправленно и помимо того в очень специфической области.

Стоп. Что значит узконаправленные? Почему мои функции (дизассемблирующие код) укзонаправленные, а твои (считающие стоимость продвижения) нет?

[djalex777]

Думаю что задача дизасемблирования кода имеет меньший круг людей пользующейся ей, чем круг людей, занимающийся SEO. И в силу того, что пользоваться ей может только узкий круг людей (по большей части может и в силу своих знаний (точнее не знаний)) задача является очень специфической, следовательно и большинство функций. "узконаправленность" - я не правильное использовал слово.

[mere]

Уважаемый ТС, протектор не в этом случае, как он сможет предупредить нелегельное использование самой проги? Лучше всего обезопасить это эфективно использовать логику работы.