Какие есть сабжи на zx-spectrum, в первую очередь интересны самые необычные :)
Кто с какими сталкивался или делал ?
Так же хочется услышать о самой стойкой - труднопроходимой защите.
Пишите.
Вид для печати
Какие есть сабжи на zx-spectrum, в первую очередь интересны самые необычные :)
Кто с какими сталкивался или делал ?
Так же хочется услышать о самой стойкой - труднопроходимой защите.
Пишите.
Вот уж не встречал, хотя если чуть-чуть подпилить мою "заполнялку" экрана то в некотором роде будет шифрование (картинки)
Код:ORG 8000h
LD BC,055Ah
LD HL,_lp_1
LD DE,4000h
_lp_1: LD A,B
ADD C
RLCA
LD B,C
LD C,A
LD A,(DE)
XOR C
LD (DE),A
INC DE
LD A,D
CP 58h
RET Z
JP (HL)
Шифрование и защита от взлома - это разные вещи, в общем-то. Подход разный и требования тоже.
Защита от взлома предназначена для затруднения просмотра программы при том, что для нормального запуска программы знание какого-либо пароля не требуется. То есть взломщику не нужно подбирать пароль, вместо этого ему нужно разбираться в запутанной программе. Запутывание программ (code obfuscation) - это очень интересное направление в науке информатике. Во времена эры Спектрума люди вручную, по большей части интуитивно, занимались этим. На сегодняшний день существуют научно обоснованные, автоматические запутыватели кода. И упаси Боже всех нас от необходимости разбирать результаты их работы. Труд адский, скажу я вам!
Шифрование имеет другие цели и методы. Считается, что взломщику известен алгоритм (метод) шифрования, но не известен ключ (пароль). И секретность ключа является главным бастионом шифровальной защиты.
Если кого-то интересует шифрование на ZX, то во-первых, старые программы использовать для этого категорически не рекомендуется. В былые времена не было той строгости в обращении с шифрами. Каждый мог придумать "сложный, невзламываемый" шифр на коленке и реализовать его в своей программе. А опытный современный взломщик шифров, соответственно - взломать такой шифр довольно быстро.
Чтобы надежно защищать данные шифром, нужно использовать научно обоснованный, общепринятый метод шифрования, для Спектрума лучше всего наверно DES подходит. Можно поискать реализации для Z80. В последнее время стало модным делать DES-bootloaders для микроконтроллеров и вообще реализовывать этот метод на микроконтроллерах, так что должно существовать много 8-битных реализаций.
Добавлено через 8 минут
Я лично в 96м году реализовал шифрование данных методом квадрата Виженера на ASC CP/M. Но, конечно, взлом квадрата Виженера - это задача для студентов, позже я в одной книжке по взлому шифров видел это в качестве упражнения в одном из первых разделов :)
Что касается защиты запутанным кодом, то рекомендую желающим взломать (то есть разобраться) в защите моей проги RRESTORE (http://www.geocities.com/barmaley_m/rrestore.zip). Интересно будет послушать мнения профессионалов :)
Добавлено через 14 минут
А еще, из защит запутанным кодом, мне очень интересной показалась защита Max Iwamoto. Фактически, там был реализован пи-код (псевдокод) путем вызова коротких подпрограмм, каждая типа:
LD A,R
RET
INC HL
RET
XOR (HL)
RET
POP HL
LD SP,HL
RET
и так далее. Последовательность, в которой эти подпрограммы вызывались, была сохранена на стеке, так что никакого цикла, выбирающего откуда-то адреса этих подпрограмм в нужной последовательности, не существовало. Вместо этого последовательность адресов была записана на стеке, SP устанавливался на начало этой последовательности, а потом выполнялась команда RET :) Подпрограммы, вроде последней, позволяли осуществлять "переходы" в этом пи-коде. Были также подпрограммы условного перехода, на основе которых делался цикл ксорки.
Выглядело это все страшно до тех пор, пока я не понял основную идею. После этого восстановить программу в пи-коде и разобраться в ней было легко. Сама она не была запутанной.
Самый лучший способ это написать собственный компрессор и ненадо никаких криптований !!! Допустим, берём текст и пакуем его с помощью DSQ, и всё ... Никто не раскодирует ... Ну, понятно, что спектрумисты раскодируют, тут без вопросов ... =)
Но вообще-то, увидив эту тему я вспомнил теплые времена прошлого, когда мы с друзьями садились на двух спеках и писали защиты, потом менялись местами и взламывали ... Таким образом родилась, когда-то, совершенно идиотски реализованая мною игра, PITON-3M. В нашей игре "хакер-крякер" мы остались вдвоём с моим другом Яцковским Славиком. Соперничество дошло до защит глобального уровня. Мы в программах писали всяческие ругательства друг на друга, ну и задача у противника была их убрать. Если убирал наглые фичи, продукт удалялся навсегда, по "джентельменскому" соглашению. Ну ... Вообщем, по-сей день так и не взломали ... Конечно всё это было детство, но защита родилась.
Итак ... В общей сложности сама игра, без застваки, занимает 19 килобайт. Из них 9 килов игра и 10 защита.
Условия были таковы:
1. Убрать номер телефона на который нужно позвонть и сказать ГАДОСТЬ.
2. Убрать фразу "Яцковский тормоз перестройки"
3. Убрать фразу "Яцковский CATTLE"
4. Убрать фразу "PROTECTION BY ROB F. 1993" (боже, как давно это было)
Знаешь, я вот посмотрел - не убрали не потому что сложно, а потому что нудно смотреть и проверять надо, чего у тебя получила очередная процедура из hl и куда упрыгала... Времени уйдет много, поэтому трогать даже не буду.
Интересная защита встречалась в отечественной игре-демке колобок, как она там работала я так и не понял, какая-то путаница со страницами памяти.
Еще было интро от повер оф соунд, к игре болдердаш (в этом интро еще можно было активировать cpm экран), там защита на инт2 была вроде подвешена, стс-ом не проходима :)
автор спрашивал про крипто-. в компрессоре нет крипто-чего-либо. имея код компрессора можно написать декомпрессор (и наоборот). под крипто- надо понимать некую защиту с ключом, имея алгоритм работы которой, но не имея ключа, расшифровка невозможна.
думаю, на спеке не было ни одной такой защиты/криптовалки.
что касается трудной защиты.. думаю, проблемно пройти любую защиту, которая завязана к времянкам железа (например, чтение подряд идущих секторов с одинаковыми номерами; да и это при умении обходится).
я уже писал, что многие защиты на спеке были дырявые, у них были уязвимости, сводящие на нет всю идею защит.
1. крутая ксорка, запутанный код, вся фигня.. но т.к. в итоге прога обратится к дисководу, ставим точку останова на #5CC2 и готово. все ксорки расксорились и смотри че хошь. просто когда разрабатывали защиту, не предусмотрели...
2. диск защищенный от копирования. сколько их видел таких защит, ВСЕ обезвреживались одинаково легко. просто никто не подумал о таком методе;)
Ключ это то же алгоритм !!! Для компрессированных данных нужен ключ - "декомпрессор". А вот то, что он записан рядом с данными это другой вопрос. Но если запаковать данные с одной стороны, а с другой стороны их распаковать, то выцепив их на стадии передачи, надеяться на декодин почти не реально.
За всю историю самые лучшие защиты, как я считаю, были написаны Bill Gilbert'ом. Да я их взламывал за 5 минут имея только чистую кассету. Но с точки зрения изврата и запутанности кода - они лучшие.
А насчёт защиты от копирования:
Я делал защиту в Киеве от копирования. И никакими стандартными методами её не ломануть. Понятно, что можно найти в коде место проверки. Но это если явно дать понять, что тебя скопировали обманным путём. А если в игре поубирать какие-то предметы, допустим, и ты это поймёшь только после 1 часа и гры. То уверен, что хакер это делать не будет. Он ломанёт, увиди, что запустилась, и отдаст результат дальше.
Моя защита делалась на чистых ГМД дисках. Ниразу не форматированных. Правда было много дисков, которые поставлялись в форматированном виде. Но мы ходили на завод ЭлектронМаш и набирали нулёвых дисков. Далее форматируется весь диск, кроме 3 треков. После ... Читается руками отсутсвующий трек. Информация получается битая, и каждый раз читается разная. Но замечен был эффект, что читалось, допустим, в первый раз 111101111, а во второй раз 111111011. То есть нолики смещались, но это мсенщение не превышало 5-10 бит. Так, что тут железно. Никакой копир орегинал не скопирует. Если моя прога выкупала, что данные в этом треке читаются стабильно, - "пиши пропало", портим внутренности игры ... В данном случае это был UFO. Нашего продавца Руслана на радиорынке не утраивала защита в орегинале, поскольку прекрасно копировалась каким-то Speccy копиром, кажется Donald-бла-бла-бла, что-то такое в названии было. Вот не помню точно, но какой-то хороший копир.
Конечно вариант полного взлома не рассматривается. В таком случае любые криптованные данные читаются, имея ключ. Я сам ломал кучу подобных игр, как на Speccy, так и на PC.
А вообще защиты это ГАВНО !!! Это смерть искусству ... Любой софт не должен быть защищён. Максимум, что я признаю. это защищать данные в сети, которые ты хочешь передать только конкретному человеку и спрятать их от лишних глаз.
Добавлено через 22 минуты
Нет ... Тут ты не прав ... Не убрали именно потому что не смогли !!! Это было всё в ZX-Club'е ... И мы собирались на подобные мероприятия не однократно ...
нет, если говорить о крипто - то декомпрессор - это алгоритм и он может быть известен. это во-первых. а во-вторых, если взять тот же dsq как он есть сейчас, сжать большой текст и отдать криптоаналитику..... боюсь, он быстро это все расколет, т.к. сжатие - это НЕ шифрование! да и сжатие делается стандартными методами. поэтому, ему стоит только подумать "а вдруг оно просто сжато" и он относительно легко восстановит формат.
вот здесь ты ошибаешься. если, например, заранее известен тип данных, то более чем реально. особенно, если это текст;)
я не про такие защиты говорил, а про общего применения. такие-то понятное дело, что можно наворотить, что хрен все куски найдешь...
а это еще проверять надо бы;) не копир, так руками сделать такой трек. кстати, если на дорожке секторов нет, то она не обязана читаться бит в бит.
я вот еще че думаю.. в то время не было микроконтроллеров так массово, а то все бы защиты ломались;)
Тобосом смотрю компилил
Да ... Я noobie ... =)
Точно фуфло ... Ок ... Перейдём к более сложным "потугам" ...
А кто-нибудь делал на микроконтроллере читалку для дискет?
Я размышлял над этим одно время, но так вплотную и не занялся. Хотел амижные и агатовские дискеты прочитать. Там основная сложность на мой взгляд - это выделение из приходящих импульсов сигнала синхронизации. Занимается этим узел под названием Data Separator.
Простейшие из них строятся на мультивибраторе типа АГ3 с подстройкой, хорошие - на основе ФАПЧ... Я пытался найти в интернете схему, но хорошей так и не нашел, плохую делать не захотел, а мозгов пока не хватило свою придумать :)
Поэтому я люблю писать всё сам ... На планете 90% кода пишется через инет. Линкуют стандартные библиотеки. И потом оно всё глючит. И исправить не могут, потому что не знают чего туды накомпилировали.
Прекрасно ... Прикрепляю файл ... Это текст, в нём информация, которая знакома каждому из вас. Думать не надо, это пакованный текст. Только лишь пакер, то есть можно ещё и заархивировать. Но пока только пакер. Я его сам написал, зипу проигрываю в 1.32 раза. За-то скоростной депакинг. Мне этот пакер нужен как stream'овый по работе.
Думаю недели хватит для раскодировки ? Ровно через неделю я выложу депакер, и каждый сможет распаковать.
Робус - обеспечение защиты данных путем секретности алгоритма - это тупиковая ветвь эволюции. Поясню, почему:
1. Секретный элемент (алгоритм) одинаков для всех защищенных текстов. Если злоумышленнику станет известен алгоритм депакера, он сможет прочитать все твои тексты. В случае же, когда секретным является ключ, а не алгоритм, то тексты можно шифровать разными ключами, и попадание только одного ключа в руки врагу дает ему доступ не ко всем твоим текстам, а только к их части.
2. Секретный алгоритм упаковки сложно поменять в случае необходимости (если старый стал известен врагу, например). Малые изменения в алгоритме будут недостаточны - враг сможет их угадать. Большие изменения трудоемки и требуют квалификации. С другой стороны, если секретным является ключ, а не алгоритм, то поменять ключ легко.
3. Использование секретных алгоритмов недоступно тем, кто не имеет квалификации разработчика. Услуги разработчика со стороны делают последнего автоматически посвященным во все тайны. С другой стороны, защита, основанная на секретных ключах, не имеет этого недостатка. Даже если я разработал программу шифрования, то это еще не значит, что я смогу прочитать тексты, которые ты зашифровал с ее помощью.
4. Объем секретной информации (программа-депакер) очень велик, его труднее передать адресату, чем пароль. Пароль можно на ухо шепнуть, а программу - будь добр на электронном носителе передавай.
5. Хранение секретной части (программы-депакера) является уязвимым местом. Если человек может держать свои пароли в памяти, и чтобы врагу их получить, потребуется пытать или шантажировать жертву, то программа-депакер должна храниться на электронном носителе, который можно украсть или отобрать.
Добавлено через 11 минут
Добавлю. Методы шифрования (или упаковки в качестве шифрования), созданные дилетантами, могут иметь уязвимости к следующим типам атак:
1. Сравнение нескольких шифротекстов (поиск в них закономерностей и на их основе - полный или частичный взлом одного или всех)
2. Known plaintext attack (атака известным исходным тестом). Иногда врагу может быть известно (другими путями) полностью или частично исходное содержание шифротекста. На этой основе он иногда может восстановить ключ, восстановить остальной шифротекст и т.д. Классическая возможность подобной атаки - это всевозможные сигнатуры, содержащиеся в файлах ("JFIF" в jpg-файлах; "RIFF" - в wav- и avi-файлах; "Rar!" - в рар-архивах и т.д.)
3. Chosen plaintext attack (когда злоумышленник может, не зная ключа и алгоритма, подсовывать ему выбранные произвольно фрагменты текста для зашифрования)
И другие.
Успех взлома шифра не обязательно основывается на анализе одного лишь сообщения. Иногда может потребоваться перехват нескольких сообщений или ситуации, подобные вышеописанным. Но они возникают достаточно часто в жизни - и поэтому профессиональные разработчики шифров учитывают все это и стремятся сделать свои шифры устойчивыми к подобным уязвимостям.
Да не тупиковая ... Я прекрасно понимаю, что знать как всё устроено, - легко найти ... Ты думаешь я просто так выложил файл ??? Запакованный файл с кодом XOR'а это не взламываемая вещь !!! Понятно, что если запаковать, а потом проксорить поверх, то ломается ... Но если ксорить с учётом хода паковки, то код ксорки меняется на ходу. Тут я это и сделал ... Если поменяется хотя бы одно слово в тексте, то резко меняется алгоритм кода. В данном случае делается всего две зависимости. Первая зависимость от количество не пакуемых данных на блок (8192 байт), вторая зависимость от количество повторяемых участков кода на блок. В данном случае меняется только Код, а точнее говоря их два. А есали сделать ещё и плавающую талицу ксоров, которая в данном пакере фиксированная, то просто полный аут.
В моём пакере два кода которые модифицируют друг друга в зависимости от данных. Начальное значение так же фиксированно. А ведь можно поменять.
Код я имею в виду КЛЮЧЬ для ксора.
Голая математика легко просчитывается криптовщиком, голая логика легко просчитывается криптофщиком. Но стоит применить и мат. и лог. получаем приличную кашу.
Поэтому и уникальны Specc'овские программеры, они умеют применять все свои знания.
Добавлено через 5 минут
Данный алгоритм может меняться на ходу. Мало того ещё и программироваться. На ходу меняются методы записи повторений и комманд.
Думаю не ломанёте ... Конечно всё возможно в этом мире, но думаю что данный метод потребует только для частного случая мучений на неделю. Да же я зная все возможные перетасовки команд и записи длин пакетов искал бы только ключ неделю. Всё что из этого файла можно понять это размер пакованных данных.
Добавлено через 7 минут
Не ... Ну это вообще не обсуждается ... Я могу просто взять и выложить распакованные данные и депакер не нужен ...
Мы же мыслим здраво !!! Депакер и пакер никому не известен, это очевидно ....
оффтопик, конечно...
ну, я за свою жизнь видел очень много людей, называющих себя программистами. когда начинаешь с ними работать, выясняется, что они много не знают, не понимают, понимают не верно или как-то интуитивно (а это самое опасное). так вот само собой, если такие пишут чего-то вместе, то и результат понятно какой! и не надо это приводить в пример. а что касается "все сам".. так ты наверное по-настоящему-то больших проектов и не делал (да еще за ограниченное время).
есть 2 подхода: один твой (да и мой тоже), а второй коммерческий. я когда пишу, я свою прогу вылизываю и тестирую сам, т.к. мне лучше известно где и что надо проверять и какие баги могут быть при моем подходе. когда же люди делают огромный проект за короткое время, им проще нанять ниче не понимающего в программировании тестера, который будет искать в программе баги опытным путем, а программист будет меньше сосредоточиваться на отладке и быстрее писать. все понимают, что это не совсем правильно, но задача решается (хоть и продукт получается слегка глюкавым).
это я к чему. не надо говорить, что "все сам" - это единственно правильный метод.
недели? офигеть... предложишь мне 24 часа 7 дней сидеть и ломать? а кто будет работать? мне еще жить на что-то надо. это во-первых. во-вторых, вряд ли можно ломать по одному зашифрованному тексту. нужно много текстов, и коротких, и длинных. и хотя бы пару из них расшифрованных (ты бы еще букву А зашифровал и попросил расшифровать;).
ну и еще я хотел спросить: а где можно применять закрытые алгоритмы-то? взять, например, переписку. делать прогу ради 2х человек? для всех-то ты её выложить не можешь, в проге ключ. девайс общается с компом по закрытому протоколу? так можно прогу на компе поломать..
Мне больше всего нравится сравнительная форма как константа. Большие это сколько ? В чём мерить ? В гигабайтах ? Во времени создания ? Я занимаюсь профессиональной деятельностью с 1998 года. Самый большой мой проект я считаю "ФОТОМЕТР", это индустриальный лабораторный прибор для измерения цветности бумаги. Но там программирования не много, зато немало запатентованных исследовательских работ. Если словом БОЛЬШИХ называется гигантский код, то начиная с 2004 по сей день работаю ведущим инженер-программистом. Сейчас, вроде как по-подсчётом заканчиваю 7-ой проект. В общей сложности, если брать Израиль, Россию и Украину у меня в подчинении 18 программистов. Одновременно веду три проекта. Но я большего отупения человечества(программисто ) не видел, начиная с 2004 года. Да, это приносит компании прибыль, но на каком гавне. И я работаю тут только ради денег и никогда не буду гордиться той работой, которую делаю сейчас. Да, я досконально изучил говёный линукс, смысл которого я вижу только в поддержки Ethernet'а(IP/PPP). Я досконально знаю OpenRg и Asterisk. Ну и что ??? Говно всё это, причём редко глючное. Все эти XML, JAV'ы, C# - всё это порождение похабного отношения к искусству программирования. И, когда мне выставляют рамки, как ты говоришь, - (да еще за ограниченное время), и при этом, что OpenRg, что Asterisk, что линукс, глючит в данный момент, я не могу писать разработчикам - "ВЫ ЛОХИ У ВАС ТУТ 33.33 ошибки в коде". Я просто сажусь и правлю это. И на поиск этих ошибок, порождённых лозунгами - "БОЛЬШИЕ проекты", уходит времени ровно столько, сколько бы ушло на "всё сам". Так, извини, моё "всё сам", почему-то работает уже не один год и не на одном заводе и не один проект.
А вот гордиться я буду меньшими проектами, научными. Например система обнаружения людей в аэропортах. С видеокамер считывается 2-3 кадра в секунду снимки толпы, вносятся ФЕЙСЫ в архивчик, и потом на другой камере в другом месте делается то же самое. Итак, известно, когда ФЕЙС зашёл и когда вышел. Система противо-террористическая. Успешно работает в Борисполе и в БенГурионе (терминал 3). Вот это была научная работа. Хоть наш директор её и продал, хоть я со всей нашей командой и остался у разбитого корыта. Но за то это работает и это глобальный проект. И этот проект сделан с максимальной дотошностью, в нём нет ни виндовса, ни линукса там ВСЁ СВОЁ. И мы его от а до я сделали за 2 года с учётом введения в эксплуатацию и тестом на эффективность.
Поэтому если ты хочешь сделать надёжную систему, то - только один путь - "всё сам". А если речь идёт о, например, мобильном телефоне, тот тут пусть будет солянка. Всё равно я не куплю такой мобильный. Именно поэтому я хожу со старым мобильным. У него зелёный экран и он не умеет играть МП3, за-то он не зависает и не раздражает тормозящими менюшками.
Тут я тебя очень хорошо понимаю. У самого такая жизнь, которую я стал ненавидеть. Просто была затронута тема о криптографии, и был поиск самого мощного способа защиты. Моя практика показала, что именно перемешанный пак с кодировкой делает данные, не поддающиеся анализу. Просто была такая практика. Я понимаю, что могу ошибаться, что нет ничего невозможного.
Это волне реализуемо. Запакуем. Только я хочу сразу предупредить. Да же 20 байт текста я бы в сети передавал бы с еррорными пакетами. Как мы делали в казиношном проекте в 2002 году. Я согласен не заниматься таким в данном случае. К вечеру постараюсь найти пробелы в работе и запаковать с 10-ок текстов.
Так ... Это уже наглость ... Такое через неделю ... Мы же договорились, что депакер и пакер не известен. Расшифрованный текст - практически ключ. Хотя и не очень эффективный, но всё же это очень серьёзный путь к расшифровке. В данном случае мы рассматриваем самый приоритетный вариант использования защиты. То есть голые данные. В жизни такой ситуации практически нет. Как правило, человек видит данные между двумя устройствами, которые что-то делают. Он видит реакцию устройства. Например - изображение, звук, исполнение разнообразных функций.
Так что, выложить 10 закодированных текстов, это пожалуйста, и без рандомных добавок. Но на раскодированный я не согласен. Но можно и этот вариант проверить.
Тогда меняем немного правила. Через неделю я выложу оригинал 10-ти текстов запакованных текстов. Останется только один, - первый.
Ну ... Поле действий просто неограниченно. Например - на данный момент мы занимаемся именно подобной задачей. Есть такая штука как GSM, это, с одной стороны простой пакет радио связи. Но это только тогда когда два устройства стандартные. По настоящему GSM пакет имеет около 300 видов конфигурации. Мобилы юзают только один, служба безопасности от 3 до 5. Как ты понимаешь, шифровка тут очень актуальна.
А так мы это применяли в:
1. В десятках приборах. Программу на компе хай воруют, она только отображает процессы и задаёт параметры. Зато вся система общается по собственному протоколу. Максимум что могут сделать, это с контроллеров, непосредственно с кристалла, считать программу. Ну, так нет проблем, вперёд. Во всей системе около 20 разновидностей контроллеров. Єто обойдётся в кругленькую сумму. У нас такое делают за $100000, для одного контроллера. Дешевле купить у производителя. Каждый контроллер связан друг с другом по собственным протоколам с собственными кодами защиты. Центральному, он отдаёт только состояние датчиков и протекающих процессов.
2. ФЕЙС детектор. Тут я буду молчать.
3. Казиношном проекте (против кражи данных об обороте в казино)
А вообще, взламывается всё, тут главный фактор - Время.
Очень быстро писать *****код и очень медленно писать качественные велосипеды- вещи одного порядка проблематичности.
Вот писать быстро и качественно - это показатель мастерства разработчика. Тут даже язык программирования на второй план отходит. Ибо правильно сделанный алгоритм на каком-нибудь скрипте будет работать быстрее наколенной поделки на ассемблере.
Прекрасное высказывание !!! Я согласен с каждым словом ... Именно такой у меня подход к работе. Да же на текущей, где меня постоянно заставляют обращать внимание на процентность ошибки в проекте. Если процент ошибки работы не привышает 15% то баг не рассматривается и не считается критичным. Именно подобное меня раздражает.
Быстро и качественно это моё стремление. Понятно, что я не гуру, но к этому идеалу я всегда стремлюсь. Но если рассматривать приоритеты то я бы их раставил так:
00000. Быстро и качественно
00001. Медленно и качественно
65535. Быстро и говёно ИЛИ медленно и говёно
А что делать с правильным алгоритмом на ассмеблере ??? Эти "правильные" алгоритмы на скриптах кишат везде, и они меня за время работы так уже задрали, что моя любимая команда на СЯХ перед такими обработчиками скриптов стала - "//". А особенно в OpenRG, ссори, просто наболело, и от слова скрипт начинает типать.
В принципе, нормальный подход. Отвлекаться на мелочи, когда есть более крупные проблемы преступно. Тем более что большинство мелких багов рассасываются при исправлении крупных. Другое дело когда вообще не рассматриваются низкоприоритетные баги, даже если нет более приоритетных. У нас вот цель- 0 багов в итоге, у тестеров соотвецно другое мнение:)
ой песта-песта....
antiofftop: да!
я имел в виду большой код. например, возьми опенофис. софтина здоровая, глючная. за сколько ты напишешь такую, если "все сам" с нуля? пока ты напишешь, остальные сделают "*****код" и продадут его.
так и я не буду. я полностью разделяю твою точку зрения про линуксы, программеров и прочее (я сам часто точно так же ругаю то, с чем приходится работать). только не будь так категоричен и самоуверен.
во-первых, если у человека нет никаких наработок и перед ним стоит задача сделать быстро, ясен перец у него один выход - взять чье-то. если времени очень мало - то он может даже и не разобраться, че как работает. только задачу он выполнит.
а ты рассуждаешь, что у тебя уже есть наработки свои, ты их применяешь и все здорово пашет. так само собой! только плюс, если так. только на практике такое очень редко бывает.
не надо лукавить. то, что есть в линуксе - ты бы писал сам несколько лет.
линукс хорош не только своим тцп/ип стеком, в нем много полезных хреней (если эти хрени действительно нужны). а тцп и езернет, а так же файловая система и пр. легко делаются даже на микроконтроллерах.
вот как тебе сказать. ты же не будешь спорить, что делать все своё - это гораздо сложнее, нежели взять линукс и сделать на его основе? вот и я думаю, что не будешь. а согласен, что за более сложную работу надо платить больше денег? а платят? вот и результат. нет заинтересованных людей в качественном продукте, если люди заинтересованные быстро продать хрень.
есть второй путь: разобраться как работает то, на чем ты это сделал. если ты действительно досконально изучил линукс внутри, то у тебя не должно быть вопросов, а че это оно тут не так работает.
это тоже самое, как ассемблерщик ругает си, мол, непонятно, как он все скомпилирует, я теряю контроль над программой и т.п. так а что тебе мешает разобраться в компиляторе? недельку поковыряешься - больше не будет вопросов.
а, собс-но, кто пытался твой пакер анализировать? или ты сам "просто подумал и понял"? или ты криптоаналитик?
это как? ошибки CRC? если обмен между девайсами - можешь вообще без црц делать - это дело разработчика. хакеру же твои црц по барабану.
ха-ха-ха! а с чего это наглость? почему ты думаешь, что в жизни не будет известно, что за текст ты передаешь? в жизни-то как раз похакать твою кодировку еще интереснее, можно видеть что происходить, пробовать разные виды атак. а так - скучно. да и нет у меня особой уверенности, что за короткое время у меня что-то получится. я не спец, я просто балуюсь иногда.
и расшифрованный текст - это не ключ никак.
и здесь ты ошибаешься. имея в наличии такую систему можно поставить очень много экспериментов и очень многое понять именно по реакции.
кстати, однажды один чел мне рассказывал, как они в конторе, которая занимается системами охраны, делали свои приборы тоже с самовыдуманным шифрованием. вот он мне рассказал принцип, и я практически сразу придумал, как такую систему расколоть просто снифая траффик. а у них там в системе был "типа ключ" 256 байт:)))
и вот с некоторых пор я не верю в псевдошифрование.
ты, конечно, молодец, тексты выложил, но мы не договорились. за неделю я 100% ниче не успею, а больше никто браться не будет. щас конец года, на работе завал.
ну и плюс к тому, абсолютно ничего не известно про исходные данные.
Robus, кстати, скажи в какой кодировке были тексты? чтоб хоть немного сократить мне время..
Народ, что вы на Робаса накинулись?
Давайте начнем с этого?
и с чего тут начинать?
ну так то ж изначально. там же и написано, что секретный алгоритм (в жизни) - фигня. и даже где-то по ссылкам есть хороший пример: раньше не был известен алгоритм шифрования в GSM, сейчас же все известно и ломается. короче, это оффтоп:) абсолютно все ломается за 5 минут терморектальным методом:)
В Windows русиш ... =)
Страшно такое читать ... Особенно когда каждый день с этим работаешь ... Ты, вообще, в курсе, что GSM пакет может меняться ? С мобильным оператором только один вид пакета ходит. А их десятки. Мне довилось работать только с одним, иным, видом пакета. Только лишь для того что бы заставить операторский модем принять пакет, нужно было на несущей сгенерировать ошибки на строго-определённых задержках друг от друга и на строго определённое время продолжительности. И это был только один, из подобного рода пакетов. А их десятки, и проанализировать ты их не можешь, хотя бы по той причине, что по воздуху они пролетят только в экстренных ситуациях. А про стандартные мобилы никто не говорит, тут и КРИПТО-ПАЯЛЬНИК не нужен. Да же мы на фирме стандартным WaveCom'ом, можем подключиться к любому активному VoiceStream'у, если, кстати, у такового не стоит CLIP.
Любишь поиздеваться ... Кого собираешься пытать ??? У нас мирная тема ...
Добавлено через 4 минуты
P.S.: Кстати ... Есть ещё GSM пакеты по четырём несущим одновременно 900+1900+850+1800. У нас такое запрещается, да же по двум одновременно, в Израиле, почему-то разрешено.
да ты не бойся:) тема мирная:)
а я, вообще-то, говорил про шифрование в GSM, которое применяется для голосового канала, смс и гпрс, которое как раз "Да же мы на фирме". тут как раз и была такая ситуация, когда секретили алгоритм, но он утек и оказался не стойкий. кстати, до сих пор в открытом виде нет детальной информации и софта, а некоторые продолжают утверждать, что перехват данных в GSM невозможен.
Минула неделя ... Выкладываю пару раскодированных текстов ... Интересно, если сделать не математический код, а филосовский. Создать эдакий искуственный интеллект, который в свою очередь создаст ещё один, с нужной нам информацией.
Протянута - едва-едва
- Моей ладонью
Линия насмешки.
Не так надежно, как Судьба,
Не так враждебно.
Не так легко, как белая метель,
Мое кружение по ветру.
Где я - не более, чем тень,
Не подчинившаяся свету.
Робус, да ты не спеши. никто не горит желанием ковыряться в твоих файлах, может, кроме меня. а мне в данный момент не совсем до них.