Анон, ты можешь в fgrep и найти значение CS_BASE?
Кароч, CS_BASE это начало сегмента кода и ты можешь просто посчитать правую константу в КАЛЬКУЛЯТОРЕ (или попробовать считать относительно сегмента ".text" как это в AT&T. Вот только может случиться хуита, если там количество байт у тебя где-то поменяется. Такие дела.
Кароч, CS_BASE это начало сегмента кода и ты можешь просто посчитать правую константу в КАЛЬКУЛЯТОРЕ (или попробовать считать относительно сегмента ".text" как это в AT&T. Вот только может случиться хуита, если там количество байт у тебя где-то поменяется. Такие дела.
да с хуя ли CS_BASE это начало сегмента кода, когда он определен с помощью equ?
алсо, сегментов а-ля .text в коде вообще нет, хуй знает как так.
короче значение вычисляется как 0x1000-0x8097
и как в калькуляторе считать |? это точно оператор ИЛИ или что-то другое?
Ты саемперсон? Не важно впрочем, "|" это побитовое ИЛИ, инфа 99%
.text это метка в AT&T синтаксисе http://stackoverflow.com/questions/14544068/what-are-data-and-text-in-x86
Ты в коде значение CS_BASE искал?
да, я ж писал - вычисляется из двух других переменных, объявляемых там же. 0x1000-0x8097 в итоге.
и да, это все три поста я. за ссыль спасибо.
и да, если | - ИЛИ, как оно считается в mov? совершенно не понимаю
Антош, я посчитал, и получилась подозрительно красивая константа '0xffff'
бтв ты случаем с операционки на операционку не портируешь?
Все константы асм считает при конпеляции же!
Я тут еще посеменю, попробуй эту штуку : https://code.google.com/p/ta2as/
нет.
ну посчитал он константы, как он между ними делает ИЛИ? я чего-то не понимаю, да?...
штуку попробую, сенкс, долго искал, так и не нашел.
Смотри, берем простой код на Си :
margo@margaret tmp $ cat fail.c
int main()
{
int a = 0xde000000 + 0x00ad0000 + 0x0000beef;
return a;
}
При трансляции в асм получается такая штука :
margo@margaret tmp $ cc -S fail.c
margo@margaret tmp $ cat fail.s
.file "fail.c"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $-559038737, -4(%rbp)
movl -4(%rbp), %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Gentoo 4.8.4 p1.4, pie-0.6.1) 4.8.4"
.section .note.GNU-stack,"",@progbits
Восхитительная отрицательная константа и есть то, что получиться должно
>>> hex(0x100000000-559038737)
'0xdeadbeef'
а как это вообще с темой связано? яннп((
Принцип один и тот же, у продвинутых ассемблеров есть метки, макросы, которых в исполняемых файлах и инструкциях процессора нет, ассемблер точно так же считает все величины, которые возможно вычислить на этапе компиляции.
Скажем, если у тебя CS_BASE был бы не через equ объявлен, а был бы например адресом переменной, чье значение ты хотел бы использовать, у тебя в один мув не получилось бы ничего сделать и нужно было бы использовать инструкции И/ИЛИ/сдвига.
Понимат?
понимат. не понимат другого: у тебя в коде куча инструкций, начинающихся с точки. у меня ни одной. плохой код или что?
С точки начинаются директивы ассемблера - разделение на секции, экспортируемые символы, всякая служебная информация, типа версии системы. Насколько я помню, с точки ни одной инструкции не начинается вообще. Если писать вручную, то большую часть директив можно пропустить, кроме разделения на секции и объявления символа main
Пример вручную написанного кода :
.text
usage: .string "try to write : ./main test \n"
err_fork: .string "fork"
some_text: .string "%s qwertyuiop asdfghjkl zxcvbnm \n"
file_cat: .string "/bin/cat"
cat_arg0: .string "cat"
err_execv: .string "execv"
wait_text: .string "wait"
.globl main
.text
main:
# 0(%ebp) int ebp
# 4(%ebp) ret
# 8(%ebp) int argc
# 12(%ebp) char argv
pushl %ebp
movl %esp, %ebp
#check argc
cmp $2, 8(%ebp)
jge argc_ok
movl 12(%ebp), %ebx
pushl $usage
call printf
addl $8, %esp
#exit
jmp exit_fail
argc_ok:
#fork
call fork
testl %eax, %eax #sravnivaem eax s nulem, esli eax<0, to "-"
#esli eax = 0 to zero flag ustanovitsya
#Intel Optimization Manual
jns fork_success
#perror
pushl $err_fork
call perror #ob"yasnyet kodi oshibok
addl $4, %esp
jmp exit_fail
fork_success:
jnz parent
movl 8(%ebp), %eax
shl $4, %eax
pushl %eax
pushl 12(%ebp)
pushl %ebp
call memcpy
addl $12, %esp
#child process
#execv(file_cat, argv)
movl $cat_arg0, (%eax)
pushl %eax
pushl $file_cat
call execv #zamenyaet process programmoi iz file
#zamenyetsya cat
addl $8, %esp
#perror
pushl err_execv
call perror
addl $4, %esp
#exit
pushl $1
call exit
parent:
#parent process
pushl $0
call wait
addl $4, %esp
testl %eax, %eax
js wait_err
#roditel dolzhen vizvat printf(3) i raspechatat kakoi libo text
pushl $some_text
call printf
addl $4, %esp
#exit
pushl $0
call exit
wait_err:
pushl $wait_text
call perror
addl $4, %esp
pushl $1
call exit
exit_fail:
#exit
pushl $1
call exit
Верстка съехала, вместо \t табы должны быть
ну тогда вообще хреново, ибо я совсем хз как там чего объявлять, а никаких .main в коде нет.
Посмотри этот пост:
.globl main # Экспорт метки
.text
main: # Есть тонкость, если метка main:, то компилировать надо с gcc, если _main: то as/gas. Но инфа 60%, за лет 5 на асме ни строчки не было написано :3 Ах и да, прыщи, под виндой все немного по-другому.
т.е. просто добавить .globl _main и .text в начало кода?
но почему as пытался без всего этого компилить и не ругался на это?
Тут мой ответ, в нем слово из спам-листа, но я не знаю какое. Файл. http://pastebin.com/zrNBQCr7
аа, то есть оно само добавится в файл файл.о после ассемблирования командой as? ну збс.
нет же, после ассемблирования у тебя объектный файл, его надо слинковать, а линковщик (ld) требует чтобы был объявлен символ main
да и кстати ты можешь КУЧУ объектных файлов слинковать в один исполняемый
>>52942
аа, окей, значит, все же прописать в код в самом начале .globl _main .text?
аа, окей, значит, все же прописать в код в самом начале .globl _main .text?
если фаел один - то да, если нет, то зависит от ситуации.
Ну и переменные не объявляй в .text ;)
а в чем?
в .data же
И все-таки рекомендую книгу посмотреть, она относительно короткая, хоть и на мунспике, но оче годная
На стеке еще можно их объявлять (относительно ebp или esp)
так, понял, сенкс
но все же, пока я не могу запустить ta2as, что не так с mov'ом?
например, насколько я понял из статей и примеров кода, в АТТ здесь
> [dword GDT_ADDRESS+DESCRIPTOR_ADDRESS+4]
+4 выносится за скобку, так?
> [dword GDT_ADDRESS+DESCRIPTOR_ADDRESS+4]
+4 выносится за скобку, так?
Что, оп, хакирствуешь старые х86? Там же чуть ниже в презентации написан код в 8 строк (после препроцессора) который гораздо проще перепистать. Хотя я хз как ты с таким знанием асма собрался для своего руткита payload делать.
как-как...плакать и делать...
Ладно, это не самая сложная часть. Самая сложная - в нулевое кольцо сначала попасть. Никто не будет твои еба-модули ядра себе устанавливать.
> нулевое кольцо
Господи, посмотрите на живого ньюфага! Не знает про технологию зацикленного нуля!
>зацикленного нуля
Реквестирую соус!
АНОНЫ, ОЧЕНЬ СРОЧНО НУЖНО ПОНЯТЬ АССЕМБЛЕР С АЗОВ. ИНТЕРЕСНО НЕ ТОЛЬКО САМО ПРОГРАММИРОВАНИЕ, НО И УСТРОЙСТВО КОМПЬЮТЕРА. (НА ПАРАХ ПОСТОЯННО ГОВОРЯТ ПРО КАКИЕ ТО РЕГИСТРЫ, АККУМУЛЯТОРЫ, ПРОЧУЮ ХУЙНЮ, Я НИЧЕГО НЕ ПОНИМАЮ - ПАРЫ ПРОЕБАЛ) РЕКВЕСТИРУЮ УЧЕБНИКИ, ВИДЕО КУРСЫ, ВСЮ ПОЛЕЗНУЮ ИНФОРМАЦИЮ. ОЧЕНЬ НУЖНА ВАША ПОМОЩЬ!
Начни с Таненбаума "архитектура компьютера", про Ассемблер в принципе куча книг тут например: http://habrahabr.ru/post/131971/ , сам сейчас читаю Ревича "Практическое программирование микроконтроллеров Atmel AVR на языке ассемблера", написано довольно живо и просто.
Я не советую вам в это углубляться, парни, я писал простенькие программы под AVR в эмуляторе, в тырпрайзе и web'е это вам не поможет, разве что выпендриться перед коллегами, для серьезного embedded это тоже днище. Танненбаума следует навернуть, да. Хорошая книга.
советую автора Магда - у него несколько книг. Из плюсов - то, что написано под винду. Из минусов - большие листинги и слабое использование макросов. Для начала, имхо, пойдет.
Я тоже вижу подобную хуиту в первый раз и если я не ошибаюсь, это диррективы предпроцессора компилятора в сишном стиле, на что указывают логические операторы, в таком случае, всё что в круглых скобках становится лишним, и может быть вычислено во время компиляции в виде некоторого константного значения, не обязательно во всех случаях одинакового, которое уже используется непосредственно в программе.
Если не читать литературу по си я полагаю, ты не сможешь узнать значение | & >>
Открыл Магда, прочёл "Для того чтобы из объектного файла создать исполняемый файл, работающийв MS-DOS, следует выполнить командную строку link /со имя_файла.obj", удалил.
Ты не поверишь, но чтобы сделать исполняемый файл MS Windows, нужно сделать то же самое.
Пофиг, этот Магда уже зашкварился.
Он может быть на следующей странице ещё скажет вставить дискету с MASM, кто его знает.
Помогите. Не могу разобраться с делением в FASM.
Вроде всё понятно - если делим eax на к примеру bl, то результат будет в ah и al, где остаток а где частное похуй, ща не об этом, почему
mov eax,[bid]
mov bx,260
div bx
или
mov eax,[bid]
mov bl,8
div bl
или даже
mov ax,word[bid]
mov bl,8
div bl
не выдают ошибку при компиляции, зато вешают моё недоприложение ошибкой выполнения?
В общем расскажите по жёсткому, как делить числа?
И ещё, что за хрень такая, что если значение помещается в слово, 258 например в регистр bx, мне нужно аккумулятор делить на регистр в двойное слово размером(ebx)?
Фасм тут не при чём. За ошибками компиляции тебе в хаскиль. Дели как написано в мануле и не выёбывайся.
Попизди мне тут про ошибки компиляции, очевидно же, что есть какое то неочевидное расхождение реальности с мануалом.
Анон выручай есть пара вопросов не могу найти ответ
49. Как будет выглядеть машинный код, если в загрузочном коде биты настройки равны 010, двоичный код имеет вид 15 13 17, а начальный адрес равен 50? _______
50. Если машинный код равен 13 78 67, начальный адрес - 50, а двоичный код - 13 28 17, то как будут записаны биты настройки? ___________
Анон выручай есть пара вопросов не могу найти ответ
49. Как будет выглядеть машинный код, если в загрузочном коде биты настройки равны 010, двоичный код имеет вид 15 13 17, а начальный адрес равен 50? _______
50. Если машинный код равен 13 78 67, начальный адрес - 50, а двоичный код - 13 28 17, то как будут записаны биты настройки? ___________
Ты поехавший. Какие биты? Какая платформа? Какой ассемблер? Почему числа не в hex? Почему ты считаешь, что мы должны делать за тебя твою домашку?
>Почему ты считаешь, что мы должны делать за тебя твою домашку?
1. Ты программистишка
2. Ты всё равно сидишь за компом и ничего не делаешь
3. Вместо того, чтобы тратить время на бессмысленные выебоны, ты мог бы уже давно решить мою домашку.
Есть OllyDbg и есть переменная в 4 байта в памяти. К этой переменной обращаются из нескольких мест, но Breakpoint on Memory Access останавливает ход на одной и той же инструкции или это какая-то процедура, что ее несколько раз вызывают. Можно как-то вывести список адресов и инструкций, что обращаются к этому куску памяти? Ну или хотя бы сделать так, чтоб отладчик не останавливал ход на помеченной инструкции, даже если она обращается к памяти?
В двоечке есть Breakpoint->Memory log. В единичке, насколько я знаю, без плагинов не извернуться. Можешь ODBGScript взять, например. Или написать плагин сам.
Спасибо.
Странно. Почему у меня Олли 1 и качая, я думал, что это последняя версия?
Потому что OllyDbg 2 - то еще говно.
x64dbg попробуй еще не обращай внимание на название, он может и в 32-битный код. Стильно, модно, молодежно, скриптуется на питоне, но условных брейкпоинтов из коробки нет, лол.
Так я и не понял, как memory log пользоваться. x64dbg тоже, похоже, не может выводить адреса инструкций списком. Немного объясню свою проблему, может кто сталкивался:
Есть переменная и есть бесконечный цикл в программе. Несколько раз в этом цикле переменную читают для отрисовки и еще каких-то дел, несколько раз ее читают, чтобы изменить (не обязательно инкремент бай 1 - была 4, стала 0, например) при определенных условиях (ПКМ) и один раз читают, чтобы определить дальнейшие действия при других определенных условиях (ЛКМ).
Мне нужно найти вот это последнее последнее место, то есть как-то заставить отладчик не останавливаться на других инструкциях. inb4 замени все нопами
Может попробовать как-то поставить условие, типа если EIP == адресу инструкции, которую нужно пропустить, то не останавливаться? Но это все равно стремно, потому что нужно будет руками находить все такие места и прописывать условие
Кажется разобрался с memory log. Если использовать условия, то программа тормозит и как-будто не отвечает, а мне нужно, чтоб она плавненько шла, будто бы и отладчик не прицеплен.
> программа тормозит и как-будто не отвечает
Для Memory breakpoints отладчик убирает доступ со страницы памяти, содержащей нужный тебе адрес, ждет access violation, возвращает доступ, выполняет инструкцию, убирает доступ... это все тормозит, иначе никак.
Попробуй Breakpoint->Hardware log, хардварные точки останова гораздо быстрее. Настраиваешь как на пике (expression можно нормальный написать, с дополнительной инфой), потом в логе (Alt+L) видишь, кто обращался. Копируешь в текстовый редактор, удаляешь дублирующиеся строки, профит.
Во, теперь не тормозит, спасибо. Только почему-то программа останавливается, если открыто окно HWB (даже если брейкпойнт отключен).
Не пойму, чо тебе мешает пошагово двигаться по коду и увидеть инструкцию с адресом слева от неё, перед ошибкой? Ты же как то нашёл, что именно попытка доступа к переменной тебе ошибку выдаёт.
Насколько я понял, он пытается хакнуть клиент какой-то игры.
Ананасы, подскажите годный учебник по ASM x86.
Да уже все. Если бы пошагово двигался, то не смог бы сделать так, чтобы необходимые условия выполнились ПКМ и нужная мне инструкция обратилась к памяти. Да там и кода столько, что я бы просто не смог вот таким путем.
у фасма в папочке годный мануал по х86.
У меня ахуительные вопросы.
Что такое строковые операции в FASM, что за приколы с 'DS:ES'?
Как юзать FFPU?
Мануал читал, нихуя не понятно, точнее, как оказалось гуглопереводчик переводит не лучше меня.
Что такое строковые операции в FASM, что за приколы с 'DS:ES'?
Как юзать FFPU?
Мануал читал, нихуя не понятно, точнее, как оказалось гуглопереводчик переводит не лучше меня.
Перефразируй свои охуительные вопросы. Я не понял ни одного.
> строковые операции
lods movs stos - ты про эти? Что с ними не так?
lodsb = lods byte[ds:esi]
stosb = stos byte[es:edi]
movsb = movs byte[es:edi],byte[ds:esi]
> Как юзать FFPU?
FPU? Просто пиши инструкции.
> ты про эти? Что с ними не так?
Эти, с ними всё хорошо, но я не пойму ни как что такое ds:esi, что значит это двоеточие и что строковые операции делают с ними.
В мануале пишется, что после строковой операции в зависимости от флага позиция инкрементируется или декрементируется - какая позиция? где? что перемещает movs?
>FPU? Просто пиши инструкции.
Тут тоже есть немножко проблема с пониманием, поскольку в мануале то десятичные инструкции то FPUшные перемежаются.
> какая позиция? где? что перемещает movs
> The string operations operate on one element of a string. A string element may be a
> byte, a word, or a double word. The string elements are addressed by si and di (or esi
> and edi) registers.
> (мануал, который ты читаешь)
Все эти инструкции работают с 8/16/32-битными значениями (можно писать краткую форму с суффиксом b/w/d: lodsb/lodsw/lodsd или полную форму lods byte[ds:esi]) и неявно используют регистры ESI, EDI или оба. В ESI/EDI лежат, соответственно, исходный адрес и адрес назначения (eSi: S = source, eDi: D = destination). Все эти инструкции читают/пишут что-то по адресам из ESI или EDI (в зависимости от инструкции). Все они затем прибавляют или вычитают (в зависимости от DF) к используемому регистру (ESI, EDI или к обоим, если используются оба) 1, 2 или 4 байта (в зависимости от размера значения). Т.е., делают что-то по адресу, содержащемуся в регистре, а после выполнения инструкции готовы повторить то же самое для следующего элемента. Это удобно использовать для работы со строками посимвольно, поэтому инструкции называются строковыми (но никто тебе не запрещает считать сумму элементов массива с помощью той же lodsd, например).
lods читает в AL/AX/EAX значение по адресу, хранящемуся в ESI. stos записывает AL/AX/EAX по адресу из EDI, а MOVS объединяет обе инструкции: не затрагивая EAX, берёт по адресу из ESI, кладёт по адресу из EDI, ну и тоже изменяет ESI/EDI, конечно. scas берет значение по адресу EDI (!!!), сравнивает (по сути cmp) с AL/AX/EAX, ставит флаги соответственно. cmps делает практически то же, но сравнивает значение по адресу из ESI со значением по адресу из EDI, ставит флаги (и опять же модифицирует ESI и EDI после).
Сами по себе эти инструкции менее полезны, чаще используются в каком-нибудь цикле для операций со строками:
mov ecx,string_size
mov esi,string1
mov edi,string2
rep movsb ; Копируем из string1 в string2 string_size байтов.
Ну и насчет DS/ES (есть еще CS/SS/FS/GS): это сегментные регистры. Используются процессором для вычисления и проверки линейного адреса. Явно или неявно используются каждый раз, когда инструкция обращается к памяти. Какой конкретно сегментный регистр будет использоваться, определяется самой инструкцией и/или (для register indirect access) регистром, через который происходит обращение (для [esi] по умолчанию используется DS, для [edi] - ES, поэтому lods word[ds:esi] то же самое, то lods word[esi]). В современных ОС, работающих в защищенном режиме чаще всего DS = ES = SS (могут быть не равны, но, скажем так, эквивалентны), что позволяет тебе забыть о том, где какой сегментный регистр используется, и даже о том, что они вообще существуют, а беспокоиться только о виртуальном адресе (т.е., о том, что чаще всего просто адресом называют). Если же ты собираешься писать под какой-нибудь DOS, то с сегментацией придётся разобраться.
Про FPU читай что-нибудь типа http://www.website.masmforum.com/tutorials/fptute/ только не забывай, что в фасме st(0) пишется как st0, ну и просто в мануал поглядывай параллельно.
Ага, пасиба, теперь понятнее.
Значит
[code]
proc memcpy uses eax esi edi,srcp,dstp,size
mov ecx,0
mov esi,[srcp]
mov edi,[dstp]
@@:
mov al,byte[esi + ecx]
mov byte[edi + ecx], al
inc ecx
cmp ecx,[size]
jne @b
ret
endp
[/code]
эквивалентно по сути
[code]
proc memcpy uses eax esi edi,srcp,dstp,size
mov ecx,[size]
mov esi,[srcp]
mov edi,[dstp]
repnz movs [si],[di]
ret
endp
[/code]
так?
> repnz movs [si],[di]
Во-первых, раз movsb никак не модифицирует флаги, да и не нужно тебе это, то ты должен сказать rep, а не repnz. Оно работает и так точнее не работает - не проверяет флаги из-за магии набора инструкций, но лучше так не делать.
Во-вторых, это не скомпилируется. si и di - это 16-битные регистры (младшие 16 бит esi и edi). То есть адресовать ты ими можешь только первые 64к памяти. В 32-битной системе movs будет использовать esi и edi. Еще ты перепутал порядок. У нас в Intel инструкции делают op dest, src (в данном случае movs [edi],[esi]). А еще ты не указал размер. Пиши либо movsb, либо movs byte[edi],[esi].
И заодно, uses eax ты можешь не писать. По конвенциям stdcall/cdecl 32-битные функции обязаны сохранять только ebx/esi/edi/ebp и df, а eax/ecx/edx можно портить, никто не обидится. Ты можешь городить свои конвенции вызовов, в том числе решить, что eax тоже стоит сохранять, но это повлияет и на скорость, и на размер кода.
Ну я понял, ошибки учёл.
Значит:
proc memcpy uses esi edi,srcp,dstp,size
mov ecx,[size]
mov esi,[srcp]
mov edi,[dstp]
rep movsb
ret
endp
И дело в шляпе?
А если жахнуть:
proc memcpy uses esi edi,srcp,dstp,size
mov ecx,[size]
mov esi,[srcp]
mov edi,[dstp]
rep movsd
ret
endp
Оно будет по 4 байта копировать, ошибок аля выход за пределы массива не будет и операндов не потребует?
> А если жахнуть
То тебе придется разделить size на 4 (иначе ты скопируешь size * 4 байтов со всеми вытекающими последствиями), а также случаи, когда size на 4 нихуя не делится (т.е., остаются байты, которых мало на dword, но копировать их все равно нужно).
[code]
...
mov ecx,[size]
and ecx,3
...
rep movsb
mov ecx,[size]
shr ecx,2
...
rep movsd
[/code]
>То тебе придется разделить size на 4
Я так и знал.
Пофиксил тебя, не благодари.
ПХПшник?
Почему вдруг?
У тебя порядок неправильный. Если есть лишние байты, то первым циклом ты выйдешь на середину слова, и второй будет копировать половину байтов из первого, а половину из второго. Тормоза, гроб, смерть.
По тому что из твоей жопы хвост торчит двухметровый, обезьяна.
Там по-хорошему должны быть с двух сторон movsb (сначала копируем до границы адреса, выровненного на дворд, потом копируем двордами, потом копируем остатки), но анон только узнал про эти movsb, зачем усложнять-то?
Жаль что утонул, щас подниму. Асемблер кун помоги в универе дали вот это http://rghost.ru/8gZcTfm88 сказали там есть пример запустишь посмотришь. Так вот это говно под 8 не завелось скачал хр на виртуалку, exe запустилось че делать не понимаю, фаилы asm не поддаются запуску. Помогай АНОН
Батник запускай. И посмотри, что в нем: там сначала компилируется программа, потом линкуется, потом запускается под отладчиком. Алсо, DOSBox, и не нужна XP.
Интересно чому компилятор просто не засунул константу сразу в eax? Или это без оптимизаций?
Это без оптимизаций, для упрощения отладки, и это гцц.
проиграл
антоха, такая тема, вынужден по определенным обстоятельствам не зная ассемблера переводить прогу на нем с синтаксиса Intel на AT&T (лучше даже не спрашивай, как я до такого докатился). в общем-то со всем разобрался, кроме пары строк.
mov dword [dword GDT_ADDRESS+DESCRIPTOR_ADDRESS+4],
(CS_BASE&0xff000000) | (0x00cf9a00) |
(CS_BASE&0x00ff0000)>>16
во-первых, хуй знает, почему в исходнике это на трех строках. я вообще не слышал о многострочном mov. ладно, черт с ним, переводами строки и табуляцией пренебрежем - получается вроде бы обычный мов, только с одним но.
если просто поменять операнды местами и заменить квадратные скобки на круглые (а именно так нужно поступать с скобками при переводе, разве нет?), получаем too many memory references for 'mov', что вполне оправданно - из памяти в память низя. значит, что-то из операндов - константа.
константы в чертовом AT&T отличаются знаком $ перед числом. я пробовал пихать его везде, где только мог - ошибка не исчезает. ананасы, бля буду, я перешерстил весь гугл, но так и не нашел вообще никакой инфы по mov с использованием логических операторов | и &. еще и >> какой-то, вообще охуеть, по нему вообще ничего (ну не может гугл в поиск символов, увы). поясните за эту хуйню, если сами знаете, ну или ссылку, хотя б на буржуйском. с меня как обычно.