Защита секция кода во FLASH в ATmega, Как защититься от несанкционированного выполнения кода Опции

[Дон Амброзио]

А кто как защищает код в MCU от несанкционированного выполнения в результате случайного перехода из одной точки программы в другую от воздействия помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения). А?

Приведу пример
--------------------
lab_1_input: ldi R16 , $00
mov R16 , $98
...
lab_1_output: mov R17 , R5
-----------------------
lab_2_1_input: mov R18, R17


Т.е. допустим программа предусматривает переход к выполнению кодового фрагмента, начинающегося с метки lab_2_1_input только после отработки до конца фрагмента [lab_1_input;lab_1_output]

А представим , что от помехи произошёл случайный переход из произвольной точки 1-го фрагмента кода в произвольную точку 2-го фрагмента кода....

Как вы ПРОГРАММНО отлавливаете такие ситуации?

Т.е. как Вы реализовываете в своих программах для микроконтроллеров ATmega механизм защиты FLASH-памяти от несанкционированного выполнения кода. Ну т.е. как контролировать, что в данный фрагмент кода вошли не где попало, а через строго определённые на этапе проектирования программы, точки

А кто как защищает код в MCU от несанкционированного выполнения в результате случайного перехода из одной точки программы в другую от воздействия помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения).

Кстати, причины такого случайного джампа могут быть не только в разрушении PC.
Может также случайным образом измениться содержимое ячейки FLASH или содержимое хранимой в ОЗУ таблицы переходов... В любом случае МОЖЕТ произойти переход в точку некоторого логического сегмента кода, которая не предусмотрена данным логическим сегментом FLASH

[Liseev]

А как вы будете защищать "механизм защиты от несанкционированного выполнения"?
А механизм защиты механизма защиты?
А от прямого попадания молнии?

Используйте WDT от "случайных" зависаний ну и, пожалуй, проверяйте CRC программного кода.
Здесь эта тема броде бы обсуждалась

[Дон Амброзио]

Используйте WDT от "случайных" зависаний

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

проверяйте CRC программного кода

Проверяю

Здесь эта тема броде бы обсуждалась

Обсуждалась...А отслеживаю темы подобной тематики

[SasaVitebsk]

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

Liseev писал вам правильно, а вы наводите тень на плетень. Естественно, ни о каких программных зависаниях речь не может идти. Но "зависание", как таковое, это не бездействие процессора. Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный", только в "неправильное" время. Из этого состояния его и вытягивает WDT.

Предложу вам свой метод вставки WDT.

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

Тестируется.

[Дон Амброзио]

Liseev писал вам правильно, а вы наводите тень на плетень.

Странный у вас метод ведения дисскусии

Но "зависание", как таковое, это не бездействие процессора.

Да что Вы говорите...Прям открытие для меня сделали..А я прям не знал

Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный"

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

Предложу вам свой метод вставки WDT.

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

И как всё это можно применить в многозадачной среде RTOS?
http://electronix.ru/forum/index.php?showtopic=43223

[SasaVitebsk]

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

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

Ладно попытаюсь вам объяснить.

Представьте себе правильно написанную программу, которая отработана и не содержит не единой ошибки. В ней находится следующий текст например:

Код

...
ReadLptEPP:
    sbic    pinc,LptSTB    ; Строб пришёл?
    rjmp    ReadLptEPP    ; иначе повторить
    sbic    pine,WRITE    ; Если запись HOST, то продолжить
    rjmp    errLptEPP    ; иначе ошибка
    in        wl,ILPT        ; ввод данных в wl
    sbi        portc,WAIT    ; подтвердить
rwaitNoLptSTB:
    sbis    pinc,LptSTB    ; Строб сняли?
    rjmp    rwaitNoLptSTB; иначе повторить
    cbi        portc,WAIT    ; подтвердить
    ret
...

Теперь представьте себе что произошёл сбой в работе процессора и программа попала в ReadLptEPP либо rwaitNoLptSTB. Не по логике работы программы, а по сбою. Если для вас это непонятно, то представьте, что произошла ошибка во время перехода процессора, либо во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда. Ну что доступно объясняю? Более того чтобы не исказилось и кудабы проц не пошёл, то он заткнётся в каком-нибудь цикле!!!! Это то понятно? В любой программе правильно написаной десятки либо тысячи циклов. Что тут непонятно? Но если ваша программа, например, сидит в цикле ожидания символа из UARTа, а он туда не должен придти, по той банальной причине, что вы не делали запроса и не потому что программа неправильно написана, а потому, что произошёл сбой и программа попала туда, куда не должна была попасть.

Что тут не ясно?

[Дон Амброзио]

Что тут не ясно?

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы..Я Вам еще раз повторяю: в граммотно спроектированной программе вечных циклов быть не должно не при каких искажениях данных и регистров!!!!

