CopyCache Runner
Раннер сборки прошивок загружает шаблон политики подписи в кеш и проверяет его перед запуском задания. На диске шаблон менять нельзя, но для запуска важна именно копия в памяти. В ELF `copycache-runner` ищем, какие поля открывают экспорт и кто может их перезаписать.
## Решение
Смотрим расположение полей кешированной политики.
| Смещение | Поле | Что нужно для запуска |
|---:|---|---|
| 0 | `name[16]` | На проверку не влияет |
| 16 | `flags` | `0x4558504f` |
| 20 | `job` | `0x26050613` |
| 24 | `checksum` | `flags ^ job ^ 0xa5a5a5a5` |
После загрузки `job` уже правильный, а `flags` равен нулю. Поэтому прямой вызов `run sealed job` заканчивается `policy denied`.
В меню есть операция `AEAD_COPY`. Она принимает смещение и 32-битное слово, проверяет только попадание записи внутрь всей структуры, после чего выполняет:
```c
memcpy((char *)&cache + off, &word, 4);
```
Граница структуры соблюдается, но служебные поля внутри неё доступны для записи наравне с остальными данными. Для экспорта меняем разрешение и пересчитываем контрольную сумму.
```python
flags = 0x4558504f
job = 0x26050613
checksum = flags ^ job ^ 0xa5a5a5a5
```
Через `3) AEAD_COPY` пишем `flags` по смещению `16`, затем `checksum` по смещению `24`. Если хочется проверить себя, `2) show cached policy` показывает новые значения.
При выборе `4) run sealed job` сервис проверяет разрешение на экспорт, номер задания и контрольную сумму в кеше. Изменённая политика проходит проверки, и сервис выдаёт флаг. Файл шаблона на диске при этом остаётся прежним.
[Солвер](solve/solve.py).
## Флаг
`caplag{copy_cache_changed_policy_without_touching_disk}`