Reyn1984, в общем случае, скорее всего, ничего не получится. Ключом может выступать, например, серийник устройства или комбинация серийника и вон тех 10 байт по смещению в неочевидном месте недоступной части EEPROM плюс XOR с секретной строкой. Поэтому без устройства ключ не получишь, да и механизм его получения загрузчиком устройства может быть эзотерический.
Владислав Калужский, это нормально, я сам её никогда не читал. У нас были в университете практические занятия, где мы реализовывали какие-то методы сортировки (каждому студенту давали свой вариант), свои файловые системы (мне досталось на инодах с древовидной системой блоков), интерполяция функции одной и двух переменных, поиск собственных значений матрицы, QR/LU-разложения и всякое такое... Какие-то преподаватели давали основы TeX или сетевого взаимодествия (типа "напиши игру быки и коровы по сети"). Обучались на конкретных задачах, нередко математического содержания (по нашему основному профилю).
Олимпиадные задачки, интерфейсы, несложные игрушки, приложения для решения каких-нибудь несложных задач (ежедневник, музыкальный плеер итд итп) - этого за глаза хватит на текущем этапе. Не нужно браться за книги слишком высокого уровня.
В любой кникже по алгоритмам обязательно используются символика ассимптотики (типа O(n)), это в школе вообще никогда не проходят, кроме возможно очень крутых школ с математическим уклоном. Подобную терминологию и сопутствующую теорию надо изучать или в рамках полноценной программы высшего образования (то есть пойти в институт учиться), или осваивать самостоятельно. Но на начальном этапе это не нужно. Как-то решил задачу - уже хорошо.
Андрей Ширяев, на Android можно поменять в специальном файле только на рутованном устройстве. И то это не очень тривиально (там по-моему PDU в sqlite хранится).
Но реально, зачем это всё? Если обмануть суд - это вряд ли выйдет. Есть содержание SMS очень важно, то не будут полагаться на то, что видно на телефоне, а реально запросят оператора, который обязан всё и вся хранить три года. Если же задача другая - то расскажи, какая именно. Сейчас это очень смахивает на XY problem: вместо реальной задачи задаётся вопрос о своих попытках её решить каким-то весьма вероятно кривым способом.
oslik_ppc, вообще говоря, может быть не очень ок. Если код прям дублируется, то его лучше оформить как совместно используемый общий модуль. Но это, как обычно, не должно становиться самоцелью. Например, если у нас есть какая-то несложная функция на 10 строчек, которая тонет в 20 тыс. строчек непересекающегося кода обоих проектов, то усилия по выделению этого незначительного общего кода в отдельный репозиторий, подключаемый к этим проектам, могут быть совершенно неоправданы.
С другой стороны, наличие такого совпадающего микрокусочка кода может быть признаком либо того, что проекты принципиально разные и несвязанные между собой, либо что в них одни и те же вещи сделаны принципиально по-разному. И это может быть признаком архитектурно неудачных решений.
Например, в одном компоненте наворочено ORM, а в другом идёт работа многочисленными прямыми запросами к той же самой базе данных. Кода общего нет, но по факту есть две реализации работы с одной и той же базой. И внутри получаются почти такие же запросы, но разными способами и с излишним дублированием кода.
Или в одном компоненте всё построено на асинхронных вызовал async/await, а в другом - на синхронных задачах в тредпуле с коллбэками. То есть два архитектурных подхода, которые в итоге могут решать одни и те же задачи. Причём не всегда можно одно заменить другим. Например, если у нас в одном компоненте используется глубоко синхронная библиотека, то его может быть слишком сложно переделать на асинхронщину. Это, кстати, обычное узкое место рефакторинга: есть куча кода, который уже работает, но его архитектура не позволяет куски старого кода легко интегрировать в новую архитектуру.
Я раньше работал в организации, где делали собственную систему для решения различных задач, она была написана на php и восходила к разработке студента, который в начале нулевых писал код вообще без функций :) По мере усложнения было много боли по переделыванию этого всего на Zend Framework, классы, MVC и всё такое. И там прогеры как-то прилично усилий потратили, чтобы научиться корректно и без побочных эффектов вызывать из старого кода новый и наоборот, чтобы можно было рефакторить по частям, а не писать полностью идентичный аналог параллельно с поддержкой существующего.
Но если это собственный мелкий проект, затеваемый с нуля, то можно просто волевым решением выбирать изначальное единообразие, чтобы не создавать себе причин излишне страдать в будущем. Сразу стремиться к одинаковой работе с данными через единый модуль с ORM.
duo456, использование соли нужно не для ломания расшифровываемости, а для того, чтобы данные нельзя было подобрать по готовым таблицам.
Как это работает на простейшем примере хеширования паролей: пусть у нас используется MD5, тогда MD5("123")=202cb962ac59075b964b07152d234b70, и если у нас из миллиона пользователей 10 имеют пароль 123, то в базе будет 10 хешей с таким значением, которые легко найдутся по радужным таблицам. Но если каждый пароль будет посолен, то хеши станут разными. Например, MD5("nk4Wu3XUbNvf123")=3f39c284a3b16263ebcc50ada7148d3e и уже потребуются радужные таблицы намного большего объёма. Причём даже знание хеша+соль не поможет упростить задачу подбора.
Конкретно к шифровке-расшифровке. Мы добавляем случайную соль в исходный текст по каким-то конкретным, чтобы было понятно, где она заканчивается и как её выкинуть в итоге. Например, "соль:текст" или json'чиком {"text":"текст","salt":"соль"}. Если соль каждый раз будет случайной, то в результате расшифровки мы получаем текст с солью, которую можно выкинуть (она не имеет смысла, просто добавляется для увеличения энтропии шифротекста) и получить исходный текст. Но шифротекст при этом кардинально меняется.
Это может быть особенно ценно в протоколах, в которых передаются данные, принципиально допускающие повторения. Например, если передаются показания датчиков, то они ж могут повторяться.
Александр, у меня есть планшет Samsung 2014 года и на него довольно долго больше 4.4 нельзя было поставить. Недавно я его достал из шкафа и решил попробовать оживить. Оказалось, для него таки производитель выпустил Android 5 или 6, но на этом всё. Но умельцы делали сборку LineageOS даже на 10 андроиде, попрыгав с бубном и Heimdal, я смог это накатить, дополнить нормальным recovery, microg и всё такое. Но по отзывам пользователей эта сборка иногда ребутяется. И кажется у меня такое тоже было, видно, что пролежавший ночь планшет без запущенных накануне приложений.
Впрочем, как полноценный планшет я его всё равно не планировал использовать. Во-первых, он старый и не супер быстрый по современным меркам, хотя и не совсем тормознутый, тем более что это была не самая нищебродская модель на момент выпуска (думаю, планшет 11 года всё же будет помедленее). Во-вторых, у него сломана защёлка слота сим-карты (я пытался скотчем заклеивать, но он всё равно отваливается быстро под давлением пытающейся выпрыгнуть симки), так что стал он у меня Wi-Fi only. В-третьих, этот планшет в наше время больше ценен своим стилусом, так что его всё ещё можно использовать для рисования.
Так что отсутствие официальной поддержки новых андроидов - необязательно приговор. Надо искать, сделал ли кто работоспособную сборку. Конкретно этот мой планшет официально LineageOS не поддерживается, но вот энтузиасты сделали достаточно работоспособную сборку.
benzcrew, это новая фича, она введена в апреле 2023 как развитие switch_inline_query (которая работала только с текущим чатом). Надо смотреть, реализовали ли поддержку в библиотеках актуальных версий. Но это не добавление бота в чат, это inline mode: в строку ввода подставляется @имя_бота и произвольный текст, дальше пользователь уже сам решает, отправлять сообщение или нет. В общем-то, если используется именно эта фича, то это должен быть бот-помощник в написании сообщений.
oslik_ppc, да, примерно в таком направлении и надо мыслить. Условно, у нас есть универсальный уровень абстракции, который позволяет работать с данными и прозрачно отображать их в базу данных. И через эту прослойку работают все приложения нашего проекта. Так часто и делают.
Как правило (но это не всегда так) лучше использовать для данных общий код: модели, функции, параметры базы итд итп. Это упростит сопровождение кода, внесение изменений в структуру базы итд итп. Разные части проекта используют общий код, что уменьшает неоднозначности в поведении.
Да, это не надо воспринимать как категорическое требование. Например, если части проекта написаны на разных языках, то логично, если для них работа с базой написана на своих языках. Или если к компонентам разные требования, или они используют почти непересекающиеся части базы. Но в целом стоит очень хорошо подумать, зачем дробить работу с базой, ибо это банально неудобно и увеличивает риск ошибок и неоднозначностей.
anton1221, если у мошенников это налаженный на*бизнес, то у них может быть всё готово даже для того, чтобы украсть одну копейку в один клик. Более того, наоборот, воровать большие суммы опасно, а мелкие - больше шансов, что пользователь забьёт. Ссылаться на то, что раньше сервис ничего не воровал, достаточно бессмысленно, ведь это обязательств никаких не создаёт.
Но в данном случае явно проблема в симке. Другой вариант - угнали с одного из устройств файл сессии (поэтому в списке нет других залогиненных сессий).
Justa Gain, а тебе якобы можно под всеми вопросами писать что ТС дураки.
И ты посмотри, он всего лишь высказался, что на русских форумах вместо ответа на вопрос все норовят обсудить личность автора (это, конечно не всегда так, но излишняя любой части наших соотечественников к такому достаточно известна), на что ты прямо назвал его "личностью" в кавычках и начал неприкрыто наезжать. Он же даже слово "быдлан" применил по отношению к неопределённому кругу лиц, а ты - к нему персонально.
Как ни крути, а наиболее непорядочно и агрессивно в этой ситуации поступил именно ты.
Justa Gain, настоятельно рекомендую сменить тон комментариев, потому что рано или поздно модераторам надоест всего лишь удалять наиболее одиозные из твоих сообщений, и они могут перейти к более кардинальным мерам.
Да, тут часто пользователи не могут нормально сформулировать свои задачи, показывают непонимание элементарных вещей и всё такое, но как бы именно для такой категории пользователей сайт и предназначен в первую очередь. Унижать людей за то, что они не очень умные - это недопустимо.