во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда

Вот в этом, собственно, и вопрос темы. Как спроектировать программу, чтобы она детектировала приведённые Вами явления. Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны


Хочу заметить, Господа что я прекрасно себе представляю, что [u]абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно[/u] (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

Такой команды у AVR нет.

Согласен.. описАлся

Если это в основном цикле

Какой ещё основной цикл в многозадачной многопоточной среде RTOS? И там стеков не один, а несколько...Причём как стеки PC, так и стеки данных

[SasaVitebsk]

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы....

Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны
Хочу заметить, Господа что я прекрасно себе представляю, что [u]абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно[/u] (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

Простите пожалуйста О ВЕЛИКИЙ.
Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.
Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

С уважением,
ваш почитатель.

[Дон Амброзио]

Простите пожалуйста О ВЕЛИКИЙ.
Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.
Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

С уважением,
ваш почитатель.

А Вы ещё ИАРу напишите, что у них неправильный ИАР...

А вообще "нЕчего на зеркало пенять коли рожа кривая"(с) Если Вы не хотите чуть-чуть больше подумать на стадии проектирования программы, то тут уже Вам не ИАР, не Atmel ни кто-либо ещё уже не поможет

Кстати, Господа!! Хочу заметить вот что:

1) Вы мне хорошо расписали необходимость применения WDT в простейшей программе типа СуперЛуп и даже объяснили, где лучше вставлять команду сброса WDT для этого случая... Но при этом ничего не сказали о специфике применения WDT для случая многопоточных приложений в вытесняющей RTOS
2) Что можно применить кроме WDT высказлся только Непомнящий Евгений, а что же остальные?

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

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

[defunct]

2) Что можно применить кроме WDT высказлся только Непомнящий Евгений, а что же остальные?

Вы же и так все знаете, зачем Вам еще что-то советовать?!

Но это я конечно погорячился, но если встанет такая дилема - я пойду на это

Горячий испанский парень.

Вот Вам ответ.. От себя лишь добавллю термин "счётчик-ограничитель количества итераций цикла" Вам о чём-нибудь говорит?

это еще что за зверь такой "счетчик ограничитель". В RTOS каждая задача - это бесконечный цикл.

Мне это хорошо известно.. Но я с такими пока не работал...

Слова дойстойные анекдота.

Тема то у нас гораздо шире.. Или просто никто больше не знает других методов "борьбы" с явлением, указанном в названии темы?

тема ваша тупая на самом деле, и в том виде в каком задача поставлена в первом посте - не имеет решения вообще.

Не звизди..

Куда смотрят модераторы?! Пора бы немного остудить гарячего парня.

( я последнее время больше программером работаю, хотя я могу и платы разводить, и схемы проектировать).

50% боксер / 50% сторожевая собака © какой-то мультик

Чуть-чуть пошевелить мозгами для Вас мучение?

опять хамство.

У меня наприммер в моих программах работающих в среде моей же RTOS

Спасибо Вам большое...Я давно уже хотел Вам это предложить... Да стеснялся.. Боялся Вас обидеть...

полное хамство.

А кто хамил? И где? И почему бы Вам свои благодарности было не написать в привате? Зачем тему-то замусоривать?

Вы. В каждом посте. Потому что меня Ваша манера ведения дискуссии просто бесит. Пришел всезнающий барин, и давай всем объяснять какаие они л...и., какой уж тут приват.
Тему эту уже не замусоришь, она и так замусорена вашими постами "от и до".

[Дон Амброзио]

это еще что за зверь такой "счетчик ограничитель".

"На свете есть много такого, мой друг, Горацио, что и не снилось нашим мудрецам"(С)

Я собсно хочу отметить, что задача автора ветки - нерешаемая. Ее можно только обойти, но не решить.

Принимается

Я немного неправильно сформулировал задачу.

Я написал в исходном сообщении: А кто как защищает код в MCU от несанкционированного выполнения в результате случайного перехода из одной точки программы в другую от воздействия помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения). А?


А правильно бы надо было так (ведь именно это меня и интересует):

А кто как организует код программы, чтобы программа детектировала (обнаруживала) случайные переходы из одной точки программы в другую, вызванные воздействием помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения) т.е. переходы, не предусмотренные на этапе проектирования программы

Согласен, что защита не 100%.

Вот я и говорю, что не 100% но всё же эффект ведь налицо от применения "программных методов"
Что эти Господа так упираются против использования программных методов обнаружения сбоев? Не понимаю

А что касается несанкционированных помех и т.д., то эти вопросы лучше решать другими способами (экранами, фильтрами, убрать подальше от источника помех.....).

Конечно лучше... И плюс для подстраховки рассыпать в проге код обнаружения случайных джампов...Так...На всякий пожарный

