Les fichiers binaires, avec lesquels on ne peut pas faire de diff, n'ont pas d'intérêt à être présents directement sur le dépôt : cela consomme inutilement de la place et rend le clonage du dépôt inutilement long. Vous **devez** utiliser [git-lfs](https://docs.gitlab.com/ee/topics/git/lfs/) sur le GitLab du CRI pour tous les fichiers binaires contenus dans ce dossier.
- Pas plus 4GB à télécharger **par étape** (ie. tous les fichiers de cette étape) : 4GB, c'est jusqu'à 5 minutes de téléchargement, c'est vraiment beaucoup lorsqu'on est impatient de faire l'étape.
- Archives `.tar.bz2`, `.tar.gz`, `.tar.xz` ou `.zip` lorsque nécessaire. **PAS** de `.rar`, ...
- Compresser (sans tarball, juste via **gzip**[^gz]) les fichiers lorsque c'est utile (memory dump, images BMP, disques, fichiers textes, ...).
Indiquez dans le fichier `DIGESTS.txt` le hash du fichier compressé (utilisé par la plateforme pour vérifier que le fichier distribué n'a pas été altéré) **et** le hash du fichier initial décompressé (pour l'affichage sur la plateforme).
Ces fichiers seront concaténés automatiquement au moment de leur import sur la plateforme.
Seul le hash du fichier entier est requis dans le fichier `DIGESTS.txt`.
[^gz]: l'intérêt de `gzip` est que le serveur web sera capable de distribuer le fichier sans faire apparaître la compression. Voir le [module nginx utilisé](https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html).
Le fichier `DIGESTS.txt` se trouve dans le répertoire `files/` de chaque étape. Il contient les condensats des fichiers se trouvant dans le dossier respectif.
On le génére avec la commande suivante :
```sh
b2sum * > DIGESTS.txt
```
{{% notice warning %}}
Ce fichier est à générer **avant** l'upload. Son utilité est d'avoir un moyen
de vérifier, une fois sur place, sans connexion Internet, que l'intégralité de
l'arborescence n'a pas été altérée et que les fichiers servis sont bien les
La commande `b2sum` fait partie des *GNU Core Utilities* depuis la [version 8.26](https://github.com/coreutils/coreutils/commit/ea94589e9ef02624a3837f97f80efd7d3dcf56bf). Pour Windows, le site officiel du projet fourni [une archive avec un binaire utilisable](https://www.blake2.net/#su).
L'algorithme [blake2b](https://blake2.net/) est utilisé à la place d'un SHA-1 ou MD5 car il est plus rapide que ces derniers et est encore considéré comme sûr.
{{% /notice %}}
### Cas des fichiers en plusieurs parties
Dans le cas où vous êtes contraint de découper vos fichiers avant de les uploader, seule la somme de contrôle du fichier entier, avant découpage, est nécessaire.
### Cas des fichiers compressés (`gzip`és)
Si vous avez `gzip`é votre fichier pour qu'il soit distribué décompressé, indiquez dans votre `DIGESTS.txt` à la fois :
* **le condensat du fichier compressé :** il sera utilisé par la plateforme lors de l'import de vos étapes afin de s'assurer que les fichiers n'ont pas été altéré durant l'un des multiples transferts,
* **le condensat du fichier initial, décompressé :** c'est celui qui sera affiché dans l'interface, aux participants.
Dans certaines situations, un fichier peut être optionnel pour valider le défi, mais celui-ci peut donner un avantage certain à l'équipe qui le récupère.
Par exemple, fournir le profile Volatility d'un Linux peut faire gagner beaucoup de temps, ou encore, lorsque l'on n'est pas en mesure de déchiffrer un binaire à analyser, on peut envisager de fournir le binaire déchiffré ou dépacké, ... Mais pas automatiquement !
Dans ce cas on parle de fichiers « indices ». C'est-à-dire qu'ils seront distribués comme des indices et pourront coûter un certain nombre de points aux équipes qui les téléchargent.
Dans le fichier `challenge.txt`, il vous faudra y faire référence dans une section `[[hint]]` :
```toml
[[hint]]
filename = "foobar.exe"
cost = 10
title = "Binaire non packé"
```
## Cacher un fichier tant qu'un flag n'a pas été validé
C'est au(x) flag(s) d'indiquer quel(s) fichier(s) ils verrouillent tant qu'ils n'ont pas été validé par un participant.
Dans le fichier `challenge.txt`, pour un `[[flag]]` donné, on ajoutera :
```toml
[[flag]]
...
[[flag.unlock_file]]
filename = "foobar.csv"
```
Ici, le fichier `foobar.csv` sera débloqué dès lors que le flag auquel il est rattaché est validé.
Il est possible de faire en sorte qu'un fichier ne soit débloqué qu'après la validation de plusieurs flags, en ajoutant le même `[[flag.unlock_file]]` au niveau des autres flags à débloquer.
## Ne pas distribuer un fichier avant l'archivage du site
Si votre défi dépend de ressources en ligne, qui peuvent ne pas être accessible le jour du challenge, ou qui ne seront plus accessible une fois la compétition passée, nous devez inclure une archive avec ces ressources. Il peut s'agir de captures d'écran, d'une version aspirée du site, ...
Il faudra alors faire figurer dans [le `challenge.txt`]({{< relref "challenge.md" >}}#les-fichiers) une référence au fichier, avec un attribut `hidden` :
``` toml
[[file]]
filename = 'rnicrosoft.io.tar.xz'
hidden = true
```
L'archive du site rnicrosoft.io ne sera dévoilé que sur la version archivée du site, ou pendant la compétition par une intervention manuelle de l'équipe serveur, si jamais il y avait un soucis de connectivité.
## D'autres attributs ?
Les fichiers peuvent posséder des attributs spécifiques dans [le `challenge.txt`]({{< relref "challenge.md" >}}#les-fichiers).