Take the following instruction sequence for example: While the math being performed is not complicated, determining the original programmer’s intent is not necessarily straightforward due to the assembly generated by the compiler.

The MAC address is then split into its OUI and NIC components, and a tedious set of multiplications, xors, and shifts ensues (full disassembly listing here):īreak out the MAC and start munging the NIC This code isn’t retrieving a WPS pin at all, but instead is grabbing the router’s WAN MAC address. Since the WPS pin is typically programmed into NVRAM at the factory, one might expect sub_4D56F8 to simply be performing some NVRAM queries, but that is not the case: The default WPS pin itself is retrieved via a call to sub_4D56F8. However, this data proved not to be user controllable, as the value placed in the format string is the default WPS pin for the router. I first began examining this particular piece of code with the hopes of controlling part of the format string that is passed to _system. While perusing the latest firmware for D-Link’s DIR-810L 80211ac router, I found an interesting bit of code in sbin/ncc, a binary which provides back-end services used by many other processes on the device, including the HTTP and UPnP servers:

Convert mac address to pin