Android position independent executables

Android 5.0 «error: only position independent executables (PIE) are supported.» #1

Comments

wikijm commented Oct 24, 2016

PIE is a useful security feature, as randomizing the address space makes it significantly more difficult for an attacker to exploit bugs in a program.

I get this error after:

Starting Responder.py, Ctrl-C to exit

The text was updated successfully, but these errors were encountered:

nvssks commented Oct 24, 2016

can you give me the output of these commands:
pm list packages qpython
getprop ro.build.version.release

Seems like the check I have for the version is not working.
qPython has a different script (with no PIE) for android >5

wikijm commented Oct 24, 2016

pm list packages qpython

nvssks commented Oct 24, 2016

You’re using qPython3, I haven’t tested Responder with Python version 3.

Quick solution would be to install qPython for Python 2.7 (until I test and update the code)

wikijm commented Oct 24, 2016 •

Thanks for your quick answer.
Same issue on QPython.

pm list packages qpython

3ntr0phy commented Oct 24, 2016

I have this issue: only PIE are supported.
How do you run the script?

pm list packages qpython

nvssks commented Oct 24, 2016

could you try running:
su -c sh /data/data/org.qpython.qpy/files/bin/qpython-android5.sh
and
su -c sh /data/data/org.qpython.qpy/files/bin/qpython.sh

One of each should give the same error or a Python interpreter.
Seems that the version of android is not adequate for this check

3ntr0phy commented Oct 24, 2016

It doesn’t produce any error and does not open a python interpreter, it just produce me this:
127|
Nothing changes. :/

3ntr0phy commented Oct 24, 2016

Which Android version did you use for testing it?

nvssks commented Oct 24, 2016

I’m testing it on Android 6.0.1
and I had tested it on 4.7 as well.

Can you open qPython from the icon and select console?
The first line should be one of the above

3ntr0phy commented Oct 24, 2016

Yes but the first line is /data/user/0/org.qpython.qpy, not /data/data/org.qpython.qpy/. Moreover i get the python interpreter if i remove the -c from the command :
su sh /data/user/0/.

nvssks commented Oct 24, 2016

Pushed a new commit in https://github.com/nvssks/Android-Responder/tree/dev-1
It will try with the PIE/non-PIE version of qPython’s script if the first fails

Could you please test this version and let me know if it works

@Jacoppy try running the script with su sh $DIR/startTether.sh and see if that works

wikijm commented Oct 25, 2016

Result with the new commit:

nvssks commented Oct 25, 2016

I think I had a small error in the script :/ — (updated in dev-1)

Can you open qPython, go to console and post a screenshot?

wikijm commented Oct 25, 2016

nvssks commented Oct 25, 2016

I think I have fixed it in the latest update in dev-1

Otherwise if this still doesn’t work, let the script fail and try to run Responder manually:
su -c sh /data/data/org.qpython.qpy/files/bin/qpython-android5.sh ./Responder/Responder.py -I rndis0 -f -w -r -d -F
or
su -c sh /data/data/org.qpython.qpy/files/bin/qpython-android5.sh ./Responder/Responder.py -I usb0 -f -w -r -d -F

Not sure which interface Android 5.0 uses (usb0 or rndis0)

wikijm commented Jan 13, 2017

It seems to work like a charm.
Thanks a lot 🙂

OZZ-MAN commented Mar 13, 2018

Why would I be getting a Lolipop error in Nouget? I was having the understanding that «pie» was an Android 5 issue.

Источник

[FIX] [Android ‘L’] Bypassing the new PIE security check

Breadcrumb

cernekee

Senior Member

Last month, Chainfire posted a nice writeup on several new security changes happening upstream in AOSP. There has been much discussion of the SELinux changes and what that means for root apps, but I’d like to touch on another change that can affect even garden variety non-root apps: mandatory PIE (position-independent executables).

If you’re running the Android «L» developer preview image, you may have noticed that some of your native binaries no longer execute:

PIE is a useful security feature, as randomizing the address space makes it significantly more difficult for an attacker to exploit bugs in a program. However, in this case, one must trade off compatibility for security: PIE is only available in JB 4.1 and above, so most app developers targeting a wide range of Android versions have disabled PIE in their builds. The new PIE check in «L» will cause breakage for most apps that ship native executables.

As it turns out, even some of the precompiled binaries shipped with Android itself are affected, and Google has temporarily disabled PIE enforcement. It is not clear whether they will re-enable it at a later date.

Since the Android «L» preview images were built prior to Google’s latest change, they still have PIE enabled. I am attaching a flashable «bypass-pie.zip» which overwrites one byte in /system/bin/linker to bypass the PIE check:

