Having decided upon the outlined attack, we tried it by creating an Enigma simulator, encrypting English texts, and letting the program decrypt them. The success rate was fairly high; the wheel and ring settings were always correct, but the plugboard settings were sometimes slightly off.
On October 7, Gunnar and Staffan felt ready to go and let a group of workstations try all the possible settings, storing the 100 most likely decryptions for manual inspection. In the morning, we were disappointed: None of the candidate decryptions looked even remotely like text in any language. What had gone wrong? An intense testing and debugging pass commenced, but no bugs were found.
The explanation came a couple of days later when Stage 7 was cracked: The plaintext for that stage revealed that Singh had been mischievous when constructing this stage: The first two wheels should actually be exchanged! Confident that Stage 8 would succumb immediately, the three team members who found the solution to Stage 7 pulled an all-nighter running the Enigma cracker with the correct wheel settings. Again, nothing sensible was produced by the program.
At this point we knew that we had the correct wheel setting, but our program still failed to find the solution. So what could be wrong? We looked for bugs in the program, but could not find any. Turning to the algorithmic approach, we decided on changing scoring method and removed the assumption that the plaintext was in German, instead trying the less efficient but more general method of assuming that the correct plaintext had the most skewed frequency distribution. Again, the workstations were set to their work during the night.
When Gunnar came to work the next morning, he found the following output from the program.
Highest scores: 10356.00 OUA FA E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10354.00 OUA FP E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10232.00 OUA FA E->X SQCDEFGHRNLKUJTPBIAOMVWXYZ 10220.00 OUA FP E->X SQCDEFGHRNLKUJTPBIAOMVWXYZ 10206.00 OUB FB E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10168.00 OUA EA E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10168.00 OUA EP E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10150.00 OUB FC E->I SBTDEFGHINLKUJWPQRACMVOXYZ 10112.00 OUA EA E->X SQCDEFGHRNLKUJTPBIAOMVWXYZ 10104.00 OUA EP E->X SQCDEFGHRNLKUJTPBIAOMVWXYZThe second column gives the initial position of the wheels, the third column gives the ring settings, the fourth column the mapping of the letter E, and the sixth column the rest of the plugboard settings. The best solution corresponds to a plugboard with 7 swaps:
DASXATESUNGKOCRWXISWJBLHWCXXSWEXEXNEUIXELWHAELAKEINEHJIWWEIL KRVXCIEXVIWXXESXEAWKCDIENOXISWXXITHXHABEXVASXLINKSSWEHEMDEXB YWEXDEXESTHLUESSEPSXENJDETKWXXESXISWIEINSXNIESXGERCXEHNSXZER MXZERCXEVESXEIOSXEINSXEITHEPRCGRAMMIERWEXDESXUNDXENWDETKWEXD ASSXDASXOCRWXYEBUGGERXCEDNNESYMIWXOEMXUNWEBSWEHENDENXSTHJUEU SELXENWKCDIERBXONRDFALJIRESULWAWXDIEXUNWENSWEHENDENXSTHRISWZ EITHENXHAWAs we can see this look almost like German. Some of the plugboard connections are however wrong. If we look carefully we see the ``words'' STHLUESSE, PRCGRAMMIER, and RESULWAW in the plaintext. It looks as if C should not be swapped at all, and that instead O and T should be swapped. If we then leave W unmodified we get 6 swaps altogether:
Using these settings the complete plaintext emerged along with the codeword PLUTO:
DASXLOESUNGSWORTXISTXPLUTOXXSTUFEXNEUNXENTHAELTXEINEXMITTEIL UNGXDIEXMITXDESXENTKODIERTXISTXXICHXHABEXDASXLINKSSTEHENDEXB YTEXDESXSCHLUESSELSXENTDECKTXXESXISTXEINSXEINSXZEROXEINSXZER OXZEROXEINSXEINSXEINSXXICHXPROGRAMMIERTEXDESXUNDXENTDECKTEXD ASSXDASXWORTXDEBUGGERXWENNXESXMITXDEMXUNTENSTEHENDENXSCHLUES SELXENTKODIERTXWIRDXALSXRESULTATXDIEXUNTENSTEHENDENXSCHRIFTZ EICHENXHAT
The plaintext was in German, but the program still could not recognize the right plaintext when using frequency tables for German. What was the explanation for this? Inspecting the plaintext, it is clear that X was used as word delimiter and XX as sequence delimiter. As X is rare in most German texts, the approach based on frequency tables failed to recognize the correct plaintext.