Extraire un dossier d’un dépôt git avec suivi du renommage

développement
Posted on Leave a comment on Extraire un dossier d’un dépôt git avec suivi du renommage

git contient une commande permettant d’extraire un dossier d’un dépôt existant. C’est pratique lorsque le dépôt contenait initialement un seul projet, qui a évolué au cours du temps, grossit, et est devenu un truc trop gros pour rester dans un dépôt unique. Cela se fait avec la commande git –subdirectory , mais cette commande ne suivait pas le renommage du dossier à extraire et l’on se retrouvait donc avec un historique tronqué.

Le script ci-dessous fonctionne (c’est déjà ça), en travaillant sur le dépôt lui-même plutôt que l’espace de travail, lequel ne reflète qu’une version spécifique. Il :

  • ne garde du dépôt que tout ce qui se trouve ou bien dans Kveer.MyAwesomeProject, ou bien dans MyAwesomeProject, qui sont un même dossier que j’ai renommé à un moment donné
  • il fait remonter à la racine le contenu des dossiers susmentionnés
  • quitte à casser tout l’historique, j’en profite pour unifier le nom et l’email utilisé dans les commits (on pourra ajouter une condition pour ne réécrire que ses propres commits)
  • je supprime le dossier package pour réduire la taille du dépôt
  • plus qu’à nettoyer
  • le nouveau dépôt est prêt à être chargé.
# extracts the subdirectory
# i take this opportunity to rewrite author name and email of my commits
git filter-branch --prune-empty --env-filter '
GIT_AUTHOR_EMAIL=my-awesome-email@kveer.fr
GIT_AUTHOR_NAME=Veovis' --index-filter '
    # Delete files which are NOT needed
    git ls-files -z | egrep -zv  "^(Kveer.MyAwesomeProject|MyAwesomeProject)" |
        xargs -0 -r git rm --cached -q
    # Move files to root directory
    git ls-files -s | sed -e "s-\t\(Kveer.MyAwesomeProject\|MyAwesomeProject\)/-\t-" |
        GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
        git update-index --index-info &&
        ( test ! -f "$GIT_INDEX_FILE.new" \
            || mv -f "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE" )
'

# deletes the backup ref
git update-ref -d refs/original/refs/heads/master

# more cleaning by removing a directory that should not be tracked
git filter-branch --index-filter \
  'git rm --ignore-unmatch --cached packages'

# deletes the backup ref
git update-ref -d refs/original/refs/heads/master

# cleans the repo
git gc
git repack -Ad

La commande subdirectory ne doit pas servir à modifier un dépôt existant. En effet il réécrit tous les commits, tous les hash sont différents. Le nouveau dépô n’aura donc plus aucun lien avec l’ancien dépôt et il sera impossible de faire un push autrement que sur un dépôt vierge ou bien en forçant le passage.

Sources

Bloquer l’accès à un site web pour tout le monde sauf…

développement
Posted on Leave a comment on Bloquer l’accès à un site web pour tout le monde sauf…

Lors du développement d’un site web, il est pratique à partir d’un certain moment de le publier et pouvoir le rendre accessible à une minorité de personnes (du genre le client pour commencer à avoir du feedback).

Je décris dans ce billet différentes méthodes permettant de répondre à ce besoin.

Filtrage par IP

Une solution naïve serait de bloquer l’accès au site sauf à une poignée d’IPs, qui serait les IPs des personnes autorisées à consulter le site en construction. Cela cependant ne fonctionne pas si l’IP n’est pas connu à l’avance, comme par exemple lorsque le FAI fournit des IPs d’un pool dynamiques ou tout simplement lors d’une présentation (Orange et Bouygues notamment).

Filtrage par Cookie

Une seconde solution, et c’est celle que je veux présenter ici, se base sur un autre mécanisme. Je trouve cette solution particulièrement élégante car simple tout en répondant parfaitement au problème.
Dans cette solution, la clé n’est plus l’IP comme dans la première solution mais le cookie. La présence d’un cookie détermine l’accès au site.

L’implémentation la plus simple se fait en deux phases:

  • la première phase est la création d’une page-à-la-con dont le seul objectif sera d’insérer le cookie au navigateur puis d’effectuer une redirection par JavaScript vers le point d’entrée du site.
  • la seconde phase est l’implémentation de la restriction, en général au sein du serveur web car alors c’est de la configuration pur et il n’est pas nécessaire de bidouiller le code source du site.

La restriction doit répondre aux règles suivantes :

  1. L’url permettant de poser le cookie doit être en accès libre. Il faut la garder secrète.
  2. L’accès au site doit être autorisée si la requête provient d’une IP autorisée ou si le cookie d’accès est présent
  3. Poser un fichier robots.txt pour éviter que l’url du premier point soit crawlé par les principaux moteurs de recherche.

Ci-dessous un exemple d’implémentation de la restriction façon Apache

SetEnvIf Request_URI "youhou_cookie\.php$" let_me_in
SetEnvIfNoCase Cookie "euphor=tissu" let_me_in

order deny,allow
allow from 82.247.154.152
allow from 193.248.37.205
allow from 2001:470:1f13:129f::/64
allow from env=let_me_in
deny from all

Et voilà une version pour IIS

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />
                <rule name="cookie-redirect" enabled="true" patternSyntax="ExactMatch" stopProcessing="true">
                    <match url="entry-url" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="Redirect" url="/" appendQueryString="false" redirectType="Found" />
                </rule>
                <rule name="cookie-checker" patternSyntax="ECMAScript" stopProcessing="true">
                    <match url=".*" negate="false" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{REQUEST_URI}" pattern="^entry-url$" negate="true" />
                        <add input="{HTTP_COOKIE}" pattern="pass=euphor" negate="true" />
                    </conditions>
                    <action type="AbortRequest" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="set-cookie" preCondition="url-checker" patternSyntax="ECMAScript" stopProcessing="false">
                    <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
                    <action type="Rewrite" value="pass=euphor; Max-Age=86400" replace="true" />
                </rule>
                <preConditions>
                    <preCondition name="url-checker">
                        <add input="{REQUEST_URI}" pattern="entry-url" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <httpErrors errorMode="Detailed" />
    </system.webServer>
</configuration>

 

Il sera préférable d’effectuer la redirection en javascript plutôt qu’avec un code HTTP 302, on évite quelques cas à priori bizarre (je ne me suis pas penché dessus) où le cookie n’est pas pris en compte par le navigateur.