Use this at your own risk. It works for me. The same non-PIE curl binary now runs correctly with the patched linker:

This was tested on hammerhead-lpv79-preview-ac1d8a8e.tgz. If somebody wants to test on razor-lpv79-preview-d0ddf8ce.tgz and post the result, that would be helpful.

It is not necessary to wipe any caches after flashing, although you may want to «clear data» for any apps that were crashing prior to applying the change so that they can start fresh.

Update 2014/07/21: AOSP has re-enabled the PIE check after recompiling their last non-PIE binary. I filed a ticket asking Google to revert this change in order to avoid breaking ABI compatibility.

Источник

Android 5.0 and later only support position-independent executables(-fPIE) #119

Comments

sajid-verveba commented Oct 29, 2018

i have genrated exutables using tinyalsa release 1.1.1 with command ndk-build inside jni folder.
I have copied tinymix in /data/local/tmp, also set chmod 777 to tinymix file.

After running tinymix command on device i got following errror:

«/data/local/tmp/tinymix»: error: Android 5.0 and later only support position-independent executables (-fPIE).

The text was updated successfully, but these errors were encountered:

ghost commented Oct 29, 2018 •

Does it help adding LDFLAGS += -fpie to utils/Makefile ?

sajid-verveba commented Oct 30, 2018

no it didn’t solved my problem yet.
we need to do following thing to make it running.

Position Independent Executable or PIE allows a program to be relocated, just like a shared object. At each run of the program, the program can be loaded at different addresses to make it harder for an attacker to guess certain program state.

You can compile and link a PIE executable in one of two ways. First, compile everything with -fPIE and link with -pie. The second is to compile everything with -fPIC and link with -pie.

ghost commented Oct 30, 2018

Alright, thanks for that info. I added those flags to the compiler flags and linker flags. If you pull the latest changes, you should be able to give it a shot.

ghost commented Nov 18, 2018

@sajid-verveba Did this fix your issue?

ghost commented Nov 28, 2018

I verified that the executables run now using termux and clang. You can open another issue if the problem persists.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

‘su’ does not run on Nexus 5/Lollipop — only position independent executables (PIE) are supported #268

Comments

RunasSudo commented Nov 29, 2014

Clicking Recovery/Install gives ‘There was an error installing Superuser. Please send a log of the error to the developer.’ Manually installing the su binary and attempting to run it gives:
error: only position independent executables (PIE) are supported.

The text was updated successfully, but these errors were encountered:

RunasSudo commented Dec 1, 2014

Well, I compiled su from source targeting android-21 , and I ended up with a binary that works in ADB but crashes in Terminal Emulator with

I’ll leave this one to the experts.

jazzrz86 commented Dec 4, 2014

The problem is, even if you are root, you are still effectively running in the shell or untrusted_app context. SElinux will stop you from doing anything. SU will need to have the policy adjustments alongside root- and it is a huge effort compared to previous Android.

The current root solution (SuperSU from ChainsDD) spawns from the zygote context and still requires a supporting binary to adjust the SElinux policies.

leesah commented Feb 8, 2015

Does this mean Lollipop cannot be rooted as previous versions and it’s pointless to install any of the three alternatives in Play store?

sparkym3 commented Feb 8, 2015

No that is not what it means. Lollipop is rootable and superSU is a great working version (though not open source).

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

PIE (Position Independent Execution)

	Авторство
	В. М. Виноградова
	Согласовано: 22 января 2018 года

PIE (англ. Position Independent Execution – Независимый от расположения исполняемый файл) – исполняемые файлы, полностью созданные из кода, не зависящего от местоположения.

Содержание

Позиционно-независимый код (PIC)

Независимый от местоположения код (Position-Independent Code) — это код, который может быть размещена в любой области памяти, поскольку все ссылки на ячейки памяти в нем относительные (например, относительно счётчика команд). Возможность создания позиционно-независимого кода зависит от архитектуры и системы команд целевой платформы. К примеру, если во всех инструкциях перехода в системе команд должны указываться абсолютные адреса, то код, требующий переходов, практически нельзя сделать позиционно-независимым. В архитектуре x86 непосредственная адресация в инструкциях работы с данными представлена только абсолютными адресами, но поскольку адреса данных считаются относительно сегментного регистра, который можно поменять в любой момент, это даёт возможность создавать позиционно-независимый код со своими ячейками памяти для данных. Кроме того, некоторые ограничения набора команд могут сниматься с помощью самомодифицирующегося кода или нетривиальных последовательностей инструкций.

