Интересно бы взглянуть на байт-код для dict и {}. Но наверняка там такая же история и dict вызывается как функция с kwarg, которые не требуют кавычек по своей природе.
При создании через {} ключом может быть и отличный от строки тип, поэтому автоматически конвертировать в неё нельзя.
В данном случае происходит ровно то, что и должно - вызов функции. И оптимизировать его будет некорректно, потому что никто не мешает написать list = tuple, например. Или свой супер-конструктор объекта, мимикрирующего под список. И интерпретатор байт-кода должен будет выполнить именно его, для чего внутри и нужно сделать честный вызов по имени.
У покемонов был другой блоб, ощутимо проще. А ингрессовский таки был разломан, и успешно эксплуатировался в определённых кругах до смерти апи старого сканера.
Старый клиент никак и не боролся с чтением траффика. Но вот подменить что-либо существенное в исходящих пакетах, не словив бан, было нельзя из-за шифованного блоба с «подписью» пакета, clientBlob. Вот разломать его на порядок сложнее, чем поставить доверенный серт и mitm-ать траффик.
Из раздела "Когда я получу Флиппер?" таки непонятно, когда же его можно получить. Есть какие-то верхние/нижние оценки? Если сборка планируется маленькими батчами, что будет с доставкой - в порядке кикстартерной очереди или тоже батчиться по регионам для оптимизации стоимости?
Play Store. Play Services. Некоторые игры в качестве одной из техник усложнения взлома. Наверняка некоторые банковские приложения также применяют пинниг.
Зачем защищаться от владельца устройства который поставил корневой сертификат?
А точно владелец поставил сертификат? А может, разработчик хочет больше уверенности, что запросы формирует именно оригинальное приложение? Разработчики не доверяют пользователю? Да быть такого не может.
У приличного софта сертификаты прибиты гвоздями, и клиент проверяет сертификат сервера по зашитому отпечатку. При mitm-атаке он будет отличаться, клиент разорвёт соединение.
Очень странно звучит «удалось получить Х строк исходного кода» в контексте реверс-инжиниринга. Их не получают, а пишут заново, опираясь на анализ бинарника. Лучшее, что можно «получить» — псевдокод, но в репозитории вполне себе аккуратный и структурированный код компонентов игры.
Про Hyper-Threading абзац во многом неверный. HT подразумевает одно АЛУ на 2 вируальных ядра, и в случае ошибок предсказания ветвления и прочего, что вызвало бы сброс конвейера и ожидание его заполнения, происходит переключение на второй набор регистров и исполнение инструкций с соседнего "ядра". Так что потоки на НТ ядре работают по очереди не "в худшем случае", а всегда.
Далее,
Организация планирования в … Windows является: приоритетной и вытесняющей.… А вытесняющей потому, что если возникает более приоритетный поток, он вытесняет тот, который сейчас исполнялся.
Это вообще неверно. Есть понятия вытесняющей и кооперативной многозадачности. В случае кооперативной, процессы (потоки) сами решают, когда отдать управление планировщику ОС для дальнейшей передачи другому процессу. (И если они плохо написаны или виснут, то могут не передать вовсе). А при вытесняющей многозадачности, планировщиком полностью рулит ОС, отбирая процессор у программ без их участия и согласия, "вытесняя" их. И возникновение новых потоков и их приоритеты с принципом работы такой многозадачности не связаны.
А когда-то Intel ведь продал своё ARM-подразделение, XScale.
SAR-ы у современных трубок гораздо меньше, чем в эпоху древних звонилок.
Интересно бы взглянуть на байт-код для dict и {}. Но наверняка там такая же история и dict вызывается как функция с kwarg, которые не требуют кавычек по своей природе.
При создании через {} ключом может быть и отличный от строки тип, поэтому автоматически конвертировать в неё нельзя.
В данном случае происходит ровно то, что и должно - вызов функции. И оптимизировать его будет некорректно, потому что никто не мешает написать list = tuple, например. Или свой супер-конструктор объекта, мимикрирующего под список. И интерпретатор байт-кода должен будет выполнить именно его, для чего внутри и нужно сделать честный вызов по имени.
Нормально, там ещё и stl-я с контейнерами в аппликейшенах достаточно
Есть ст. 1280 ГК РФ, в которой описаны кейсы, когда можно легально выполнять обратную разработку ПО. Кейс автора подтягивается под них.
Из раздела "Когда я получу Флиппер?" таки непонятно, когда же его можно получить. Есть какие-то верхние/нижние оценки? Если сборка планируется маленькими батчами, что будет с доставкой - в порядке кикстартерной очереди или тоже батчиться по регионам для оптимизации стоимости?
https://habr.com/ru/company/pixonic/blog/555364/
Есть CellMapper.
А точно владелец поставил сертификат? А может, разработчик хочет больше уверенности, что запросы формирует именно оригинальное приложение? Разработчики не доверяют пользователю? Да быть такого не может.
А зачем считать Фибоначчи в числах с плавающкй запятой? Ни точности, ни скорости.
Про Hyper-Threading абзац во многом неверный. HT подразумевает одно АЛУ на 2 вируальных ядра, и в случае ошибок предсказания ветвления и прочего, что вызвало бы сброс конвейера и ожидание его заполнения, происходит переключение на второй набор регистров и исполнение инструкций с соседнего "ядра". Так что потоки на НТ ядре работают по очереди не "в худшем случае", а всегда.
Далее,
Это вообще неверно. Есть понятия вытесняющей и кооперативной многозадачности. В случае кооперативной, процессы (потоки) сами решают, когда отдать управление планировщику ОС для дальнейшей передачи другому процессу. (И если они плохо написаны или виснут, то могут не передать вовсе). А при вытесняющей многозадачности, планировщиком полностью рулит ОС, отбирая процессор у программ без их участия и согласия, "вытесняя" их. И возникновение новых потоков и их приоритеты с принципом работы такой многозадачности не связаны.