FAQ

  1. Pas besoin de s’embêter avec tout ça, il suffit simplement de ne pas laisser trainer l’url du site non ?
    Il suffit de surfer sur le site avec Google Chrome par exemple et le site se fait référencer dans la semaine.
  2. En plaçant un robots.txt, on évite que le site se fasse référencer par les moteurs de recherche, c’est bon là ?
    Oui Google et Bing! respectent le fichier robots.txt, mais ce n’est pas un simple fichier qui va bloquer, techniquement parlant, le référencement par tout moteur de recherche. Le crawler de la bibliothèque nationale de France par exemple ignore complètement ce fichier
  3. Obligé de suivre la solution 2 alors ?
    Sous l’angle de la sécurité, garder secret un nom de domaine ou poser un fichier robots.txt c’est de l’esbrouffe. Tant qu’il n’existe pas de barrière solide, on peut doit considérer que le site est en accès libre. La solution 1 peut suffire mais la solution 2 apporte de la souplesse.

pfSense sur APU

administration, gentoo
Posted on Leave a comment on pfSense sur APU

Ce poste rapide explique comment faire fonctionner pfSense lorsqu’il est installé sur un APU pcEngine avec une SDCard

Pré-requis

Avant de commencer, mettez en place un environnement permettant de monter une partition UFS (un FreeBSD ou un Linux avec le module qui va bien).
Le mode LiveCD de FreeBSD dans une VM fonctionne, mais le clavier qwerty et l’éditeur vi va probablement compliquer la tâche.

Manipulation

  1. Dans l’environnement, branchez-y la carte SD et montez la partition 1 de la manière suivante : mount -t ufs /dev/da1s1a /mnt/p1 où da1s1a est la partition 1 du disque 1 sous FreeBSD et /mnt/p1 un dossier où le montage va se faire.
  2. Editer le fichier /mnt/p1/boot/loader.conf en y ajoutant les lignes suivantes :
    1. comconsole_speed= »115200″
    2. kern.cam.boot_delay=10000
  3. Démontez les partitions, la carte SD peut-être replacée dans l’APU.

La première ligne sert à aligner la vitesse de communication du port série avec celle du BIOS, ce qui évite de reparamétrer le terminal et d’y perdre des lignes.
La seconde ligne ajoute un délai permettant au kernel de charger les modules permettant d’accéder à la carte SD.

Notes

L’image de pfSense sous format nanosd comporte 3 partitions. Les deux premières contiennent chacune une copie du système. La troisième partition est celle contenant la configuration.
La manipulation doit donc être effectuée deux fois, une fois pour chacune des deux premières partitions.

Retour d’expériences

Au bout de quelques heures d’utilisation, je me rend compte que pfSense, c’est cool, mais dès qu’on souhaite faire quelque chose d’avancé (multi-homing, IPSec avec chiffrage ECC et authentification par certificat, configuration poussé du pare-feu, dns menteur,…), ça pu pas mal. L’interface graphique étant très limitative, mon intérêt pour pfSense a disparu.

Le boitier tourne depuis sous Gentoo avec un petit ssd au format m.sata pour le système principal et une copie de sauvegarde plus ancienne sur la carte  SD depuis janvier 2015, et j’en suis très content. Ca fait son travail, et ça le fait très bien.

Sources

Restauration autoritaire de SYSVOL

administration, windows
Posted on Leave a comment on Restauration autoritaire de SYSVOL

J’aime bien commencer une belle et chaude semaine d’été par une restauration autoritaire de SYSVOL. Ou comment annoncer gentillement que bordel de merde, c’est pas le moment, j’avais vraiment autre chose à faire que de me prendre le choux avec ça. Ce billet détaille ma résolution pour remettre debout l’infra Active Directory.

État des lieux

Avant toute chose, il est de rigueur de décrire le parc et les versions utilisées. En effet Microsoft a introduit énormément de changements à partir de Windows Server 2008, et la procédure décrite ici ne pourra en conséquence pas fonctionner pour un contrôleur de domaine Windows Server 2003 ou plus ancien. Pour être plus précis, la procédure ne peut s’appliquer que lorsque le niveau fonctionnel du domaine est au minimum fixé à Windows Server 2008.

Le parc est plutôt modeste et est, pour la partie qui nous concerne, composé de :

  • 1 contrôleur de domaine sous Windows Server 2012 (AZSHARA)
  • 1 contrôleur de domaine sous Windows Server 2012R2 (ALEXSTRASZA)
  • le niveau fonctionnel du domaine est fixé à Windows Server 2012
  • le niveau fonctionnel de la forêt est fixé à Windows Server 2012
  • un script PowerShell qui s’exécute au démarrage de chaque ordinateur via une GPO. Le script est enregistré quelque part dans le partage SYSVOL

sysvol_script_ps

Symptômes

J’avoue qu’il s’agit d’un problème qui aurait pu être évité, mais ne connaissant aucun indicateur fiable « OK, ton domaine fonctionne normalement, tout est bien synchronisé » (en revanche si vous en connaissez un, un script ou n’importe quoi qui puisse me donner l’état de santé du domaine, je suis preneur), j’ai du faire avec les petits moyens dont je dispose.
A priori, les contrôleurs de domaine fonctionnaient normalement, les utilisateurs pouvaient se logguer, les contrôleurs étaient redémarrés régulièrement pour appliquer les mises à jour Windows. Cependant il existait un phénomène assez curieux mais sur lequel je ne me suis penché qu’assez tardivement : de temps en temps, les changements que je faisais sur le script PowerShell n’étaient pas pris en compte lorsque je le testais par la suite sur une VM de test. Ce script est mis à jour assez régulièrement car il sert à déployer tout ce qui ne repose pas sur du MSI, c’est à dire Firefox, Filezilla, les grosses mises à jour Visual Studio etc…
Après une énième occurrence du phénomène, je décide de prendre 5 minutes pour regarder de plus près ce qu’il se passe vraiment. J’accède alors au partage SYSVOL où se trouve le script sur chaque contrôleur de domaine et là, c’est le drame : chaque serveur possède une version du script différente ; le partage n’est absolument plus synchronisé, dans un sens comme dans l’autre.

Diagnostic

Comme toujours dans ces cas là, on part à la chasse aux informations. Je trouve assez rapidement la raison pour laquelle il n’existe plus de réplication dans le journal d’événement d’un des contrôleurs de domaine.

event_bad-stop