PIС обычно используется для разделяемых библиотек, так что один и тот же библиотечный код может быть загружен в местоположение в каждом адресном пространстве программы, где он не будет перекрывать другие виды использования памяти (например, другие разделяемые библиотеки). PIC также использовался на старых компьютерных системах, не имеющих MMU [Источник 1] , так что операционная система могла удержать приложения друг от друга даже в пределах одного адресного пространства системы с MMU-less.

Независимый от позиции код может быть выполнен на любом адресе памяти без модификации. Это отличается от перемещаемого кода, в котором редактор ссылок или программный загрузчик модифицирует программу перед выполнением, чтобы ее можно было запускать только из определенного места в памяти. Генерация независимого от позиции кода часто является стоит по умолчанию для компиляторов, но они могут накладывать ограничения на использование некоторых функций языка, например: запрет использования абсолютных адресов (код, зависящий от положения, должен использовать относительную адресацию). Инструкции, которые ссылаются непосредственно на конкретные адреса памяти, иногда выполняются быстрее, и замена их эквивалентными инструкциями относительной адресации может привести к немного более медленному выполнению, хотя современные процессоры делают разницу практически незначительной.

История

На первых компьютерах, таких как IBM System/360 (1965), код был зависимым от местоположения: каждая программа была создана для загрузки и запуска с определенного адреса. Если многозадачная операционная система допускала одновременное выполнение нескольких заданий с использованием отдельных программ, операции должны были быть запланированы таким образом, чтобы никакие два параллельных задания не запускали программы, требующие одинаковые адреса загрузки. Например, как программа расчета заработной платы, так и программа учета дебиторской задолженности, созданная для работы по адресу 32K, не могут одновременно выполняться одновременно. IBM DOS / 360 (1966) не имел возможности перемещать программы во время загрузки. Иногда поддерживалось несколько версий программы, каждая из которых была построена для другого загружаемого адреса. Специальный класс программ, называемых самопересекающимися программами, был закодирован, чтобы передислоцироваться после загрузки. IBM OS / 360 (1966) переносила исполняемые программы, когда они были загружены в память. Требовалась только одна копия программы, однако после загрузки программа не может быть перемещена.

Для сравнения, на ранних сегментированных или базовых и граничных системах, таких как Burroughs B5000 (1961) и Multics (1964), код был по своей природе не зависящим от местоположения, поскольку адреса в программе относились к текущему сегменту, а не к абсолютному. Независимый от позиции код был разработан для устранения этих ограничений для несегментированных систем. PIEа может быть загружена по любому адресу в памяти. Изобретение динамического преобразования адреса (функция, предоставляемая MMU) изначально уменьшило потребность в PIC, потому что каждый процесс мог иметь свое собственное независимое адресное пространство (диапазон адресов). Тем не менее, несколько одновременных заданий с использованием одного и того же кода создали пустую трату виртуальной памяти. Если два задания выполняются полностью идентичными программами, динамическое преобразование адресов обеспечивает решение, позволяя системе просто сопоставлять адрес 32K двум разным заданиям с теми же байтами реальной памяти, содержащими единственную копию программы.

Различные программы могут использовать общий код. Например, программа расчета заработной платы и программа дебиторской задолженности могут содержать как идентичную подпрограмму сортировки. Общий модуль (разделяемая библиотека представляет собой форму совместно используемого модуля) загружается один раз и отображается в два адресных пространства. [Источник 2]

Технические детали

Вызовы процедур внутри разделяемой библиотеки, как правило, выполняются с помощью небольших частей таблицы связывания процедур, которые затем вызывают окончательную функцию. Это позволяет библиотеке наследовать некоторые вызовы функций из ранее загруженных библиотек, а не использовать собственные версии. Ссылки на данные из позиционно-независимого кода обычно делаются косвенно через глобальные таблицы смещения (GOT), которые хранят адреса всех доступных глобальных переменных. Существует один GOT на единицу компиляции или объектный модуль, и он расположен с фиксированным смещением от кода (хотя это смещение неизвестно, пока библиотека не связана). Когда компоновщик связывает модули для создания общей библиотеки, он объединяет GOT и устанавливает окончательные смещения в коде. Нет необходимости корректировать смещения при загрузке разделяемой библиотеки позже.

