Для любых сложных вызовов Windows API используйте библиотеку [Winim](https://github.com/khchen/winim), это экономит огромное количество времени и не сильно увеличивает размер исполняемого файла (см. ниже) в зависимости от способа импорта.

Даже поддерживает COM!!!

## Создание Windows DLL с экспортируемой `DllMain`

Огромное спасибо человеку, опубликовавшему [это](https://forum.nim-lang.org/t/1973) на форуме Nim.

Компилятор Nim пытается автоматически создать функцию `DllMain` для вас во время компиляции, когда вы указываете ему создать DLL для Windows, однако по какой-то причине он её не экспортирует. Чтобы иметь экспортируемую `DllMain`, нужно передать `--nomain` и определить функцию `DllMain` самостоятельно с соответствующими прагмами (`stdcall, exportc, dynlib`).

Также необходимо вызвать `NimMain` из вашего `DllMain`, чтобы инициализировать сборщик мусора Nim. (Очень важно, иначе ваш компьютер буквально взорвётся).

Пример:```nim
import winim/lean

proc NimMain() {.cdecl, importc.}

proc DllMain(hinstDLL: HINSTANCE, fdwReason: DWORD, lpvReserved: LPVOID) : BOOL {.stdcall, exportc, dynlib.} =
  NimMain()
  
  if fdwReason == DLL_PROCESS_ATTACH:
    MessageBox(0, "Hello, world !", "Nim is Powerful", 0)

  return true

### Создание XLL
Вы можете создать XLL (DLL для Excel, представьте себе) с функцией автозапуска, которая может использоваться для доставки полезной нагрузки. Следующий код создает простой XLL с функцией автозапуска и всем остальным шаблонным кодом, необходимым для компиляции в виде библиотеки ссылок. Данный POC компилируется как DLL, после чего вы можете изменить расширение на .xll, и при двойном щелчке он откроется в Excel и запустит полезную нагрузку:```nim
#[
    Compile:
        nim c -d=mingw --app=lib --nomain --cpu=amd64 nim_xll.nim
        
    Will compile as a DLL, you can then just change the extension to .xll
]#

import winim/lean

proc xlAutoOpen() {.stdcall, exportc, dynlib.} =
    MessageBox(0, "Hello, world !", "Nim is Powerful", 0)

proc NimMain() {.cdecl, importc.}

proc DllMain(hinstDLL: HINSTANCE, fdwReason: DWORD, lpvReserved: LPVOID) : BOOL {.stdcall, exportc, dynlib.} =
  NimMain()

  return true

## Разница в размере исполняемого файла при использовании библиотеки Winim и без нее

Удивительно, но разница в размере довольно незначительна. Особенно если применить описанные выше оптимизации размера.

Для этой цели были созданы два примера: `pop_bin.nim` и `pop_winim_bin.nim`.

Первый определяет вызов WinAPI `MessageBox` вручную, а второй использует библиотеку Winim (конкретно `winim/lean`, которая представляет собой только базовый SDK, см. [здесь](https://github.com/khchen/winim#usage)), результаты:```
byt3bl33d3r@ecl1ps3 OffensiveNim % ls -lah bin
-rwxr-xr-x  1 byt3bl33d3r  25K Nov 20 18:32 pop_bin_32.exe
-rwxr-xr-x  1 byt3bl33d3r  32K Nov 20 18:32 pop_bin_64.exe
-rwxr-xr-x  1 byt3bl33d3r  26K Nov 20 18:33 pop_winim_bin_32.exe
-rwxr-xr-x  1 byt3bl33d3r  34K Nov 20 18:32 pop_winim_bin_64.exe

## Соображения по Opsec

Из-за того, как Nim динамически разрешает DLL с помощью `LoadLibrary` через свой FFI, ни одна из ваших внешних импортированных функций фактически не появится в статических импортах исполняемого файла (см. [эту запись в блоге](https://web.archive.org/web/20210117002945/https://secbytes.net/implant-roulette-part-1:-nimplant/) для получения дополнительной информации):

![](https://assets.kitploit.com/production/public/readmes/6566/ae35b71c435c8fe24112a95abb0eca863721c9fde9b14efb7d4f2701bb57b3b9.png)

Если вы компилируете исходный код Nim в DLL, похоже, что у вас всегда будет экспортированный `NimMain`, независимо от того, указываете ли вы свой собственный `DllMain` или нет (??). Это потенциально может использоваться как сигнатура; не знаю, сколько организаций на самом деле используют Nim в своем стеке разработки. Определенно выделяется.

![](https://assets.kitploit.com/production/public/readmes/6566/1e291f2b170de9f5728e36cc2c6e489477480fa4b215dcf78341531805781448.png)

## Написание Nim без среды выполнения Nim

Поскольку Nim сильно помечается антивирусными решениями, один из способов обойти это — писать программы на Nim без среды выполнения Nim. [Writing Nim-less Nim](https://www.youtube.com/watch?v=EXX3HmCG3pw) — это доклад, в котором описываются шаги по написанию кода на Nim без среды выполнения Nim и C; исходный код из этого доклада доступен [здесь](https://github.com/m4ul3r/writing_nimless). Доклад продолжает и расширяет работу [zimawhit3](https://github.com/zimawhit3) с [Bitmancer](https://github.com/zimawhit3/Bitmancer/tree/main).

Предпосылка заключается в том, чтобы полагаться на определения типов `winim` и использовать написание кода, которое не приведет к использованию среды выполнения Nim.

## Преобразование кода C в Nim

https://github.com/nim-lang/c2nim

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

## Языковые мосты

  - Интеграция с Python: https://github.com/yglukhov/nimpy
    * Это на самом деле очень интересно, [особенно эта часть](https://github.com/yglukhov/nimpy/blob/master/nimpy/py_lib.nim#L330). С некоторыми модификациями можно ли загрузить PythonxXX.dll из памяти?

  - Интеграция с Jave VM: https://github.com/yglukhov/jnim

## Отладка

Используйте функцию `repr()` в сочетании с `echo`; поддерживает почти все (??) типы данных, даже структуры!

См. [эту запись в блоге для получения дополнительной информации](https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html)

## Настройка среды разработки

Этот репозиторий поддерживает [VSCode Devcontainers](https://code.visualstudio.com/docs/remote/create-dev-container), что позволяет вам разрабатывать в контейнере Docker. Это автоматизирует настройку среды разработки для вас.

1. Установите VSCode и Docker Desktop
2. Клонируйте этот репозиторий и откройте его в VSCode
3. Установите расширение `Visual Studio Code Remote - Containers`
4. Откройте палитру команд и выберите команду `Remote-Containers: Reopen in Container`

VSCode теперь соберет образ Docker (это займет некоторое время) и поместит вас прямо в вашу предварительно собранную среду разработки Nim!

## Ловушки, в которые я сам попадал

- При вызове winapi с Winim и попытке передать нулевое значение убедитесь, что вы передаете значение `NULL` (определенное в библиотеке Winim), а не встроенное значение `nil` из Nim. (Уф)

- Чтобы получить дескриптор ОС для созданного файла после вызова `open()` в Windows, нужно вызывать `f.getOsFileHandle()`, **а не** `f.getFileHandle()` по причинам.

- Компилятор Nim принимает аргументы в форме `-a=value` или `--arg=value`, хотя если посмотреть на справку, аргументы передаются только как `-a:value` или `--arg:value`. (Важно для Makefile'ов)

- При определении байтового массива также нужно указать хотя бы в первом значении, что это байтовый массив; немного странно, но ладно (https://forum.nim-lang.org/t/4322)

Байтовый массив в C#:```csharp
byte[] buf = new byte[5] {0xfc,0x48,0x81,0xe4,0xf0,0xff}

## Интересные библиотеки Nim

- https://github.com/dom96/jester
- https://github.com/pragmagic/karax
- https://github.com/Niminem/Neel
- https://github.com/status-im/nim-libp2p
- https://github.com/PMunch/libkeepass
- https://github.com/def-/nim-syscall
- https://github.com/tulayang/asyncdocker
- https://github.com/treeform/ws
- https://github.com/guzba/zippy
- https://github.com/rockcavera/nim-iputils
- https://github.com/FedericoCeratto/nim-socks5
- https://github.com/CORDEA/backoff
- https://github.com/treeform/steganography
- https://github.com/miere43/nim-registry
- https://github.com/status-im/nim-daemon

## Ссылки Nim для разработки имплантов

- https://web.archive.org/web/20210117002945/https://secbytes.net/implant-roulette-part-1:-nimplant/
- https://securelist.com/zebrocys-multilanguage-malware-salad/90680/
- https://github.com/MythicAgents/Nimplant
- https://github.com/elddy/Nim-SMBExec
- https://github.com/elddy/NimScan

## Участники 

Виртуальные объятия всем, кто внес свой вклад ❤️

<a href="https://github.com/byt3bl33d3r/OffensiveNim/graphs/contributors">
  <img src="https://contrib.rocks/image?repo=byt3bl33d3r/OffensiveNim" />
</a>