Sujet: VU+ avait un timebomb dans ses drivers, l'hécatombe des clones

[pr2]

Bonjour,

Il semble que VU+ avait bien préparé leur coup (félicitations à eux), depuis plusieurs drivers un timebomb contre les clones étaient présent, il semble que celui-ci se soit déclencher à l'occasion de Pâques.

C'est l'hécatombe chez les clones de VU+, bien joué les gars!

Pr2

[Danield]

Excellente nouvelle, surtout quand on voit la pub faite pour les clones sur certains forum. J'attends avec impatience les retours de certains.

[chmix38fr]

Bonjour,

Il semble que VU+ avait bien préparé leur coup (félicitations à eux), depuis plusieurs drivers un timebomb contre les clones étaient présent, il semble que celui-ci se soit déclencher à l'occasion de Pâques.

C'est l'hécatombe chez les clones de VU+, bien joué les gars!

Pr2

Salut,

c'est a dire !! merci pour l'info mais on en sait pas plus ... quelles conséquences pour les clones..??
définitivement "Brickés ??"" ou autres pb logiciels ?
On aimerait bien en savoir plus pour bien se fendre la poire !!!

@+

[pr2]

L'info circule sur plusieurs forums anglophones, les clones semblent bien "mortes" maintenant certains arriveront sans doute à les ressusciter...

En fait le bootloader a été effacé... 

Un lien en pleine ébullition sur le sujet:

Code: [Sélectionner]

http://www.digitalworldz.co.uk/vu-solo2-receivers-633/378201-anyone-got-chinese-vu-225.html

Pr2

[pr2]

Bonjour,

Un poste qui est intéressant à lire (désolé en anglais):

http://openpli.org/forums/topic/33364-vu-clone-attack/#entry418708

Pr2

[killminusnine]

Merci Pr2,
Post super intéressant en effet !

Pour ceux qui ne parlent pas la langue de Shakespeare, je me suis permis de le traduire !

Source : radxnl (membre Pli Core)
Traduction : Kill-9

Donc, petite formation technique, juste pour ceux que ça intéresse

Il y a environ un peu plus de six mois, j'avais déjà fait savoir que l'on avait ajouté une « bombe à retardement » dans les pilotes VU+. Je ne connais plus le fil exact par cœur, mais je suis à peu près certain que la fonction de recherche permet de le retrouver.

Les versions suivantes du pilote, excepté pour les corrections et améliorations de bugs habituelles, tentaient d'exécuter ce qui est désormais exécuté «en direct» .

Grâce au fait que les gars qui clonent la sécurité pour le compte des Chinois (et c'était fait en Europe, en fait, comme beaucoup d'entre vous le savaient peut-être), ils produisent une assez bonne copie de la puce TPM Alpu (de chez Neowine), qui est utilisée par de nombreux fabricants de terminaux et bien sûr ne proposent pas vraiment de protection contre les clones, et n'en proposeront jamais . Vu+ se devait donc de chercher un autre moyen d'établir l'authenticité du circuit.

Ainsi, le deuxième choix logique était le FPGA, Eh ! en plus c'était complètement légal de toute façon et pour les entreprises de clonage, ça voulait dire, à coup sûr, une ardoise supplémentaire de 10 à 25.000 $ pour l'extraire et donc c'était bien sûr la solution la plus logique.

Donc, cela nous amène à la situation actuelle : le mieux qu'ils puissent faire est de tout simplement effacer le bloc dans la nand d'où le système embarqué démarre, cela voudrait dire que les revendeurs devront au moins être équipés des outils et des logiciels nécessaires à relancer tous les terminaux tués durant l'attaque du 19 avril 2014.

Ce qui est bien évidemment une bonne chose à bien des égards !

Premièrement - la filière des clones est interrompue, même si ce n'est que pour peu de temps. Mais ça donne un signal fort au marché de l'utilisateur final de ne jamais acheter un clone (bien évidemment, l'achat d'un clone est toujours une mauvaise chose en soi) et que par conséquent vous ne pouvez jamais être sûr de ce qui va se passer.

Deuxièmement - Ca crée un marché pour le «gars qui bricole dans son grenier avec sa station de soudure» (non pas qu'il en aura besoin dans le cas présent) mais vous savez de quel gars je parle, ce sont les mêmes gars qui ont aidé quand les modules CI et autres terminaux ont été tués (c'est-à-dire effacés) dans le passé.

Je suppose donc que la prochaine étape sera que les fabricants de clones vont commencer à expédier des outils d'activation pour les revendeurs, et ainsi de suite, et ils corrigeront bientôt le problème en trois coups de cuillère à pot.

Maintenant, juste parce que nous avons le pouvoir, jettons un rapide aperçu de ce qu'est exactement la « vérification d'authenticité » et les « contre-mesures » prises par VU+.

Laissez-moi d'abord juste mettre les choses au point, je n'ai aucune implication dans des activités de clonage, je suis juste un chercheur indépendant qui aime «voir ce qui se passe sous le capot".

Et que j'explique ou non, ça ne changera rien à l'affaire, le matériel actuellement désactivé sera ressuscité, j'en mets ma main au feu, compte tenu du fait que trop d'unités ont déjà été vendues et qu'il est donc impératif que les entreprises qui les ont fabriquées corrigent le «problème», et il est certain qu'elles le feront.
 
