First of all, let it be said that the D2 nano acts only once in the card that receives it.
The first time that it's received, it activates a different algorithm of the nano 51
whose low nibble of the first argument byte is equal to the low nibble of the first argument byte of the nano D2.
Because of the numerous clockcycles used by the card when it receives it's first nano D2,
it is supposed that the trial of validation of this nano is similar to that used by the nano B1,
but this argument has still not been fully resolved.
As we know, until the current date (15 September 2004) we have seen three different types of argument of the nano D2 in the ECM.
For the first months we had:
(D2)01ED10CE52FFFFDDD831450000000000
subsequently, we had:
(D2)029601C1ACDA307ED1AE46D450CEE176
from 14 September we have:
(D2)0939A79E24C5F4219B39B6014A40F31C
Currently we know that the D2 nano is not just a simple carrier of data (like erroneously hypothesized in the New nano FAQ).
In fact, it activates the various algorithms of nano 51 as indicated by the low nibble of the first byte of its argument.
Therefore:
(D2)01xxxxxxxx... activates (51)0191xxxxxxxx
(D2)02xxxxxxxx... activates (51)0291xxxxxxxx
(D2)09xxxxxxxx... activates (51)0991xxxxxxxx
And so on..
The three nanocommands (and their respective arguments) listed just above,
activated variations to the algorithm of the nano 51 that it presented, at the time, with the following arguments:
(51)0191000000
(51)0291C7F0BB
(51)0991B99744
We had also different arguments relevant to the nano (51)01xxxxxxxx but all those did use the same algorithm.
Here, for example, is a de-SE of an ECM of 30 August 2004:
(D2)01ED10CE52FFFFDDD8314569A9761619
(51)0191FC2B94
(0F)
(1C)10
(39)3FF6E1
(12)00
(27)1D1E
(13)2C
(13)2D
(13)33
(D1)3025E328AF5DAF3ABAE0407FE9D272E4
and here is a de-SE of an ECM of 10 September 2004:
(D2)01ED10CE52FFFFDDD83145F29B61B309
(51)015FABDA6
(1C)10
(0F)
(39)D436FF
(12)00
(27)1D2A
(13)2C
(13)2D
(13)33
(D1)D0A04DD462F051A3F462F9970536E45F
We can note from the comparison of the different (D2)01xxxxx....
that the following nano have been present in D2 (and respective arguments) :
(D2)01ED10CE52FFFFDDD831450000000000
(D2)01ED10CE52FFFFDDD8314569A9761619
(D2)01ED10CE52FFFFDDD83145F29B61B309
We note that the last 5 byte of the argument of the command do not influence the construction of the first part of the same command.
If we wanted to activate the algorithm of the nano (51)0191xxxxxx in a card that never received the nano (D2)01xxxxx....
we are able well to build and to send off an command like the following one:
(D2)01ED10CE52FFFFDDD83145xxxxxxxxxx
In which the value of the xxxxxxxxxx could be changed at our pleasure.
Definitive: the first 11 bytes of the argument of nano D2 have fixed characters!
At the time of writing, it's still unknown how the validation of, and the argument to nano D2 works,
for that eventual activation of other algorithms for the nano 51 will depend from the
volont? of the GF that? the but pu?
(guess by me, something like: volontair of the <GF>?? that works he's but of)
to build a valid argument of the nano D2 that can activate new variations in the algorithm of the nano 51.
We also cannot predict the future argument's of possible nanocommand D2's that activate other algorithms for the nano 51.
Theoretically, we could have the following values of nano 51 in the future:
(51)0091xxxxxxxx
(51)0391xxxxxxxx
(51)0491xxxxxxxx
(51)0591xxxxxxxx
(51)0691xxxxxxxx
(51)0791xxxxxxxx
(51)0891xxxxxxxx
(51)0A91xxxxxxxx
(51)0B91xxxxxxxx
(51)0C91xxxxxxxx
(51)0D91xxxxxxxx
(51)0E91xxxxxxxx
(51)0F91xxxxxxxx
All these values will correspond potentially to different variants of the same algorithm.
These vary everything, and might potentially be activated from other arguments than the nano D2.
We cannot predict such arguments nor how to calculate them.
In all these cases, ALL of THE emulators will be destined to fail.
A original card holder will receive the correct D2 as needed.
You salute,
Pop-Rock
Thx Dfs & Pop-rock
