Compile time обфускация используя NAND/NOR

[kunix]

forceinline — наше все!
Вообще, это конечно колхоз.
Обфускацию должен делать компилятор.

[Dinisoid]

Спасибо, воспринимайте это как POC, для людей кто не хочет модифицировать конкретный backend LLVM :)

[kunix]

Впрочем, не всегда можно скомпилять себе тулчейн.
Я тоже этим всем занимаюсь.
Часто приходится инлайнить обфусцированный код для создания строк, при помощи forсeinline и alloca.
В коде это выглядит как sprintf(buf, CSTRA(«top secret»), ...);

Заинлайненый alloca в цикле — мой любимый баг :)

[avdx]

А какой смысл использования ГСПЧ, если функция xorshift256_next не сохраняет состояние? Т.е. получается, что каждый следующий вызов RND никак не зависит от предыдущего — при каждом новом вызове просто инициализируется новый ГПСЧ, который генерирует одно число. Не проще ли напрямую использовать хэш от __COUNTER__ и __TIME__?

[Dinisoid]

Можно делать и так как вы говорите, но качество рандома будет хуже чем у xorshift256, это основная причина почему сделано именно так, можете провести эксперимент с TestU01 если есть возможность и интерес. Так же посмотрите макрос SEED в проекте.

[avdx]

Насколько я понимаю, при использовании этого (как и многих других) ГПСЧ, каждый вызов next() должен использовать состояние, сохраненное предыдущим вызовом. Только в этом случае можно говорить о какой то случайной последовательности и, соответственно, ее свойствах.
Здесь же при каждом вызове RND генерируется новое состояние с помощью этого макроса SEED, которое потом никуда не сохраняется и соответственно при следующем вызове xorshift256_next() никак не используется. Т.е. каждое новое случайное число определяется новым SEED и зависит от него, а не от свойств ГПСЧ.

[kunix]

Dinisoid просто использовал ГПСЧ вместе хеш-функции.

[Dinisoid]

avdx, Вы правильно считаете, но наличие сохраненного состояния не гарантирует вам хорошей рандомизации если за основу взят неправильный принцип его генерации, состояние — это только одна важная часть PRNG. Передо мной не стояла задача сохранять стейт xorshift256, в данном случае просто получить вменяемые compile time значения, чтобы не получать повторения одних и тех же инструкций на большОм количестве операций.

[avdx]

Задача понятна. Но генерируемая таким образом последовательность (назовем ее X), не является последовательностью, генерируемой указанным ГПСЧ, а является последовательностью, полученной из первых чисел последовательностей, генерируемых разными ГПСЧ, инициализированными случайным образом. Соответственно нельзя утверждать, что X обладает свойствами последовательностей, генерируемых данным ГПСЧ. Тогда какой смысл в его использовании вообще?
Я думаю, если сгенерировать тестовую последовательность описанным способом (без сохранения состояния), то указанный в статье тест она пройдет не лучше, чем последовательность, сгенерированная хэш функцией, используемой для генерации состояний. Поэтому я и написал, что проще использовать сразу результат хэш функции. Хотя возможно у этой хэш функции случайность вообще плохая и присутствуют какие то явные патерны, тогда первое число, генерируемое ГПСЧ, действительно может обладать большей случайностью, но все же вся последовательность не будет обладать свойствами, обеспечиваемыми этим генератором.

[yleo]

Использовав xorshift Dinisoid пальнул из пушки по воробьям и устроил пытки MSVC. Для подобной задачи хватило-бы простейшего миксера. Причем использование макросов, а не новомодных constexpr, доставило бы компилятору намного меньше мук ;)

Тем не менее, более-менее приличный ГПСЧ использованный подобным образом (без состояния, с инициализацией от натуральной последовательности) пройдет все упомянутые тесты, как и более-менее приличная хэш-функция.