Серия «Жестокие эксперименты»

Исходный код отрефакторенной версии выложен на Github.

Задача

Допустим есть некий софт, созданный еще «при царе Горохе» неким гордым но умным одиночкой, которого с тех пор никто не видел. Софт живой и с пользователями, которые приносят прибыль, поэтому его надо как‑то развивать и поддерживать.

В попытке расширить команду разработки, вы начинаете нанимать новых разработчиков, но раз за разом происходит одна и та же ситуация:

проработав месяц-два, нанятые программисты в ужасе убегают в закат.

Кто‑то при увольнении намекает на причины такого поступка, в диапазоне от «ваш проект попахивает» до надо «срочно все переписать». После примерно десятого убежавшего программиста, вы наконец начинаете задумываться, что возможно с проектом действительно что‑то не так и стоит провести этот самый «рефакторинг».

Так это обычно начинается.

Образец

В качестве образца для этой статьи был взят один интересный но малоизвестный широкой публике проект JPC:

The fast x86 PC emulator in 100% pure Java

Самый настоящий эмулятор старого x86-компьютера, реализованный без всяких нативных частей — на чистой Java!

Как-то так это выглядит у автора(ов) в работе:

Проект старый, но и интересный:

Read more about JPC - since it's launch at JavaOne 2007, JPC can now boot many more operating systems (including graphical linuxes) and it's much faster.

Не очень большой (~6500 файлов с исходным кодом), но имеет стадию «внутренней генерации» — часть исходного кода создана не вручную а путем запуска кодогенератора по метаданным, что довольно часто встречается у больших проектов с историей, причем на любом языке.

Еще к сожалению JPC немного заброшен, что для статьи только в плюс поскольку добавляет реалистичности — именно в таком состоянии чаще всего пребывают проекты, которые просят «привести в чувство».

Текущее состояние

После переезда проекта на Github, список коммитов выглядит следующим образом:

Никаких тестов в проекте нет, по всей видимости тестировалось все вручную с помощью молитвы, еще судя по исходному коду — далеко не весь функционал является рабочим, что также характерно для проектов в «пред‑рефакторинговом» состоянии.

Думаю теперь очевидно почему для этой статьи был выбран именно JPC — несмотря на редкость решаемой задачи, для рефакторинга это самый типичный клиент.

Собирается сей чудо-проект с помощью.. Makefile, что для мира Java является дичью и извращением редкостью:

make application

Примерно как собирать проект на QT с помощью Gradle или (еще лучше) — sbt.

Предложите как-нибудь коллегам и посмотрите на реакцию, некоторые точно перестанут с вами здороваться за руку.

Для сборки необходимо указать путь к JDK в переменной PATH, при этом сборка проходит успешно даже с последними версиями (автор использовал OpenJDK 21).

Готовое приложение JPCApplication.jar появится в корне проекта после завершения сборки, но на этом хорошие новости заканчиваются:

Собранное приложение отказывается запускаться, что мы исправим чуть ниже.

Стадия первая: новый скелет

Первым делом, как и в реальном боевом проекте, необходимо избавиться от любого «самопала», задействованного при сборке. Причина, почему этот шаг критически важен на самом деле не так очевидна:

статические анализаторы — главный иструмент рефакторинга, крепко привязаны к структуре проекта и стандартным средствам сборки

Разумеется существуют варианты и с произвольной структурой проекта, но эффективность рефакторинга будет заметно ниже. Поэтому автор сделал стандартный (для своей практики) «финт ушами»:

перевел сборку проекта на Apache Maven, максимально широко поддерживаемый средствами анализа кода, CI-системами и средами разработки.

Реализовать такую миграцию в данном случае оказалось очень просто, поскольку JPC совсем не использует внешние библиотеки. Все что я сделал — раскидал ресурсы и исходный код в стандартную для Maven структуру каталогов:

Исходный код был перенесен из каталога src в src/main/java, ресурсы — в src/main/resources. Также был добавлен очень простой pom.xml, описывающий минимальные шаги сборки проекта:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.x0x08.samples</groupId>
<artifactId>jpc-refactored</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.4.2</version>
<configuration>
<archive>
<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>

Обратите внимание на куда более упрощенную генерацию манифеста:

<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>

Указывается только стартовый класс, используемый для запуска приложения, а дата сборки и название будут проставляться автоматически самим Maven.

В оригинальной сборке происходит добавление еще и атрибута, отвечающего за параметры запуска «по-умолчанию»:

echo "Default-Args: -fda mem:resources/images/floppy.img -hda mem:resources/images/dosgames.img -boot fda" >> jpc.manifest

Это было убрано, поскольку точно такой же параметр запуска зашит еще и в код:

Наследие «былых времен», которое также достаточно часто встречается в устаревших проектах — во времена Java 1.5 и апплетов было модным использовать собственные атрибуты в манифесте.

Стадия вторая: удаление ненужного

Как в практически любом долгоживущем проекте, в JPC есть свои «внутренние утилиты» — отдельные программы, написанные для задач внутренней автоматизации.

Это та самая «грязная рабочая поверхность», которую не видит конечный пользователь.

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

В JPC внутренние утилиты реализованы в виде отдельных классов в пакете «tools» и нескольких шелл-скриптов в корне проекта.

И то и другое я просто не стал переносить в новую версию, также я убрал часть исходного кода эмулятора, отвечающего за отладку (пакет org.jpc.debugger) — по той же самой причине.

Что потребовало правок в классе org.jpc.emulator.PC.java:

был убран импорт класса org.jpc.debugger.LinearMemoryViewer а используемая статичная функция translateLinearAddressToInt перенесена в класс PC.

Все эти действия позволили сократить кодовую базу проекта практически вдвое, что сильно упростило следующий шаг рефакторинга.

Стадия третья: критические проблемы

Наконец мы подошли непосредственно к самому рефакторингу, который я буду проводить с помощью среды разработки Intellij Idea.

Первый запуск анализатора дает следующий результат:

24 критических ошибки и ~ 37 тысяч предупреждений — не так уж плохо, по сравнению с тем что бывает на свете.

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

Так что эти места стоит рефакторить в первую очередь, пока проект хотя-бы собирается из исходников.

Есть и хорошая новость:

Как видно из скриншота выше, большая часть критичных ошибок гнездится в классе JPCApplet, который используется для запуска приложения в режиме Java-апплета — ныне устаревшей технологии, когда-то работавшей с помощью плагина для браузера.

Поскольку плагин более официально не поддерживается — вся технология приказала долго жить и у обычных пользователей не встречается, так что класс можно удалить.

Но все несколько сложнее, поскольку еще есть вложенные классы, один из которых используется снаружи (org.jpc.j2se.JPCApplication):

JPCApplet.PlayPausePanel pp = new JPCApplet.PlayPausePanel(this);

Я просто перенес этот класс по месту использования, что позволило наконец удалить JPCApplet из проекта целиком.

Получилось минус 13 критических ошибок.

Еще один источник проблем — класс LinkBorder также можно удалить, поскольку он использовался лишь из удаленного JPCApplet.

Что дало еще минус три критических ошибки.

Дальше смотрим класс org.jpc.emulator.peripheral.Mixer, который забит предупреждениями от анализатора буквально через каждую строчку, однако вносить массовые правки пока не стоит — «всемогущая» Idea временами ошибается и это именно такой случай.

Ограничимся лишь одним методом:

private void ShowVolume(String name,FloatRef vol0,FloatRef vol1) {
System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",new Object[] {name,
new Float(vol0.value*100),new Float(vol1.value*100),
new Float(20*Math.log(vol0.value)/Math.log(10.0f)),new Float(20*Math.log(vol1.value)/Math.log(10.0f))}
);
}

Анализатор ругается (в первую очередь) на конструктор new Float(), поскольку его прямое использование объявлено устаревшим, а в новых версиях Java стоит использовать Float.valueOf() в качестве замены.

Но как только вы замените конструктор, анализатор подскажет еще несколько оптимизаций, так что конечный вариант будет достаточно сильно отличаться:

System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",
name,
vol0.value * 100, vol1.value * 100,
20*Math.log(vol0.value)/Math.log(10.0f),
20*Math.log(vol1.value)/Math.log(10.0f));

Следующий класс для изучения org.jpc.j2se.PCMonitorFrame, где анализатор ругается на два места с критическими ошибками.

Первое место характерно для устаревших проектов и встретится еще не раз:

catch (AccessControlException e)
{
LOGGING.log(Level.WARNING, "Not able to add some components to frame.", e);
}

Дело в том что класс ошибки, которая тут обрабатывается объявлен устаревшим в новых версиях:

'java. security. AccessControlException' is deprecated since version 17 and marked for removal

Поскольку исключение AccessControlException в новых версиях не выбрасывается, весь блок try-catch можно спокойно удалить.

Следующее место, код в этом же классе:

if (runner.isAlive())
{
try
{
runner.stop();
}
catch (SecurityException e) {}
}

Ругается анализатор на уникальный метод stop(), который был отмечен как устаревший еще до того как я начал писать на Java:

'stop()' is deprecated since version 1.2 and marked for removal

