Catégorie : Script

9 juillet 2015 /

Voici un script pour formater sa clef USB, vous pouvez l’utiliser et l’adapter à vos besoins.
N’hésitez pas à me faire parvenir les modifications que vous y apporterez que j’améliore le mien.

#!/bin/bash

echo « Bienvenue pour le formatage de ta clef Usb Starmate »
READ
echo « Avant de continuer, il faudrait que tu es connaissance du chemin de ta clef (/dev/?) »
echo « La commande ‘sudo fdisk -l’ va t’y aider « 
echo « Are you ready??!!??? »
READ
echo « Comment tu veux appeler la Bête (en essayant d’être original cette fois, hein!! …) »

read –>%nom_de_ma_clef

echo « tape le nom du chemin exact de ta clef ou du périphérique a formater (exemple: /dev/sdc) »

read  –>%chemin

——————————————

echo « Quel type de format de fichier tu veux »
echo « ext2 »
echo « ext3 (EXT2+journalisation) »
echo « ext4 (EXT3 en attendant Btrfs) »
echo « msdos) »
echo « ntfs (Windeaube 3, le retour) »

read –>%format

——————————————-

echo « Repicatulatif: »
echo « La clef va se trouve a cet endroi %… »
echo « Et va être formater avec le système de fichier %format »
echo « Are you Ready? »

read

sudo  mkfs.%format -L « %nom_de_ma_clef » %chemin

21 juin 2015 /

La fork bomb est une forme d’attaque par déni de service contre un système en utilisant la fonction fork. Elle se base sur la supposition que le nombre de programmes et de processus pouvant être exécutés simultanément sur un ordinateur est limité.

Une fork bomb fonctionne en créant un grand nombre de processus très rapidement afin de saturer l’espace disponible dans la liste des processus gardée par le système d’exploitation. Si la table des processus se met à saturer, aucun nouveau programme ne peut démarrer tant qu’aucun autre ne termine. Même si cela arrive, il est peu probable qu’un programme utile démarre étant donné que les instances de la bombe attendent chacune d’occuper cet emplacement libre.

Non seulement les fork bombs utilisent de la place dans la table des processus, mais elles utilisent chacune du temps processeur et de la mémoire. En conséquence, le système et les programmes tournant à ce moment-là ralentissent et deviennent même impossibles à utiliser.

En Bash:

:(){ :|:& };:

Explications:

:() définit une fonction nommée : .
Puis { :|:& } est le corps de la fonction. Dans celui-ci, la fonction s’appelle elle-même (:), puis redirige la sortie à l’aide d’un pipe (|) sur l’entrée de la même fonction : et cache le processus en fond avec &. La fonction, ensuite appelée avec :, s’appelle récursivement à l’infini.

La fork bomb fonctionne en créant autant de processus que possible. Ainsi, s’en premunir, il suffit simplement de limiter le nombre de processus pouvant être exécutés par un programme ou par un utilisateur. En permettant aux utilisateurs de non-confiance de lancer seulement un petit nombre de processus, le danger d’une fork bomb, intentionnelle ou non, est réduit. Toutefois, cela n’empêche pas un groupe d’utilisateurs de collaborer pour consommer les emplacements processus, à moins que la limite totale des processus soit plus grande que la somme des limites des processus individuelles.

Les systèmes de type Unix permettent de limiter le nombre de processus via la commande ulimit. Dans un noyau Linux, cette limite peut être indiquée via RLIMIT_NPROC. Si un processus appelle fork et que l’utilisateur possède déjà plus de RLIMIT_NPROC processus alors le fork échoue. Ici encore la limitation est propre à un utilisateur donné et ne permet pas de déjouer les attaques simultanées par plusieurs utilisateurs. Elle permet toutefois de limiter l’impact de forks accidentels, par exemple lors de la conception d’un logiciel ou d’un bogue dans une application.

 

Voici d’autre façon de faire des Fork Bomb:

En langage C:

#include
int main(void)
{
while(1) {
/* ici on peut ajouter un malloc pour utiliser plus de ressources */
fork();
}
return 0;
}

En Javascript:

function open_target_blank()
{
window.open(window.location);
}
window.onload = open_target_blank();
OU
while (true)
{
var w = window.open();
w.document.write(document.documentElement.outerHTML || document.documentElement.innerHTML);
}

En Perl:

fork while fork

En Perl depuis un terminal:

perl -e "fork while fork" &

En Python:

import os
while True:
os.fork()

En Ruby:

loop { fork }

En VB:

Private Sub Main()
Do
Shell App.EXEName
Loop
End Sub

15 juin 2015 /

La commande source permet de lire et d’exécuter les commandes contenues dans un fichier passé en argument avec l’environnement du shell en cours, puis renvoie le code de retour de la dernière commande exécutée dans le fichier.

En gros, de base, un processus ne peut pas modifier l’environnement de son parent. Il ne peut modifier que son propre environnement. Il peut aussi choisir quel environnement transmettre lors d’un exec.

Quand tu exécutes un script de cette façon « ./script.sh », ton shell devient un fork dans lequel un nouveau shell va exécuter le script. Les variables du script sont placés dans l’environnement du processus fils, pas dans le processus père.

Alors que quand on « source » un fichier, cela demande au shell courant d’interpréter le script qui est passe en argument. Cela ne crée pas de sous-shell. Donc dans ce cas le script modifie bien l’environnement du shell courant.

Note que « .  » est équivalent à « source ».
Au lieu de faire « source script.sh », on peux faire « . ./script.sh ».

Exemple:

. ./script.sh

ou

source ./script.sh

Avec cette commande, on « source » le fichier script.sh contenant des fonctions ou des variables; c’est à dire que les variables contenues dans le fichier « sourcé » deviennent connues pour le shell courant, idem pour les fonctions.

Rappel:

Faites attention,  « ./  » et source ne font pas la même chose.

./script.sh lance le script comme un fichier executable, lancant un nouveau shell pour son execution.
source script.sh lis et execute les commandes/paramètres du fichier passé en argument dans le shell courant

Donc « ./script.sh » n’est pas comme « . script.sh », mais « . script.sh » est pareil que « source script.sh »