C’est à partir d’ici où il est important de savoir dans quel niveau fonctionnel le domaine se trouve. Les contrôleurs de domaines sont tous maîtres, il n’y a pas (par défaut) de relation 1 maître – x esclaves comme c’est souvent le cas pour les serveurs de bases de données transactionnelles. Les données synchronisés entre les contrôleurs de domaine sont :

  • l’annuaire. Il contient entre autre tous les utilisateurs, groupes, unités organisationnelles, les enregistrements DNS, la topologie de réplication.
  • le partage SYSVOL, il contient mon script et des fichiers en relation directe avec les stratégies de groupe (les GPOs) mises en place.

Etant donné que le problème ne se situe pas sur l’annuaire, la commande repadmin.exe ne sera d’aucun secours. A la place, il faudra utiliser la commande dfsrdiag.exe.
Vu que cette dernière est bien barbare et demande un certain nombre de paramètre non évident, j’ai préféré examiner la réplication via la console de gestion du système de fichiers distributés DFS (dfsmgmt.msc).
Cette console permet de créer un rapport d’intégrité (première option), ce que j’ai fait ou de tester la propagation (seconde option pour lancer le test, troisième option pour suivre la progression du test)
Je vous conseille fortement d’ouvrir ce rapport exclusivement avec Internet Explorer sous peine d’avoir du hachis parmentier à l’écran avec un autre navigateur.

rapport-1 rapport-2 rapport-3 rapport-4

 

Résolution

Je suis donc la procédure décrite dans l’événement pour relancer la synchronisation, cela nous mène au second drame.

Et impose un choix à faire parmi deux propositions :

  • on suit les recommandations de l’événement et on considère que la copie du partage SYSVOL est foutue car trop vieille. La bonne copie est donc celle se trouvant sur l’autre contrôleur de domaine. C’est souvent le choix à faire dans le cas où l’on a au moins 3 contrôleurs de domaines dont 2 au minimum ont une réplication fonctionnelle du partage SYSVOL.
  • on fait sa tête de mule et l’on décide que finalement la vieille copie est la bonne et devrait écraser l’autre copie.

Restauration autoritaire / non-autoritaire

  • Si vous avez un contrôleur de domaine avec un SYSVOL propre, alors vous pouvez (et même devriez) effectuer une restauration dite non-autoritaire, c’est à dire que l’on va invalider la copie du SYSVOL foutue, afin que le contrôleur de domaine qui héberge la copie la resynchronise à partir des autres contrôleurs de domaine. Dans mon cas, cela se traduit par AZSHARA qui va synchroniser son partage SYSVOL à partir de ALEXSTRASZA
  • Si vous avez opté pour le second choix ou bien si aucun contrôleur de domaine n’a un SYSVOL propre, alors il est nécessaire d’effectuer une restauration dite autoritaire, c’est-à-dire que l’on va explicitement déclarer qu’un des contrôleurs de domaine a la « bonne » copie du SYSVOL, et tous les autres contrôleurs de domaines vont effectuer une resynchronisation sur cette copie. La restauration autoritaire est à considérer comme la solution de la dernière chance, il est préférable tant que faire se peut d’effectuer en priorité une restauration non-autoritaire.

Sources

Authentification SSH par AD

administration, gentoo, windows
Posted on Leave a comment on Authentification SSH par AD

J’essaie lorsque c’est possible d’éviter la sur-multiplication des mots de passe à gérer. Dans un environnement principalement Microsoft, Active Directory permet de résoudre assez bien ce problème, c’est cool. Un annuaire pour les unir tous (et dans les ténèbres les lier).

Qu’en est-il des distributions Linux ? Je gère un petit nombre de serveurs sous Linux, pour lesquels l’intérêt de les intégrer dans un domaine Active Directory est proche du néant (sans parler du foutoir à mettre en place côté Linux). En effet, il n’y a pas de GPO, l’authentification par mot de passe est désactivé sur ces serveurs, et seul quelques personnes doivent pouvoir y avoir accès et de manière limitée.

Je me suis donc orienté vers une solution où la base utilisateurs des serveurs Linux reste locale (via /etc/passwd et /etc/shadow donc) mais en cherchant à centraliser la clé SSH de ces utilisateurs avec Active Directory.

David Gwynne (voir source) s’est déjà penché sur ce problème et a exhibé un paramètre contenu dans OpenSSH permettant de contrôler l’étape d’authentification via clé publique de manière très flexible, ce paramètre acceptant un script en entrée.

Le principe est alors très simple :

  1. un utilisateur tente de se connecter au serveur linux en SSH
  2. le serveur SSH récupère le nom d’utilisateur et exécute le script indiqué par le paramètre AuthorizedKeysCommand
    1. par mesure de sécurité, OpenSSH propose d’exécuter ce script sous une autre identité, ce qui est fortement préférable vu qu’OpenSSH est root
    2. ce script va se connecter à un serveur LDAP à l’aide d’identifiants dédié
    3. il va récupérer l’objet utilisateur correspondant au nom d’utilisateur, et s’il existe retourner sa ou ses clés publique SSH

L’intérêt consiste à éviter de devoir manipuler le fichier /home/{user}/.ssh/authorized_keys2 sur chaque serveur pour chaque utilisateur, la création d’un accès se faisant alors en deux temps :

  1. création du compte sur le serveur linux avec la commande useradd
  2. si ce n’est pas déjà fait, ajout de sa clé dans Active Directory

Mise en place de la solution

  1. Dans le fichier /etc/ssh/sshd_config, on ajoute/modifie les lignes suivantes:
AuthorizedKeysCommand /etc/ssh/authorized_keys.pl
AuthorizedKeysCommandUser _sshkeys

# si ce n'est pas déjà fait, ci-dessous les paramètres à modifier pour désactiver l'identification par mot de passe
PasswordAuthentication no
ChallengeResponseAuthentication no

2. Contenu du fichier /etc/ssh/authorized_keys.pl. Il faudra renseigner le nom du domaine, le nom d’utilisateur et mot de passe d’un compte pour se connecter à l’annuaire.

#!/usr/bin/perl -w

use strict;
use Net::DNS;
use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_SUCCESS LDAP_INVALID_CREDENTIALS);
use Net::LDAP::Util qw(escape_filter_value);