Примерно до версии 1.8 использование данного метода еще можно было как‑то оправдать наличием устаревших библиотек, в нынешних реалиях этот метод — просто еще один способ «выстрелить себе в ногу»:

Stopping a thread causes it to unlock all the monitors that it has locked.

Так что в коде использование этого метода точно стоит заменить на стандартный .interrupt() :

if (runner.isAlive())
{
runner.interrupt();
}

Блок try-catch также можно спокойно убрать, поскольку SecurityException не выбрасывается в новых версиях Java при попытке остановки нити.

На этом все критические проблемы в проекте решены и получен минимальный практический смысл от всей затеи:

убраны места, которые могут сломать сборку проекта в новых версиях Java

Стадия четвертая: ошибки выполнения

Пришло время наконец попробовать запустить нашего «франкенштейна».

Сборка разумеется завершится успешно (не зря же старались), но при запуске будет выбрасываться все та же ошибка поиска ресурсов:

В оригинальной версии JPC, часть ресурсов (например образы биоса) загружались только из jar‑файла, часть (образы дисков) — только снаружи, из каталога resources, при этом каталог с ресурсами был общим.

Сию дичь необходимо пресечь и сделать в более адекватном стиле, например как это реализовано в движке знаменитого Quake:

сначала ищем внешний файл, если не найден — ищем в ресурсах, если не найден в ресурсах — падаем с ошибкой

За чтение образа BIOS отвечает вот такой метод в классе org.jpc.emulator.motherboard.Bios:

private static final byte[] getBiosData(String image) throws IOException {
InputStream in = Bios.class.getResourceAsStream(image);
if (in == null) {
throw new IOException("resource not found: " + image);
}
try {
ByteArrayOutputStream bout = new ByteArrayOutputStream();

while (true) {
int ch = in.read();
if (ch < 0) {
break;
}
bout.write((byte) ch);
}

return bout.toByteArray();
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}
}

В принципе за такую реализацию уже можно начинать бить, спасает лишь факт, что столь идиотсткое побайтовое чтение работает исключительно с ресурсами, которые уже находятся в памяти.

Конечный вариант после всех чисток выглядит так:

private static byte[] getBiosData(String image) throws IOException {

File f = new File(image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

f = new File("resources",image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

final URL u = Bios.class.getResource(image);
if (u == null)
throw new IOException("resource (bios) not found: %s".formatted(image));

try (InputStream in = u.openStream()) {
return in.readAllBytes();
}
}

Логика переделана на возможности современной Java 17, поэтому кода стало сильно меньше, также были добавлены проверки на наличие ресурса:

• по полному пути,

• по частичному (предполагается что файл находится в каталоге resources),

• поиск внутри jar приложения.

Но при следующей попытке запуска получаем еще одно исключение, уже в другом месте:

Причиной является искусственная проверка:

if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();

Когда-то давно системный загрузчик классов действительно наследовался от URLClassLoader, так что проверка бы отработала.

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

Однако одним лишь удалением проверки дело не ограничилось — необходимо почистить еще один метод, реализующий «закат солнца вручную»:

private static final Iterator<String> getResources(String directory)
{
ClassLoader context = Thread.currentThread().getContextClassLoader();

List<String> resources = new ArrayList<String>();

ClassLoader cl = JPCApplication.class.getClassLoader();
if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();
URL[] urls = ((URLClassLoader) cl).getURLs();

int slash = directory.lastIndexOf("/");
String dir = directory.substring(0, slash + 1);
for (int i=0; i<urls.length; i++)
{
if (!urls[i].toString().endsWith(".jar"))
continue;
try
{
JarInputStream jarStream = new JarInputStream(urls[i].openStream());
while (true)
{
ZipEntry entry = jarStream.getNextEntry();
if (entry == null)
break;
if (entry.isDirectory())
continue;

String name = entry.getName();
slash = name.lastIndexOf("/");
String thisDir = "";
if (slash >= 0)
thisDir = name.substring(0, slash + 1);

if (!dir.equals(thisDir))
continue;
resources.add(name);
}

jarStream.close();
}
catch (IOException e) { e.printStackTrace();}
}
InputStream stream = context.getResourceAsStream(directory);
try
{
if (stream != null)
{
Reader r = new InputStreamReader(stream);
StringBuilder sb = new StringBuilder();
char[] buffer = new char[1024];
try
{
while (true)
{
int length = r.read(buffer);
if (length < 0)
{
break;
}
sb.append(buffer, 0, length);
}
} finally
{
r.close();
}

for (String s : sb.toString().split("\n"))
{
if (context.getResource(directory + s) != null)
{
resources.add(s);
}
}
}
}
catch (IOException e)
{
LOGGING.log(Level.INFO, "Exception reading images directory stream", e);
}

return resources.iterator();
}

Тут происходит поиск доступных образов дисков путем последовательного перебора всех файлов внутри .jar с приложением.

С учетом того что .class файлов внутри ~6500 — такое решение мягко говоря «не оптимально».

Вообще говоря любой поиск ресурсов через перебор во время работы приложения является медленным, это и есть основная причина медленного запуска любого приложения на (например) Spring Boot.

Поскольку в проекте используется очень небольшое количество образов диска и нет вариантов по резкому увеличению их количества, я просто зашил названия в код:

private static final String[] IMAGES = {
"images/dosgames.img",
"images/floppy.img",
"images/linux.img",
"images/odin070.img",
};

private static Iterator<String> getResources(String directory)
{
final List<String> resources = new ArrayList<String>
(Arrays.stream(IMAGES).toList());
final File f = new File(directory);

if (!f.exists() || !f.isDirectory()) {
return resources.iterator();
}

final File[] files = f.listFiles();

if (files == null) {
return resources.iterator();
}
for (File ff: files) {
resources.add(directory + ff.getName());
}

return resources.iterator();
}

Метод getResources() используется для отображения списка доступных образов дисков через меню приложения, все внутренние образы (зашитые в.jar) добавляются в этот список автоматически.

После столь примитивной правки, приложение стало запускаться визуально быстрее даже на мощном современном ноутбуке, так что не стоит недооценивать силу простых решений ;)

Хотя всех правок выше оказалось недостаточно, следующая остановка — класс org.jpc.support.ArrayBackedSeekableIODevice, который (внезапно) играет ключевую роль в проекте.

Метод configure() отвечает непосредственно за загрузку образов дисков и дискет:

public void configure(String spec) throws IOException
{
resource = spec;
imageOffset = 0;

InputStream in = ArrayBackedSeekableIODevice.class.getClassLoader().getResourceAsStream(resource);
if (in == null) {
LOGGING.log(Level.SEVERE, "resource not found: {0}", resource);
throw new IOException("resource not found: " + resource);
}
try {
byte[] buffer = new byte[1024];
ExposedByteArrayOutputStream bout = new ExposedByteArrayOutputStream(32*1024);

while (true) {
int read = in.read(buffer);
if (read < 0)
break;
bout.write(buffer, 0, read);
}

imageData = bout.getBuffer();
length = bout.getPosition();
} catch (IOException e) {
LOGGING.log(Level.SEVERE, "could not load file", e);
throw e;
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}

Переделываем с учетом современных реалий:

public void configure(String spec) throws IOException {
resource = spec;
imageOffset = 0;

File f = new File(spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}

f = new File("resources",spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}
final URL u = ArrayBackedSeekableIODevice.class.getResource(spec);
if (u == null)
throw new IOException("resource (image) not found: %s"
.formatted(spec));

try (InputStream in = u.openStream()) {
imageData = in.readAllBytes();
length = imageData.length;
}
}

Тут тоже три последовательные проверки на поиск образа диска и использование современного API для минимизации кодовой базы.

Эта доработка оказалась финальной и наконец можно успешно запустить эмулятор:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -hda src/main/resources/images/linux.img

Будет запущен Qemu Linux Test Distribution:

Или так:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -fda mem:images/odin070.img

запустится FreeDOS ODIN:

На этой стадии была проведена самая настоящая «коммерческая оптимизация» — доведен до ума функционал актуальный конечным пользователям.

Так что вас за такое-то скотство, проведенное с рабочим проектом уже точно не уволят ;)

Стадия пятая: массовые правки

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

массовые и сквозные правки исходного кода, во всем проекте целиком

Рабочая область выглядит как-то так:

Собственно все «желтенькое» на скриншоте ниже — места для рефакторинга, заботливо подсказанные средой разработки:

К сожалению на практике все несколько сложнее чем подсказывает Idea и просто нажимать «Alt + Shift + Enter» на каждую подсказку не стоит:

Все потому, что в проекте активно используется Reflection API для загрузки и обращения к методам класса необычными способами:

try {
Method valueOf = type.getMethod("valueOf", String.class);
return valueOf.invoke(type, value);
} catch (NoSuchMethodException e) {
System.err.println(type + " :No suitable method");
}

Что сводит анализаторы исходного кода с ума, поэтому примерно половина методов в проекте десктоп-приложения, не использующего никакие IoC-контейнеры отмечено как неиспользуемые:

Скотство?

Конечно скотство, но и в реальных больших и старых проектах такое тоже будет в обязательном порядке — когда‑то использование Reflection API считалось модным и молодежным явлением, убрать которое "под капот" смогли только те самые IoC‑контейнеры вроде Spring.

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

Лямбды появились еще в Java 8 и с тех пор уже нет никакого здравого смысла их игнорировать — они здорово сокращают объем кода:

В любом legacy-проекте, особенно если это приложение для десктопа такого будет очень и очень много:

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

Хороший пример, подсказанный анализатором:

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

Следующие две проблемы — также частые гости устаревших проектов:

Точно также как и с ненужными модификаторами в интерфейсе, всего лишь занимают место и увеличивают объем кода.

Хотя пример выше это совсем уж старый код, поскольку метод Arrays.asList () появился еще в Java 7 — былинные времена далекого прошлого, как можно было его сохранить до сих пор — загадка.

Эпилог

Если вы никогда не видели JPC то стоит посмотреть, поскольку он в свое время несколько расширил мнение о возможности Java, в первую очередь в плане производительности — тема о которой много и сильно шутили еще 10 лет назад.

Ну а если перед вами стоит задача провести подобный рефакторинг — стадии с первой по четвертую фактически являются руководством к действию.

Массовые правки я бы с ходу делать не рекомендовал — очень уж высокие риски, что что‑то пойдет не так.

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

P.S.

Статья была опубликована на Хабре,  оригинал доступен в нашем блоге.

Все началось когда автор наткнулся на одну интересную статью где эксперт по 3D-технологиям вместил специально оптимизированный и обфусцированный код рейтрейсера на C++ в размеры своей визитки.

Вот такой код:

#include <stdlib.h> // card > aek.ppm
#include <stdio.h>
#include <math.h>
typedef int i;typedef float f;struct v{
f x,y,z;v operator+(v r){return v(x+r.x
,y+r.y,z+r.z);}v operator*(f r){ return
v(x*r,y*r,z*r);}f operator%(v r){return
x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r
){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r.
y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v
operator!(){return*this*(1/sqrt(*this%*
this));}};i G[]={133022, 133266,133266,
133022, 254096, 131216, 131984, 131072,
258048,};f R(){return(f)rand()/RAND_MAX
;}i T(v o,v d,f&t,v&n){t=1e9;i m=0;f p=
-o.z/d.z; if(.01<p)t=p, n=v(0,0,1),m=1;
for(i k=19;k--;)for(i j=9;j--;)if(G[j]&
1<<k){v p=o+v(-k,0,-j-4);f b=p%d,c=p%p-
1,q=b*b-c;if(q>0){f s=-b-sqrt(q);if(s<t
&&s>.01)t=s,n=!(p+d*t),m=2;}}return m;}
v S(v o,v d){f t;v n;i m=T(o,d,t,n);if(
!m)return v(.7,.6,1)*pow(1-d.z,4);v h=o
+d*t,l=!(v(9+R(),9+R(),16)+h*-1),r=d+n*
(n%d*-2);f b=l%n;if(b<0||T(h,l,t,n))b=0
;f p=pow(l%r*(b>0),99);if(m&1){h=h*.2;
return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1
,1):v(3,3,3))*(b*.2+.1);}return v(p,p,p
)+S(h,r)*.5;}i main(){printf("P6 512 "
"512 255 ");v g=!v(-6,-16,0),a=!(v(0,0,
1)^g)*.002,b=!(g^a)*.002,c=(a+b)*-256+g
;for(i y=512;y--;)for(i x=512;x--;){v p
(9,9,9);for(i r=64;r--;){v t=a*(R()-.5)
*99+b*(R()-.5)*99;p=S(v(17,16,8)+t,!(t*
-1+(a*(R()+x)+b*(y+R())+c)*16))*3.5+p;}
printf("%c%c%c",(i)p.x,(i)p.y,(i)p.z);}}