Позиционные независимые функции получают доступ к глобальным данным, путем определения абсолютного адреса GOT с учетом их собственного значения счетчика текущей программы. Это часто делается в форме поддельного вызова функции для получения возвращаемого значения в стеке (x86) или в специальном регистре (PowerPC, SPARC, [[MIPS (Microprocessor without Interlocked Pipeline Stages)|MIPS], возможно, по крайней мере, некоторые другие RISC-процессоры , ESA / 390) , которые затем могут быть сохранены в предопределенном стандартном регистре. Некоторые архитектуры процессоров, такие как Motorola 68000, Motorola 6809, WDC 65C816, Knuth’s MMIX, ARM и x86-64, позволяют ссылаться на данные по смещению от счетчика программ. Это специально сделано для того, чтобы PIC стал меньше, менее требователен к регистру и, следовательно, более эффективным. [Источник 2]

Windows DLLs

Библиотеки динамической компоновки (DLL) в Microsoft Windows используют вариант E8 инструкции CALL. Эти инструкции не нужно исправлять, когда загружается DLL.

Предполагается, что некоторые глобальные переменные (например, массивы строковых литералов, таблицы виртуальных функций) содержат адрес объекта в разделе данных resp. в разделе кода динамической библиотеки, поэтому хранимый адрес в глобальной переменной необходимо обновить, чтобы отразить адрес, куда была загружена DLL. Динамический загрузчик вычисляет адрес, на который ссылается глобальная переменная, и сохраняет в нее значение, это вызывает копирование при записи той страницы памяти, что содержит эту ​​глобальную переменную. Страницы с кодом и страницы с глобальными переменными, которые не содержат указателей на код или глобальные данные, остаются общими между процессами. Эта операция выполянется в любой ОС, которая может загружать динамическую библиотеку по произвольному адресу.

В Windows Vista и более поздних версиях Windows перемещение DLL и исполняемых файлов выполняется менеджером памяти ядра, который совместно использует перемещенные двоичные файлы в нескольких процессах. Изображения всегда переносятся с предпочтительных базовых адресов, [[ASLR (Address Space Layout Randomization)|рандомизация размещения адресного пространства].

Версии Windows до Windows Vista требуют, чтобы DLL-файлы системы предварительно связывались по неконфликтующим фиксированным адресам во время соединения, чтобы избежать перемещения изображений во время выполнения. Перенос времени выполнения в этих старых версиях Windows выполняется загрузчиком DLL в контексте каждого процесса, и результирующие перемещаемые части каждого изображения больше не могут быть распределены между процессами.

Передача библиотек DLL в Windows отличается от более ранней процедуры OS / 2, из которой она извлекается. OS / 2 представляет третий вариант и пытается загрузить DLL, которые не являются позиционно-независимыми, в выделенную «общую арену» в памяти и отображает их после загрузки. Все пользователи DLL могут использовать одну и ту же копию в памяти.

Позиционно-независимый код в современных Unix-системах

Компиляторы современных систем семейства UNIX — GNU С или стандартный С-компилятор UNIX SVR4 имеют ключ -f PIC. Впрочем, код, порождаемый при использовании этого ключа, не является позиционно-независимым в указанном выше смысле: этот код все-таки содержит перемещаемые адресные ссылки. Задача состоит не в том, чтобы избавиться от таких ссылок полностью, а лишь в том, чтобы собрать все эти ссылки в одном месте и разместить их, по возможности, отдельно от кода. Это очень полезно при создании разделяемых библиотек.

Код, генерируемый GNU С, использует базовую адресацию: в начале функции адрес точки ее входа помещается в один из регистров, и далее вся адресация других функций и данных осуществляется относительно этого регистра. [Источник 3] На процессоре х86 используется регистр %ebx, а загрузка адреса осуществляется командами, вставляемыми в пролог каждой функции (пример 1).

На процессорах, где разрешен прямой доступ к счетчику команд, соответствующий код выглядит проще, но принцип сохраняется: компилятор занимает один регистр и благодаря этому упрощает работу загрузчику.

Пример 1. Получение адреса точки входа в позиционно-независимую подпрограмму

Как мы видим в примере 2, на самом деле адресация происходит не относительно точки входа в функцию, а относительно некоторого объекта, называемого GOT. Счетчик команд используется для вычисления адреса этой таблицы, а не сам по себе. Компилированный таким образом код предназначен в первую очередь для разделяемых библиотек формата ELF (формат исполняемых и собираемых [модулей], используемый большинством современных систем семейства Unix).

Пример 2. Позиционно-независимый код, порождаемый компилятором GNU С

Влияние компиляции с PIE на результирующий двоичный файл

The Fedora Engineering Steering Committee поддерживает консервативный список пакетов, которые должны быть созданы с использованием функций безопасности GCC. Пакеты, не входящие в этот список, имеют функции безопасности, включенные по усмотрению упаковщиков. В настоящее время не существует консенсуса в отношении того, когда необходимы бинарные файлы с повышенной безопасностью. В результате, использование защищенных двоичных файлов может стать спорной темой. Большинство аргументов можно свести к тому, превышает ли выигрыш в безопасности производительность, связанную с использованием этой функции. [Источник 4]

Позиция Независимые исполняемые файлы (PIE) — это результат процесса упрочненного компоновки пакетов. Бинарный файл PIE и все его зависимости загружаются в случайные расположения в виртуальной памяти каждый раз, когда приложение выполняется. Это сильно затрудняет атаки Return-Oriented Programming (ROP).

Пример 3. Рассмотрим следующую программу «Hello World»:

Для уменьшения постороннего влияния, в данном примере используется нестандартная реализация стандартных функций библиотеки во время компиляции:

Двоичный ELF, который создается этой сборкой, не имеет зависимостей от libc или загрузчика для запуска. Это означает, что он может загружаться в память и запускаться независимо от компоновщика для динамического поиска и привязки с зависимостями. Однако это затрудняет совместное использование и повторное использование подпрограмм. Общим решением этой проблемы является создание общей библиотеки:

Следующий шаг — перекомпилировать основной двоичный код, указывающий, что некоторые определения символов существуют во внешней общей библиотеке:

Размер результирующего двоичного файла имеет меньшую секцию .text, поскольку этот код содержится в общей библиотеке libnotc.so. Есть и другие существенные отличия:

Чтобы программа корректно выполнялась, двоичный код ELF должен быть сконструирован таким образом, чтобы он позволял загрузчику разрешать символы во время выполнения. Поскольку адрес символа в памяти не является частью основного двоичного файла, загрузчик добавляет уровень косвенности в таблицу связей процедур (раздел .plt). Вместо прямого вызова puts () секция .plt содержит специальную запись, указывающую загрузчику. Затем загрузчик должен найти фактический адрес функции. После этого он обновляет запись в глобальной таблице сдвига (GOT). Последующие вызовы одной и той же процедуры выполняются переходами из записи GOT.

Стандартный двоичный файл ELF обычно загружается в тот же базовый адрес в виртуальной памяти каждый раз, когда он выполняется. Компоновщик использует это в неперемещаемом коде, перескакивая на абсолютные адреса символов. Это, как оказалось, имеет небольшое преимущество в производительности, поскольку быстрее перейти к абсолютному адресу, чем к относительной адресации. Это особенно верно для приложений i386, поскольку для этого требуется другой регистр.

Чтобы увидеть разницу между динамическими и PIE-приложениями, нам нужно перекомпилировать пример программы как PIE. Это просто требует добавления -fpic -pie-флагов к тому, что мы имели ранее:

Обратите внимание, что адрес, указанный командой размера для каждой из секций ELF, является относительным адресом, тогда как адрес, указанный для динамического примера, использует абсолютное местоположение. Это необходимо, потому что программа и все ее зависимости будут загружены в случайные места в виртуальной памяти при выполнении. Это включает в себя предварительно связанные библиотеки и как таковая служит эффективной технологией предотвращения эксплойтов для атак, которые опираются на возврат к известным адресам стандартных системных библиотек.

Где используется PIE

Бинарные файлы PIE используются в некоторых дистрибутивах Linux, ориентированных на безопасность, чтобы позволить PaX или Exec Shield использовать [[ASLR (Address Space Layout Randomization)|рандомизация размещения адресного пространства], чтобы злоумышленники не знали, где существующий исполняемый код находится во время атаки безопасности, используя эксплойты, которые полагаются на знание смещения исполняемого кода в двоичных файлах, например обратные атаки на libc. Mac OS X и iOS Apple полностью поддерживают исполняемые файлы PIE, начиная с версий 10.7 и 4.3, соответственно; Появляется предупреждение, когда исполняемые файлы не-PIE iOS отправляются на утверждение в App Store Apple, но нет жесткого требования, так что приложения, не относящиеся к PIE, не обязательно будут отвергнуты. В OpenBSD PIE включен по умолчанию на большинстве архитектур начиная с OpenBSD 5.3, выпущенного 1 мая 2013 года. Поддержка PIE в статически связанных двоичных файлах, таких как исполняемые файлы в каталогах / bin и / sbin, была добавлена ​​ближе к концу 2014 года. Начиная с Fedora 23, разработчики Fedora решили создать пакеты с включенным PIE по умолчанию. Android осуществляет поддержку PIE в Jelly Bean и исключил линкерную поддержку без PIE в Lollipop.

Источник