нервные админы основаная проблема любых чатов, т.к. отбивают желание чтолибо писать. для особо нервных есть кнопочка отключить уведомления если что

А ведь раньше был нормальный чат

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

Это было про наплыв «участников» которые вначале общались, а потом начинали спам закидывать.

Это было про наплыв «участников» которые вначале общались, а потом начинали спам закидывать.

Ну а молчуны зачем набегают? У них же срок жизни крайне мал - как опубликовал [спам], так бан словил. Думаю, что больше 10 минут после спама не живут

Не очень понятно зачем массовый набег необходим

Ну а молчуны зачем набегают? У них же срок жизни крайне мал - как опубликовал [спам], так бан словил. Думаю, что больше 10 минут после спама не живут

Приводят спамеров. А какие-то и логгируют чат.

Приводят спамеров. А какие-то и логгируют чат.

Для лога чата достаточно одно сообщение опубликовать, а потом архив запросить

Впрочем, это оффтопик. Замолкаю

всем привет мне надо что то на бота пройти проверку или нет?

всем привет мне надо что то на бота пройти проверку или нет?

Чего ты от ассемблера хочешь? Как ты дошёл до жизни такой?

Чего ты от ассемблера хочешь? Как ты дошёл до жизни такой?

я наверно покажусь дураком, но на линуксах меня начал раздражать тот факт, что не всегда драйвера есть в дитсрибутивах линукс ( в их репозиториях ? хз), и я решил что нужно научится писать самому драйвера ( а у меня случай с wifi адаптером). А т.к чтобы хорошо понимать С, я решил начать с ассамблера, как то так

я наверно покажусь дураком, но на линуксах меня начал раздражать тот факт, что не всегда драйвера есть в дитсрибутивах линукс ( в их репозиториях ? хз), и я решил что нужно научится писать самому драйвера ( а у меня случай с wifi адаптером). А т.к чтобы хорошо понимать С, я решил начать с ассамблера, как то так

даже на https://wireless.wiki.kernel.org/ ?

даже на https://wireless.wiki.kernel.org/ ?

и не говори, слишком сложный путь выбрал... Хотя интересный да

я наверно покажусь дураком, но на линуксах меня начал раздражать тот факт, что не всегда драйвера есть в дитсрибутивах линукс ( в их репозиториях ? хз), и я решил что нужно научится писать самому драйвера ( а у меня случай с wifi адаптером). А т.к чтобы хорошо понимать С, я решил начать с ассамблера, как то так

Не обязательно. Ладно, живи. Рекомендую зайти во флудочат и не забыть прочитать правила.

я так свой неработающий синкпад поднял

я так свой неработающий синкпад поднял

Руками?

Руками?

вафлю

я наверно покажусь дураком, но на линуксах меня начал раздражать тот факт, что не всегда драйвера есть в дитсрибутивах линукс ( в их репозиториях ? хз), и я решил что нужно научится писать самому драйвера ( а у меня случай с wifi адаптером). А т.к чтобы хорошо понимать С, я решил начать с ассамблера, как то так

Чтобы хорошо понимать С, надо писать на С. А вообще, что у тебя за вайфай адаптер такой, где дров нет? С алиэкспресса какой-то?

Broadcom небось

Не обязательно. Ладно, живи. Рекомендую зайти во флудочат и не забыть прочитать правила.

ок хорошо

Чтобы хорошо понимать С, надо писать на С. А вообще, что у тебя за вайфай адаптер такой, где дров нет? С алиэкспресса какой-то?

realtek

Чтобы хорошо понимать С, надо писать на С. А вообще, что у тебя за вайфай адаптер такой, где дров нет? С алиэкспресса какой-то?

они есть, но надо научится писать драйвера все таки )

на линуксы

а куда мне писать по вопросам asm сюда или в флудилку?

Туда по вопросам новичка и не совсем ассемблерные вопросы.

Туда по вопросам новичка и не совсем ассемблерные вопросы.

ок

всем привет

почему после захода в zf_1:

код заходит в zf_0

Потому что ассемблер выполняется последовательно, а в конце zf_1 ты никуда не прыгнул

то есть здесь будет точно так же

после ZF_1:

он зайдет так же в zf_0:

Кончено, точно так же. У тебя что после mov ah,1 идёт? mov ah,0 — это и исполнится, а ты чего ожидал? Где переход? Метка не обозначает начало или конец какого-то блока. Это просто обозначение места, куда должен быть прыжок или где находятся какие-то данные, не более.

А когда я вижу связки вроде вот этих jz + jmp, меня аж передёргивает. Зачем тут jmp, когда можно jz заменить на jnz?

Кончено, точно так же. У тебя что после mov ah,1 идёт? mov ah,0 — это и исполнится, а ты чего ожидал? Где переход? Метка не обозначает начало или конец какого-то блока. Это просто обозначение места, куда должен быть прыжок или где находятся какие-то данные, не более.