После компиляции:

c++ -O3 -o card card.cpp

Генерировал у автора вот такую картинку:

Мы позеленели от зависти тоже захотели себе что-то такое, но поскольку занимаемся все же серверами а не 3D-графикой и больше Java, чем C++ — решили что будет круто уместить на обратной стороне нашей визитки простейший HTTP-сервер на Java.

Вместе с запуском и компиляцией.

Еще при наличии графического окружения будет запущен браузер.

Плюс немного криптографии для защиты от подделки.

Весь код уместился в 18 строк, выровненных по ширине так чтобы влезть в размеры визитки:

Вбиваете код с визитки в любимый редактор, сохраняете файл как vcard.sh и запускаете:

chmod +x ./vcard.sh
./vcard.sh

Результат:

Локально запустится простейший HTTP-сервер, который отдаст текстовую страничку с нашими контактами. При наличии GUI  — запустится еще и браузер по-умолчанию, с автоматическим открытием страницы этого сервера.

И все это в 18 строк кода.

Да, еще будет нужен любой Linux/BSD/MacOS/Solaris и любая версия JDK начиная с 1.8 на машине.

Поддержку запуска на Windows делать не стал (хотя это и возможно технически), но можно спокойно запустить в WSL .

Чтобы вы не мучились с вводом кода с картинки, вот текстовая версия:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0
i com.sun.net.httpserver.*;i j.awt.Desktop;i j.io.*;i j.util.*;i j.net.*;i j.nio.file.*;
i java.security.MessageDigest;i javax.crypto.Cipher;i javax.crypto.spec.SecretKeySpec;
p class Yo{p static void main(String[]args)throws E!{Cipher dcipher=Cipher.getInstance("AES");
dcipher.init(2,new SecretKeySpec(Arrays.copyOf(MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0]))).replaceFirst("ED=\"([^<]*)\";","")
.trim().getBytes()),16),"AES"));String ddata=new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)),"U8!");int p=8000;String h="0x7f000001";HttpServer s=HttpServer.create()
.createContext("/",(HttpExchange t)->{String r=String.format(ddata,System.nanoTime());t.getRE?()
.set("Content-type","text/plain;charset=U8!");t.sendRE?(200,r.getBytes("U8!").length);
try(OutputStream os=t.getResponseBody()){os.write(r.getBytes("U8!"));}}).getServer();
s.bind(new InetSocketAddress(p),1);new Timer().schedule(new TimerTask(){public void run(){
if(!Desktop.isDesktopSupported()){System.out.println(ddata);return;}try{Desktop.getDesktop()
.browse(new URI("http://"+h+":"+p));}catch(E! e){throw new RuntimeE!(e);}}},2000);s.start();}
static String ED="TfPrCIlXEUInGJPpr4++hQfa2Whq4RFzdbFP5C4s/s8=";}

Ну разве не прелесть?

Как это работает

Тут используется связка из заголовочного shell-скрипта и слегка обфусцированного кода на Java. Еще я не стал кодировать весь блок на Java полностью в HEX-строку, чтобы визуально оставалось ощущение исходного кода.

Начнем с заголовочного скрипта:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0

Самая первая строчка:

#!/bin/sh

Это shebang, стандартное для Unix указание на используемый интерпретатор, про него и так все знают. Дальше происходит создание временного каталога в /tmp и присваивание его имени переменной в скрипте:

t=$(mktemp -d);

Затем получение скриптом собственного имени с полным путем:

e=$(realpath $0);

Чтение скриптом самого себя, с отрезанием первых 4х строк - чтобы получить блок кода на Java:

sed '1,4d' $0

Дальше начинается pipe, в котором результат предыдущей команды передается на вход следующей:

|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java

Результат всех преобразований записывается в файл Yo.java, в том самом временном каталоге.

Малоизвестная опция -XDignore.symbol.file отключает предупреждение об использовании системных классов JDK (com.sun.net.httpserver.*) в проекте — в 1.8 версии классы встроенного в JDK HTTP-сервера еще считались системными.

Запуск с передачей полного пути оригинального скрипта для последующего его чтения из Java-кода:

java -cp . Yo $e

Сам код после деобфускации и форматирования выглядит уже вот так:

import com.sun.net.httpserver.*;
import java.awt.Desktop;
import java.io.*;
import java.util.*;
import java.net.*;
import java.nio.file.*;
import java.security.MessageDigest;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
public class Yo {
public static void main(String[] args) throws Exception {
Cipher dcipher = Cipher.getInstance("AES");
dcipher.init(2,
new SecretKeySpec(Arrays.copyOf(
MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0])))
.replaceFirst("ED=\"([^<]*)\";", "")
.trim().getBytes()), 16), "AES"));
String ddata = new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)), "UTF-8");
int p = 8000;
String h = "0x7f000001";
HttpServer s = HttpServer.create()
.createContext("/", (HttpExchange t) -> {
String r = String.format(ddata, System.nanoTime());
t.getResponseHeaders()
.set("Content-type", "text/plain;charset=UTF-8");
t.sendResponseHeaders(200, r.getBytes("UTF-8").length);
try (OutputStream os = t.getResponseBody()) {
os.write(r.getBytes("UTF-8"));
}
}).getServer();
s.bind(new InetSocketAddress(p), 1);
new Timer().schedule(new TimerTask() {
public void run() {
if (!Desktop.isDesktopSupported()) {
System.out.println(ddata);
return;
}
try {
Desktop.getDesktop()
.browse(new URI("http://" + h + ":" + p));
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}, 2000);
s.start();
}
static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";
}

