My slides from RusCrypto-2017
Stay tuned!
Thursday, April 13, 2017
Wednesday, March 15, 2017
The release of EVHEN
A fast and lightweight asymmetric cryptography with a possibility of encryption would give us a lot of the very important advantages. First, there would be no need for Diffie-Hellman key exchange algorithm. It would make a process of starting of a communication much lighter, faster and secure. One would communicate simultaneously with 2 and more others encrypting\decrypting a content "on-the-fly" without fear of the sender spoofing. Second, the hardware requirements for the secure communications would be much less. It's very sensitive for IoT. And there would be one important effect: some attacks (like DDoS over HTTPS) would be much more complicated and much less effective. Third, ... it would be a fast and lightweight asymmetric cryptography with a possibility of encryption and that is all...
Today I release EVHEN. EVHEN is a fastest asymmetric cipher which allows both encryption and signing of messages WITH A SPEED OF A CLASSICAL SYMMETRIC BLOCK CIPHER! It is based on the chaos theory, theory of symmetric SPN-ciphers, white-box cryptography and on the method of concealing of a linear relationship (https://eprint.iacr.org/2010/419.pdf). I named this work in honor of two greatest mathematicians: Evariste Galois and Jules Henri Poincare.
Everyone can access a source code here and try EVHEN for themselves. Feel free to contact me and stay tuned.
Best regards
Sunday, January 8, 2017
A sample of a chaotic white-box cipher
Hello, all!
I am happy to announce a release of a new version of my white-box tables generator. The previous one is accessible here: https://github.com/ReCryptLLC/white-box The improved version has the following advantages:
I am happy to announce a release of a new version of my white-box tables generator. The previous one is accessible here: https://github.com/ReCryptLLC/white-box The improved version has the following advantages:
- S-boxes are generated using chaotic maps;
- Diffusion layers of the rounds are based on the randomly generated MDS-matrices;
- Some improvements in implementation of LRC method (https://eprint.iacr.org/2010/419.pdf) which allow usage of a chaotic symmetric cipher in asymmetric way.
I also would like to announce a more detailed description of a theoretical background. Sources also will be available soon.
For now everyone can download 3 sample files here: https://drive.google.com/file/d/0B4mHmobiyiGfQmZkTTNOZHNrYTQ/view?usp=sharing
wb_encr_tbl.h and wb_decr_tbl.h contain white-box tables for encryption and decryption. main.cpp is a sample of usage.
Feel free to contact me.
Best regards.
Friday, December 2, 2011
Monday, November 28, 2011
Ariadne. On deobfuscation in practice
ZeroNights-2011 is over. It was a very interesting event in the Russian information security world. The slides of our talk are presented below.
It was our first public talk about Ariadne engine. Our team had been working hardly on its creation for the more than a year. Ariadne is an engine for reverse engineers. It will help them effectively analyze executables. Our engine can be used for deobfuscation, obfuscation and for any other code-flow or data-flow analysing task. It contains built-in trace deobfuscation (AIR Wave deobfuscation technology). And it's easy to build Ariadne into other third-party projects.
See it for yourself: http://ariadne.group-ib.ru/
It was our first public talk about Ariadne engine. Our team had been working hardly on its creation for the more than a year. Ariadne is an engine for reverse engineers. It will help them effectively analyze executables. Our engine can be used for deobfuscation, obfuscation and for any other code-flow or data-flow analysing task. It contains built-in trace deobfuscation (AIR Wave deobfuscation technology). And it's easy to build Ariadne into other third-party projects.
See it for yourself: http://ariadne.group-ib.ru/
Thursday, February 10, 2011
Tuesday, January 11, 2011
Отголосок прошлого :)
На cracklab-е обсуждается тема взлома конверта, разработкой которого я занимался раньше :) Интересно, сколько времени потребуется на решение задачки (восстановление извлеченных инструкций). Судя по всему, версия конверта достаточно древняя.
Кстати, технику выдергивания одной инструкции (а это и делает опция /RIP_CODE) используют достаточно большое количество протекторов. Очень часто таким образом запутывают граф потока управления. Armadillo, к примеру, ставит int 3 вместо извлеченной инструкции. В некоторых конвертах ставится call, что накладывает ограничения на размер инструкции (>= 5 байт).
При кажущейся простоте подхода восстановить исходные инструкции может быть и не так просто. Все зависит от того, насколько защищен интерпретатор извлеченной инструкции. Можно, в принципе, попробовать восстановить посредством анализа входов и выходов, но здесь возникает проблема идентификации этих входов и выходов. Например, как определить, что была извлечена инструкция mov eax, [imm]? Поставить бряк на память? А если есть фальшивые чтения памяти? А если флаги доступа к страничке эпизодически меняются тем же VirtualProtect-ом? Плюс ко всему, необходимо полное покрытие исследуемеого файла дизассемблером, что в случае перехваченных инструкций еще более затруднительно. Т.е. задачка то в общем случае вовсе нетривиальная :)
Другой вопрос в том, какой защитный механизм срабатывает при интерпретации такой перехваченной инструкции. Может так случиться, что восстанавливать исходные нет никакой необходимости. Проще подкорректировать интерпретатор так, чтобы он всегда работал как надо :)
В случае с конвертами, идущими в качестве бесплатного (или платного) приложения к донглам, упор делается на поддержку всех выпускаемых ключей. А значит и младших (медленных и устаревших), и сетевых моделей. Это значит, что вызывать электронный ключ каждый раз при вызове интерпретатора перехваченной инструкции даже при использовании профайлера нельзя (именно поэтому мы пока не видим хороших автоматических решений для ключей с загружаемым кодом). Особенно четко это проявляется в случае сетевых ключей. Поэтому используется либо периодический опрос (когда клиент сам задает период опроса донгла), либо кеширование информации, полученной с помощью донгла.
В случае периодического опроса вся вина при потере производительности ложится на клиента, который осуществляет защиту. Период опроса он, как правило, задает самостоятельно.
В случае кеширования информации необходим хитрый механизм, который, в зависимости от платформы, на которой запущено защищенное приложение, будет определять время, в течение которого информация будет храниться в кеше. Или надо придумать некоторый параметр, который это время регулировал бы, свалив всю вину на клиента :) Информация в этом случае достаточно стандартная (расшифрованные с помощью донгла код, байт-код или данные, ключ для расшифрования чего-либо, какое-нибудь инициализирующее значение для чего-либо, полученное с помощью донгла).
Самое интересное в том, что для задачи привязки софта к ключу (или лицензирования вообще) глубокой разницы между полноценной обфускацией кода программы и выдергиванием по несколько (или даже по одной) инструкций с последующим встраиванием интерпретатора нет. В случае лицензирования ведь нет необходимости защищать пользовательский код от анализа, а надо, чтобы он не работал при невалидной или отсутствующей лицензии. А вот механизм лицензирования должен быть действительно качественным, что сложно обнаружить в унифицированных решениях в силу объективных причин.
Кстати, технику выдергивания одной инструкции (а это и делает опция /RIP_CODE) используют достаточно большое количество протекторов. Очень часто таким образом запутывают граф потока управления. Armadillo, к примеру, ставит int 3 вместо извлеченной инструкции. В некоторых конвертах ставится call, что накладывает ограничения на размер инструкции (>= 5 байт).
При кажущейся простоте подхода восстановить исходные инструкции может быть и не так просто. Все зависит от того, насколько защищен интерпретатор извлеченной инструкции. Можно, в принципе, попробовать восстановить посредством анализа входов и выходов, но здесь возникает проблема идентификации этих входов и выходов. Например, как определить, что была извлечена инструкция mov eax, [imm]? Поставить бряк на память? А если есть фальшивые чтения памяти? А если флаги доступа к страничке эпизодически меняются тем же VirtualProtect-ом? Плюс ко всему, необходимо полное покрытие исследуемеого файла дизассемблером, что в случае перехваченных инструкций еще более затруднительно. Т.е. задачка то в общем случае вовсе нетривиальная :)
Другой вопрос в том, какой защитный механизм срабатывает при интерпретации такой перехваченной инструкции. Может так случиться, что восстанавливать исходные нет никакой необходимости. Проще подкорректировать интерпретатор так, чтобы он всегда работал как надо :)
В случае с конвертами, идущими в качестве бесплатного (или платного) приложения к донглам, упор делается на поддержку всех выпускаемых ключей. А значит и младших (медленных и устаревших), и сетевых моделей. Это значит, что вызывать электронный ключ каждый раз при вызове интерпретатора перехваченной инструкции даже при использовании профайлера нельзя (именно поэтому мы пока не видим хороших автоматических решений для ключей с загружаемым кодом). Особенно четко это проявляется в случае сетевых ключей. Поэтому используется либо периодический опрос (когда клиент сам задает период опроса донгла), либо кеширование информации, полученной с помощью донгла.
В случае периодического опроса вся вина при потере производительности ложится на клиента, который осуществляет защиту. Период опроса он, как правило, задает самостоятельно.
В случае кеширования информации необходим хитрый механизм, который, в зависимости от платформы, на которой запущено защищенное приложение, будет определять время, в течение которого информация будет храниться в кеше. Или надо придумать некоторый параметр, который это время регулировал бы, свалив всю вину на клиента :) Информация в этом случае достаточно стандартная (расшифрованные с помощью донгла код, байт-код или данные, ключ для расшифрования чего-либо, какое-нибудь инициализирующее значение для чего-либо, полученное с помощью донгла).
Самое интересное в том, что для задачи привязки софта к ключу (или лицензирования вообще) глубокой разницы между полноценной обфускацией кода программы и выдергиванием по несколько (или даже по одной) инструкций с последующим встраиванием интерпретатора нет. В случае лицензирования ведь нет необходимости защищать пользовательский код от анализа, а надо, чтобы он не работал при невалидной или отсутствующей лицензии. А вот механизм лицензирования должен быть действительно качественным, что сложно обнаружить в унифицированных решениях в силу объективных причин.
Subscribe to:
Posts (Atom)