Никаких автоматических переходов, пропусков кода и пр. нет в ассемблере. Даже если ты вставишь процедуру посреди кода, она выполнится (через неё не будет прыжка, т.к. proc/endp — это тоже просто метки и директивы компилятора, процессору на них плевать). И даже если ты напишешь mov ah,9 mov dx,offset abc abc: db 'hello' int 21h то после mov выполнится не int, а db 'hello' (а что это — см. в дизассемблере). И т.д.

Спасибо большое

Уяснил

Парни, я пишу обёртку _start для main под Linux x86-64, чтобы избавиться от stdlib (флаг -nostdlib для gcc). То есть просто нужно передать argc, argv во внешний символ main, но чё-та с argv в main, который уже на C реализован, какие-то проблемы. argc получается такой, как ожидалось. .globl _start _start: /* clear the frame pointer */ xor %ebp, %ebp /* extract arguments and set up for main */ pop %rdi pop %rsi /* The stack pointer %rsp must be aligned to a 16-byte boundary before making a call */ and $0xfffffffffffffff0, %rsp call main /* get return value for exit call */ mov %rax, %rdi /* call exit on kernel */ mov $60, %rax syscall Что я делаю не так? Плиз хелп. Асмом под i386 только в студенческие годы занимался, с x86-64 дела не имел на таком уровне.

попробуй: pushq %rbp movq %rsp, %rbp вместо xor %ebp, %ebp

и символ main не обязателен если libc не линкуется...

main чисто для консистентности, чтобы выглядело как нормальная программа на C. Если заменяю, xor %ebp, %ebp на pushq %rbp и movq %rsp, %rbp, то уже и argc становится невалидным в main :(

может main написана под 32бита и аргументы берёт из стека а не из регистров ?

Не, как раз проверено опытным путём, что main берёт аргументы из RDI и RSI — mov'ал туда магические числа и делал return argc и return argv для exitcode

не уверен, но можно попробовать : movabsq $main, %r8 callq *%r8

main чисто для консистентности, чтобы выглядело как нормальная программа на C. Если заменяю, xor %ebp, %ebp на pushq %rbp и movq %rsp, %rbp, то уже и argc становится невалидным в main :(

Так, надо сначала pop сделать, а потом push. И аргументы там разве не подряд идут в стеке (указатели подряд)?

Но вообще, внешний rbp по логике влиять не должен никак.

не уверен, но можно попробовать : movabsq $main, %r8 callq *%r8

Не уверен, что это значит. Это аргументы должны со стека теперь считываться?

Т.е. первый pop — кол-во аргументов. Следующий pop — указатель на нулевой аргумент (имя файла). Следующий pop — указатель на первый аргумент. Следующий pop — указатель на второй аргумент. Т.е. получается так: # rbp вообще не трогаем — это забота вызываемой функции pop %rdi mov %rsp, %rsi and $-16, %rsp call main

Не уверен, что это значит. Это аргументы должны со стека теперь считываться?

это попытка вызвать main по абсолютному адресу

Т.е. первый pop — кол-во аргументов. Следующий pop — указатель на нулевой аргумент (имя файла). Следующий pop — указатель на первый аргумент. Следующий pop — указатель на второй аргумент. Т.е. получается так: # rbp вообще не трогаем — это забота вызываемой функции pop %rdi mov %rsp, %rsi and $-16, %rsp call main

А когда ты делаешь: pop %rdi pop %rsi ты подразумеваешь, что в стеке указатель на массив указателей на строки, хотя так сам массив указателей на строки и есть.

та неее, на стек аргументы кладутся только для 32бит (по крайней мере первые 6 в linux) кстати что за платформа ? линукс или виндоус ?

Т.е. первый pop — кол-во аргументов. Следующий pop — указатель на нулевой аргумент (имя файла). Следующий pop — указатель на первый аргумент. Следующий pop — указатель на второй аргумент. Т.е. получается так: # rbp вообще не трогаем — это забота вызываемой функции pop %rdi mov %rsp, %rsi and $-16, %rsp call main

Да, кажется, так работает)

та неее, на стек аргументы кладутся только для 32бит (по крайней мере первые 6 в linux) кстати что за платформа ? линукс или виндоус ?

А куда же тогда они должны класться в 64 битах?

On x86-64 UNIX systems(http://www.x86-64.org/documentation/abi-0.99.3.pdf), including Linux and default NetRun, the first six parameters go into rdi, rsi, rdx, rcx, r8, and r9.

On x86-64 UNIX systems(http://www.x86-64.org/documentation/abi-0.99.3.pdf), including Linux and default NetRun, the first six parameters go into rdi, rsi, rdx, rcx, r8, and r9.

Не открывается у меня что-то этот файл, можешь прикрепить? И там точно про параметры именно при запуске? Вообще, при syscall по ABI x64 параметры передаются немного в другом подярке: rdi, rsi, rdx, r10, r8, r9. Но там rcx заменён на r10, потому что инструкция syscall сохраняет в rcx значение rip.

https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf 27 страница

ну main то не является системным вызовом ? или я что-то упустил из виду ?

ну main то не является системным вызовом ? или я что-то упустил из виду ?

Не является, это я для примера :)

https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf 27 страница

Так, это передача параметров при вызове функций. Не при старте программы же. Можешь вот это скачать и прикрепить (у меня x86-64.org почему-то не хочет грузиться)? http://www.x86-64.org/documentation/abi.pdf

Вот тут пишут, что в стеке всё. https://stackoverflow.com/questions/3683144/linux-64-command-line-parameters-in-assembly

Most important (for more information see examples below): in x86-64 the command line arguments are passed via stack: (%rsp) -> number of arguments 8(%rsp) -> address of the name of the executable 16(%rsp) -> address of the first command line argument (if exists) ... so on ... It is different from the function parameter passing in x86-64, which uses %rdi, %rsi and so on.

#book #abi #x86_64 x86_64 abi

#book #abi #x86_64 x86_64 cheatsheet

https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf 27 страница

См. 34-ю страницу, там как раз про аргументы командной строки.

См. 34-ю страницу, там как раз про аргументы командной строки.

Danke schön

См. 34-ю страницу, там как раз про аргументы командной строки.

ОК, спс ! мой недочёт, до аргументов передаваемых в программы не добрался ещё ))

