Ha elolvasod a korábbi elemzést, abból kiderül, hogy nem is igazán történt forráskód módosítás.
Mindössze egy konfigurációs paraméter lett megváltoztatva, ez pedig vagy hardkódolva volt a forrásban, vagy build-time paraméter volt. Ha az utóbbi, akkor nem feltétlenül van verziókövetve.
A gáz sokkal inkább az, hogy az implementációban minden szükséges körülmény elő volt készítve a backdoorhoz, és arról szó sincs, hogy ez "illetéktelenül" került volna be.
Az egész Dual EC algoritmus fő baja az, hogy ezen a bizonyos Q paraméteren áll vagy bukik az egész titkossága. (Ezért is gyanítják az NSA-t mögötte, az egész túl szép ahhoz, hogy véletlen legyen, valószínűleg egy hadseregnyi matematikus célzottan dolgozott rajta, hogy kitaláljanak egy ilyen tulajdonsággal rendelkező algoritmust) Normális esetben a Q egy random érték kéne hogy legyen, de származtatott módon is elő lehet állítani úgy, hogy - jelen tudásunk szerint - az előállításhoz használt paraméterek hiányában nem lehet utólag megállapítani, hogy valóban random, vagy számított értékkel van dolgunk. Viszont ha a Q származtatott, akkor akinek a megvannak a Q előállításhoz felhasznált kiinduló-értékek, az majdnem törni tudja. Azért majdnem, mert a payload-ot nem tartalmazó cryptostreamből egy egészen rövid szakaszhoz is hozzá kell férnie, hogy a további szakaszokat maga is elő tudja állítani. És hogy hogynem a Juniper kódjában pont volt egy bug, amit ezt lehetővé tette. A Juniper eddig nem a szabványban rögzített (egyébként szintén "gyanús") Q értéket használt, hanem egy sajátot amiről - természetesen - nem tudni hogyan állították elő. Vagyis simán lehet, hogy ez egy eleve üzemszerűen működő backdoor volt. Ezt a paramétert valaki kicserélte egy másik Q-ra. Vagyis mindössze annyi történt, hogy korábban "A" csoport tudta kihasználni, ezután "B" csoport tudja kihasználni a backdoor-t. A "javítás" annyi volt, hogy visszaállították az eredeti Q értéket, vagyis újra az "A" csoport tudja törni a kódot.
---
Régóta vágyok én, az androidok mezonkincsére már!