Тут уже большая часть логики вполне очевидна, поэтому раскрою лишь два самых сложных фрагмента.

Криптография

Когда я только начинал думать над реализацией этой штуки, уже было ясно что нужен какой-то неочевидный контроль целостности:

исходный код очевидно будут пересылать через сообщения, в виде постов или по почте, что легко его сломает.

Поэтому хотелось хоть какую-то защиту от подделки содержимого, чтобы компьютерные дети не добавили патч Брамина в самое интересное место, а индийский паренек не подменил авторство и мои контакты на свои, ради строчки в резюме.

Задачу усложнял факт передачи открытых исходников и ограничение по размерам, но видимо получилось:

static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";

Именно тут находится текст:

We write software. @alex0x08

На каждую попытку как-то подменить содержимое (включая заголовок) будет выдаваться вот такая ошибка:

Exception in thread "main" javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:981) at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1062) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at Yo.main(Yo.java:6)

Получается код сам себя защищает от подделки.

0x7f000001

Вторым неочевидным моментом является вот такой странный адрес хоста:

String h = "0x7f000001";

Который используется при формировании ссылки для открытия браузером:

Desktop.getDesktop().browse(new URI("http://" + h + ":" + p));

Такое применение однозначно говорит о том что адрес очень даже стандартный, поскольку проходит как стадию валидации на стороне Java при формировании объекта URI, так и валидацию на стороне запускаемого браузера.

Это просто нотация, вариант написания IP-адреса 127.0.0.1, обозначающего loopback (петлю) — внутренний интерфейс, к которому можно подключиться локально, а не из сети.

Вот тут больше примеров различных вариантов написания IP-адресов, уверен — удивит даже бывалых админов.

P.S.

Статья была опубликована на Хабре, более фривольный оригинал статьи находится в нашем блоге, где мы подробно рассказываем об ужасах разработки, вгоняя в краску даже опытных и бывалых.

Волшебный мир Windows

Немного матчасти для тех кто не знает об этом языке:

Go (часто также golang) — компилируемый многопоточный язык программирования, разработанный внутри компании Google[11]. Разработка Go началась в сентябре 2007 года, его непосредственным проектированием занимались Роберт Гризмер, Роб Пайк и Кен Томпсон[12], занимавшиеся до этого проектом разработки операционной системы Inferno. Официально язык был представлен в ноябре 2009 года.

Автор, как и наверное большинство разработчиков, считал Golang всего лишь новомодной корпоративной игрушкой, призванной подсадить широкие программисткие массы на очередную технологию «корпорации добра» — создавался этот язык внутри Гугла и для задач Гугла, которые разумеется сильно отличаются от обывательских.

Поэтому когда мне показали работу Golang с WinAPI «из коробки» я был сильно удивлен — в более серьезных языках вроде C/C++ работа c внутренностями Windows всегда выглядела куда более монструозной. Так и родилась эта замечательная статья.

Что мы будем в этот раз творить:

Desktop-приложение с настоящим интерфейсом, с учетом реалий Windows, которое запустит встроенный вебсервер, с методом REST API на ассемблере.

Еще будет загрузка графического файла и установка его в качестве обоев — через WinAPI. Плюс небольшой обход файрвола, чтобы не показывался вот этот раздражающий экран с предупреждением:

Надеюсь описанное в статье удивит даже опытных разработчиков на Golang.

Собственно так выглядит наш сегодняшний герой в действии:

А так выглядит работа с системным треем:

Еще у нас будет стандартный модальный диалог:

И конечно встроенный веб-сервер, с веб-интерфейсом:

По традиции весь проект целиком выложен на Github.

Сборка и запуск

Начну с банального — как всю эту дикую радость собрать и запустить. Первым делом разумеется надо скачать и установить Go:

Для Windows уже давно существуют готовые официальные сборки Golang, даже с инсталлятором.

Взять можно с официального сайта Golang, вот тут.

Я использовал последнюю на момент написания версию 1.22.5, но язык столь бурно развивается, что не удивлюсь если выйдет более новая версия еще до завершения статьи.

Разработка проекта происходила в Visual Studio Code, который давно и официально поддерживает Go:

Теперь самое интересное:

для сборки проекта использовались не обычные Makefile и не шелл-скрипты — так характерные для проектов на «гошечке», а целая отдельная внешняя система сборки — Magefile.

Ставится она множеством разных способов, я использовал вот такой:

git clone https://github.com/magefile/mage
cd mage
go run bootstrap.go

После установки в окружении появляется бинарник mage, отвечающий за сборку:

Забираем проект:

git clone https://github.com/alex0x08/golang-winapi-asm.git

Скачиваем и устанавливаем зависимости:

mage install

Собираем:

mage build

Если сборка прошла успешно, в текущем каталоге будет файл ungoogled-go.exe, который можно свободно перемещать и запускать на пользовательских компьютерах — он полностью статичный и не зависит от установленного Golang.

Опционально можно запустить:

mage generate

Этой командой запустится генерация файлов add.s и stub.go — для метода на ассемблере. Стоит также отметить, что конечная и отладочная сборка немного отличаются, разделение происходит путем проброса параметра:

-X main.DebugMode=false

Которым изменится значение глобальной переменной — флагом отладочного режима, который в свою очередь немного влияет на поведение программы.

Теперь начинаем разбираться, как же оно все работает.

Приложение Windows

Если попробовать собрать и запустить в Windows классический «Hello world» на C:

#include <stdio.h>
int main() {
printf("Hello, World!");
return 0;
}

Вместо ожидаемого пустого графического окна запустится страшная черная консоль как на снимке выше. Это происходит потому что в Windows для графических программ используется другая точка запуска (entry point):

Every Windows program includes an entry-point function named either WinMain or wWinMain.

И если уж жизнь вас заставила разрабатывать на Go под Windows, еще и с графическим интерфейсом, то стоит «гошечке» об этом сообщить, добавив флаг в параметры ldflags.:

-H windowsgui

Целиком это выглядит так:

go build -ldflags "-H windowsgui"

Помимо этого, я указываю режим сборки exe:

-buildmode=exe
Build the listed main packages and everything they import into
executables. Packages not named main are ignored.

Для того чтобы получить в итоге сборки один большой и переносимый запускаемый exe файл.

Golang и WinAPI

Стоит пояснить читателям, в чем вообще заключается сложность работы с WinAPI. Для примера возьмем официальный «Hello world» на C++ под Windows:

#ifndef UNICODE
#define UNICODE
#endif

#include <windows.h>

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg,
WPARAM wParam,
LPARAM lParam);

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE,
PWSTR pCmdLine, int nCmdShow)
{
// Register the window class.
const wchar_t CLASS_NAME[] = L"Sample Window Class";

WNDCLASS wc = { };

wc.lpfnWndProc = WindowProc;
wc.hInstance = hInstance;
wc.lpszClassName = CLASS_NAME;

RegisterClass(&wc);

// Create the window.
HWND hwnd = CreateWindowEx(
0, // Optional window styles.
CLASS_NAME, // Window class
L"Learn to Program Windows", // Window text
WS_OVERLAPPEDWINDOW, // Window style

// Size and position
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

NULL, // Parent window
NULL, // Menu
hInstance, // Instance handle
NULL // Additional application data
);

if (hwnd == NULL)
{
return 0;
}

ShowWindow(hwnd, nCmdShow);

// Run the message loop.
MSG msg = { };
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg,
WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_PAINT:
{
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hwnd, &ps);
// All painting occurs here, between BeginPaint and EndPaint.
FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_WINDOW+1));
EndPaint(hwnd, &ps);
}
return 0;
}
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

Ну что, много тут понятного?

А все потому что 90% кода даже в столь простом приложении не имеют никакого отношения к C++, а являются структурами, макросами или функциями самого WinAPI.

От C++ тут только примитивные типы (int) и управляющие конструкции (case, while).

Поэтому задача как-то серьезно взаимодействовать с WinAPI (дальше чем разовый вызов какой-то функции) — всегда была, есть и будет сложной. А разработка под Windows является отдельной специальной дисциплиной, чемпионы которой запросто могут забыть обычный C/C++ вообще и всю разработку (даже серверную) вести на инструментах WinAPI.

Но вернемся к нашей «гошечке».

Go далеко не C++ и является экзотикой в мире Windows-разработки, по крайней мере за пределами кампусов Google.

Но внезапно оказалось, что поддержка WinAPI в нем очень даже неплоха.

Взгляните как выглядит вызов WinAPI функции для установки обоев на Golang:

var (
user32DLL = windows.NewLazyDLL("user32.dll")
procSystemParamInfo = user32DLL.NewProc("SystemParametersInfoW")
)
func main() {
imagePath, _ := windows.UTF16PtrFromString(`image.jpg`)
fmt.Println("[+] Changing background now...")
procSystemParamInfo.Call(20, 0, uintptr(unsafe.
Pointer(imagePath)), 0x001A)
}