[defunct]

А кто как организует код программы, чтобы программа детектировала (обнаруживала) случайные переходы из одной точки программы в другую, вызванные воздействием помехонесущего электромагнитного поля

Детектировать случайный переход из одной точки программы в другую своевременно и безболезненно для текущей выполняющейся программы невозможно. Стало быть вопрос лишь в масштабах последствий такого сбоя (по убыванию):
1. Нарушение памяти программ.
2. Нарушение содержимого регистров / памяти данных - в последствии к "подвисанию" неверной работе части программы.
3. Порча незначительных данных например пакета защищенного кодом защиты. (плохо конечно, но с этим можно смириться).
4. Чисто везение, прыжек в участок кода - который ничего не испортил (например из финализации одной функции в финализацию другой с подобными параметрами). Везение рассматривать не будем.

Итого лечить надо только 1 и 2.

Первое лечится с помощью дублирования кода программы. Определяется и устраняется эта ошибка при очередной перезагрузке устройства. Как правило после такого сбоя устройство перезагружается по WDT.

Второе - система продолжает работать но часть функций отказала. Лечится перезагрузкой, перезагрузка делается опять с помощью WDT.

Вопрос в том где и как сбрасывать WDT чтобы последствия сбоя были 100% устранены. Решить этот вопрос можно например введя мониторинг статуса каждой задачи. Если используется RTOS, то сделать это достаточно просто - idle task (задача с самым низким приоритетом) периодически оцнивает состояние каждой задачи, если все задачи в порядке - WDT сбрасывается. Состояние же каждой задачи должно определяться индивидуально, для каждой задачи свой отдельный таймаут.

Пусть имеется некое устройство, которое занимается опросом некоторых датчиков по одному интерфейсу, и отправляет результаты - по другому. Тогда работу этого устройства можно разбить на 5 задач:
1. idle (занимается контролем WDT)
2. обслуживание передачи по интерфейсу датчиков.
3. обслуживание приема по интерфейсу датчиков.
4. обслуживание передачи по интерфейсу хоста.
5. обслуживание приема по интерфейсу хоста.

Статус первой задачи всегда Ок (коль уж в нее попали, то стало быть она работает).
Статус 2-й задачи переходит в состояние Alert если счетчик отправленных пакетов не изменяется в течение заданного таймаута.
Статус 3-й задачи определяется таймаутом "за n секунд не принято ни одного байта"
Статус 4-й задачи определяется аналогично 2-й
и наконец статус 5-й - аналогично 3-й.

Если хотя бы одна задача не в порядке, то в задаче 1 запрещаем прерывания и подвешиваем систему циклом
while( K * WDT_CYCLE)
__no_operation();

где
WDT_CYCLE - константа, соответвующая количеству циклов эквивалентное интервалу WDT.
K - коэффициен >1, для гарантии сброса МК.

Если вдруг получается так, что мы выходим из этого цикла. Тогда WDT вероятно тоже сбойнул - пытаемся:
1. Выполнить аппаратный сброс (если заранее предусмотрели управление внешней схемой сброса).
2. Выполнить прыжек по RESET вектору (т.к. хуже уже все равно не будет).


PS: До сих пор, против "случайных прыжков" этих программных мер мне хватало с головой.

[Дон Амброзио]

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

В корне не согласен с этой аксиомой(откуда Вы это взяли). 100% случайных джампов конечно никогда не отловить. А вот если предположить что джампы на любую величину смещения относительно заданной точки равновероятны, то можно отловить большинство случайных джампов.. Отловить в смысле обнаружить в программе, что случайный джамп имел место. Выше уже приводилось по крайней мере 2 метода как это сделать

Как правило после такого сбоя устройство перезагружается по WDT.

С чего Вы это взяли? Допустим во FLASH некоторый код изменился так, что вместо команды установки флага "Пришёл пакет извещения о пожаре" будет команды сброса этого флага. И девайс будет работать нормально просто в любом случае будет считать, что у него всё ОК и никакого пожара нет. И соответственно никакого зацикливания/зависания не произойдёт, а девайс при этом будет находиться в неисправном состоянии

Второе - система продолжает работать но часть функций отказала. Лечится перезагрузкой

Сама по себе перезагрузка, как таковая, ничего не лечит. Она просто сбрасывает MCU периферию в исходное состояние. Более того, она не позволит установить причину перезагрузки. Например если зацикливание было вызвано самопроизвольным изменением регистра UBRR из-за чего UART перестал принимать пакеты извне или случайым сбросом флага разрешения прерываний от UART, то после перезагрузки вся периферия сброситься в исходное состояние и мы не узнаем "а чё это было-то?"

если все задачи в порядке - WDT сбрасывается. Состояние же каждой задачи должно определяться индивидуально, для каждой задачи свой отдельный таймаут.

