Pull to refresh

Comments 18

Вам не кажется, что те, кто использует подобные ломалки, принципиально ничего не покупают? Так что игра не стоит свеч. Или у вас есть положительная динамика роста покупок?
Нет, я не считаю что пользователи которые любят халяву, никогда не заплатят за нужную функцию. Им же досталось устройство на iOS, может быть у них просто карточка не привязана к аккаунту и лень покупать iTunes gift card, может просто жалко денег. Главное что в этом нету принципиальной позиции и в какой-то момент пользователи понимают, что если им нравится приложение и они хотят чтобы оно развивалось — не жалко заплатить разработчику денег. Я это наблюдаю за своими знакомыми, которые сначала ждут раздачи халявы и скачивают только бесплатные приложения, потом не выдерживают и покупают первое приложение. Дальше-проще и 1-3$ — это не такие уж и большие деньги.
Это мы с вами прекрасно понимаем, что без материальной поддержки разработчики не смогут выпускать качественный контент. Но я очень часто встречаюсь с непониманием людей, далеких от разработки, почему им надо платить за что-то еще, если они уже заплатили за телефон (я говорю про отечественный рынок). Такие люди обычно просто удалят приложение. Вот я и поинтересовался у вас, есть ли какие-то сдвиги в цифрах.
Положительная динамика роста покупок у меня есть, но она была и до реализации защиты. Возможно защита помогает удерживать положительную динамику, а может она и не участвует в этом процессе и просто приложение хорошее и его с удовольствием покупают. Слишком много факторов в этом участвуют.
Никто не в курсе как обстоит это дело в MKStoreKit?..
Автор пишет что его имплементация уже включает в себя receipt verification, но прямо не отвечает на следующие вопросы
— Подвержен ли MKStoreKit этой новой уязвимости? (он как бы говорит что «нет»)
— Использует ли он новый VerificationController? (судя по всему нет)
А может всё и не так просто. Для iOS он отправляет проверку на свой сервер, но сервер отвечает просто YES, NO. Т.е. когда сервер взломщиков будет присылать правильный, но чужой чек от покупки — этот Kit не сможет заметить что его обманывают.
Возможно, наверное я поторопился вешать на него всех собак сразу.
Надеюсь он закроет дыру, если она в его коде есть.
Значит зазнался чувак. Как-то слишком катерочино заявляет что его код уже включает в себя верификацию, прям с восклицательным знаком… Видимо не хочет ронять свою репутацию «industry standard», которую сам себе приписал.

И похоже он ничего делать не собирается. В описании на гитхабе сказано «работаю на поддержкой Lion, после этого, скорее всего, никаких больших обновлений больше не будет (если только Apple не придумает новый механизм In-App Purchases)». Уже появился Mountain Lion, последние коммиты были 3 месяца назад, на открытый баг он отписался один раз, мол «все у меня проверяется!» и замолк. Жалко будет если он совсем забил на это дело.
GitHub тем и хорош, что вы можете сделать форк, доработать его StoreKit и отправить pull-request.
Я недавно описывал метод защиты с MKStoreKit в этом посте.
Могу сказать по этому поводу следующее. С учетом того, что мои проги с этой защитой скачали больше 600 000 раз, попыток взлома — немеряно. мой сервер отрабатывает всю статистику. и метод защиты на данный момент работает отлично. То есть статистика из itunesconnect и статистика, которая собирается через приложения не отличаются больше чем на 2%-3%.
И я у себя на сервере сохраняю все сертификаты для дальнейшего анализа. Попыток много — успешных взломов не видел.
У меня в приложении используется код проверки покупок от Apple доработанный напильником. Отчеты о крэшах с testflight показывают что в день где-то 3-5% новых пользователей пробуют активировать бесплатно покупки на джейлбрейкнутых телефонах с помощью твиков. Но т.к. твики рассчитывают на отсутствие детальной проверки со стороны приложения — они просто крэшатся. :)

BTW успешная «бесплатная покупка» тем и отличается от неуспешной, что приложение её не может отличить от настоящей. :) Иначе откуда эти 2-3%?
2-3% — это Non-consumable покупки на разных устройствах под одним appleid, и восстановление покупок после переустановки. Еще, возможно, несовпадение временых рамок статистики.

А то что приложение крешится — я считаю непремлемо, потому что как-то это неправильно. в слечае взлома, я прямым текстом пользователю пишу — Покупка не подтверждена. Это, как мне кажется, изящнее.
Если оно крэшится у пользователя, который подгрузил твик, который подменил функции приложения в рантайме, то тут тяжело что-то поделать. :) Я конечно заменю в следующей версии этот крэш на сообщение с призывами к совести, но надо понимать, что такие пользователи сами себе злобные буратины. :)
Поздравляю! Вы сделали защиту сами! Apple кинула в вас куском кода с проверкой, сама не сделав ничего. Кстати, по-моему в 2014 сертификат внутри истечет=)
Я разработчик, а не специалист по безопасности. Я не ломаю чужие приложения и как видно по моей первой статье, верные идеи в неопытных руках приносят не много пользы. Apple как обычно оставляет вкусности на последний момент, посмотрим что будет после выхода iOS6.

Кстати, вам стоит признать, что с проверкой сертификата и проверкой соответствия полей в SKPayment ваш сервис пока ничего не может поделать. Ваш ход, как говорится.
Да, я это признал. Ждем iOS6=)
На андроиде есть механизм патча dalvik-cache.

LuckyPatcher тому пример.
Может и такое есть для iOS?
Sign up to leave a comment.

Articles