sub ad_bind($$$)
{
	my $domain = shift;
	my $user = shift;
	my $pass = shift;

	my $res = Net::DNS::Resolver->new;
	my $query;
	my $answer;
	my $ldap_error;

	$query = $res->query("_ldap._tcp." . $domain, 'SRV');
	if (!$query) {
		die "unable to query SRV records for $domain";
	}

	my @answers = $query->answer;
	foreach $answer (@answers) {
		# next if ($answer->port != 389)

		my $ldap = new Net::LDAP($answer->target, timeout => 2);

		$ldap_error = $@;
		next unless ($ldap);

		my $mesg = $ldap->bind(sprintf("%s@%s", $user, uc($domain)),
			password => $pass);
		return ($ldap) if ($mesg->code == LDAP_SUCCESS);

		if ($mesg->code == LDAP_INVALID_CREDENTIALS) {
			return (undef, $mesg->error);
		}

		$ldap_error = $mesg->error;
	}

	return (undef, $ldap_error);
}

if (scalar @ARGV != 1) {
	die "username not specified";
}

my $username = $ARGV[0];
my $ad_filter = sprintf('(&(sAMAccountName=%s)(objectClass=user))', escape_filter_value($username));

my %d = (
	'kveer.fr' => {
		'user' => 'sshkeys',
		'pass' => 'ton_mot_de_passe',
		'base' => 'DC=kveer,DC=fr',
		'filter' => $ad_filter
	}
);

foreach my $domain (keys %d) {
	my $param = $d{$domain};

	my ($ds, $err) = ad_bind($domain, $param->{'user'}, $param->{'pass'});
	next unless ($ds);

	my $mesg = $ds->search(
		base	=> $param->{'base'},
		filter	=> $param->{'filter'},
		attrs	=> ['altSecurityIdentities']
	);
	next unless ($mesg->code == LDAP_SUCCESS);

	for (my $i = 0; $i < $mesg->count; $i++) {
		my $entry = $mesg->entry($i);

		my @ids = $entry->get_value('altSecurityIdentities');
		foreach my $id (@ids) {
			my ($type, $value) = split(/:/, $id, 2);
			print "$value\n" if ($type eq 'SSHKey');
		}
	}
}

3. puis enfin quelques commandes pour terminer la configuration (à adapter en fonction de la distribution)

#!/bin/bash

USERNAME=_sshkeys
SCRIPT_FILE=/etc/ssh/authorized_keys.pl

useradd -s /sbin/nologin -d /var/empty/ $USERNAME
chmod 750 "$SCRIPT_FILE"
chown root:"$USERNAME" "$SCRIPT_FILE"

Ajouter la clé SSH

Pour chaque utilisateur devant avoir un accès nunux, il suffit de déclarer leur clé publique au sein d’Active Directory, dans l’attribut altSecurityIdentities. L’avantage de cet attribut est qu’il existe déjà, et fonctionne à l’aide d’un préfixe sur les valeurs, de sorte à ce qu’il puisse être utilisé par un acteur différent (ici OpenSSH) sans impacter l’usage initial qui en est fait de cet attribut. Ci-dessous à travers l’outil de gestion graphiques de l’annuaire dsa.msc.

ssh_ad_dsa

Remarques

  • Le script n’est pas parfait et peut être améliorer. Il ne vérifie pas par exemple si le compte en question est désactivé ou non.
  • Le script utilise l’attribut altSecurityIdentities. On aurait très bien pu créer un attribut dédié, mais cette solution a l’avantage d’éviter de modifier manuellement le schéma AD.

Source

Désactiver les Router Advertisement sur les modem Thomson

administration
Posted on Leave a comment on Désactiver les Router Advertisement sur les modem Thomson

Toute personne ayant un abonnement ADSL chez OVH est un geek et sait donc que l’interface web des modems Thomson est… disons très perfectible pour rester gentil.

Je vais donc détailler ci-dessous la méthode permettant de désactiver réellement les Router Advertisement envoyés par le modem, ce qui permettra d’avoir son propre routeur IPv6 (et sans la nécessité d’utiliser le modem en bridge).

Disclaimer

Comme d’habitude, la procédure risque de vous déconnecter d’Internet et tant pis pour vous si vous cassez tout. Vous devez avoir une bonne connaissance du protocole IPv6, notamment au niveau des échanges effectués en ICMPv6, du routage et du protocole de découverte des voisins (NDP aka Neigbour Discovery Protocol).

Pensez à sauvegarder la configuration de votre modem afin de toujours pouvoir revenir en arrière dans une configuration fonctionnelle.
J’ai galéré pendant 2 jours avant d’avoir un truc fonctionnel, il y a donc de forte chance pour que ça ne fonctionne pas du premier coup.

Juste pour rire, la méthode qui ne fonctionne pas.

  • Allez sur la page d’administration du modem
  • Cliquez sur Home Network > Interfaces > Configure
  • Décochez la case « Use Stateless DHCPv6 Server » et valider en appuyant sur Apply
  • Et voilà, ça marche pas (même après un redémarrage du modem) !

technicolor_radvd

Par « ça marche pas », j’entends par là que le modem continue toujours à balancer ses RA et ses DNS, comme on peut le vérifier en écoutant le réseau ou via les logs de mon propre démon radvd :

Aug 15 14:18:53 tefnout radvd[5802]: our AdvOtherConfigFlag on enp2s0 doesn't agree with fe80::xxxx:xxxx:xxxx:xxxx
Aug 15 14:18:53 tefnout radvd[5802]: RDNSS address 2001:41d0:1:e2b8::1 received on enp2s0 from fe80::xxxx:xxxx:xxxx:xxxx is not advertised by us
Aug 15 14:18:53 tefnout radvd[5802]: RDNSS address 2001:41d0:3:163::1 received on enp2s0 from fe80::xxxx:xxxx:xxxx:xxxx is not advertised by us
Aug 15 14:18:53 tefnout radvd[5802]: our AdvValidLifetime on enp2s0 for 2001:41d0:fe1c:1300:: doesn't agree with fe80::xxxx:xxxx:xxxx:xxxx
Aug 15 14:18:53 tefnout radvd[5802]: our AdvPreferredLifetime on enp2s0 for 2001:41d0:fe1c:1300:: doesn't agree with fe80::xxxx:xxxx:xxxx:xxxx

Et maintenant la méthode qui fonctionne

  • Ouvrez putty et connectez-vous en précisant l’ip du modem ainsi que le protocol Telnet
  • Connectez-vous. Les identifiants par défaut sont Administrator pour le nom d’utilisateur et il n’y a pas de mot de passe.
  • Tapez ce qui suit, en adaptant bien sur avec votre prefix/subnet :
# ajout d'une délégation
:ip rt6advd pdadd intf=LocalNetwork subnet-id=2001:41d0:fe1c:xxxx::/64 interface-id=slaac origin=Internet types=+dhcp+6rd+6to4+ula aflag=enabled lflag=enabled
# suppression des router advertisements
:ip rt6advd pfxdelete subnet-id=2001:41d0:fe1c:xxxx::/64

