Как предотвратить переопределение класса?
 

Столкнулся с проблемой:
Есть 2 SWF, одна загружается в другую с LoaderContext текущего апп. домена.
В загружаемой SWF есть класс, например, Box.
Как сделать так чтобы нельзя было его переопределить в загрузчике?
То есть, если злоумышленник создаст экземпляр класса с таким же названием в загрузчике, то далее будет использован именно он, а не тот который был загружен позднее.

сохраняйте домен загружаемой флэшки

Никак. Сделайте так, чтобы невозможно было загрузить Ваше приложение загрузчиком.

Добавлено через 1 минуту
Загрузчик будет загружать в текущий ApplicationDomain. При конфликте пространств имен и названия класса загруженный класс будет игнорироваться.

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

Задача злоумышленника - подменить класс.

Ну у меня ситуация немного другая. Загрузчик мой тоже. А загружается секьюрити модуль с контрольными суммами итд. Как и откуда загружается - не скажу - сикрет фирмы ) Соответственно злоумышленник может манипулировать с загрузчиком и создать клоны классов секьюрити модуля (если конечно он каким то образом сможет узнать их имена). Можно же кстати делать рандомное имя класса на лету и регистрировать его? ну и свое имя он будет раскрывать уже после своей инициализации соответственно дергая некий метод загрузчика?

это я понял
моя реплика была вот по поводу этого:

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


Автор, а зачем эти пляски с бубнами?
Онлайн-казино пишете?

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

Собрать класс в рантайме и обращаться к нему через интерфейс (depency injection как оно есть). Без разрешений allowDomain внешняя флешка не сможет ничего сделать.

С этого момента по-подробнее пожалуйста )

Вам в каком месте по подробней?

Вам нужно получить экземпляр класса Box.
Согласно принципам di вы не вызываете new Box(), а используете статический класс Factory с методом getBox(), который возвращает вам объект реализующий интерфейс IBox. Внутри Factory может быть все что угодно. Например класс Box будет представлять из себя строку, которая загружается как байтмассив, как вариант там могут быть пачки функций, которые навешиваются на динамический класс. Для дополнительной защиты можно снимать хэши и проверять их (сделать отдельно класс с таблицами соответствия). В итоге через Factory мы будем получать только правильные подписанные классы. При этом можно проверять подпись как у вновь создаваемого класса, так и у вызывающего. Получится очень милая атмосфера паранои и недоверия в приложении.

а что, если злоумышленник переопределит этот Фэктори класс и метод getBox? То есть, если подставной класс Фэктори будет зарегистрирован раньше инициализации секьюр модуля

Добавлено через 1 минуту
Я так понимаю отловить имена классов не так сложно в дампе памяти?

О это будет мазохизм.

Ну это понятно. Вопрос в том как это предотвратить.

Необходимость замены _всех_ классов в подгруженном приложении считается решением задачи?

Я вообще ничего не понял. Может быть пространства имен могут помочь ?!

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

я подозреваю, тут чисто академический интерес?

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

Добавлено через 20 часов 28 минут
мда жаль. вроде никак.