А кто будет считать этот тайм-аут?

[defunct]

В корне не согласен с этой аксиомой(откуда Вы это взяли). 100% случайных джампов конечно никогда не отловить.

Потому что:
1. Они случайны, а это значит что можно прыгнуть из "RET" одной функции на "RET" другой.
2. Есть вероятность сбоя детектора, поясню - достаточно мощная EM помеха, способная привести к прыжку бог знает куда, также легко может нарушить содержимое памяти.

Ну и Вы сами говорите что 100% нельзя отловить, а раз 100% нельзя отловить то зачем их ловить?!

Чаще выгоднее мониторить конкретные узлы МК. И делать recovery там где это возможно, но не всегда это возможно вообще...

А вообще, советую поработать с ARM, прыжки случайные там отлавливаются самим процессором на раз аппаратурой процессора. Сильная EM помеха приводящая к случаному прыжку и Вы раньше или позже, но 100% попадете в один из трех Exception'ов DABT/PABT/UNDEFABT.

[galjoen]

Ну и Вы сами говорите что 100% нельзя отловить, а раз 100% нельзя отловить то зачем их ловить?!

CRC тоже 100% защиты не даёт. CRC16 не более чем в 65536 раз защищённость повышает, а CRC32 не более чем в 0x100000000 раз. Что тогда и CRC не пользоваться? Это-же не 100%!

Конечно сбой надо продетектить,

+1

Речь о том, что до сброса мы не сможем отдетектить нарушение FLASH. Ну это просто очень накладно пересчитывать CRC флеша постоянно в процессе работы.

Совершенно не накладно. В задаче с наименьшим приоритетом по 1-му слову за раз. У меня это основной цикл. У вас это idle таск. Только срабатывать это должно не сразу. А например, когда 2 раза подряд CRC не совпало.

Так в чем вопрос - переходите на ARM с MMU. В старших моделях (920T и выше) мало того, что каждому килобайту памяти можно настроить параметры доступа, так еще определяется и "выровнянность" кода. А если прыгнули внутри одного блока - то DATA_ABORT обеспечен, т.к. сбой произойдет из-за искаженных данных. Но и в младших моделях некоторые прелести MMU есть, а цена такая же как и на меги.

У ARM код из ОЗУ берётся. А в ОЗУ код гораздо больше изменениям от помехи подвержен, чем во FLASH. Хотя-бы при переписывании его туда.

[Дон Амброзио]

У ARM код из ОЗУ берётся.

Ээээ...Тогда они однозначно менее надёжны, поскольку ОЗУ попортить помехе гораздо легче чем ПЗУ

И прыгают они у Вас исключительно на код, а на данные размещенные во флеш
видимо никогда не прыгают

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

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

+

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

Странно.. Я читал совершенно другие "методики правильного проектирования". Что наооборот землю надо пускать кольцом по краю платы

[singlskv]

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

Ой..., а Вы не просветите нас про Ваш дезактивированный формат ? или еще
не придумали как это должно выглядеть...
Ну и как-то вопрос про 32бит команды был обойден, не нравятся неудобные вопросы ?

[Дон Амброзио]

Ой...

Да ничо, ничо

а Вы не просветите нас про Ваш дезактивированный формат ? или еще
не придумали как это должно выглядеть...

Почему же...Придумал.. И давно уже юзаю...У меня данные храняться в команде CPI Rd , K.
Как Вы, конечно же знаете, код этой команды 0011KKKK ddddKKKK. Отсюда 12 из 16 бит ячейки флэшь можно заюзать под данные. Т.е. 25% объёма флешь мы теряем в случае такого способа хранения данных.. Но зато !!!! Если в результате случайного джампа проц попадёт на область данных, то он просто выполнить цепочку команд CPI Rd , K а в конце области данных у меня стоит джамп JMP CRASH

Сообщение отредактировал Дон Амброзио - Feb 14 2008, 18:56

[singlskv]

Почему же...Придумал.. И давно уже юзаю...У меня данные храняться в команде CPI Rd , K.
Как Вы, конечно же знаете, код этой команды 0011KKKK ddddKKKK. Отсюда 12 из 16 бит ячейки флэшь можно заюзать под данные. Т.е. 25% объёма флешь мы теряем в случае такого способа хранения данных.. Но зато !!!! Если в результате случайного джампа проц попадёт на область данных, то он просто выполнить цепочку команд CPI Rd , K а в конце области данных у меня стоит джамп JMP CRASH

Хотелось бы увидеть реальный пример хранения ну например таблиц CRC16 modbus в
"дезактевированном" состоянии....

Нет в ATmega-х таких команд

Ээээ..., Вы правда знаете все команды ATmega ?
LDS,STS это какие-то другие команды ? не 32 бит ?
Ну уж просветите, наш Гуру...