# ajout d'une route, pour que le modem balance les paquets en retour à votre router (nécessaire en mode router)
:ip rtadd dst=2001:41d0:fe1c:xxxx::/64 gateway=fe80::20c:29ff:xxxx:fbf intf=LocalNetwork status=up metric=0 static=enabled
# suppression de l'ancienne route
:ip rtdelete dst=2001:41d0:fe1c:xxxx::/64 intf=LocalNetwork
  • Et on termine bien sur par un saveall  pour que la configuration soit persistante (survive à un reboot)

Les commandes qui commencent par :ip rt6advd  ne servent pas qu’à envoyer des Router Advertisements, elles servent également à autoriser la délégation du préfixe dans le réseau local (= avoir un autre routeur IPv6 en plus du thomson). Il n’est donc pas possible de simplement détacher l’interface avec la commande :ip rt6advd ifdetach intf=LocalNetwork , cela aura pour effet de couper toute connectivité IPv6.

Divers

Pour aligner le modem avec les valeurs par défaut de radvd :

:ip rt6advd pfxadd intf=LocalNetwork subnet-id={VOTRE-PREFIX-IPV6}::/64 interface-id=slaac vltime=86400 pltime=14400 aflag=disabled lflag=enabled

On peut lister les interfaces sur lesquels il balance du RA avec la commande suivante : :ip rt6advd iflist

De manière générale, la commande help  aide dans la plupart des cas à découvrir toutes les fonctionnalités du modem. Le modem est en paille (c’est dommage), mais il est fonctionnellement très bien fournit sur le contrôle de toute la pile réseau.

Régler le problème de bandes noires avec les cartes graphiques ATI

windows
Posted on Leave a comment on Régler le problème de bandes noires avec les cartes graphiques ATI

Sur certain écran, lorsque l’affichage est contrôlé par une carte graphique de marque AMD, on peut observer suite à une mise à jour des pilotes que l’image ne couvre pas tout l’écran. C’est à dire qu’il y a des bandes noires tout autour de l’image, alors même qu’on a réglé la résolution d’affichage correctement. C’est ce que l’on appelle « underscan ».

Habituellement, cela se règle en quelques clics en utilisant le Catalyst Control Center > Paramètres graphique (Graphics Settings) > l’écran > Mise à l’échelle (Scaling options).

Et si l’on a pas installé le Catalyst Control Center, comment qu’on fait ? C’est ce que nous allons voir.

Si comme moi vous n’avez pas le Catalyst Control Center d’installé, parce que c’est une usine à gaz, trop lent, trop lourd ou peu importe, le seul moyen de récupérer l’espace perdu est d’aller jouer avec la base de registre.

A noter : la procédure n’est pas automatisable : les paramètres se trouvent dans une clé de registre donc le nom est dynamique, le chemin est donc différent sur chaque machine.

Voici la procédure :

  • Naviguez dans la base de registre jusqu’à ce chemin : HKLM\SYSTEM\CurrentControlSet\Control\Video . Vous y trouverez plusieurs sous-clé représentant des GUID.
  • Chaque GUID représente un affichage, qui peut éventuellement être virtuel (VNC, Remote Desktop). Le « bon » GUID sera celui contenant une sous-clé 0000 , laquelle contiendra un certains nombre de valeurs relatives à ATI
  • Une fois localisé le bon GUID, mettez vous dans la sous-clé 0000  et créez la valeur DWORD DigitalHDTVDefaultUnderscan  avec donnée 0.
  • Redémarrer l’ordinateur.
  • Terminé.

Ci-dessous la modification faite sur mon PC.

ati_underscan

Sources

Intégrer les Google Apps à la compilation d’une rom Android

android
Posted on Leave a comment on Intégrer les Google Apps à la compilation d’une rom Android

Ce post décrit une méthode permettant d’inclure les Google Apps directement dans une rom Android.
Cela évite ainsi de devoir flasher l’appareil 2 fois de suite à chaque mise à jour de la ROM : une fois pour la rom elle-même, puis une seconde fois avec les Google Apps.

Ce post ne décrit pas comment compiler une ROM, il suppose que l’environnement est déjà en place et fonctionne !
L’intégration des Google Apps n’est clairement pas autorisée par Google dans le cadre d’une distribution publique de la ROM. La méthode n’est donc à faire que pour vos propres compilation et rien d’autre.

  1. La première chose à faire est évidemment de se procurer les Google Apps. Vous pouvez les trouver ici.
  2. Ensuite ouvrez un shell et sourcez le fichier ~/buid/envsetup.sh : source ${VOTRE_RACINE_ANDROID}/build/envsetup.sh
  3. Décompressez les Google Apps dans le dossier suivant $ANDROID_BUILD_TOP/vendor/extra/google. Créez le dossier s’il n’existe pas. Pour préciser, vous devriez avoir un fichier $ANDROID_BUILD_TOP/vendor/extra/google/install-optional.sh  après décompression
  4. Exécutez le script ci-dessous dans ce même shell
  5. Ouvrez le fichier $ANDROID_BUILD_TOP/vendor/asus/tf700t/tf700t-vendor.mk  (remplacez évidemment ce qu’il faut pour votre apareil) et ajoutez-y $(call inherit-product-if-exists, vendor/extra/google.mk)
  6. Plus qu’à lancer une compilation
#!/bin/bash
FOUT=$ANDROID_BUILD_TOP/vendor/extra/google.mk

cd $ANDROID_BUILD_TOP/vendor/extra/google
echo 'PRODUCT_COPY_FILES += \' > $FOUT
find system -type f -exec echo -e \\tvendor/extra/google/\{\}:/\{\} \\ \; | sort >> $FOUT
echo 'PRODUCT_COPY_FILES += \' >> $FOUT
find optional -type f -exec echo -e \\tvendor/extra/google/\{\}:/\{\} \\ \; | sort >> $FOUT

 

ERRATA: il faut enlever les 2 \ finaux qui trainent dans le fichier généré.

Purger massivement des MKV

développement
Posted on Leave a comment on Purger massivement des MKV

J’ai écrit un petit script en Powershell afin de pouvoir traiter en masse des fichiers MKV en y enlevant toutes les pistes qui ne m’intéressaient pas.
Les MKV ont en effet la capacité d’embarquer plusieurs flux vidéos, audios, sous-titres et même des fichiers joints (des polices embarquées par exemple pour une utilisation avec les sous-titres), ce qui est très pratique.
Dans mon cas, il s’agissait de vidéos avec 3 flux audios, 3 sous-titres dont les 2/3 en russe (que je ne parle pas), le dernier tiers en anglais.

