<story><title>Unravelling Konami&apos;s Arcade DRM</title><url>http://mon.im/2017/12/konami-arcade-drm.html</url></story><parent_chain></parent_chain><comment><author>tptacek</author><text>&lt;i&gt;After 15 minutes spent trying to decipher this, I simply translated the code into Python and iterated infinitely. Turns out, this is how you perform big-endian addition without actually converting the number to little-endian. An odd way of doing it, but perhaps a compiler optimisation. It turns out they’re actually using AES_CTR, but instead of incrementing the entire counter IV, they’re only using the last 4 bytes. A little strange, but if your encrypted file is 232 &lt;/i&gt; 16 bytes long, you have other problems to worry about.*&lt;p&gt;Not all that strange. The &amp;quot;counter block&amp;quot; is normally split into a nonce, which allows you to reuse the same key on multiple messages without generating a duplicate keystream, and a counter; an AES block is 16 bytes wide, so a 64 bit counter is more typical, but I&amp;#x27;ve seen 32.&lt;p&gt;Doing that can even make sense, if you have bounded message sizes (&amp;lt;64 gigs) --- the larger the space you allocate for the nonce, the safer it is to generate nonces randomly, rather than using a system to remember all previous nonces to avoid collisions.</text></comment>
<story><title>Unravelling Konami&apos;s Arcade DRM</title><url>http://mon.im/2017/12/konami-arcade-drm.html</url></story><parent_chain></parent_chain><comment><author>distantsounds</author><text>This stuff has been documented in private circles for over a decade now, and hasn&amp;#x27;t been made public because these games aren&amp;#x27;t available to play outside of owning a cabinet in Japan or acquiring the data via less-legit methods. While it&amp;#x27;s a fun exercise to explore, the real-world application is sadly limited to grey-market implementations that Konami frowns upon, which reinforces why the exposure has been limited.</text></comment>