Вообще то, единый jar файл можно создать практически в любом проекте с любым набором famework и библиотек (maven-assembly-plugin). Это такое же никакое отношение имеет к SpringBoot как логгер (который не имеет прямого отношения framework).
готовые конфигурации
Готовые конфигурации — это дело наживное. Когда много наработок в разных framwork, то они как бы уже есть.
Самое главное, из моего опыта, это отсутствие конфиликтов библиотек. Как только начинаешь делать что то более менее сложное (разные реализации Java EE в одной программе, например) — начинаются пляски с бубном (особенно когда нужно общий jar файл сделать).
Очень не однозначное впечатление от статьи.
Стиль вопросов/ответов как бы подразумевает запоминание без понимания.
Слова "магия spring boot" как раз из этого корня.
Не с конкретных "магических" свойств нужно начинать изучение. А из общего понимания.
Что Spring Boot это всего лишь довольно простое ядро (контенеры) и куча адаптированных для того что бы не конфиликтовали между собой "библиотек".
Которые никто не мешает использовать и в не Spring framework.
Один из ярких примеров — вопрос про логирование. SpringBoot? Представляю какая каша в голове возникнет у джунов.
Какие преимущества у Spring Boot?
IMHO: Основное преимущество — то что библиотеки между собой не так конфиликтуют, когда пытаешься эту солянку использовать отдельно (точнее меньше с этим проблем).
А пункт "Проект на Spring Boot может компилироваться в автономный JAR-файл" вообще удивил и заставил улыбнуться.
А ведь кто то заучивать будет это для собеседования...
Когда есть четкое понимание того, кто прислонился, есть записи с камер наблюдения с его лицом, с хронометражем,
В вагоне метро, например? Телефоны могут быть вообще физически на разных континентах быть (лишь бы IP пакеты не слишком долго ходили между)
А насколько типично с такой покупкой потом идти в метро в толпу?
Хм. У меня, как не пойду в Ашан или какой еще супермаркет, то меньше 1000 практически никогда не получается. И в очереди обычно стоят с тележками груженными.
Средний чек который я вижу в очереди — 3-4 тыс рублей. И у людей явно не последние деньги на продукты.
Но на практике как-то не наблюдается такой проблемы.
А кто его знает. Наблюдается или нет. Банки такую статистику не публикуют.
В общем, меня мало утешит, что я попал в редкий случай, если с моей карты стырят деньги таким способом. Тем более, что опротестовать не реально. По правилам ПС: вот карта, вот PIN. Не опротестовывается.
Весьма сомнительное, на мой взгляд, мероприятие выходит для злоумышленников — достаточно хлопотное, с неиллюзорными рисками и негарантированным результатом. Имхо, проще кошельки из карманов вытаскивать…
Человеку, который прислонился к кому то в метро — даже поймать за руку не получится. И предъявить нечего. Это же не кошелек из кармана потянул и за руку поймали.
Получается, что нужно подсмотреть пин (который при вводе в общем-то рекомендуется закрывать рукой — тогда микрокамера мало что увидит),
Специально наблюдал, стоя в очереди к банкомату, сколько человек прикрывают рукой/корпусом вид на PIN клавиатуру. Очень мало.
А уж сколько человек вводят PIN в магазине ничем не закрывая. (суммы в супермаркете > 1000 руб — это типично). Редкость когда кто то прикрывает.
Даже без камеры не напрягаясь фиксировал кто какой PIN ввел.
Android. Ровно с тех пор как Google отрыл API. Сразу и
Еще в 2014 году делал/отлаживал первый демонстрационный пример HCE приложения Visa (MC попозже спеки сделал).
см.
android.nfc.cardemulation.*
android.nfc.NfcAdapter
Кстати, нужны еще и ключи шифрования, да. Открытые ключи МПС.
Для целей описанных в статье — не нужны. Смысл такому ПО проверять RSA подписи?
У бесконтактной карты гораздо опасней другие вещи.
Вот когда мост для бесконтактной карты на двух телефонах (c NFC) позволял только делать без пиновые покупки в пределах 1000 руб — это было еще ничего..
Но вот когда Сбер ввел выдачу наличных по безконтакту!
Микро камера для подсмотреть PIN — элементарно. Прислонится к толпе, к кошельку жертвы одним из телефонов "моста" — да проще простого.
Не нужны никакие накладки и пр. Просто камера для подсмотреть за вводом PIN и два андройд телефона. Ну еще программки под андройд, которые валяются на GitHub выложенные такими же энтузиастами.
Хотя в программке обеспечивающей "мост" между двумя телефонами (один — ридер, другой эмулятор карты) ничего сложного нет, но ее и писать не нужно. Уже валяются, сделанные в "исследовательских целях".
Вот совсем не уверен, что ПО Сберовских банкоматов анализирует миллисекундные накладные задержки на выполнение команд карты (которые может вносить такой "мост").
Так, что паранойя носить карту в экранированном чехле — это не обязательно паранойя.
В ходе стажировки получилось создать новый инструмент для работы с бесконтактными банковскими картами
То что Вы рассказали, тем кто работает в теме и так известно. И набор утилит у тех кто с этим работает, как самописных, так и платных специализированных не мал.
Я понимаю, восторг "первооткрывателя", но стоило ли выкладывать на Github?
Дали инструмент школоте и кууул хацкерам делать гадости. Зря… на мой взгляд.
И, кстати, атаками это названо чересчур громко.
Да можно сделать мелкие гадости людям. Например соседу по школьной парте.
Особенно с блокировкой PIN.
Хотя PIN карты легко разблокировать выбрав смену PIN (увы, если поддерживает) банкомате (там on-line PIN + EMV скрипт). Но не все знают и для них будет неприятно когда карта перестанет работать в POS.
Блокировка по ATC — слишком долго карту нужно мучить (хотя… некоторые, не буду показывать пальцем, ставят в профили персонализации меньшее значение, чем 0xFFFF. Типа безопаснее для криптоанализа ключей карты).
Большинство из рассмотренных программ пытаются имитировать работу POS-терминала и используют словари с идентификаторами поддерживаемых карт, поэтому часто такие решения будут работать только с Visa и MasterCard.
Не просто так, кстати, PSE — опционально по EMV. И по факту, часто на картах остутствует.
Считанных данных хватит для привязки карты в некоторых онлайн-магазинах (в основном, в зарубежных), также полученную информацию можно использовать для более персонализированной атаки с применением социальной инженерии
CVV2 только графически персонализируется. Покажите, pls, один из "некоторых онлайн-магазинах" который не требует CVV2 и при этом не использует 3D.
Если после этого дайвер быстро поднимется на поверхность, то накопившийся под стеклом гелий может выдавить его, что опасно не только для часов, но и для водолаза.
Если дайвер поднимется настолько быстро, что часы без клапана не успеют стравить давление, то выдавливание стекла может обеспокоить только его наследников.
И не важно, на воздухе или на тримиксе он погружался.
Хотя наличие гелиевого клапана существенно повышает стоимость часов, это «усложнение» трудно назвать бесполезным.
Часы для дайвера на тримиксе внутри костюма!
Ну конечно можно умудрится натянуть сухой костюм не снимая наручных часов (поверх), если действовать аккуратно, что бы манжеты не порвать часами.
Но… это… странно. Как минимум.
Я бы поставил высшую строчку этому "усовершенствованию" в рейтинге самых бесполезных усовершенствований.
Странно, когда я делал свой 3D сканер https://habr.com/ru/post/412479/
то работа с камерой не показалась слишком сложной. Все логично и дает почти полный доступ. Да и примеров и документации просто масса.
Наверное, не хватает простой "кнопки счастье" "записать видео" в API. Но для этого проще поискать обертку вокруг фактически низкоуровневого (скорее средне..) управления камерой от Android.
Хотя, если честно, не понял зачем 2019 году очередная статья "как я разбирался с Camera2 API".
А теперь, если вам всё ещё интересно зачем мне потребовалось пилить свой пост на эту тему уже в 2019, то добро пожаловать под кат.
Аплодирую! Эта фраза заставила меня заглянуть внутрь.
Не автор статьи, но судя по фото это HSM от фирмы КриптоПро (совместимый с CPS от Крипто Про)
Сертифицированных поставщиков таких продуктов в России можно пересчитать по пальцем одной руки фрезировщика с большим опытом.
Мне всегда странно когда говорят, что новый язык увеличил скорость разработки в разы.
Может я чем то не тем занимаюсь. но 60..80% в разработке ПО времени это не кодирование как таковое.
А кодирование… пусть Java до 8 уступала Kotlin. Пусть текста кода поменьше получается.
Но сказать что в разы ускоряет кодирование — то же как то перебор.
В сущности какая разница на чем. Нормальные IDE — ускоряют.
Это шаблонный код, кочующий из проект в проект. И не так что бы сложный для понимания.
Если не интересует потребление, то можно вообще все модули включить.
Чем мне не нравится Arduino как концепция… Кто то дернул чью то библиотеку (зачастую корявую и на оптимизированную) и все. Эмбедет разработчик в резюме.
Сколько всего надо прописать в исходник чтоб заставить хотя бы помигать светодиодом на каком-нибудь STM32?
Немного… (инициализация шаблонно). Если через напрямую в стиле "записать в порт" то практически столько же как на AT DDRD |= _BV(PD0); PORTD &= ~_BV(PD0);
(что не очень хороший стиль. ибо код не переносим может оказаться)
За то проблемы "остается немного времени на анимацию на дисплее" не беспокоят.
И да. "Наверно, с них начинает почти любой embedded разработчик." не совсем правильное утверждение. Если, конечно, под "embedded разработчик" не понимать "я тут светодиодом помигал".
Документация от STM ничем не сложнее чем от Atmel.
очередном проекте, понадобилось мне определить кодировку текста, который возвращался в виде XML.
Если кто присылает байтовый набор данных который на самом деле win-1251, а в заголовке XML указана кодировка UTF-8, то я бы ему "мягко" попенял.
Ибо ошибка грубейшая. И чаше всего (на практики было) поправляют эту ошибку..
Почему то (не в обиду, но факт и моя личная статистика) такую ошибку допускают разработчики на PHP.
Типичная ошибка: XML с кодировкой UTF-8 в XML заголовке, без указания codepage в HTTP заголовках c фактическим Win-1251 в HTTP body.
Это я к тому, что определять по косвенным признакам кодировку — закладывать мину замедленного действия.
А по моему, на малине, гораздо удобнее сочетание "C/C++" библиотек и python.
Опять же, gcc есть и кросс. Писать С++ код внутри малины и там же компилировать… Можно. Но для чего то мелкого. Иначе мазохизм.
Спасибо. Понятно.
А то смутило упоминание контекста PCI DSS (требования Visa & MC к ТСП и процессингам), касающиеся в основном хранению и использованию платежных/карточных данных (ключи,HSM,PIN блоки, треки и прочее) к обычному универсальному облачному сервису.
Хотя, любопытно как это выглядит… Организация конечная (банк/эквайрер/процессинг..) проходит сертификацию для Visa & MC по PCI DSS. Как помогает сертфикат выданный "облаку" сертификации этой организации?
"Как" — в смысле, как это выглядит процедурно.
Вообще то, единый jar файл можно создать практически в любом проекте с любым набором famework и библиотек (maven-assembly-plugin). Это такое же никакое отношение имеет к SpringBoot как логгер (который не имеет прямого отношения framework).
Готовые конфигурации — это дело наживное. Когда много наработок в разных framwork, то они как бы уже есть.
Самое главное, из моего опыта, это отсутствие конфиликтов библиотек. Как только начинаешь делать что то более менее сложное (разные реализации Java EE в одной программе, например) — начинаются пляски с бубном (особенно когда нужно общий jar файл сделать).
Очень не однозначное впечатление от статьи.
Стиль вопросов/ответов как бы подразумевает запоминание без понимания.
Слова "магия spring boot" как раз из этого корня.
Не с конкретных "магических" свойств нужно начинать изучение. А из общего понимания.
Что Spring Boot это всего лишь довольно простое ядро (контенеры) и куча адаптированных для того что бы не конфиликтовали между собой "библиотек".
Которые никто не мешает использовать и в не Spring framework.
Один из ярких примеров — вопрос про логирование. SpringBoot? Представляю какая каша в голове возникнет у джунов.
IMHO: Основное преимущество — то что библиотеки между собой не так конфиликтуют, когда пытаешься эту солянку использовать отдельно (точнее меньше с этим проблем).
А пункт "Проект на Spring Boot может компилироваться в автономный JAR-файл" вообще удивил и заставил улыбнуться.
А ведь кто то заучивать будет это для собеседования...
В вагоне метро, например? Телефоны могут быть вообще физически на разных континентах быть (лишь бы IP пакеты не слишком долго ходили между)
Хм. У меня, как не пойду в Ашан или какой еще супермаркет, то меньше 1000 практически никогда не получается. И в очереди обычно стоят с тележками груженными.
Средний чек который я вижу в очереди — 3-4 тыс рублей. И у людей явно не последние деньги на продукты.
А кто его знает. Наблюдается или нет. Банки такую статистику не публикуют.
В общем, меня мало утешит, что я попал в редкий случай, если с моей карты стырят деньги таким способом. Тем более, что опротестовать не реально. По правилам ПС: вот карта, вот PIN. Не опротестовывается.
Человеку, который прислонился к кому то в метро — даже поймать за руку не получится. И предъявить нечего. Это же не кошелек из кармана потянул и за руку поймали.
Специально наблюдал, стоя в очереди к банкомату, сколько человек прикрывают рукой/корпусом вид на PIN клавиатуру. Очень мало.
А уж сколько человек вводят PIN в магазине ничем не закрывая. (суммы в супермаркете > 1000 руб — это типично). Редкость когда кто то прикрывает.
Даже без камеры не напрягаясь фиксировал кто какой PIN ввел.
Android. Ровно с тех пор как Google отрыл API. Сразу и
Еще в 2014 году делал/отлаживал первый демонстрационный пример HCE приложения Visa (MC попозже спеки сделал).
см.
android.nfc.cardemulation.*
android.nfc.NfcAdapter
Для целей описанных в статье — не нужны. Смысл такому ПО проверять RSA подписи?
У бесконтактной карты гораздо опасней другие вещи.
Вот когда мост для бесконтактной карты на двух телефонах (c NFC) позволял только делать без пиновые покупки в пределах 1000 руб — это было еще ничего..
Но вот когда Сбер ввел выдачу наличных по безконтакту!
Микро камера для подсмотреть PIN — элементарно. Прислонится к толпе, к кошельку жертвы одним из телефонов "моста" — да проще простого.
Не нужны никакие накладки и пр. Просто камера для подсмотреть за вводом PIN и два андройд телефона. Ну еще программки под андройд, которые валяются на GitHub выложенные такими же энтузиастами.
Хотя в программке обеспечивающей "мост" между двумя телефонами (один — ридер, другой эмулятор карты) ничего сложного нет, но ее и писать не нужно. Уже валяются, сделанные в "исследовательских целях".
Вот совсем не уверен, что ПО Сберовских банкоматов анализирует миллисекундные накладные задержки на выполнение команд карты (которые может вносить такой "мост").
Так, что паранойя носить карту в экранированном чехле — это не обязательно паранойя.
То что Вы рассказали, тем кто работает в теме и так известно. И набор утилит у тех кто с этим работает, как самописных, так и платных специализированных не мал.
Я понимаю, восторг "первооткрывателя", но стоило ли выкладывать на Github?
Дали инструмент школоте и кууул хацкерам делать гадости. Зря… на мой взгляд.
И, кстати, атаками это названо чересчур громко.
Да можно сделать мелкие гадости людям. Например соседу по школьной парте.
Особенно с блокировкой PIN.
Хотя PIN карты легко разблокировать выбрав смену PIN (увы, если поддерживает) банкомате (там on-line PIN + EMV скрипт). Но не все знают и для них будет неприятно когда карта перестанет работать в POS.
Блокировка по ATC — слишком долго карту нужно мучить (хотя… некоторые, не буду показывать пальцем, ставят в профили персонализации меньшее значение, чем 0xFFFF. Типа безопаснее для криптоанализа ключей карты).
Не просто так, кстати, PSE — опционально по EMV. И по факту, часто на картах остутствует.
CVV2 только графически персонализируется. Покажите, pls, один из "некоторых онлайн-магазинах" который не требует CVV2 и при этом не использует 3D.
Если дайвер поднимется настолько быстро, что часы без клапана не успеют стравить давление, то выдавливание стекла может обеспокоить только его наследников.
И не важно, на воздухе или на тримиксе он погружался.
Часы для дайвера на тримиксе внутри костюма!
Ну конечно можно умудрится натянуть сухой костюм не снимая наручных часов (поверх), если действовать аккуратно, что бы манжеты не порвать часами.
Но… это… странно. Как минимум.
Я бы поставил высшую строчку этому "усовершенствованию" в рейтинге самых бесполезных усовершенствований.
Одни мой знакомый (обеспеченный) рассказывал, что знания из этой книги ему очень помогли в 90-х.
Все рецепты дикого капитализма Ж-)
Странно, когда я делал свой 3D сканер https://habr.com/ru/post/412479/
то работа с камерой не показалась слишком сложной. Все логично и дает почти полный доступ. Да и примеров и документации просто масса.
Наверное, не хватает простой "кнопки счастье" "записать видео" в API. Но для этого проще поискать обертку вокруг фактически низкоуровневого (скорее средне..) управления камерой от Android.
Хотя, если честно, не понял зачем 2019 году очередная статья "как я разбирался с Camera2 API".
Аплодирую! Эта фраза заставила меня заглянуть внутрь.
Не автор статьи, но судя по фото это HSM от фирмы КриптоПро (совместимый с CPS от Крипто Про)
Сертифицированных поставщиков таких продуктов в России можно пересчитать по пальцем одной руки фрезировщика с большим опытом.
Мне всегда странно когда говорят, что новый язык увеличил скорость разработки в разы.
Может я чем то не тем занимаюсь. но 60..80% в разработке ПО времени это не кодирование как таковое.
А кодирование… пусть Java до 8 уступала Kotlin. Пусть текста кода поменьше получается.
Но сказать что в разы ускоряет кодирование — то же как то перебор.
В сущности какая разница на чем. Нормальные IDE — ускоряют.
Это шаблонный код, кочующий из проект в проект. И не так что бы сложный для понимания.
Если не интересует потребление, то можно вообще все модули включить.
Чем мне не нравится Arduino как концепция… Кто то дернул чью то библиотеку (зачастую корявую и на оптимизированную) и все. Эмбедет разработчик в резюме.
HTTP body не в той кодировке я привел просто для примера.
Если из непонятного источника загружается в неизвестное кодировке. Т.е. без всякой спецификации и протокола...
К слову, если из файла, то обычно BOM заголовок ставят и его нужно смотреть.
Все офисные пакеты Windows (и C#, например) BOM ставят в начале.
Немного… (инициализация шаблонно). Если через напрямую в стиле "записать в порт" то практически столько же как на AT
DDRD |= _BV(PD0); PORTD &= ~_BV(PD0);(что не очень хороший стиль. ибо код не переносим может оказаться)
За то проблемы "остается немного времени на анимацию на дисплее" не беспокоят.
И да. "Наверно, с них начинает почти любой embedded разработчик." не совсем правильное утверждение. Если, конечно, под "embedded разработчик" не понимать "я тут светодиодом помигал".
Документация от STM ничем не сложнее чем от Atmel.
Все это конечно замечательно. НО зачем?
Цена, размер корпуса да и потребление в этом режиме 32-х битных контроллеров практически те же что и на ATMega.
Почему все так упорно пользуются древними ATMega?
Если кто присылает байтовый набор данных который на самом деле win-1251, а в заголовке XML указана кодировка UTF-8, то я бы ему "мягко" попенял.
Ибо ошибка грубейшая. И чаше всего (на практики было) поправляют эту ошибку..
Почему то (не в обиду, но факт и моя личная статистика) такую ошибку допускают разработчики на PHP.
Типичная ошибка: XML с кодировкой UTF-8 в XML заголовке, без указания codepage в HTTP заголовках c фактическим Win-1251 в HTTP body.
Это я к тому, что определять по косвенным признакам кодировку — закладывать мину замедленного действия.
А по моему, на малине, гораздо удобнее сочетание "C/C++" библиотек и python.
Опять же, gcc есть и кросс. Писать С++ код внутри малины и там же компилировать… Можно. Но для чего то мелкого. Иначе мазохизм.
Спасибо за подробный ответ.
Как выглядит сертификация PCI DSS на всем своем — я знаю. А с облаком никогда не сталкивался.
Спасибо. Понятно.
А то смутило упоминание контекста PCI DSS (требования Visa & MC к ТСП и процессингам), касающиеся в основном хранению и использованию платежных/карточных данных (ключи,HSM,PIN блоки, треки и прочее) к обычному универсальному облачному сервису.
Хотя, любопытно как это выглядит… Организация конечная (банк/эквайрер/процессинг..) проходит сертификацию для Visa & MC по PCI DSS. Как помогает сертфикат выданный "облаку" сертификации этой организации?
"Как" — в смысле, как это выглядит процедурно.