Afin d’alléger les fichiers et ainsi pouvoir les visionner sur mon téléphone, j’ai cherché le moyen de pouvoir effectuer cette purge, mais rapidement. Pour cela, les MKVToolnix, la boite à outil officielle du conteneur MKV vont être très utiles, ils contiennent :

  • un outil permettant d’analyser un MKV et donc de voir ce qu’il contient
  • un outil d’extraction
  • et enfin un outil de « création »

Le script en question est donc surtout un « parser » pour mkvinfo, l’outil d’analyse, permettant ensuite de lancer tout seul la suite des opérations.

Voici la sorti type d’un mkvinfo

+ En-tête EBML
|+ Type de document : matroska
|+ Version du type de document : 2
|+ Version lue du type de document : 2
+ Segment, taille 2409578102
|+ En-tête de recherche (sous-entrées ignorées)
|+ EbmlVoid (taille : 4012)
|+ Informations sur le segment
| + Coefficient temporel : 1000000
| + Application de multiplexage : libebml v0.7.9 + libmatroska v0.8.1
| + Application d'écriture : mkvmerge v3.2.0 ('Beginnings') built on Feb 12 2010 16:46:17
| + Durée : 3479.872s (00:57:59.872)
| + Date : Mon Mar 01 18:00:07 2010 UTC
| + Titre : Alpha News 1x01
| + UID de segment : 0x9b 0xe4 0xc8 0x25 0x73 0x3d 0xb7 0xed 0x81 0xc7 0x25 0x6e 0xb9 0x36 0x9e 0x8e
|+ Pistes du segment
| + Une piste
| + Numéro de piste : 1 (identifiant de piste pour mkvmerge & mkvextract : 0)
| + UID de piste : 323836576
| + Type de piste : video
| + Activé : 1
| + Marque par défaut : 1
| + Marque de forçage : 0
| + Marque de laçage : 0
| + Cache minimum : 1
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : V_MPEG4/ISO/AVC
| + Codec de décodage intégral : 1
| + Données de codec privées, longueur 95 (profil h.264 : High @L3.1)
| + Durée par défaut : 41.708ms (23.976 images/champs par seconde pour une piste vidéo)
| + Langue : eng
| + Nom : "Pilot"
| + Piste vidéo
| + Largeur (pixels) : 1280
| + Hauteur (pixels) : 720
| + Entrelacé : 0
| + Largeur à l'écran : 1280
| + Hauteur à l'écran : 720
| + Une piste
| + Numéro de piste : 2 (identifiant de piste pour mkvmerge & mkvextract : 1)
| + UID de piste : 3094425017
| + Type de piste : audio
| + Activé : 1
| + Marque par défaut : 1
| + Marque de forçage : 0
| + Marque de laçage : 1
| + Cache minimum : 0
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : A_AC3
| + Codec de décodage intégral : 1
| + Durée par défaut : 32.000ms (31.250 images/champs par seconde pour une piste vidéo)
| + Langue : rus
| + Nom : Dolby Digital 5.1 448 kbps @ Lostfilm
| + Audio track
| + Fréquence d'échantillonnage : 48000
| + Canaux : 6
| + Une piste
| + Numéro de piste : 3 (identifiant de piste pour mkvmerge & mkvextract : 2)
| + UID de piste : 31873723
| + Type de piste : audio
| + Activé : 1
| + Marque par défaut : 0
| + Marque de forçage : 0
| + Marque de laçage : 1
| + Cache minimum : 0
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : A_AC3
| + Codec de décodage intégral : 1
| + Durée par défaut : 32.000ms (31.250 images/champs par seconde pour une piste vidéo)
| + Langue : rus
| + Nom : Dolby Digital 5.1 448 kbps @ foxlight
| + Audio track
| + Fréquence d'échantillonnage : 48000
| + Canaux : 6
| + Une piste
| + Numéro de piste : 4 (identifiant de piste pour mkvmerge & mkvextract : 3)
| + UID de piste : 3654252222
| + Type de piste : audio
| + Activé : 1
| + Marque par défaut : 0
| + Marque de forçage : 0
| + Marque de laçage : 1
| + Cache minimum : 0
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : A_AC3
| + Codec de décodage intégral : 1
| + Durée par défaut : 32.000ms (31.250 images/champs par seconde pour une piste vidéo)
| + Langue : eng
| + Nom : Dolby Digital 5.1 448 kbps
| + Audio track
| + Fréquence d'échantillonnage : 48000
| + Canaux : 6
| + Une piste
| + Numéro de piste : 5 (identifiant de piste pour mkvmerge & mkvextract : 4)
| + UID de piste : 152612246
| + Type de piste : subtitles
| + Activé : 1
| + Marque par défaut : 0
| + Marque de forçage : 0
| + Marque de laçage : 0
| + Cache minimum : 0
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : S_TEXT/ASS
| + Codec de décodage intégral : 1
| + Données de codec privées, longueur 1555
| + Langue : rus
| + Nom : Russian @ ASS @ Faker020285
| + Une piste
| + Numéro de piste : 6 (identifiant de piste pour mkvmerge & mkvextract : 5)
| + UID de piste : 2319477894
| + Type de piste : subtitles
| + Activé : 1
| + Marque par défaut : 0
| + Marque de forçage : 0
| + Marque de laçage : 0
| + Cache minimum : 0
| + Coefficient temporel : 1
| + Identifiant d'ajout de bloc maximum : 0
| + Identifiant du codec : S_TEXT/ASS
| + Codec de décodage intégral : 1
| + Données de codec privées, longueur 1166
| + Langue : eng
| + Nom : English @ ASS
|+ EbmlVoid (taille : 1024)
|+ Pièces jointes
| + Joints
| + Nom du fichier : corbel_0.ttf
| + Type MIME : application/x-truetype-font
| + Données du fichier, taille : 260648
| + UIF du fichier : 4097748661
| + Description du fichier : Imported font from Breaking Bad 1x01 Pilot HD720p.ass
| + Joints
| + Nom du fichier : GARA_0.ttf
| + Type MIME : application/x-truetype-font
| + Données du fichier, taille : 198069
| + UIF du fichier : 1642350759
| + Description du fichier : Imported font from Breaking Bad 1x01 Pilot HD720p.ass
| + Joints
| + Nom du fichier : Candara_0.ttf
| + Type MIME : application/x-truetype-font
| + Données du fichier, taille : 218504
| + UIF du fichier : 3442251435
| + Description du fichier : Imported font from Breaking Bad 1x01 Pilot HD720p.ass
| + Joints
| + Nom du fichier : HermesCTT Regular_0.ttf
| + Type MIME : application/x-truetype-font
| + Données du fichier, taille : 54693
| + UIF du fichier : 2891661193
| + Description du fichier : Imported font from Breaking Bad 1x01 Pilot HD720p.ass
| + Joints
| + Nom du fichier : GOTHIC_0.ttf
| + Type MIME : application/x-truetype-font
| + Données du fichier, taille : 137565
| + UIF du fichier : 61850035
| + Description du fichier : Imported font from Breaking Bad 1x01 Pilot HD720p.ass
|+ Cluster

