Почему во многих вузах всё ещё предпочитают Delphi ?

Исследование лично проводил или следовал по уже известным тропам? Какое поколение пациента?
Новости о хардварном бекдоре в их камнях были еще несколько лет назад, интересно как обстоит ситуация сейчас.

 

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

 

стоп стоп, что?

ты про то что там нельзя сделать скажем как в си:

__declspec(naked)
unsigned int __rdtsc32()
{
__asm
{
rdtsc
ret
}
}

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

 

Исследование проводил сам. Результаты - подтвердили наличие ошибки в обработке комманд.
После этого расследования, перешёл на камни AMD.

Дальше - камни Intel научились в HiDef 1080p видео декодинг и AES-256 hardware coding.
Технически - делаeт всё правильно и лучше AMD.

Пермутаций кода не наблюдается.
Что на входе - можно видеть, что на выходе - that is differnt story.

 

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

(Надо будет раскопать этот зверинец backup CD и вызвать их к работе)

GCC C - позволяет написать свой загрузчик .exe кода, и asm инструкции вставить в код - делается иначе.

 

во-первых - сравнивай побайтово данные, на листинг что выдаёт дизассемблер не смотри. во вторых - если у тебя чтото гдето меняется - устанавливай точки останова на чтение/запись, смотри какой код обращается и или читает/пишет туда

 

Мой согласен с тобой.
А как в среде Linux отслеживать interrupts функций? Точка, точка, запятая - вышла рожица кривая.

Kernel 4.1.4-ck - знать не хочет о прерываниях и запросы от девайсов обрабатывает быстро, Brain Fuck Sched

Не нашел ещё отладчика кода C в Linux. Может, ты знаешь?

 

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

 

> если у тебя чтото гдето меняется - устанавливай точки останова на чтение/запись
Инженеры Intel, умеют и это предугадать, действия заинтересованных .
И поэтому точки отладки, можно вводить - чтобы увидеть, как они не срабатывают, процессор берёт в себя over 64 байтов кода и исполняет их, в потоке всех других комманд в кэше процессора.

Подумал и решил - надо ставить Intel C Compiler и знакомиться с ним.

 

ну интеловский конпилятор тебе может и даст какойто прирост в скорости или запилит интринсиками какието вычисления типа avx/sse итд, в местах где у тебя memcpy или чтото такое, но это тут ни при чем. гугли чтото типа programming debug registers - это собсна аппаратная реализация точек останова во всех х86/x64 процах и амд и интела. обычные софтварные дебаггеры на самом деле в месте где ты ставишь брейкпойнт записывают код 0xCC, а потом выполняют прогу так чтобы ты ничего не заметил, а вот аппаратные брейкпойнты предусмотрены в процессоре, тащемта именно за счёт них у тя есть возможность ставить бряки не только на выполнение но и на чтение/запись

 

Научился за 5 лет вуза писать бат фаелы

 

комментатор Болталки Античат: и тут altblitz понимает что в виндах его sn0w нагнет с минуты на минуту и преходит на ту же тему но на линукс, вау! какая игра! какие повороты!