Тут красиво скрыты все скользкие моменты вроде передачи указателя на участок памяти, где лежит путь до файла с картинкой:

unsafe.Pointer(imagePath)

Или вопрос с кодировками:

windows.UTF16PtrFromString(`image.jpg`)

Не буду разбирать весь код, поскольку вот тут лежит отдельная большая статья, в которой все уже подробно расписано.

Скажу лишь что благодаря столь серьезной поддержке WinAPI, получилось создать этот тестовый проект и не утопить читателя утонуть в деталях реализации.

WinAPI и графический интерфейс

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

import (
"syscall"
"unsafe"
)

// MessageBox of Win32 API.
func MessageBox(hwnd uintptr, caption, title string, flags uint) int {
ret, _, _ := syscall.NewLazyDLL("user32.dll").
NewProc("MessageBoxW").Call(
uintptr(hwnd),
uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr(caption))),
uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr(title))),
uintptr(flags))
return int(ret)
}

// MessageBoxPlain of Win32 API.
func MessageBoxPlain(title, caption string) int {
const (
NULL = 0
MB_OK = 0
)
return MessageBox(NULL, caption, title, MB_OK)
}

И оно даже работало. Но только объем кода очень быстро вырос до былинных размеров и никак не влезал в масштаб статьи.

Поэтому от такого подхода пришлось отказаться, оставив лишь работу с системным треем.

Все остальное я отдал на откуп готовым библиотекам. В частности построение окон и обработку событий были реализованы через библиотеку Windigo. — хотя это по-сути лишь набор готовых биндингов для функций WinAPI.

Вот так выглядит в работе демо-приложение на Windigo:

func main()

Запуск приложения Go согласно спецификации начинается с функции func main() в пакете main:

A complete program is created by linking a single, unimported package called the main package with all the packages it imports, transitively. The main package must have package name main and declare a function main that takes no arguments and returns no value.

Первая же строка внутри main() нашего проекта нуждается в пояснении:

runtime.LockOSThread()

Этот вызов из пакета runtime нужен для того чтобы все goroutines (легковесные потоки Go) выполнялись в отдельных системных потоках каждый.

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

A goroutine should call LockOSThread before calling OS services or non-Go library functions that depend on per-thread state.

Следующим шагом происходит вызов функции, отвечающей за построение графического интерфейса:

mainWindow = newMyWindow()

Разберем как формируются и связываются графические элементы, в нашем проекте за это отвечает функция:

func newMyWindow() *MyWindow

Возвращаемая структура:

type MyWindow struct {
wnd ui.WindowMain
lblName ui.Static
txtName ui.Edit
btnShow ui.Button
}

Содержит все графические элементы — само окно (wnd), текстовую метку (lblName), текстовое поле (txtName) и кнопку (btnShow).

Первым делом происходит настройка создаваемого окна:

opts := ui.WindowMainOpts().
ClassStyles(co.CS_NOCLOSE).
Title("Tiny Server").
ClientArea(win.SIZE{Cx: 600, Cy: 245})

С помощью константы co.CS_NOCLOSE отключается кнопка закрытия окна:

CS_NOCLOSE 0x0200 Disables Close on the window menu.

Ну и дальше задается заголовок и размеры создаваемого окна — тут все просто. Зато сложно чуть ниже:

if DebugMode == "false" {
// ID of icon resource, see resources folder
// does not work in debug mode
opts = opts.IconId(101)
}

Тут указывается иконка окна в виде числового ID ресурса, файл с ресурсами minimal.syso был взят из демо-проекта Windigo:

A syso file, ready to use, that contains the icon and the manifest. Just place it at the root folder of your project. You can load the icon using the resource ID 101.

Следующим шагом происходит вызов сложной цепочки инициализации окна:

// create main window
wnd := ui.NewWindowMain(opts)

В конце которой вызывается известная функция WinAPI CreateWindowEx, используемая для создания нового графического окна.

Дальше происходит создание отдельных элементов:

// build UI
me := &MyWindow{
wnd: wnd,
// add label
lblName: ui.NewStatic(wnd,
ui.StaticOpts().
Text("Server log").
Position(win.POINT{X: 10, Y: 22}),
),
// add shutdown button
btnShow: ui.NewButton(wnd,
ui.ButtonOpts().
Text("&Quit").
Position(win.POINT{X: 510, Y: 17}),
),
// add message log (text area)
txtName: ui.NewEdit(wnd,
ui.EditOpts().
WndStyles(co.WS_CHILD|co.WS_VISIBLE|co.WS_VSCROLL).
CtrlStyles(co.ES_AUTOHSCROLL|co.ES_MULTILINE|co.ES_LEFT|co.ES_READONLY).
Position(win.POINT{X: 0, Y: 45}).
Size(win.SIZE{Cx: 600, Cy: 200}),
),
}

Важно отметить, что в случае WinAPI за любой ввод текста отвечает один и тот же компонент CEdit, c разным набором настроек:

• co.ES_MULTILINE — указание на ввод нескольких строк (как textarea в HTML);

• co.WS_VISIBLE — окно не будет скрыто;

• co.WS_VSCROLL — вертикальный скролл;

• co.ES_AUTOHSCROLL — автоматический горизонтальный скролл;

• co.ES_READONLY — только для чтения.

Дальше происходит настройка обработчика кнопки для завершения работы приложения:

// setup handler on 'shutdown' button click
me.btnShow.On().BnClicked(func() {
// start confirmation dialog
resp := me.wnd.Hwnd().MessageBox("Quit application?",
"Confirm quit", co.MB_YESNO)
// if user clicked 'YES' - shutdown application
if resp == co.ID_YES {
appendToLog("Exiting..")
if httpSrv != nil {
if err := httpSrv.Close(); err != nil {
fmt.Printf("HTTP close error: %v", err)
}
}
me.wnd.Hwnd().DestroyWindow()
os.Exit(0)
}
})

По клику запускается модальный диалог с блокировкой текущего треда:

resp := me.wnd.Hwnd().MessageBox("Quit application?",
"Confirm quit", co.MB_YESNO)

Если пользователь нажал кнопку «Yes» (т.е подтвердил операцию), происходит завершение работы HTTP-сервера:

if httpSrv != nil {
if err := httpSrv.Close(); err != nil {
fmt.Printf("HTTP close error: %v", err)
}
}

Закрытие главного окна приложения:

me.wnd.Hwnd().DestroyWindow()

И завершение работы:

os.Exit(0)

Следущим шагом из функции main мы загружаем иконку, используемую в трее:

var trayIcon win.HICON

// Load icon
// in debug mode, there are no resources available, so we need to load
// icons from FS
if DebugMode == "false" {
trayIcon = win.HICON(
win.GetModuleHandle(win.StrOptNone()).LoadImage(
win.ResIdInt(101),
co.IMAGE_ICON,
16, 16,
co.LR_DEFAULTCOLOR,
))
} else {
trayIcon = win.HICON(
win.GetModuleHandle(win.StrOptNone()).LoadImage(
win.ResIdStr("gopher.ico"),
co.IMAGE_ICON,
16, 16,
co.LR_DEFAULTCOLOR|co.LR_LOADFROMFILE,
))
}

Используется разная логика для режима отладки и запуска финального бинарника, потому что в готовом приложении иконка будет находиться в ресурсах — специальном файле, упакованном вместе с приложением.

А во время отладки либо запуска вроде:

go run main.go

ресурсов не будет, поэтому придется загружать иконку непосредственно с файловой системы.

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

// close systray on main window destroy
mainWindow.wnd.On().WmDestroy(func() {
if tray != nil {
tray.Dispose()
}
})

При закрытии главного окна, произойдет и автоматическое закрытие трея — не будет эффекта потерянной инонки, когда приложение уже закрылось, а его иконка до сих пор отображается в трее.

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

var configured = false // check for action that runs only once

mainWindow.wnd.On().WmActivate(func(p wm.Activate) {
// we need to run our handler logic only once at start
if configured {
return
}
configured = true
go startServer()
})

Столь отложенный старт необходим для большей интерактивности:

метод startServer () пишет сообщения в «графический лог», если он не будет полностью инциализирован — сообщения пропадут.

Проблема заключается в том что этот обрабочик будет запускаться и на повторную активацию (например после сворачивания окна) — чтобы логика не отрабатывала повторно стоит проверка на переменную configured, которая работает в качестве флага «инициализация завершена».

Ну и сам запуск HTTP-сервера происходит через отдельный поток, чтобы не блокировать работу обработчика:

go startServer()

Последним мы добавляем инициализацию трея по событию создания главного окна:

// action on windows create
// runs once
mainWindow.wnd.On().WmNcCreate(func(p wm.Create) bool {
// create systray
tray := systray.CreateSysTray()
// set handler on icon click - just focus on main window
systray.SetTrayClickHandler(func() {
systray.ShowWindow(uintptr(mainWindow.wnd.Hwnd()),
systray.SW_SHOWNORMAL)
})

tray.SetIcon(uintptr(trayIcon))
tray.SetTooltip("Tiny Server: click me to show main window.")

return true
})

Нужно это по той простой причине что только на этой стадии появляется настоящий window handle:

mainWindow.wnd.Hwnd()

С помощью которого возможно взаимодействовать с окном:

systray.ShowWindow(uintptr(mainWindow.wnd.Hwnd())

До этого момента (т.е. до вызова обработчика) HWND нашего окна будет пустым. Наконец финальный шаг в функции main() это запуск блокирующего цикла обработки cобытий:

mainWindow.wnd.RunAsMain()

После вызова этого метода, приложение начнет реагировать на события вроде нажатия клавиш или кликов мышкой.

Теперь разберем работу с системным треем — как пример работы с чистым WinAPI.

Работа с системным треем

Разумеется есть способ проще:

взять одну из готовых библиотек, тем более что есть универсальные — сразу для Windows, MacOS и Linux и всей кучи разных сред окружения.

Но фана ради и пользы обучения для, был избран более сложный путь — закат солнца вручную взаимодействие с системным треем только через WinAPI.

Все функции, относящиеся к этой задаче находятся в пакете systray:

import (
..
systray "github.com/alex0x08/ungoogled-go/systray"
..
)

Место с которого начинается инициализация системного трея выглядит вот так:

// creates systray icon
func CreateSysTray() *TrayIcon {
// first, create hidden message-only window
hwnd, err := createMessageWindow()
if err != nil {
panic(err)
}
// create systray with parent = our message-only window
ti, err := newTrayIcon(hwnd)
if err != nil {
panic(err)
}
return ti
}

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

func createMessageWindow() (uintptr, error) {
hInstance, err := GetModuleHandle(nil)
if err != nil {
return 0, err
}

wndClass := windows.StringToUTF16Ptr("MyWindow")

var wcex WNDCLASSEX

wcex.CbSize = uint32(unsafe.Sizeof(wcex))
wcex.LpfnWndProc = windows.NewCallback(wndProc)
wcex.HInstance = hInstance
wcex.LpszClassName = wndClass
if _, err := RegisterClassEx(&wcex); err != nil {
return 0, err
}

hwnd, err := CreateWindowEx(
0,
wndClass,
windows.StringToUTF16Ptr(""),
WS_OVERLAPPED,
CW_USEDEFAULT,
CW_USEDEFAULT,
400,
300,
uintptr(HWND_MESSAGE),
0,
hInstance,
nil)
if err != nil {
return 0, err
}
return hwnd, nil
}

Ключевое тут — вызов функции WinAPI CreateWindowEx, c указанием специального флага HWND_MESSAGE:

hwnd, err := CreateWindowEx(
..
uintptr(HWND_MESSAGE)
..
)

Благодаря этому флагу можно создать невидимое окно и заставить его обработчик принимать сообщения системного трея:

// this is main window function
// see https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
func wndProc(hWnd uintptr, msg uint32, wParam, lParam uintptr) uintptr {
switch msg {
case TrayIconMsg:
nmsg := LOWORD(uint32(lParam))
// if user clicked on tray icon
if nmsg == WM_LBUTTONDOWN {
// if callback function exist
if trayClickCallback != nil {
trayClickCallback()
}
}
case WM_DESTROY:
PostQuitMessage(0)
default:
r, _ := DefWindowProc(hWnd, msg, wParam, lParam)
return r
}
return 0
}

Да, это все тот же старый добрый WndProc , описанный выше в статье и хорошо знакомый любым Windows-разработчикам.

Блок внутри:

..
case TrayIconMsg:
nmsg := LOWORD(uint32(lParam))
// if user clicked on tray icon
if nmsg == WM_LBUTTONDOWN {
// if callback function exist
if trayClickCallback != nil {
trayClickCallback()
}
}
..

Отвечает за обработку сообщений системного трея.

Функция, которая отрабатывает по событию клика левой кнопки мыши (WM_LBUTTONDOWN) выглядит вот так:

systray.SetTrayClickHandler(func() {
systray.ShowWindow(uintptr(mainWindow.wnd.Hwnd())
, systray.SW_SHOWNORMAL)
})

А systray.ShowWindow() это фактически обретка над чистым WinAPI:

func ShowWindow(hWnd uintptr, nCmdShow int32) (int32, error) {
r, _, err := procShowWindow.Call(hWnd, uintptr(nCmdShow))
if r == 0 {
return 0, err
}
return int32(r), nil
}

Поскольку procShowWindow — чистый definition для фукнции WinAPI ShowWindow:

..
libuser32 = windows.NewLazySystemDLL("user32.dll")
..
procShowWindow = libuser32.NewProc("ShowWindow")
..

Словом, уровень интеграции с WinAPI и легкости его применения поражает воображение.

Лог

Он же «журнал работы» — отображает события в приложении в центральной части рабочей области. Логика записи выглядит следующим образом:

// appends to UI log
func appendToLog(message string) {
// could be no window yet
if mainWindow == nil || mainWindow.txtName == nil {
fmt.Println(message)
return
}
// window could be not visible yet
// and attempt to add message will raise an exception
if !mainWindow.txtName.Hwnd().IsWindowVisible() {
fmt.Println(message)
return
}
// get current text
txt := mainWindow.txtName.Text()
// to avoid overflow
if len(txt) > 512 {
txt = ""
}
b := strings.Builder{}
b.WriteString(txt) // append existing text
b.WriteString(message) // append new message
b.WriteString("\r\n") // this is Windows, so \r\n, not \n !
// and finally set updated text (yep, there is no append, sorry)
mainWindow.txtName.SetText(b.String())
}

Кроме достаточно очевидного пропуска записи в случае неполной инициализации, тут есть еще вот такая логика:

if !mainWindow.txtName.Hwnd().IsWindowVisible() { fmt.Println(message) return }

Нужно это потому, что CEdit не даст изменить текст внутри если сам компонент еще не отображается, а попытка вызова метода API изменения текста вызовет ошибку.

Также внезапно (хотя для кого как) оказалось что стандартный компонент Windows для ввода не поддерживает логику добавления (append) — только полную замену всего текстового блока:

// get current text
txt := mainWindow.txtName.Text()
// to avoid overflow
if len(txt) > 512 {
txt = ""
}
b := strings.Builder{}
b.WriteString(txt) // append existing text
b.WriteString(message) // append new message
b.WriteString("\r\n") // this is Windows, so \r\n, not \n !
// and finally set updated text (yep, there is no append, sorry)
mainWindow.txtName.SetText(b.String())

Поэтому с точки зрения современной разработки это выглядит как колхоз, но увы — таковы реалии WinAPI.

Встроенный HTTP-сервер

В составе Golang идет готовый встраиваемый HTTP-сервер (пакет «net/http»), с примитивами обработчиков для типовых действий.

С его помощью удалось минимальными силами реализовать весь тестовый функционал, метод инициализации и запуска встроенного HTTP-сервера выглядит вот так:

// starts HTTP server
func startServer() {
appendToLog(fmt.Sprintf("Starting, debug mode: %s", DebugMode))

// firewall bypass does not work correctly in debug mode
if DebugMode == "false" {
server.AddAppFirewallRule()
appendToLog("Added firewall rule..")
}
// create request multiplexer, see https://pkg.go.dev/net/http#ServeMux
mux := http.NewServeMux()
// test assembler method
mux.HandleFunc("/asmtest", server.TestAsmMethod)
// upload & set wallpaper image
mux.HandleFunc("/upload", server.UploadHandler)
// default handler
mux.HandleFunc("/", server.IndexHandler)

// if this is production mode - bind to all interfaces
if DebugMode == "false" {
httpSrv = &http.Server{
Addr: ":8090",
Handler: mux,
}
} else {
// otherwise - bind to localhost (firewall bypass
// does not work in debug mode)
httpSrv = &http.Server{
Addr: "localhost:8090",
Handler: mux,
}
}

appendToLog(fmt.Sprintf("Server started at %s", httpSrv.Addr))
// set logging handler
server.SetMessageLogHandler(appendToLog)
httpSrv.ListenAndServe() // here will be lock
}

Разберем что тут происходит, первым шагом идет запись в лог:

appendToLog(fmt.Sprintf("Starting, debug mode: %s", DebugMode))

Затем попытка отключить NAG-screen файрвола:

// firewall bypass does not work correctly in debug mode
if DebugMode == "false" {
server.AddAppFirewallRule()
appendToLog("Added firewall rule..")
}

Как это работает подробно разобрано ниже, пока замечу что этот обход не работает в режиме отладки, поэтому тут и стоит такая странная на первый взгляд проверка.

Следующим шагом происходит инстанциация мультиплексора запросов:

// create request multiplexer, see https://pkg.go.dev/net/http#ServeMux
mux := http.NewServeMux()

И связывание методов обработки с контекстом URL:

// test assembler method
mux.HandleFunc("/asmtest", server.TestAsmMethod)
// upload & set wallpaper image
mux.HandleFunc("/upload", server.UploadHandler)
// default handler
mux.HandleFunc("/", server.IndexHandler)

Т.е. по какой ссылке будет отвечать каждый обработчик.

Логика всех обработчиков разобрана чуть ниже, а пока пройдем дальше по логике инициализации HTTP-сервера:

// if this is production mode - bind to all interfaces
if DebugMode == "false" {
httpSrv = &http.Server{
Addr: ":8090",
Handler: mux,
}
} else {
// otherwise - bind to localhost (firewall bypass
// does not work in debug mode)
httpSrv = &http.Server{
Addr: "localhost:8090",
Handler: mux,
}
}

Вся эта простыня нужна по той простой причине что в Golang нет тернаров, т.е нельзя сделать логику одной строкой вроде:

Addr = DebugMode? "localhost:8090" : ":8090"

Как это было бы в Java или Typescript.

Поэтому надо было либо делать отдельную функцию, отдающую адрес, внутри которой вставлять проверку на DebugMode, либо сделать как на примере выше — два повторяющихся блока.

Дальше по логике происходит установка обработчика логирования:

// set logging handler
server.SetMessageLogHandler(appendToLog)

Со стороны пакета сервера он вызвается вот так:

// logs message with callback on UI
func logMessage(message string) {
if messageLogCallback != nil {
messageLogCallback(message)
} else {
fmt.Println(message)
}
}

А вот так выглядит пример конечного использования:

logMessage(fmt.Sprintf("Background changed to %s", dst.Name()))

Наконец последним шагом происходит запуск самого HTTP-сервера:

httpSrv.ListenAndServe() // here will be lock

Обратите внимание что httpSrv объявлен как глобальная переменная:

var (
tray *systray.TrayIcon
httpSrv *http.Server
mainWindow *MyWindow
//You can only set string variables with -X linker flag. From the docs:
DebugMode = "true"
)

Это нужно чтобы иметь возможность остановить HTTP-сервер при завершении работы (graceful shutdown):

if httpSrv != nil {
if err := httpSrv.Close(); err != nil {
fmt.Printf("HTTP close error: %v", err)
}
}

Обход файрвола

И не надо так подозрительно смотреть — речь про вполне себе документированное API, позволяющее пропустить вот такое откровенно дурацкое подтверждение:

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

This is a package for controlling the Windows Filtering Platform (WFP), also known as the Windows firewall.

С его помощью вся логика свелась к вот такой простой функции, взятой из issue в Github проекта и немного переделанной:

// adds firewall rule via WinAPI to bypass confirmation screen
func AddAppFirewallRule() error {
session, err := wf.New(&wf.Options{
Name: "ungoogled session",
Dynamic: false,
})
if err != nil {
return err
}
defer session.Close()
guid, _ := windows.GenerateGUID()
execPath, _ := os.Executable()
appID, _ := wf.AppID(execPath)
err = session.AddRule(&wf.Rule{
ID: wf.RuleID(guid),
Name: "Ungoogled",
Layer: wf.LayerALEAuthRecvAcceptV4,
Weight: 800,
Conditions: []*wf.Match{
{
Field: wf.FieldALEAppID,
Op: wf.MatchTypeEqual,
Value: appID,
},
},
Action: wf.ActionPermit,
})

if err != nil {
return err
}
return nil
}

Не буду детально расписывать эту довольно сложно воспринимаемую логику — слишком уж тут много специфики WFP, читать устанете.

Если есть желание погрузиться в тему — вам в помощь вот такая замечательная статья от авторов пакета, где расписано в деталях внутренее устройство WFP и работа с его API.

Но если в кратце — тут происходит создание и применение нового правила фильтрации, которое разрешает входящие соединения для приложения, из которого выполняется вызов API.

Golang и ассемблер

Чтобы сразу закрыть все вопросы по поводу адекватности использования ассемблера из Go, вот вам небольшая цитата:

This example is taken from the AES package of the standard Go library. It makes use of Go Assembly to leverage Intel’s hardware support for AES, calling the AES-NI CPU instructions that can perform a “round” of encryption or decryption of the AES algorithm.

Да, как только начинается большая криптография и множественные вычисления на слабом железе — сразу с дальней полки достается пыльная книга по ассемблеру.

Разумеется не было открытием что язык, с самого своего начала имевший компилятор в нативный код умеет вызывать вставки на ассемблере. Открытием была легкость и простота с которой это делается.

Еще одним открытием оказались торчащие уши Plan 9:

The assembler is based on the input style of the Plan 9 assemblers, which is documented in detail elsewhere. If you plan to write assembly language, you should read that document although much of it is Plan 9-specific

А разгадка проста — один из авторов Go когда‑то работал над Plan 9:

Robert Pike (born 1956) is a Canadian programmer and author. He is best known for his work on the Go programming language while working at Google[1][2] and the Plan 9 operating system while working at Bell Labs, where he was a member of the Unix team.[1]

Но продолжим тему с ассемблером.

Вообщем чтобы не заморачиваться с созданием и линковкой ассемблерных вставок вручную, я использовал фреймворк Avo:

avo makes high-performance Go assembly easier to write, review and maintain.

Самое важное что он дает:

• Use Go control structures for assembly generation; avo programs are Go programs

И выглядит это именно так как звучит:

//go:build ignore

package main

import . "github.com/mmcloughlin/avo/build"

func main() {
TEXT("Add", NOSPLIT, "func(x, y uint64) uint64")
Doc("Add adds x and y.")
x := Load(Param("x"), GP64())
y := Load(Param("y"), GP64())
ADDQ(x, y)
Store(y, ReturnIndex(0))
RET()
Generate()
}

Это отдельная программа на Go, которая при запуске генерирует ассемблерный код в файле asm/add.s:

// Code generated by command: go run asm.go -out asmtest/add.s -stubs asmtest/stub.go. DO NOT EDIT.

#include "textflag.h"

// func Add(x uint64, y uint64) uint64
TEXT ·Add(SB), NOSPLIT, $0-24
MOVQ x+0(FP), AX
MOVQ y+8(FP), CX
ADDQ AX, CX
MOVQ CX, ret+16(FP)
RET

А также заголовочный файл на Go в файле stub.go:

// Code generated by command: go run asm.go -out asmtest/add.s -stubs asmtest/stub.go. DO NOT EDIT.
package ungoogled
// Add adds x and y.
func Add(x uint64, y uint64) uint64

Затем данные файлы линкуются с основным приложением, а вызов метода с ассемблерной вставкой выглядит вот так:

// a test API method to call function with Assembler inside
func TestAsmMethod(w http.ResponseWriter, req *http.Request) {

query := req.URL.Query()
fmt.Println("GET params were:", query)

param1, param2 := query.Get("param1"), query.Get("param2")

int1, _ := strconv.ParseUint(param1, 10, 64)
int2, _ := strconv.ParseUint(param2, 10, 64)
fmt.Fprintf(w, "int1: %v int2: %v \n", int1, int2)

// yep, check stub.go in asmtest
out := ungoogled.Add(int1, int2)

fmt.Fprintf(w, "result: %v \n", out)
logMessage(
fmt.Sprintf("Called asm method with params: %v , %v and result: %v",
int1, int2, out))
}

Лепота и благодать, другими словами.

Смена обоев через WinAPI и загрузку файлов

Просто для демонстрации возможностей, к достаточно стандартному функционалу по загрузке файлов был приделан вызов WinAPI функции для смены обоев на рабочем столе.

Сама форма загрузки выглядит максимально стандартно:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport"
content="width=device-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Upload an image</title>
</head>
<body>
<form
enctype="multipart/form-data"
action="/upload"
method="post">
<input type="file" name="imageFile" accept="image/*" />
<input type="submit" value="upload" />
</form>
</body>
</html>

Затем она зашивается в приложение с помощью go:embed:

//go:embed upload.html
var uploadTemplate string

Т.е. во время запуска приложения, переменная uploadTemplate будет содержать HTML-шаблон выше для загрузки картинки — зашивание происходит во время сборки.

За загрузку картинки отвечает функция:

func uploadFile(w http.ResponseWriter, r *http.Request) { .. }

Внутри стандартная скучная логика разборки multipart-формы и обработки загруженного файла - ее нет смысла описывать, зато дальше происходит кое-что интересное:

// build full path to image
imagePath, err := windows.UTF16PtrFromString(dst.Name())

Тут происходит формирование ссылки на UTF-16 строку, содержающую полный путь к загруженному файлу.

Затем эта ссылка используется для вызова API:

// call WinAPI to change wallpaper to just uploaded image
_, _, err = procSystemParamInfo.Call(20, 0,
uintptr(unsafe.Pointer(imagePath)), 0x001A)
// check for errors, respond 500 if any
if err, ok := err.(syscall.Errno); ok {
if err != 0 {
fmt.Println("Error :")
fmt.Println(err)
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
}

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

Retrieves or sets the value of one of the system-wide parameters. This function can also update the user profile while setting a parameter.

Нужный нам для смены обоев actionName называется SPI_SETDESKWALLPAPER который и указывается при вызове.

Эпилог

Разумеется я такой не один и уже достаточно много разработчиков по всему миру делятся своим опытом разработки на Go и WinAPI. Надеюсь эта статья также добавит читателям восторгов и позволит взглянуть на любимый инструмент под другим углом.

Статья была опубликована на Хабре, оригинал которой доступен в нашем блоге.

The Witchcraft Compiler Collection

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

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

WCC is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms.

Да да, "черная магия" тут дословная цитата из описания проекта, а не выдумки или особенности перевода.

Если вкратце, WCC это такой набор очень специфичных утилит для препари.. исследования чужих программ.

Информации об этой штуке в сети крайне мало, фактически помимо проекта на Github, существует лишь одна интересная презентация, показанная на конференции Defcon, слайды из которой также использовались в статье.

Так что материал получился весьма редким.

Сборка и инвольтация эгрегора

К сожалению проект успел немного устареть, хотя и присутствует в виде готовых пакетов во многих дистрибутивах Linux. Однако в Mageia, которую автор использовал ради колдовской ступы на логотипе в качестве тестовой среды, WCC почему-то не оказалось, так что пришлось собирать руками.

Согласно описанию, необходимо установить следующие пакеты:

capstone, glibc, libbfd, libdl, zlib, libelf, libreadline, libgsl, make

Однако libbfd ныне стал частью пакета binutils и отдельно более не поставляется, а binutils скорее всего уже установлен по-умолчанию.

Забираем исходники и запускаем сборку:

git clone https://github.com/endrazine/wcc.git
git submodule init && git submodule update && make

Конечно же попытка собрать себе "гримуар электронного колдуна" из исходников закончится закономерным провалом:

Взывание к темным богам и поиск проблемы, взятой из трассировки выше в разных поисковиках:

undefined reference to `sframe_encoder_write'

привел наконец к вот такому багрепорту из трекера Debian. Там же был обнаружен и этот адский патч для WCC:

diff -Nru wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch
--- wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch 2020-03-21 19:02:12.000000000 +0200
+++ wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch 2023-01-18 16:09:29.000000000 +0200
@@ -12,7 +12,7 @@
-all::
- $(CC) $(CFLAGS) wcc.c -o wcc -lbfd -lelf -lcapstone
+all:
-+ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -lz -ldl -liberty -lelf -lcapstone
++ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -l:libsframe.a -lz -ldl -liberty -lzstd -lelf -lcapstone
# $(CC) $(CFLAGS) -m32 -Wl,-rpath /home/jonathan/solution-exp/unlinking/awareness/self/wcc/src/wcc/lib32/ wcc.c -o wcc32 -lelf ./lib32/libbfd-2.24-system.so ./lib32/libcapstone.so.3

cp wcc ../../bin/

Как можно догадаться из этих двух строчек (если вы приличный маг):

-+ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -lz -ldl -liberty -lelf -lcapstone
++ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -l:libsframe.a -lz -ldl -liberty -lzstd -lelf -lcapstone

для завершения сборки необходимо изменить паметры, передаваемые линковщику.

Что я и проделал в файле src/wcc/Makefile:

После исправления, сборка заканчивается успешно и в каталоге bin появляются готовые к использованию "колдунские" приложения:

Теперь можно начинать плести заклинания.

Колдунство первое: превращаем приложение в библиотеку

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

Согласно описанию, все достаточно просто, хоть и необычно - примерно как обнаружить у девушки из Тайланда кадык:

Transforming an ELF executable binary into an ELF shared library.

Последовательность заклинаний шагов выглядит так:

После вызова этих нечистивых команд, то что было рождено программой для Linux, внезапно становится разделяемой библиотекой. А узревший такое в живую быдлокодер уезжает в дурку, отсыпаться и отдыхать.

Теперь рассказываю как это колдунство работает, внимание на экран:

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

Хотя назначение этого поля не является секретом и присутствует даже в Википедии, помимо официального руководства, до столь затейливого его применения никто на моей памяти не доходил. Кроме авторов WCC.

При вызове, первым шагом происходит откат работы линковщика:

The primary use of wcc is to "unlink" (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects. The following command line attempts to unlink the binary /bin/ls (from GNU binutils) into a relocatable file named /tmp/ls.o

Пример вызова:

wcc -c /bin/ls -o /tmp/ls.o

По идее уже на этой стадии должен быть получен «relocable file», с которым может работать обычный gcc. Например должна отрабатывать команда:

gcc /tmp/ls.o -o /tmp/ls.so -shared

К сожалению в моей Mageia это не сработало, поэтому был использован альтернативный вариант "очищения":

cp /bin/ls /tmp/ls.o
wld --libify /tmp/ls.o

Результат выполнения команды wld теперь спокойно распознается обычным компилятором gcc:

gcc /tmp/ls.o -o /tmp/ls.so -shared

И в результате действительно получается разделяемая библиотека, которую можно спокойно линковать с вашим приложением:

file /tmp/ls.so
/tmp/ls.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=68d93a1d888eb560b8842
55a59c37cd6be0adddd, not stripped

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

Но едем дальше.

Колдунство второе: рефлексия для.. чистого С

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

The witchcraft shell accepts ELF shared libraries, ELF ET_DYN executables and Witchcraft Shell Scripts written in Punk-C as an input. It loads all the executables in its own address space and makes their API available for programming in its embedded interpreter.

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

Хотя авторы WCC на голубом глазу заявляют:

This provides for binaries functionalities similar to those provided via reflection on languages like Java.

до рефлексии уровня Java/.NET тут все же очень далеко и вызывать столь интересным образом методы в чужих библиотеках получается далеко не всегда.

Теперь рассказываю, как можно попробовать сие темное колдунство в действии. Интерпретатору wsh из состава WCC скармливается разделяемая библиотека или ELF-приложение:

wsh /usr/sbin/apache2

К сожалению стабильность работы вызывает вопросы, поэтому тут 50/50 — колдунство может сработать, а может выпасть segmentation fault. Если был передан бинарник — автоматически произойдет его «библификация», описанная выше.

Если сработало, появится сообщение зелеными буквами на черном фоне:

loading of libified binary succeeded

И можно будет пытаться вызывать:

a = ap_get_server_banner()
print(a)

Код выше — отдельный язык, такая своеобразная помесь С и Lua, с весьма поэтическим названием:

The resulting API, a powerful combination of lua and C API is called Punk-C

Авторы решили не заморачиваться с типами данных, поэтому и родилась на свет эта дикая помесь ужа с ежом С и Lua.

Так выглядит более сложный пример использования:

#!/usr/bin/wsh

-- Computing a MD5 sum using cryptographic functions from foreign binaries
-- (eg: sshd/OpenSSL)

function str2md5(input)

out = calloc(33, 1)
ctx = calloc(1024, 1)

MD5_Init(ctx)
MD5_Update(ctx, input, strlen(input))
MD5_Final(out, ctx)

free(ctx)
return out
end

input = "Message needing hashing\n"
hash = str2md5(input)
hexdump(hash,16)

exit(0)

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

Как видите все работает и действительно отображается MD5-хеш для введенной строки, вычисленный с помощью вызова функции из бинарника sshd.

Без исходников и без линковки.

Но это далеко не все колдовские приколы, которые позволяет творить WCC.

Колдунство третье: восстановление флагов сборки

Хотя авторы WCC опять несколько преувеличивают, рассказывая про возможность восстановления абсолютно всех флагов сборки:

When compiling C code, it is often required to pass extra arguments to the compiler to signify which shared libraries should be explicitly linked against the compile code. Figuring out those compilation parameters can be cumbersome. The wldd commands displays the shared libraries compilation flags given at compile time for any given ELF binary.

На практике же речь идет только о библиотеках:

Так что речь больше про удобство использования, чем про уникальный функционал.

Колдунство четвертое: генератор заголовков

Последнее в этой статье, но далеко не последнее по важности и применимости:

The wcch command takes an ELF binary path as a command line, and outputs a minimal C header file declaring all the exported global variables and functions from the input binary. This automates prototypes declaration when writing C code and linking with a binary for which C header files are not available.

Вот тут действительно респект и жертвоприношение уважение, поскольку столь мощное колдунство может сильно помочь в разработке:

Но все же стоит помнить про ограничения технологии и не ждать 100% корректности получаемых заголовков.

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

cat /tmp/sshd.h |head -c 500

/**
* Automatically generated by the Witchcraft Compiler Collection 0.0.9
**/
extern void *optind;
extern void *obstack_alloc_failed_handler;
extern void *error_message_count;
extern void *argp_err_exit_status;
extern void *_IO_2_1_stderr_;
extern void *stdin;
extern void *program_invocation_short_name;
[alex@illuminati wcc]$

Думаю очевидно, что артефакты вроде:

extern void *_IO_2_1_stderr_;
extern void *stdin;

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

Резюмируя

WCC это по истине необычный и редкий проект, к сожалению (или к счастью) неизвестный широкой программерской публике.

Хотя его использование требует серьезной подготовки и определенных навыков, а работа утилит часто нестабильна - эффект в виде зарева полыхающих пердаков быдлокодеров простых разработчиков выходит эпический.

Если вы занимаетесь серьезной разработкой на C/C++ под Linux и ненавидите человескую расу, думаю стоит ознакомиться с этой штукой поближе, чтобы включить WCC в свои темные планы и нечестивые эксперименты.

P.S.

Оригинал статьи в нашем блоге, статья была опубликована на Хабре.