- 1
- 2
- 3
- 4
- 5
- 6
- 7
doit({txs, [Tx]}) ->
X = tx_pool_feeder:absorb(Tx),
Y = case X of
ok -> hash:doit(testnet_sign:data(Tx));
_ -> <<"error">>
end,
{ok, Y};-
Haskell / Говнокод #25323
0
Прекраснейший код на Erlang из великолепнейшей криптовалюты AMOVEO
Здесь мы видим эндпоинт для отправки транзакций в сеть, возвращающий в случае ошибки ["ok","ZXJyb3I="]
Приглядевшись можно увидеть закодированное в base64 слово «error»Запостил:
silvesterdrago,
24 Января 2019
Follow us!
вот эти долбоебы юзали base64 чтобы таблицу зашифровать. а аддоны то пишутся на луа. то есть, весь код открытый. ну вот у меня и появился таурен с ачивками за убийство Тралла :D
> base64
Помнится, на ГК кто-то проебал учётку из-за "зашифрованного" андроид студией пароля.
В принципе, и «Base64» можно назвать шифрованием, только ключ всем известен («ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijkl mnopqrstuvwxyz0123456789+/»).
Точка с запятой в COM-файле означает инструкцию CMP, точка с запятой и пробел —– это CMP SP, [BX+SI]. Таким образом, комментарий в асме может быть вполне валидным кодом в COM-файле.
REM в COM-файле –— это PUSH DX; INC BP; DEC BP. Пробел —– это AND (ожидается байт mod R/M). Комментарий в bat-файле тоже может быть валидным кодом в COM-файле.
Пока в мою петушиную голову никак не может прийти, как совместить ASM и BAT.
можно нахуярить программ с именами мнемоник. Так можно даже ассемблер сделать
Набор com файлов, каждый из которых умеет конпелять одну инструкцию?
Ключ /A указывает, что строка справа от знака равенства является числовым
выражением, значение которого вычисляется. Обработчик выражений очень
прост и поддерживает следующие операции, перечисленные в порядке убывания
приоритета:
() - группировка
! ~ - - унарные операторы
* / % - арифметические операторы
+ - - арифметические операторы
<< >> - двоичный сдвиг
& - двоичное И
^ - двоичное исключающее ИЛИ
| - двоичное ИЛИ
= *= /= %= += -= - присвоение
&= ^= |= <<= >>=
, - разделитель операторов
Я за. Для добавления новых инструкций (SSE, AVX, NEON, VFP) не нужно будет перекомпилировать ассемблер. Достаточно будет всего лишь добавить новых программ. Это настоящий unix-way!
http://govnokod.ru/12089#comment159728
http://www.cmods-dev.de/
Верхнее серое полосатое поле нужно отмотать, дальше на белой плашке интереснее будет.
чуваки собрали флеш-рояль просто
А ларчик просто открывался: в исходник нужно было добавить директиву {$N+} (либо компилятор запустить с соответствующим ключом, либо в IDE указать в настройках проекта, но в исходнике как-то надёжнее). Выпилить поддержку плавающего питуха простым репаком нельзя, ибо она зашита в компиляторе и в модуле SYSTEM.TPU, без которого ничего не скомпилируется.
*****
А ещё Тарас троллил почтенную публику «Гейдева» вопросом, почему в его ассемблере сдвиг вправо есть знаковый и беззнаковый, а сдвиг влево только беззнаковый (ну точнее, знаковый якобы есть, но из-за какого-то бага компилируется в тот же опкод). Чуваки ему посоветовали достать полную версию компилятора.
Операция сдвига влево принимает знаковость числа отдельным параметром?
https://gamedev.ru/code/forum/?id=139163
Гуглится по простой фразе «tarasb shl sal».
Пример:
100 = 0x64 = 0b0110100;
50 = 0x32 = 0b0011010.
50 из 100 можно получить сдвигом вправо, 100 из 50 —– сдвигом влево. Освободившиеся разряды в обоих случаях заполняются нулями.
Теперь для отрицательных (в дополнительном коде, известном так же как two's complement):
-100 = 0x9c = 10011100;
-50 = 0xce = 11001110;
-50 из -100 можно получить сдвигом вправо с заполнением освободившихся разрядов единицами (т. е. слева как бы вдвигается бесконечная лента единиц).
-100 из -50 можно получить сдвигом влево (естественно, с потерей единиц, которые выезжают за пределы разрядности).
В «Java» есть оператор >>>, который освободившиеся разряды заполняет нулями (беззнаковый сдвиг), и оператор >>, который в случае сдвига положительного числа так же заполняет освободившиеся разряды нулями, а в случае сдвига отрицательного числа заполняет освободившиеся разряды единицами (знаковый сдвиг).
Для сдвига влево в «Java» есть оператор <<, а вот оператора <<< нет.
В ассемблере для x86 есть беззнаковый сдвиг вправо (SHR), знаковый сдвиг вправо (SAR) и беззнаковый сдвиг влево (SHL). А вот знаковый сдвиг влево (SAL) компилируется в тот же код операции, что и SHL.
Вопрос: почему в «Java» нет оператора <<<, а в наборе инструкций x86 не различаются знаковый и беззнаковый сдвиг влево?
В XX веке на командах решили сэкономить, чтоб вписать ОП-код с N бит?
Видно же, что в половине случаев ushl и sshl отличаются, как и ushr от sshr:
Они что, воспользовались тем, что правые сдвиги различаются, по большей части, когда результат математически верен, а левые - только когда один из сдвигов неверен, и потому плюнули на консистентность команд и полноту области определения, прописали UB для математически неверных случаев знакового сдвига и сэкономили на ОП-коде?
Разработчики процессоров и компиляторов решили, что специальная операция с сохранением математического смысла (умножение на два) для таких случаев никому не понадобится. Старшие биты всё равно будут потеряны (мы и при беззнаковом сдвиге их теряем).
Es una equivocación pensar que todos los productos extranjeros son mejores que los nacionales...