Cela va être très pratique à parser, les informations d’un même élément étant étalés sur plusieurs lignes.
L’idée va être de rassembler toutes les informations intéressantes dans un tableau avec :
* en première colonne, le numéro de piste pour mkvextract
* en seconde colonne, le type de la piste
* en troisième colonne, la langue de la piste

A coup de regex, cela donne quelque chose dans le style :

Piste Type Lang File 
----- ---- ---- ---- 
0 
video 
eng 
1 
audio 
rus 
2 
audio 
rus 
3 
audio 
eng 
4 
subtitles 
rus 
5 
subtitles 
eng 
corbel_0.ttf 
GARA_0.ttf 
Candara_0.ttf 
HermesCTT Regula...
GOTHIC_0.ttf

On retrouve bien le fait que l’information est éparpillée : pour chaque piste, l’information doit être lu sur 3 colonnes, mais à partir de ces informations, cela est suffisant pour lancer la commande de purge, on a donc tous les éléments en main pour écrire le script, ci-dessous.

function TransformMKV ($file) {
	$mkvinfo = 'C:\Program Files\MKVToolNix\mkvinfo.exe'
	$mkvextract = 'C:\Program Files\MKVToolNix\mkvextract.exe'
	$mkvmerge = 'C:\Program Files\MKVToolNix\mkvmerge.exe'
	$workdir = 'D:\temps'

	$rawOutput = & $mkvinfo $file
	$output = $rawOutput | Select-String -Pattern 'mkvextract : (?<piste>[0-9]+)', `
		'Type de piste : (?<type>.+)', `
		'Langue : (?<lang>.+)', `
		'Nom du fichier : (?<file>.+)'

	$data = $output | Select-Object @{"Label"="Piste";"Expression"={$_.Matches[0].Groups['piste'].Value}}, `
		@{"Label"="Type";"Expression"={$_.Matches[0].Groups['type'].Value}}, `
		@{"Label"="Lang";"Expression"={$_.Matches[0].Groups['lang'].Value}}, `
		@{"Label"="File";"Expression"={$_.Matches[0].Groups['file'].Value}}

	$i = 0
	$audioTracks = @()
	$subTracks = @()

	if ((Test-Path $workdir -PathType Container) -ne $true) {
		New-Item $workdir -ItemType folder
	}

	while ($i -lt $data.Count) {
		$line = $data[$i]
		$piste = $line.piste

		if ($piste -ne $null -and $piste -ne '') {
			$type = $data[++$i].type
			$lang = $data[++$i].lang

			if ($lang -eq 'rus') { continue }
			if ($type -eq 'subtitles') { $subTracks += $piste }
			elseif ($type -eq 'audio') { $audioTracks += $piste }
		}

		$i++
	}

	& $mkvmerge -q -o ("{0}\{1}" -f $workdir, [System.IO.Path]::GetFileName($file)) --default-language eng -a ($audioTracks -join ',') -s ($subTracks -join ',') "$file"
}

Get-Item -Path 'W:\source\*.mkv' | ForEach-Object { TransformMKV($_) }

 

C’est écrit à l’arrache, mais pour ce qui me concerne, il a été suffisant et reste simple à modifier.
On commence par indiquer en dur où se trouve les différents binaires, ainsi qu’un dossier de travail qui sera crée automatiquement s’il n’existe pas.
On balance un mkvinfo sur le fichier source qu’on transforme en object avec la cmdlet Select-Object . Il ne faut surtout pas utiliser Format-Table, lequel ne sert qu’à faire de l’affichage, et ne peut donc être pipé que dans la Console.

Durant la boucle, on rassemble les morceaux et on liste l’ensemble des pistes à garder (j’ai posé en hypothèse que je n’ai qu’une seule piste vidéo, et que donc je garde toutes les pistes vidéos lors de la purge).

Enfin on exécute mkvmerge, lequel a la capacité de créer des mkv à partir de flux nu, mais également à partir d’autres container, comme un mkv. La première solution étant plus difficile (car alors il faut également gérer l’existence et l’extraction des tags, chapitres, fichiers embarqués), je me suis tourné var la seconde solution, où il suffit d’indiquer ce que l’on souhaite garder et le reste est conservé.
La ligne de commande indique donc de garder tous les flux vidéos, tous les tags, chapitres et fichier embarqués, et de ne conserver que les flux audios et sous-titres spécifiés.

Enjoy !

Accès nvFlash sur l’Asus Transformer Prime TF700T

android, hack
Posted on Leave a comment on Accès nvFlash sur l’Asus Transformer Prime TF700T
Avertissement : cette bidouille a le pouvoir de transformer votre tablette en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers sans le sou et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

Description

Ce billet détaille la procédure permettant d’avoir un accès nvFlash à la tablette Asus Transformer Prime TF700T. La procédure a été testée avec succès sur ma tablette en Jelly Bean, plus précisément avec le firmware 10.6.1.14.10, le dernier mis à disposition à l’heure où j’écris. Jusqu’à récemment, il n’était possible de bénéficier de cet accès qu’avec la tablette en version ICS (Ice Cream Sandwich).

L’accès nvFlash, est un accès très bas-level, dont le principal intérêt est de pouvoir récupérer sa tablette quelque soit son état, notamment et surtout suite à un flash moisi. En d’autre terme, on bénéficie ainsi d’une tablette « brick-safe ».

Vu qu’ASUS permet de déverrouiller suffisamment le bootloader pour installer des roms customs, mais pas suffisamment pour éviter de la transformer en brique, l’accès nvFlash est donc plutôt recommandé, bien que la procédure soit risqué.

Pré-requis