#book #manual #x86_64 #abi #win64 Соглашения о вызовах в x86_64 Windows OS: Первые четыре параметра помещаются в регистрах: rcx, rdx, r8, и r9 соответственно. Остальные параметры идут через стек, справа налево. Перед вызовом функции, стек должен быть уменьшен на 32байта + 8байт для каждого параметра которые идут через стек (+16 для long double ?). Если передавать числа с плавающей точкой, то первые четыре помещаются в регистры XMM0-XMM3. Пример: void my_func(int a, double b, int c, float d); Arguments a in RCX, b in XMM1, c in R8, and d in XMM3. PS: эту инфу прикрепил под тэгом win64

Ещё важно, что стек должен быть выровнен по границе 16 байт перед вызовом функции (т.е. перед call). Таким образом, внутри функции структура стека будет такова: адрес возврата (1 qword = 8 байт) буфер для сохранения параметров (4 qword = 32 байта) параметр 5 параметр 6 параметр 7 ... выравнивание (при необходимости 1 qword = 8 байт) Сразу после вызова функции младшая тетрада esp (esp and 0x0F) = 8.

Ещё важно, что стек должен быть выровнен по границе 16 байт перед вызовом функции (т.е. перед call). Таким образом, внутри функции структура стека будет такова: адрес возврата (1 qword = 8 байт) буфер для сохранения параметров (4 qword = 32 байта) параметр 5 параметр 6 параметр 7 ... выравнивание (при необходимости 1 qword = 8 байт) Сразу после вызова функции младшая тетрада esp (esp and 0x0F) = 8.

Да, я это делаю после пролога, у меня для этого есть макрос: .macro ALIGN_STACK .if __address_size__ == 8 andq $0xfffffffffffffff0, %rsp .elseif __address_size__ == 4 andl $0xfffffff0, %esp .else andw $0xfff0, %sp .endif .endm /*; ALIGN_STACK */ PS: наверное придётся фрейм после выравнивания корректировать тоже ...

Да, но если у тебя будет передаваться нечётное кол-во параметров >= 5, то нужно будет ещё на 8 байт скидывать.

Потому что ты сделаешь 1, 3, 5... push'ей и будет опять 8 на конце.

Да, но если у тебя будет передаваться нечётное кол-во параметров >= 5, то нужно будет ещё на 8 байт скидывать.

Точно, посмотрел только что: у меня в invoke реализован подсчёт аргументов передаваемых через стек, и на этой основе делается выравнивание ...

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

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

да, ALIGN_STACK у меня вызывется после входа в main/_start (после пролога). а в invoke что-то такое: .if __address_size__ == 8 COUNT_ARGS \s1, \s2, \s3, \s4, \s5, \s6 .if aligning != 0 .set __aligned_sp__, __count_number_args__*__address_size__ CALCULATE_ALIGNMENT __aligned_sp__, __aligning_sp__ .endif .else COUNT_ARGS \rdi, \rsi, \rdx, \rcx, \r8, \r9, \s1, \s2, \s3, \s4, \s5, \s6 .set __aligned_sp__, __count_number_args__*__address_size__ .set __index_number_args__, 0 .endif

Хотя, если сделать пролог push %rbp mov %rsp,%rbp то после and ничего не должно измениться (собственно, можно его и не делать даже).

Я не понял, мы про Винду говорим или про Линукс?

в линухе требование тоже выравнивать по границе 16байт...

Просто ты скинул сначала про винду, а последний пример — про линуск (судя по списку регистров). Кол-во параметров в регистрах разное (4 и 6).