Jump to content
¯\_( ツ)_/¯
  • TAD GROUP are currently hiring penetration testers. Please read the topic in Career Central subforum.
  • Sponsored Ad
ТУК НЕ СЕ ПРЕДЛАГАТ ХАКЕРСКИ УСЛУГИ ! ×

Avatara

Moderators
  • Content Count

    400
  • Joined

  • Last visited

  • Days Won

    80

Avatara last won the day on January 20

Avatara had the most liked content!

Community Reputation

232 Excellent

About Avatara

  • Rank
    Advanced

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Здравей и много благодаря за препоръките. Password Based Key Derivation Function е включен. Има го във всички версии. Използва се при т.н. "контролни низове" (Control String). Има го в системните настройки. Ползва леко изменен алгоритъм но по принцип си е едно и също. Ето как изглежда на практика: БЕЗ ПАРОЛА: С АВТОМАТИЧНО ГЕНЕРИРАНА ПАРОЛА (НО МОЖЕ И РЪЧНО ДА СЕ ВЪВЕДЕ 1111, ПРИМЕРНО) Разликите са в Hash Digest, Secret key, Salt Data и Cipher IV. Но все пак key derivation function си зависи от избраната хеш-функция. Това няма как да се избегне при този примитив. Знаеш ли, че ти си първия, който засяга темата? Генерацията на секретни ключове и механизмът на шифроване са си цяла наука, а не сме го обсъждали. А е добре да го правим Що се отнася GCM и това го има, но е само за системите, които ползват AED. Да, но е добре да се ползва и за шифровъчни системи, които ползват блокове с размер различен от размер 128 bit. При FPS изглежда ето така (това е междинно решение): БЛОКОВ ШИФЪР С РАЗМЕР НА БЛОКА 128 BIT (IDEA PGP) БЛОКОВ ШИФЪР С РАЗМЕР НА БЛОКА 512 BIT (RC-4) Това е малко по-добро решение, защото на практика отпада ограничението с размера на блока. Просто в полето Cipher mode се задава класческото CTR, а другото ще се случи автоматично. Има и още нещо ... FPS не е шифровъчна система. На практика може използвайки криптографски примитиви (шифровъчни алгоритми, хеш-функции, делти, инициализиращи вектори, генератори а случайни числа и пр.) може да се създават всякакви шифровъчни системи. Да го кажем просто ... FPS е конструктор на шифровъчни системи. Ползваш примитивите. Комбинираш. Тестваш. Настройки. Параметри. Контрол на процесите. Ентропия. Дифузия. Информационен излишък. Ефективност и пр. Ако всичко е както трябва имаме шифровъчната система която ни трябва. Записваме и ползваме. Това си е направо цял нов раздел. Много благодаря, че повдигна тези въпроси. Има и още ... Външните обекти. Там вече е много забавно. Това е съвсем различен криптограяфски примитив и тук определено аутентефикацията се извършва по много различна логика. При това имаме не един а цял списък секретни ключове, при това уникални не само в рамките на сесията. А тук генерираме делти. На практика от една цифрова фотография, ако прилагаме различни филтри можем да генерираме неограничен брой уникални делти, а това дава допълнителна надеждност. Идеята е тези неща да не се правят ръчно, а колкото е възможно да ги автоматизираме. Както казваше един познат: "На Assembler може да направим всичко, но живота е кратък.". Още веднъж много благодаря за препоръките и за отношението по темата. Определено има какво да дискутираме.
  2. Здравейте, Функционалността не е нова. Тя е на повече от десет години. Налага се да направим огромна крачка назада, защото се оказва, че в момента има огромен проблем, който не касае само България. Не знам откъде да започна, но първопричината е използването на английски език. Английският език използван в криптографията е много специфичен. Всички термини са превод от френски и арабски, а от там става ужасна каша. Съвсем друг е въпросът с преводите на български език. Там е направо страшно. Един елементарен пример. Шифровъчният механизъм е най-важният елемент във всяка шифро-система, но тук в България липсва сериозна литература по този въпрос. Да не споменавам какви глупости са изписани в Wikipedia (и не само там). Това е много тревожна тенденция, защото реално се създава огромна заплаха за сигурността на данните. A сега по същество. Има термин, който се нарича "Хамилтоново отстояние". Кажете ми колко експерти по киберсигурност знаят какво може да ни даде това, за какво и как се използва? Аз също не бях запознат, докато един колега от Грузия не ми разясни всичко в детайли. Не знам дали сте обърнали внимание, че при FPS, имаме анализ на процеса на милисекунда. Във високите версии на продукта се работи на микро и мили секунда. В най-високите имаме и съпоставка с всеки един такт на процесора. Задавали ли сте си въпроса: Защо по дяволите е нужно това, като реално то допълнително натоварва интерфейса и затруднява процеса на разработка? Проблемът на цифровите технологии е техният дискретен характер. Това е най-слабото им място и няма как да бъде защитено. Ако съчетаете Хамилтовите отстояния с времевия анализ на практика всеки един компютър и всяко едно цифров устройство ( в т.ч. мрежово активно оборудваме, промишлени контролери, защитени системи за управление и пр.) стават напълно прозрачни за несанкциониран достъп, при това НЯМА НУЖДА ДА СА СВЪРЗАНИ С INTERNET! Но да не навлизаме в толкова "сложна материя". Да поговорим за делтите и защо са важни? Ами просто е. При хеш-функциите имаме колизии. Два различни файла могат да имат абсолютно еднакви хеш функции. Причината за този феномен е много проста и е обвързана с начина по който се изчислява checksum на файловете. За да се поправи този проблем се използват различни прийоми (вектор на инициализация, посоляване и др.). Делтите са основен елемент за противодействие на колизиите. Да, но и делтите са уязвими. Една от основните заплахи при използване на Random Delta (RD) e ако криптоанализаторът е предварително запознат с формата на информационните масиви. В този случай атаката се провежда като в определени точки се извършват случайни преобразувания. За да бъде предотвратена подобна възможност се използва хеширане, което позволява контрол на последователността. И какво следва? Делтите и хеширането са взаимнозависими от гледна точка на криптоанализа. Забавно, нали? В крайна сметка стандартните методи на шифроване са уязвими в много направление, което изисква сериозни базови познания по темата. Най-добре е ако наистина искате да навлезете в материята да използвате NIST Special Publication 800-38A и това само като начало. База без която не може. За всички термини и въпроси, свързани с Message Authentication Codes (MACs) би следвало да се ползва ISO/IEC 9797-1:2011. Повярвайте, това са много ценни документи при това достъпни и написани просто и разбираемо. Без фундаментални познания (в т.ч. и математика) е невъзможно. Аз не съм толкова добър математик, но се уча и възприемам. Това, което знам е, че чуждото мнение е една различна гледна точка, която може да бъде много полезна и да ни спести време. В този ред на мисли ... КАКВО ЩЕ КАЖЕТЕ АКО С КОЛЕГИТЕ НАПРАВИМ ЕДИN БЕЗПЛАТЕН ON-LINE КУРС ПО ТЕМАТА?
  3. Още веднъж огромни благодарности на всички за направените препоръки. Сами може да се убедите, че всички те бяха взети под внимание. От виртуалните контейнери до възможностите за използване на различни публични e-mail ресурси. Последният (но не по-важност) елемент, който бе добавен в резултат на направените препоръки, касае механизмите за шифроване и генерирането на секретни ключове. Като начало това, което е достъпно в модула за настройки на стандартните форми на шифроване са cipher mode, възможността за въвеждане и генериране на псевдослучайни hash salt и Cipher IV (или казано простично - инициализиращ вектор, initial Vector), както и възможността за въвеждане на произволни secret key (w t.`. i awtomati`no generirani ot modulite na ОРЕ). Какво ни дава това? Като начало отпада необходимостта от използване на hash, а това автоматически елиминира каквато и да било възможност за възникване на колизии. Може да използвате сесийни секретни ключове, които след сесията автоматично ще бъдат унищожени, но най-хубавото е, че може да "обменяте" (на практика те се генерират автоматично, в рамките на една работна сесия), ключове през "сивата зона" (например като използвате публични сайтове). Допълнително предимство и изчисляването на ентропията и информационният излишък. Това е важно, когато работим с текстови файлове и искаме гаранция за тяхната сигурност. В този случай обаче има и една малка подробност, на която бих желал да обърна специално внимание. Много от постулатите на криптоанализа са от началото на XIX век, когато не е имало компютри и цифрови технологии. Тук е мястото да благодаря на колега от ДАНС, който спомена нещо важно, касаещо обследването. масово се приема, че изчисляването на ентропията би следвало да се извършва спрямо символите. Да, но при компютрите имаме двоичен запис (единици и мули), при това групирани в байтове (групи по осем). Това важи и за шестнадесетичния код. Ако един текст бъде преобразуван в двоичен вид (това важи и за файловете) и преизчислим ентропията може да получим различна от очакваната средна стойност, при огромен информационен излишък. Това важи с пълна сила и за паролите, за които ще поговорим малко по-късно. Генерацията на ссийни секретни ключове е лесна за реализация. Нужен ви е произволно избран сайт или някакво цифрово изображения (може да ползвате и видео в YouTube, снимка от мобилния телефон или аудио файл). На практика един елементарен сайт позволява генерацията на над 1500 уникални секретни ключа в рамките на секунди. Това, което е важно е, че тези секретни ключове не е нужно да се предават, защото те се генерират двустранно. Това важи както за едноключевите системи за шифроване така и за двуключовите (асиметричните) шифровъчни системи. И ако трябва да обобшим ... Имаме виртуални контейнери, имаме генератори на секретни ключове, може да избираме механизмът на шифроване, може да избираме начина на шифроване (блокове, поточни шифри и др.) и като цяло имаме доста сносни възможности за защита на локални данни и обмен на защитена кореспонденция. Сега трябва да напраим следващата стъпка. Още веднъж благодаря на всички в този форум, които дадоха много ценни съвети и направиха изключително конструктивни забележки. P.S. Забравих да спомена, че се изчислява средна стойност за ентропията. Това е важно. Друг момент е, че секретните ключове имат псевдослучаен характер, защото са генерирани на обикновен компютър с ограничена разрядност. Независимо от това по груби изчисления за статистическа атака при използване на суперкомпютри ще са нужни над 14 000 000 години (допълнително ще опиша методите за оценка, които са използвани) за разбиването на някои от тях. Мисля, че това е доста голям времеви период, а и едва ли някой ще изпада чак в такива крайности. Пак повтарям, че това е система за генериране на сесийни секретни ключове, с всички произтичащи от това последствия и ограничения.
  4. Днес ще ви представя един стар-нов проект, който бе замразен повече от десет години. BS Ping се появи в "далечната" 2001 година. Ако се поразровите в мрежата ще го намерите в един доста "необичаен вид" (най-вече използваната нестандартна форма и не само). Първоначалната идея бе това да е проект за обучение. Просто визуализация на процесите и използване на малко познати мрежови протоколи, но ... Фиг.1. Kалкулатор на адреси Продуктът бе забелязан от други и постепенно се превърна в неделима част от тактическите информационни системи (не в България, естествено). В момента официалното му наименование е NCA-I. На Фиг.1. виждате стандартен адресен калкулатор. В него няма нищо сложно, а още по-малко загадъчно. Въпреки това много често ми задават въпроса: Откъде са изображенията за анализа на подмрежите на facebook, примерно. Ами ... от тук са. Това си е най-обикновен инструмент за анализ на IP адреси. В internet има много подобни решения. След много спорове и много изписани документи ни бе разрешено да публикуваме отново публичните части на проекта. Те не са кой знае какво и в тях определено няма нищо "секретно", но могат да бъдат от полза зза всички, които изучават мрежови технологии. Просто се онагледяват процеси, които са до болка познати на системните администратори. Фиг.2. Използване на tracert и геолокация на маршрута. Типичен ример за това е trasert. В случая имаме и геолокация на отделните рутери, както и визуализация на маршрута, което често се показва по филмите. Искам да подчертая, че има доста сериозна разлика между trasert и traceroot. Специално за TCP има специализиран модул, който включва и няколко често използвани конзолни команди, които могат да бъдат от полза в процеса на обучение. Фиг.3. Конзолни команди. В момента BS Ping (NCA-I) е достъпен само и единствено за ОС Windows. Причините за това са юридически. Нaй-високата версия е LE (Light Edition). Версиите SE, SPE, PE и ЕЕ са забранени за публикуване (за сега). Kакви са причините за това определено не знам. Лично аз считам, че в тези версии няма нещо, което опитен администратор да не бъде в състояние да направи, но аз съм просто един от многото и нямам думата, при важните решения. Естествено възниква въпросът: А има ли безплатна версия? Да. Има. Може да получите безплатно дори платени версии. Вариантите са да получите промо код (пишете на лична), ако ползвате Windows 10 или активиращ низ (пишете на лична) за да активирате продукта. Всичко е напълно законно и легално. Ето и адреси в Microsoft Store (за Win 10): BS Ping - FE https://www.microsoft.com/store/apps/9NJH6GV29P1Z BS Ping - LE (версията е платена и ако искате да я получите безплатно пишете на лични за да ви дам promo key) https://www.microsoft.com/store/apps/9NXJP9184XD6
  5. Здравейте, Моля да бъда извинен. Възможно е да не съм се изразил правилно. Опитвам се да насоча дискусията към базови принципи. Структурите са: Масиви; Записи; Множества. Kакво общо има това с Parallel Programming Library (PPL)? Убягва ми логиката на изложението. При паралелните процеси имаме паралелни цикли Tparallel.For и изпълнение на паралелни задачи TTasc и ITasc. Да, съгласен съм, че cross cutting логиката (Cross-Cutting Concerns - CCC), за която пишете, включва: Управление на жизнения цикъл на обектите; Оптимизация (в т.ч. и кеширане); Транзакции; Многопоточност и синхронизация; безопасност и пр., но ... това е програмна парадигма. Базов клас в Delphi е TObject. Негов наследник е Exception, но не знам някога да е имало какъвто и да било проблем. Те са си съвсем стандартни решения. Създаване, обслужване, премахване. Получаване на информация (ClassInfo, ClassName, ClassType и пр. и пр.). Обработка на съобщения. Но това са общоприети принципи и те не са обвързани с конкретен език. Аз съм визирал нещо крайно елементарно. Ще приемем, че не съм Ви разбрал правилно. Да разбирам ли, че проекта, по който работите е свързан с подредбата на съобщенията (message queue)? Нали не възразявате, ако приемем, че това което правите е SaaS технология? Или греша? Възможно е да е нещо идейно близко до MSSQ или Rabbit MQ, но с много по широка функционалност? Идеята е интересна. Асинхроннен обмен, буферизация, гарантирани доставки, еластичност и пр. и пр.. Много е модерно. Програмистите на Ruby, Python, C#, Java и пр. в момента са се запалили доста на тази тема. Ако трябва да обобщя искате да направите механизъм за интеграция в рамките на една инфраструктура (поне от това, което видях). Предвиждате ли използване на координиращ сървър? А динамични изменения във формата на съобщенията? Определено сте се заели с нещо доста мащабно. Надявам се, че не мислите да се ограничите само и единствено до т.н. "облачни технологии". Имам и един въпрос, който (извинете ме за невежеството), за мен остава открит. Какво би следвало да разбираме под "завидна скорост"? В смисъл скорост спрямо какво? Какво измерваме? Производителност? Скорост на обмен при равни други условия? Скорост на запис, при равни други условия? Скорост на обработка на динамични масиви? Скорост на обработка на статични масиви? Нещо друго? Моля Ви не се сърдете, но това са много различни неща и използваните методики са различни. Знам как се измерват параметри в Intel, Microsoft, IBM и на други места, но там си има ясно разписани правила и е ясно какво мерим (има цяла наука "Метрология"). Ако трябва да бъда съвсем откровен от няколко години, в средите, в които работя се избягва да се обсъждат въпроси, свързани с производителността, защото факторите, които влияят на този процес са повече, отколкото може да анализираме (а напоследък се появяват все нови и нови). Признавам, че очаквах да видя някакво малко, завършено крайно приложение, което да мога да си изтегля и да тествам, но това, което ми се предствавя е твърде мащабно за мен. Възможно е да нямам нужните познания и опит за да го оценя. Благодаря Ви за отговора. Ще следя това, което правите. Но все пак мисля, че едва ли ще може да се справите без фундаментална наука. Това, с което сте се заели е изключително мащабно и сложно. Прознавам, че е достойно за уважение. Вярвам, че ще се справите, но ще Ви отнеме много време. Наистина това не е нещо, което може да се направи за ден-два. С най-добри пожелания ...
  6. Здравейте Eiki, Ако ми позволите няколко малки, но важни корекции. Ще започна с нещо, което категорично не мога да приема, защото по тази логика би следвало да правим сравнение между диня и круша, което (моля да ме извините) е абсолютно некоректно, от гледна точка на ботаниката, като сериозна наука. Като начало за "аспектно ориентирано програмиране". Извинете ме, но за първи път за това "чудо" се чу от Грегор Качалес (Gregor Kiczales - Xerox Palo Alto Research Center или накратко PARC) през 2001 година. Каквото и да си говорим Delphi е език за приложения от клас A и АА+ от 1986 година и го дължим на Лоурънс Гордън Теслър. Вярно е, че и той е работил в Xerox PARC, но ..... Точно на Теслър дължим такива неща като Apple (да не забравяме, че Object Pascal е и ще си остане основен стандарт най-вече за Apple), Amazon, Yahoo и някои други неща. Аспектно ориентираното програмиране имаше една основна задача: да разреши проблемите на Java с многопоточността и управлението на транзакциите. Моля да бъда извинен, но advice е нещо обвързано с начина, по който се оформя кода, а не някакъв фундаментален принцип. Да не споменавам какво е join point и за какво служи. Само не ми казвайте колко е елементарно да се разбере фундаменталната същност на Meta Object протокола. . . . Хайде сега да поговорим за generic (или както е правилно да се нарича "обобщение"). Извинявайте, но Стефан Гленке (Stefan Glиenke) пише за често срещана грешка на програмистите. Да. Той използва специфичен английски жаргон, но ... Дяволът е в детайлите. Това е проблем, който се появява, когато C логика се прилага към Object Pascal. Нали не вярвате, че ако сипя бензин в резервоара на автомобил с дизелов двигател той ще работи нормално? ТList съхранява списък с указатели, а не данни! Сега внимавайте много добре: type TObjectList<T: class> = class(TList<TObject>, IList<T>) // ... end; Не виждате ли грешката? Тя е просто фрапираща. Извинете, но подобни "декларации", са доста съмнителни. TList и TObjectList са подредени списъци (виж Generics.Collections документацията) Погледнете декларацията. Внимателно. Много внимателно. Без емоции и предразсъдъци. Ето пример, за правилно деклариране: type TОbjectList<T> = record .... ... end; Ако използвате тази декларация и сравните изпълнимите кодове ще останете много приятно изненадан. Моля Ви нека да бъдем коректни. Ако пуснете 480 V променливо напражение на 24 V правотоково захранване то ще изгори. Тук Delphi няма никаква вина. . . . Сега за паралелното програмиране ... Тук ме изненадахте много приятно, защото цитирате любим ресурс. Мога да Ви кажа, че като регистриран Microsoft разработчик (и Microsoft Partner) знам, че каквото и да си говорим всички онези неща свързани със синхронизацията като lock, mutex и пр. не само че никой не е отменял, а и без тях определено няма да ни е никак лесно. Има и друг важен аспект, с който колегите многократно сме обсъждали на работни семинари и не само. Task Parallel Library е елемент на System.Threading.Tasks. Мисля, че е излишно да упоменавам, че реално се извършва насочване на последователни процеси към различните ядра. Да. Това определено е паралелно програмиране, но е по-скоро междинно решение и предстои още много работа. Ето един красив пример на мой колега, по темата: using System; using System.Threading.Tasks; namespace HelloApp { class Program { static void Main(string[] args) { Task task1 = new Task(() => Console.WriteLine("Task1 is executed")); task1.Start(); Task task2 = Task.Factory.StartNew(() => Console.WriteLine("Task2 is executed")); Task task3 = Task.Run(() => Console.WriteLine("Task3 is executed")); Console.ReadLine(); } } } И сега ако ми позволите, последна но ... много сериозна забележка. PHP и Java Script са скриптови езици, но моля Ви недейте да правите обобщения. Тези езици имат своето място (както и VB) и то е много важно. Тук има прекрасни програмисти на PHP и чз ги уважавам, заради това, което правят. В този ред на мисли ... Имам една голяма молба към Вас. Бихте ли били така добър да ни посочите някои Ваши разработки? В смисъл приложения, които Вие сте направили и реализирали. Ще Ви бъда много признателен. Благодаря Ви.
  7. Как би следвало да изглежда един Black List? Какво е нужно да съдържа? # This translates the names the spam lists spam domains lists # the DNS domains search. # There a far more comprehensive list these # http://www.declude.com/JunkMail/Support/ip4r.htm # you can easily search them www.DNSstuff.com. # you want search other DNSBLll have buy a contract before # attempting the lines. MAPS-RBL blackholes.mail-abuse.org. MAPS-DUL dialups.mail-abuse.org. MAPS-RSS relays.mail-abuse.org. # This line works JANET UK Academic sites MAPS-RBL+ rbl-plus.mail-abuse.ja.net. # build a similar list the RBL domains that the name # the domain rather than the IP address the exact machine that # listed. This way the RBL controllers can blacklist entire # domains very quickly easily. # These arent these more Easynet-DNSBL blackholes.easynet.nl. Easynet-Proxies proxies.blackholes.easynet.nl. Easynet-Dynablock dynablock.easynet.nl. # This list now dead must be used. #OSIRUSOFT-SPEWS spews.relays.osirusoft.com. # These folks are still going strong #SORBS-DNSBL dnsbl.sorbs.net. #SORBS-HTTP http.dnsbl.sorbs.net. #SORBS-SOCKS socks.dnsbl.sorbs.net. #SORBS-MISC misc.dnsbl.sorbs.net. #SORBS-SMTP smtp.dnsbl.sorbs.net. #SORBS-WEB web.dnsbl.sorbs.net. #SORBS-SPAM spam.dnsbl.sorbs.net. #SORBS-BLOCK block.dnsbl.sorbs.net. #SORBS-ZOMBIE zombie.dnsbl.sorbs.net. #SORBS-DUL dul.dnsbl.sorbs.net. #SORBS-RHSBL rhsbl.sorbs.net. # These are entries s #SORBS-BADCONF badconf.rhsbl.sorbs.net. #SORBS-NOMAIL nomail.rhsbl.sorbs.net. # other good lists CBL cbl.abuseat.org. RSL relays.visi.com. DSBL list.dsbl.org. BLITZEDALL opm.blitzed.org. Благодаря на колегите за предоставената информация. 🙂 И .. Някъде в този форум бях писал за агрегаторите на даннии как се ползват. 🙂
  8. За да се получи Apple ID (потребителски акаунт в Apple) са нужни две неща: Регистрирана и достъпна електронна поща; Навършени 18 години (за граждани на Република България). За какво реално трябва това? Преди всичко за достъп до iTune и други ресурси. Ако сте разработчик ще се наложи да заплатите 99 USD за регистрация. Ето адрес, на който има много изчерпателни сведения по така поставения въпрос: https://www.online852.com/free-apple-id Най-лесно и НАПЪЛНО ЗАКОННО, това се прави на следния адрес: https://appleid.apple.com/#!&page=signin Кликвате на Create Your Apple ID и след това просто попълвате изискуемата информация. Все пак се регистрирате като ПОТРЕБИТЕЛ, а не като разработчик.
  9. Каква снимка? За JPEG се прави по един начин. За всички други формати е доста различно. Имай в предвид, че не можеш да криеш кой знае колко голям код, защото ще стане лесно за прохващане. Има и още. Какво ще криптираш? Ако е скрипт ... Каква е кодовата таблица? 7 bit? 8Bit? Или UTF? Шифроването е лесно, но дешифрирането .. може да се изненадаш доста неприятно. Пак казвам, че тук съм писал много по темата, а и има безплатна програма, в която има маса шифри и можеш да тестваш. Ето ти нещпо 100% free. Има мошен модул за тестване на различни решения за шфроване. Дерзай. https://www.microsoft.com/store/apps/9PKC8NPBKNBL Това е за Windows 10. Имаш всичко за шифроване по стандартните начини. Първо се запознай с тях. За стеганографията темата е доста серизона. Ще видя какво мога да направя.
  10. Все пак аз да си попитам: Искаме да криптираме? Искаме да скриеме? Искаме да криптираме и да скриеме? Защото това са си три различни неща. Възможно е да скриеме нещо, което е криптирано и като го изведем от контейнера, в който се крие да не става за нищо. D3k4z, това което обсъждаме тук има много общо с другото обсъждане. Пак опираме до контейнери, памет, въвеждане, извеждане и пр.. И защо младите все бела искат да направят? Защо не вземат да направят програмка за обмен на розоводупести амурчета, примерно?
  11. Николчев, Ти ако на приятелката си нямаш вяра, не знам на кого имаш. Ти тази, коятоо наричаш своя приятелка искаш да издъниш, а акакво ни дава гаранция, че утре или вдругиден нас, скромните труженици, няма да издъниш пред официалните институции (я виж с НАП какво стана). Ще ни посочиш с пръст и ще кажеш: Тези ме научиха как през рутера да вляза в компа на кифлата! Те са! Ще ни заклеймиш, значи, като един същий Юда Искариот и ще ни създадеш проблеми (не че и сега си нямаме). То по-добре вместо да се занимаваш с глупости вземи та попрочети какво е това рутер, как рутера работи, какво е TCP/IP и ползва ли го приятелката ти. Четене му е майката и тогава ще да получиш прозрение свише. A Windows-а, приятелю не е какъвто беше, Захитряха гадовете и направиха живота ни тежък. Има и едни отчети, дето казват кой кога къде е влизал и какво е търсил, а я си представи, че приятелката ти вземе та разбере за тях? Знаеш ли ти, млади момко, какво е семеен скандал и на какво е способна една жена, ако разбере, че се съмняваш в нея? С жена на глава се не излиза. Само не се занимавай с жени, защото жените, колите и парите само проблеми създават и от тях иде човешкото страдание. Послушай стареца и наблегни на учебниците.
  12. Здравейте, Ако наистина искате да направите нещо сериозно е добре преди това да се запознаете със стеганографията и как тя функционира. Това, което познавате като Windows 10, няма нищо общо с професионалните версии, а още по-малко с това, което се тества в момента. Дори да направите едно сравнително добро решение, то ще има кратък живот. Това се нарича "процедура на обезсмисляне на атаката". Идеята е следната: Вие желаете да имплементирате зловреден софтуер. За да направите това е нужно да използвате времеви ресур, а също така ще имате и редица амортизационни и експлотационни разходи. Ако динамиката на една система е такава, че изисква ревърс инженерингът да се извършва през много кратки периоди от време, това ще струва по-скъпо от самата система. Яко, а? Съвсем друг въпрос е как системата разпознава дали един код е вирус или не е? Ако бяхте регистриран MIcrosoft разработчик и се бяхте запознали с документацията, кото се предосртавя напълно безплатно (повече от двадесет години Windows е с напълно отворен код, за разлика от Linux, който грижливо крие ядрото си), нямаше как да не знаете, че реално проверката се извършва въз основа на анализ на символни низове. Има и още нещо ... Всички съвременни вируси, които познавате са автоматично генерирани. Софтуерното решение за това бе разработено много отдавна от един колега, който е арменец, но успешно се прилага и до днес (за справка дори Duqu - https://en.wikipedia.org/wiki/Duqu ) бе направен по този начин, независимо от глупостите, които после бяха изписани. Блаженнио са невежите защото тях им се въздава с фурнаджийската лопата. Тази "машина за вируси" все още е достъпна в мрежата и с нейна помощ буквално се правят чудеса (не в Dark Net, a в светлата и изпълнена с ровозодупести херовимчета мрежа). Проблемът при нея (а и при всички вируси) е че те се правят от хора, а това предполага субективизъм (колко научно звучи само, а). Всеки прави нещата според собствените си познания и опит. Хубавото обаче е, че познанията и опита масово се свеждат до програмни езици, базирани на c логика и синтаксис, с всички произтичащи от това последствия (дано дълго да остане така, че конкуренцията е страшно нещо, а монопоът си е жива благодат). Още по-голяма грешкка е, когато някой реши, че ако направи нещо на assembler то ще е с пъти по-ефективно и незабележимо. Много млади програмисти са свършили професионалния си път, благодарение на тази велика заблуда. Когато някой иска да разбере "как да се промъкне по терлици в някоя ОС", е добре първо да се заеме със стеганографията или "прикриването на една информация в друга". Тук имаме различни подходи. Информацията обикновенно се крие в контейнер. Според един колега "контейнерите" биват 20, 40 и 50 футови, но той се занимава с логистика и не пие ракия. Има обаче и друго мнение, към което ние ще се придържаме. Контейнерите могат да бъдат аудио или видеофайлове, текстови файлове (текстова стеганография, която ми е любима, най-вече при т.н. "системи с отворен код", които никой не проверява), използване на цифрови изображения (не само в meta данните, а направо в пикселите на BMP, PNG, GIF и каквото там се сетиш ), пакетна стеганография (инжектиране на зловреден код в TCP/IP пакетите) и пр. и пр.. Хубаво, обаче тези, които противодействат на подобни "решения", не са глупаци и определено се радват на астрономически бюджети (само в САЩ има над три института, всеки един с бюджет, колкото този на България). А ние сме бедни и както се знае хлябът срува скъпо. Та колегите там знаят какво е анализ по празен контейнер, анализ на деформиран контейнер, сравнителен анализ и пр. и пр. и пр.. И една много интересна матиматика знаят гадовете, дето не се учи в университетите. И други неща знаят, то и за това им плащат заплати. Но ... Всеки един себеуважаващ се аналитик (така наричам хакерите) ползва собствена електронна поща, която когато получи цифрово изображение (примерно) не го отваря директно (както правят пощите на лузърите), а предвидливо го мащабира, ротира и пр, про запазване на качеството та да може де що е гадост вътре да бъде изцедена до капка. Това аналитиците са го възприели от онези в институтите. Това го нарича "да ручнеш контейнера". Тези гадове нямат вярва на дефендери, защити и антивирусни, което обаче не им пречи да ги ползват. Ние винаги трябва да се учим от онези, които знаят и могат пповече от нас самите. Ако проявяваш интерес по темата не е зле да се заемеш със задълбочено изучаване на Exchangeable Image File Format (EXIF) и какви прекраснио възможности предоставя това изчадие адово (родено от алчността на маркетолозите) на всеки, който иска да остане незабелязан. Благодарение на EXIF чудеса ще постигнеш по пътя, който си поел, но ... това е само началото. Все пак първо не е зле да се опоотърсиш от редица заблуди, като тази че JPEG е формат на графично изображение, а не начин за компресиране на графична информация, предоставящ ни огромни възможности да се надсмиваме на човешкото невежество. След като преминеш през това начално обучение е време да изучиш що е това аудио и как се ползва целесъобразно за пренос не само на звук. Там ще добиеш сили и самочувствие, но ... Най-важно е да се научиш как да имплементираш код в текстови файлове. Това вече е от сферата на черната магия. При имплементирането на текст в текст никога не бива да забравяш за размера на файла. Когато достигнеш до висините, да направиш проверка като набереш съобщението с обикновен текстови редактор и файла ти е със същата дължина като "обработения" може да ни се обадиш за да те приемем в групата на тези, които пият ракия и не се бръснат редовно. Там ще да те научим що е това пакетна обработка и колко е хубаво да се познават основите на информатиката и числените методи. И тогава ... Няма да има ОС, която да ти се опре. Нека силата бъде с теб. Дерзай и не забравяй, че никога не бива да правиш глупости, защото НПК е нещо сериозно и към него трябва да изпитваме боязън и преклонение.
  13. Само да вметна, Така посочената методика обективно погледнато е "измама", а не процес,при който се постига контрол над профила, в резултат на задълбочено познаване на internet технологиите. Този метод залага на първосигнална реакция. Потребителят САМ предоставя нужната информация, защото е подвведен. Тук става дума по-скоро за психологическа реакция, отколкото за техническо решение.
  14. Само ако ми позволите да вметна. Напълно подкрепям freeman987 за това, което е написал. Ако достъпваш структурата на базата е без значение дали е пълна или празна. Пак повтарям, че тези приложения реализират достъпа на физическо, а не на логическо ниво. Различно е. Ако някой не вярва в това, което пиша да пробва какво се случва когато се ползва FDPhusOracleLink и стандартен Connection на FD. Колкото и да е защитена ORACLE базата, всички записи (records) и полета (fields) стават напълно достъпни за всякакъв род манипулации и дори не се налага да се пише SQL. FDBachMove и всичко отива където му се посочи без един ред код. Забавното e в друг интересен аспект ... Масовата практика е да се използва Apach и естествено Linux, с всички произтичащи от това последици. Когато някой е направил нещо не се знае какво и как точно го е направил. Пример: Де що е Python програмист масово ползва cached-property. Да, но cached-property е изключително опасен код, който може да нанесе щети съизмерими само и единствено с вирус.. Причината за това е, че на практика този код е в състояние да унищожи вътрешното състояние на обекта. Приемам, че @reif позволява да се създаде кеш и че така написаният код изглежда "елегантно", но не го препоръчвам. Ако държите чак толкова да ползвате Python е по-добре да създавате кеш, по добре познатия начин, като използвате dict или друг доказан способ. Истината е, че проблемите с @reif са много стари. Те се знаеха още от времето на проекта Pyramid, но тогава си го знаехме като reify. Трие бази данни на случаен принцип като ламя. Знам, че някой ще каже, че примера няма нищо общо с SQL. Истината е, че има. Има защото и в Linux и в Apach и в SQL и в HTML има куп проблеми и те се дължат на това, че всички те са просто копирани елементи на много по-големи проекти. Да, но едно парче от счупена чаша не прави цяла чаша. Та тези приложения работят само защото има такъв вид слабост, която в програмирането се нарича "политическа грешка". Но .. да се върнем на темата. Подобен род програми (за копиране на съдържание) са безсилни срещу стандартно IntraWeb приложение. Когато се сблъскат с нещо подобно, резултатът е нулев. IntaWeb има своя логика. Тези приложения работят тогава и само тогава, когато web-ресурсите и съпътстващите ги скрипрове са изнесени файлове. Ако обаче този, който е разработвал сървърното решение е решил, че е много по-добре да използва PageProducer или TableProduser, те са неизползваеми. Можете да направите много елементарен експеримент, ако се опитате да свалите нещо от REST-сървър, който ползва PageProducer за всичко, което се достъпва по HTML. На практика ще свали резултатната странница, която няма нищо общо с реалния код. Няма да може и да свали базата, защото просто няма как да получи физически достъп. Проверено. Съвсем друг е проблемът, когато за достъп до СУБД се ползва NetBEUI или SPX. Направих проверка и за двата протокола. Получиха се доста забавни резултати. Между впрочем това дава интересни теми за размисъл.
  15. Цитирам: " ... Интересно ми е как се предобива root достъп през Linux/ADB без да имам директен достъп до телефона." Ако правилно съм те разбрал искаш да получиш административен достъп до ФАЙЛОВАТА СИСТЕМА НА мобилен апарат, но без той да е достъпен физически. Повече от ясно е, че това, което искаш е да получиш ПЪЛЕН ДОСТЪП до МОБИЛЕН ТЕЛЕФОН, като използваш БЕЗЖИЧНИ СРЕДСТВА ЗА КОМУНИКАЦИЯ. При това предполагам, че искаш ДА ИЗБЕГНЕШ ИНСТАЛИРАНЕТО НА КРАЙНО ПРИЛОЖЕНИЕ НА АПАРАТА. Въпросът е как ще се реализира свързването? През 3 или 4 G мрежа? През 5 G мрежа? През WiFi? През Bluetooth (PAN). Това са три различни технологии и съответно програмната реализация се извършва по три различни начина. Да не говорим че при последните две имаме ограничения в дестанцията и екраниращите прегради. Признавам, чистосърдечно, че нямам и най-малка представа как това се прави в Linux. Сигурно има решения, но лично аз не ги познавам. Аз съм стар параноик и не искам да имам проблеми от правно естество. За Windows има три варианта както следва: - Ползваш OneNet или Indy в комбинация с IOUtils (горещо препоръчвам второто решение) за 3G, 4G и 5G технологиите. Нали знаеш как функционира SMS? - За WiFi се ползва модифициран BaaS (да не се бърка с BASS, защото ще стане забавно), а там нямаш никакви проблеми не само за Android, но и за iOS. - За Bluetooth се работи с Tethering, но все пак е добре да знаеш, че ще трябва да си поне на десет метра от телефона и да имаш пряка видимост, макар ... като се замисля, ако знаеш кое как същото решение може да ползваш и за 4G мрежите, но там има специфика. Пак повтарям, че нямам и най-малка представа кое приложение какво прави, но знам кое как се прави. По принцип Android не е нищо повече от деформиран Linux, с всички произтичащи от това последици. Не случайно всеки ден текат актуализации към нещастните потребители. Root базираните OS са си като холандско сирене (лично мнение, но за справка попитай някой от колегите, които ще плащат солени глоби по GDPR). И ... не ми се сърди, но подобни решения някой рядко прави за личния си телефон. Прието е да се включва през USB към работната станция. Това е кабелна връзка. Лично аз така си правя приложенията за Android. Много по-евтино ми излиза, отколкото да минавам през A1, за да ги компилирам и да си правя тестовете. Да не споменавам, че е доста по-бързо. Виж, ако искаш да печелиш пари от Android, като ползваш безжични комуникации, на това мога да те науча. Като начало можeш да се запознаеш с това, което се нарича ТЕХНИЧЕСКА ДОКУМЕНТАЦИЯ: https://developer.android.com/reference/android/net/wifi/package-summary.html Техническата документация е, била е и ще си остане най-полезното четиво. Та в този ред на мисли, предполагам, че знаеш какво е ВЪНЩЕН ДИСК. Представи си, че ВЪНШНИЯТ ДИСК, го включваме не посредством кабел, а посредством WiFi. Ако си включвал мобилен апарат към работна станция на Windows (което може и да не изисква кабел), операционната система най-учитово те пита: "Алооооо. Този. На теб говоря. Да, бе. Ти дето си зада клавиатурата. Това дето го включи за какво ще го ползваш, бе? Снимки ли ще точиш, файлове ли ще обменяш или ще да ръчкаш вътре, заради спорта?" В Windows си пита. За Linux, може и да си мълчи злобно и да се подсмихва. Но по-хубаво е да си направиш нещо твое си. Лично. Добре е като начало да ползва WiFi, за да си го тестваш от съседната стая и да не си зависим от разни оператори, а най-забавно е да видиш как работи като извадиш SIM-картата. Та като пуснеш някое свое приложения използващо WiFi (примерно) и го направиш в пазарен вид (може да добавиш някоя благина), ще те науча как да го продаваш в GooglePlay. Така вместо да се занимаваш с неща, които могат да създадат само проблеми ще се научиш да припечелваш. Много е различно. Съжелявам, че не мога да помогна, но искам много да ти благодаря. Във въпроса си си описал една много интересна идея, която е свързана с реализация на internet радио, но на съвсем различен принцип. Не знам дали си даваш сметка, до какво си се докоснал , но въпросът не е в това да се получи достъп до файловата система. Много по-интересно е да накараме спикера да възпроизвежда audio без да ползваме браузъри или клиентски приложения, като при това апаратът може и да не е включен, но акумулаторната му батерия да е заредена (да си гледал последния филм за Борн). На практика телефонът на клиентите се превръща в радиоприемник, който възпроизвежда това, което искаме. Не, което иска клиента, а това, което на нас лично ни харесва! Това се нарича "система за ранно оповестяване" и повярвай е повече от златна мина. Диамантена е. Е, ... ако се направи за аудио, колко му е за видео. Така де.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.