Donc, ce qu'ils (Ndlr : VU+) ont fait en premier est un peu de magie sauce FPGA pour confirmer aux pilotes qu'ils sont en fait en train de dialoguer avec du matériel cloné (je ne vais pas m'attarder sur les détails de la façon dont ils opèrent, il s'agit juste de quelques traitements de type "défi", de quelques traitements cryptographiques basés sur DES et de quelques autres bricoles, mais pas vraiment intéressantes à détailler).

Puis, après avoir établi qu'il ne s'agit pas d'un équipement authentique, quelques compteurs commencent à tourner à certains endroits critiques, comme dans les réglages du front-end, quelques actions avec l'afficheur VFD et un compteur aléatoire connecté à l'entrée A/V . Donc, ce faisant, ils sont à peu près sûrs qu'à un moment donné les limites du compteur seront atteintes et il sera alors temps d’exécuter «la vérification».

Le déroulement de la vérification consiste en un simple «bonjour, quel jour sommes-nous ?" si c'est le 19/04/2014 ou plus tard, il est temps de procéder à quelque effacement afin de faire passer le message suivant : "nous ne sommes pas très heureux que vous ayez cloné notre matériel !".

Alors maintenant, pour amorcer l'effacement, tout ce qu'il leur reste à faire est de nettoyer la zone où le système embarqué commence sa lecture après son démarrage (le chargeur de démarrage, également connu sous le terme de CFE) . Mais quelles que soient les raisons pour lesquelles ils ont opté pour l'effacement de 64 pages, je suppose que c'est pour s'assurer qu'il ne démarrera vraiment plus (en fait, peu importe, une seule page aurait été amplement suffisante).

Un peu plus tard, durant la poursuite de l'effacement lorsque les fonctions critiques sont invoquées jusqu'à ce que le terminal soit redémarré l'utilisateur se verra gratifié à ce moment précis d'un bel écran noir et pas la moindre autre réaction du terminal, à tout jamais. Tous les ports GPIO resteront non initialisés après la mise sous tension, ce qui provoque par exemple que le voyant de l'interface réseau reste allumé en permanence et ainsi de suite.

Donc, voilà à peu près ce qui se passe. Les clones sont tués et maintenant nous allons voir en quoi la riposte consistera
 
Pour ceux qui souhaitent étudier la question par eux -mêmes, les fonctions récentes ont été ajoutées dans les pilotes à partir d'un fichier appelé brcm_fpga_secu.c,

Trouvez-le et vous verrez ce dont je parlais

Un extrait de code rapide de celui-ci (pas forcément intéressant, puisque ici le dommage a « déjà été commis» ) mais c'est juste pour l'exemple :
 

Code: [Sélectionner]

nand_erase_64_pages (void )
{
    for (int addr = 0 ; adr < 64 ; adr + = 2 )
    {
        BDEV_WR_RB ( ( BCHP_NAND_CMD_ADDRESS , addr ) ) ;
        BDEV_WR_RB ( ( BCHP_NAND_CMD_START , CMD_ERASE << BCHP_NAND_CMD_START_OPCODE_SHIFT ) ) ;
        BDEV_WR_RB ( ( BCHP_NAND_CMD_START , CMD_NULL << BCHP_NAND_CMD_START_OPCODE_SHIFT ) ) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x00 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x04 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x08 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_0 0x0c + , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x00 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x04 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x08 , 0)) ;
        BDEV_WR ( BCHP_NAND_SPARE_AREA_WRITE_OFS_10 0x0c + , 0)) ;
        BKNI_Sleep_tagged (20);
    }
    BKNI_Sleep_tagged (100);
}

La morale de l'histoire est bien sûr, qu'avec le produit authentique vous n'auriez jamais eu ce genre de problème et donc qui est toujours la voie à suivre !

Mais ça n'engage que moi Bonne lecture !

Radxnl

[MiKe]

Merci pour la traduction Kill-9 

[demosat]

Salut,

Il semblerait que les clones ne se ressemblent pas devant le timebomb.
A lire le pdf joint.

[pr2]

Oui si ils utilisent une vieille image ou si ils utilisent une image qui utilise les anciens drivers.
Le gars qui signale qu'Openpli fonctionne à mon avis le check qui se fait régulièrement ne s'est pas encore déclenché et donc après le flash cela fonctionne mais quand le check se déclenchera sa box va aussi mourir.  Mais j'ai plus souvent lu ce problème sur les clones de Solo2 ici il parle de clone de Duo.

[chmix38fr]

L'info circule sur plusieurs forums anglophones, les clones semblent bien "mortes" maintenant certains arriveront sans doute à les ressusciter...

En fait le bootloader a été effacé...  

Un lien en pleine ébullition sur le sujet:

Code: [Sélectionner]

http://www.digitalworldz.co.uk/vu-solo2-receivers-633/378201-anyone-got-chinese-vu-225.html

Pr2

MDR !! ça sent le JTAG à plein Nez !!! y vont pouvoir vendre plein d'interfaces , nos amis chinois !