I don’t think they are testing for small primes at all. Maybe you’ve made the same mistake in understanding as I did originally because of your “small primes” priming (no pun intended).
Again, look what it does for 11. Let us suppose our modulus is M.
The code divides M by 11 and finds the remainder, then it left shifts 1 by this number, so that will produce one of the values 1, 2, 4, 8, 16 and so on up to 1024.
Then it does a bitwise AND between this value and the corresponding big number from prints which is 1026. If and only if this bitwise AND gives a zero result it concludes this key was NOT generated by an Infineon device and so it’s not interesting. This even includes the small primes.
Try M = 77, which is definitely divisible by a small prime
M := 77
M % 11 = 0
1 << 0 = 1
1 & 1026 = 0
Not Infineon. They don’t care it’s divisible by a small prime, the Infineon devices don’t spit such moduli, they have a decent primarily tester inside them, it’s just that they’re broken in some other way.
So what does fail the test and cause it to keep trying? That technical report I linked illustrates, the first small prime for which it’s interesting is 11 as I mentioned earlier, Infineon devices never pick a modulus which has remainder 2, 3, 4, 5, 6, 7, 8 or 9 when divided by 11, it’s always 1 or 10. Hence the choice of 1026 which is (1 << 10) + (1 << 1).
The reason it’s doing this seems to be that if M mod 11 in { 1, 10 } that means M² mod 11 is 1 because of how modulo arithmetic works. For each small prime s there’s some small exponent a such that M^a mod s = 1 for all Infineon moduli, and the complicated mess in the sample code relates to that fact in an obscure fashion. So probably a much simpler and better test is possible, it may make sense to wait for the finished paper rather than speculate further though.