int_0x80 Sep 6 2011 at 19:02

Эффективный способ защиты от пиратства

5 min

3.7K

Development for iOS*

From sandbox

-3

Comments 14

Noobster Sep 6 2011 at 19:07

Астрологи объявили неделю неграмотных постов на хабре. :(

romeo_ordos Sep 6 2011 at 19:49

А $LOGNAME — это имя бревна? Всегда думал что $USERNAME

int_0x80 Sep 6 2011 at 19:51

под макосью нету $USERNAME, там именно $LOGNAME

N1ghtroad Sep 13 2011 at 04:23

символично…

moborb Oct 10 2011 at 08:11

Уважаемый int_0x80, а за подобную защиту из AppStore не изгоняют?
Поделитесь, пожалуйста, своим опытом ежели таковой имеется.

int_0x80 Oct 10 2011 at 09:53

Мое приложение в разработке и до цензоров еще далеко. Так что, могу поделиться только чужим опытом. Код ipref я конечно не видел, но пока, их никто не выгонял ;)

Использовать asm {...} и читать заголовки собственного приложения нигде не запрещено. Запрещено использовать, так называемые, «приватные» апи, например syscall, о котором я упомянул в статье.

moborb Oct 10 2011 at 12:20

Спасибо за разъяснения. Однако возникла еще пара вопросов

1. Есть ли proof того что код iPref использует подобные техники?
(Для варианта «открой и посмотри в IDA я слишком ленив» ).

2. Известны ли вам открытые или коммерческие средства защиты ( вроде WinLicense ), поддерживающие iOS? (я пока что о таковых не слыхал).

moborb Oct 10 2011 at 12:30

Кроме того, приведенный фрагмент на ассемблере по сути вызывает ту же запрещенную ptrace/syscall. Следовательно, за такое все-таки могут изгнать.
Или здесь расчет на то что если не найдут злоумышленники, то уж цензоры и подавно?

int_0x80 Oct 10 2011 at 17:11

В том-то и дело, что запрещен syscall, но не ptrace!
Тут очень интересный момент, например write/read это обвертка в которой используется тот же syscall. Тоесть мы можем использовать write/read, но не можем syscall(SYS_write,.....)!!!
А в результате, это все компилируется в эквивалентный ассемблерный код. Можете дизассемлировать свою программу, там очень много инструкций svc #0x80 (системный вызов).
Поэтому фактически мы ничего не нарушаем.
И да, для цензоров — это параллельная вселеная :)

Насчет ipref — это разработка ripdev, а они в свое время предлагали комерческую защиту kali (был сайт, но потом все пропало).

Часто видел в инете упоминания www.cocoanetics.com/anticrack/. Тут тоже хотят денег. Можно посмотреть ролик, там видны детали защиты. Меня не впечатлило.

lymes Nov 7 2011 at 15:11

Хорошая статья, спасибо. Жаль что проголосовать уже не могу.

Speakus Dec 13 2011 at 02:24

Интересная тема. Скажите, а каким образом выполнится код:
> ptrace(PT_DENY_ATTACH, 0, 0, 0);

Если остановка идет на входе в функцию main()?
> break main # установим точку прерывания в самое начало

int_0x80 Dec 13 2011 at 13:30

В таком случае, пошаговая трасировка программы будет выполнятся до инструкции ptrace, после чего процес gdb будит уничтожен. Лично я рекомендую разместить выше приведенный ассемблерный вызов ptrace перед UIApplicationMain в файле main.m. Помните, что главный козырь, это не столько запрет ptrace, сколько контроль целостности бинарного файла. Не страшно, если взломщик найдет наш ptrace, страшно, если он сможет его пропатчить!

tyomitch Jan 31 2019 at 09:51

Неправда:

This request is the other operation used by the traced process; it allows a process that is not currently being traced to deny future traces by its parent. All other arguments are ignored. If the process is currently being traced, it will exit with the exit status of ENOTSUP; otherwise, it sets a flag that denies future traces.

askl Mar 2 2015 at 03:19

Xcode вываливает ошибку на asm {. А если меняю на:

asm volatile (
        "mov r0, 31"     // PT_DENY_ATTACH
        "mov r1, 0"
        "mov r2, 0"
        "mov r3, 0"
        "mov ip, 26"     // SYS_ptrace
        "svc 0x80"
    );

То начинает ругаться на инструкции «Invalid operand for instruction».
Что я делаю не так?