OllyDbg 2.01 Released

Надежда уже угасала, никто не ждал чуда и тут сквозь мрак отчаянье появляется Олег и релизит свой допил Ольги, причём не просто допил, а релиз версию(уже не бета) с нормальным ченджлогом и плюшками в виде опенсурс двигла дизасма, на котором видимо и базируется Ольга. Конечно сразу стало не ясно грустить или радоватся, ведь плюшки с одной стороны хорошо, багфикс вроде бы есть, но как показывает практика вся эта линейка 2.хх нестабильна до ужаса. Решил посчупать ...

Как и предполагалось баги некуда не делись, для обычного ровного приложения полёт нормальный, но как только подсунешь нечто с tls callback, или базонезависимый код, всё крешится, зависает, буфероверфловится и т.п. чернь. Даже ручная трассировка вызывала креш.  Нормально реверсить проты и мальварь в таких условиях явно невозможно. Тваютомать!

В общем мы(покрайней мере я) всё ещё верим в тебя Олег, что ты сможешь допилить вторую линейку до стейбла, запилишь туда х64 и прочие крутые плюшки. Уж больно не хочется переходить на другие более стабильные но дико неудобные отладчики

Сайт ольги http://ollydbg.de/

Загрузка библиотеки средствами ntdll.LdrLoadDll

Собственно маленький пример загрузки dll через недокументированную LdrLoadDll из Ntdll.dll. Код полностью независим от Kernel32.dll, что даёт возможность использования его в shellcode. Для получения адреса ntdll.dll используется трюк с PEB, а для поиска адреса LdrLoadDll используется самописанный парсер заголовка PE, аналог GetProcAddress. Всё предельно просто, но мало ли кому пригодится.

* код работает только под x86, чуть позже добавлю и для x64

Утечка данных в СУБД Microsoft Access

Не знаю баг ли это или фитча, но работая с СУБД Microsoft Access заметил что файл после многочисленных операций добавления и удаления(сбойных в том числе) таблиц подозрительно стал расширятся. Первоначально думал что вероятно это следствие логирования и т.п., однако в процессе обратного проектирования из Access в ErWin, помимо существующих баз появилась целая куча мусора. Собсно скрин по сабжу:

Этого мусора в СУБД не видно, что явно не хорошо, ЗЫ Access 2010 лицуха, со всеми апдейтами.

Осторожно, многомерные массивы в С!

Наткнулся на интерестную фитчу, честно сказать раньше этого не знал, мб кому-то поможет. Пусть имеется следующий код

 #include <stdio.h>  
 #include <stdlib.h>  
 int main()  
 {  
      char ***buf;  
      char arr[5][4][3];  
      int i, a;  
      arr[4][3][2] = 0x21;  
      buf = (char ***)malloc(sizeof(char **) * 5);  
      for (i = 0; i < 5; i++) {  
           buf[i] = (char **)malloc(sizeof(char *) * 4);  
           for (a = 0; a < 4; a++) {  
                buf[i][a] = (char *)malloc(sizeof(char) * 3);  
           }  
      }  
      buf[4][3][2] = 0x21;  
      printf("%x %x", (int)arr[4][3][2], (int)buf[4][3][2]);  
      getchar();  
      return 0;  
 }  

Тут создаются 2 многомерных массива, один в качестве типа char[5][4][3], а другой как char *** и соответственно заполняется динамически. Мне еще в универе внушили что многомерный массив это указатель на указатель и т.д., следуя данной логике можно предположить что arr и buf, посути одно и тоже, однака хрен там :) Несмотря на то что обращение к элементам этих массивов выглядит одинаково, в памяти они укладываются совершенно разными способами. Массив с типом char *** действительно является указателем на указатель и т.д., однако  char[5][4][3] является указателем на сплошной блок данных и для того чтобы обратится к элементы расчитывается только смещение, без всяких прохождений по цепочке указателей. Вот так вот, как говорится доверяй но проверяй.