Vous avez besoin :

  • des pilotes Windows. Ceux-ci sont signés afin de pouvoir les utiliser simplement sous Windows 8. Il s’agit des pilotes fournit par Google, auxquels j’ai ajouté les identifications de l’ASUS Transformer Prime TF700T et du Nexus 4, que j’ai signé avec mon propre certificat. Etant donné la nature de mon certificat, ces pilotes expireront en 2015.
  • de nvFlash (à télécharger sur le site de AndroidRoot)
  • un recovery spécialement modifié (à télécharger sur le site de AndroidRoot)
  • une tablette déverouillée

Déverrouiller la tablette

Installez et exécutez l’application Unlock_v8. Elle n’est officiellement compatible qu’avec Jelly Bean. Pour Ice Cream Sandwich, il vous faut la version v7, disponible sur les serveurs d’Asus.

Obtention de l’accès APX

La procédure n’est à faire que la première fois. Elle permet de construire un blob permettant de déverrouiller les commandes en mode APX. Ce blob est nécessaire à chaque fois qu’on désire accéder au mode APX.

  1. Sauvegardez tout ce dont vous avez besoin sur la tablette, y compris la mémoire interne ; on n’est jamais trop prudent
  2. Branchez la tablette au PC si ce n’est déjà fait
  3. Démarrez la tablette en bootloader.
    • A partir de la tablette éteinte, appuyez sur Power, puis sur Volume-Down jusqu’à voir trois icônes au milieu : RCK (pour accéder au recovery), Android (pour démarrer Android), et la dernière icône pour une réinitialisation de la tablette
    • A partir de la tablette allumée, envoyez la commande adb reboot-bootloader , c’est le plus simple
  4. Flashez le recovery spécial: fastboot flash boot flatline_tf700.img . Si le transfert dure plus de 5 min, vérifier les points suivants :
    1. la tablette est bien reconnue sous Windows. Si ce n’est pas le cas, le câble USB est peut-être mal enfichée, ou il faut tester avec une autre prise USB, ou bien tentez de passer dans le bootloader avec la commande adb.
    2. sinon tentez de renommer le fichier en tf700.img  (sans underscore) et réessayez
  5. Redémarrez la tablette complètement dans le bootloader (c’est à dire, n’accédez pas directement au recovery // normalement (avec Volume-Up pour sélectionnez l’item du milieu, puis Volume-Down pour valider) , sous Android, puis repassez dans le bootloader
  6. Accédez au recovery en validant l’item RCK
  7. Sélectionnez dans les menus : Advanced > Wheelie
  8. Acceptez l’avertissement, puis sélectionnez l’étape 1 : « Step 1: Flash AndroidRoot BL »
  9. La tablette devrait s’éteindre. Allumez-la normalement sous Android, puis repassez dans le recovery (via le bootloader ou bien avec la comande @@adb reboot recovery@@)
  10. Dans le recovery, sélectionnez Advanced > Wheelie
  11. Acceptez à nouveau l’avertissement, puis sélectionnez l’étape 2 : « Step 2: Generate wheelie blobs ». L’opération va prendre un certain temps…
  12. Une fois terminez, récupérez les blobs avec la commande indiqué dans la console. Gardez les au moins en double exemplaire, ils sont indispensable pour accéder au mode APX, et ce dernier est le seul moyen permettant de récupérer sa tablette sans l’envoyer en SAV.
  13. Vérifiez que vous avez bien accès au mode APX en passant à la section suivante

Accès au mode APX

Le mode APX n’est accessible qu’à partir de la tablette à l’état éteint. La combinaison de touche est la suivante : Power suivit de Volume-Up.
Si la combinaison a bien été réalisée, l’écran de la tablette devrait s’éteindre, et le PC devrait reconnaître un nouveau périphérique intitulé APX.

Le déverrouillage des commandes APX se fait à ce moment là en tapant la commande suivante : wheelie –blob blob.bin  où blob.bin  correspond à l’un des fichiers récupérés avec le recovery modifié. Si le blob est reconnu et accepté par la tablette, wheelie  devrait afficher l’id de la tablette et l’écran devrait afficher le bootloader.

Si c’est la première fois que vous accédez au mode APX, il est vivement conseillé de sauvegarder également certaines partitions :

  • une image utile dans la récupération de sa tablette : nvflash -r –rawdeviceread 0 2944 bricksafe.img
  • la configuration d’usine avec la commande nvflash -r –read 14 14_factory-config.img
  • le token de déverrouillage du bootloader nvflash -r –read 7 07_unlock-token.img
  • d’autres partitions peuvent être sauvegardées avec le paramètre read, en spécifiant le numéro de la partition. La liste des partitions est décrite ci-dessous.

On quitte le mode APX avec la commande nvflash -r –go .

Table de partitions

La tablette TF700T contient au moins 18 partitions :

  • Partition 02 : BCT, le Boot Configuration Table.
  • Partition 03 : PT, le Partition Table
  • Partition 04 : EBT, le Encrypted Bootloader
  • Partition 05 : SOS, le recovery kernel
  • Partition 06 : LNX, le kernel linux
  • Partition 07 : CER, le bootloader unlock token
  • Partition 08 : IMG
  • Partition 09 : GP1, espace libre pour une table de partition GP1
  • Partition 10 : APP, partition /system, ext4
  • Partition 11 : CAC, partition /cache, ext4
  • Partition 12: MSC, partition /misc, ext4
  • Partition 13 : USP, Upgrade Staging Partition, monté sur /stating et au format ext3. Utilisé durant les mises à jour du firmware
  • Partition 14 : PER, partition /btmac monté durant le boot, au format fat32. Contient des données système spécifique au périphérique
  • Partition 15 : YTU, contient peut-être des données de chiffrage pour les DRM.
  • Partition 16 : CRA, usage inconnu
  • Partition 17 : UDA, /data, ext4.

Ces partitions peuvent être sauvegardées

Le Bootloader

Le bootloader est accessible en appuyant sur Power puis Volume-Down lorsque la tablette est éteinte. Il est également possible d’y accéder depuis Android en tapant adb reboot-recovery .
Une fois dedans, 4 options sont disponibles :

  • la commande fastboot, à condition que la tablette soit déverrouillée
  • le recovery (la première icône RCK)
  • la continuation du démarrage normal sous Android (la seconde icône Android)
  • la réinitialisation de la tablette (wipe data/cache, c’est la dernière icône)

On navigue entre les différentes icônes avec Volume-Down, et on valide l’item sélectionné avec Volume-Up.
A partir d’un certain temps, le bootloader peut sembler être planté ou super long, mais tant qu’on n’a pas bidouillé avec fastboot, c’est juste qu’il est très long.

Voir aussi