Cisco wireless controller device and root access

I am often approached with requests for troubleshooting of Cisco wireless controllers, some of which stem from not knowing how they are designed and work. The controller of wireless access points is not a familiar router or switch with IOS, it is a specialized computer (or virtual machine) with Linux inside. Today we will get acquainted with the hardware platforms of different controllers, learn about the mechanism of their licensing, analyze one firmware, and get root access to the device.

What for

In short, controllers are needed for centralized management of large wireless networks built on the basis of relatively non-individually adjustable access points. I wrote about this architecture in detail on Habré ( one , two , three , four ). Access points located across the premises of the enterprise (not necessarily in the same office) through a local or global network are registered on the controller, receive settings from it, are controlled by it, and provide wireless Wi-Fi access to subscribers. Virtually all models of Cisco access points are available in a standalone version (independent control through the CLI or GUI) and in a unified (limited CLI and control from the controller via CAPWAP). The controller is a hardware and software platform for interaction with access points and a wired network.
')
In preparation for the CCIE Wireless (two years ago), I needed several controllers for the experiments, which were not at hand. Prior to this, after successfully running the ACS virtual machine, Location Appliance, MSE, I tried to virtualize the controller itself in the same way. The task (solved in one and a half years) turned out to be difficult, and there was plenty of experience. That's what I want to share with the community. To begin with, let's see what the hardware of the controller is.

Iron

In fact, any controller is a specialized single-board computer with a processor of some well-known architecture, RAM, a flash disk (CompactFlash card in WISM, WLCM, 440x or a soldered chip in other models), network cards. Any doubter can open the lid of the device and see for yourself.

The Cisco 8510 and Cisco Flex 7510 are based on regular IBM 1U servers with an additional network card based on the Cavium Octeon processor , to which the controller assigns real-time packet operations (such as decrypting DTLS CAPWAP traffic). These controllers have a specific niche - aggregation of traffic of a very large number of remote (in FlexConnect mode) access points, and because of this distribution do not have.

The Cisco 5760 and Cisco Catalyst 3850 are devices close to regular routers and switches. The controller code is executed under the control of IOS XE, the same as, for example, in the ASR line. All that will be discussed below, to the data still exotic devices is not enough.

The outgoing 4402, 4404 models carry the MIPS 64 processor, the NPE co-processor and the new software versions (> 7.2) are not supported. These include the 4402 controller built into the 3750G-24WS switch, as well as the WiSM module in the Catalyst 6500 (which is two independent 4404s that receive only console, power, and GigE ports from the chassis).

The WLCM (for ISR) and SRE (ISR G2) devices are modules that are installed autonomously in the 28xx / 38xx, 29xx / 39xx series router. They differ in processor (Celeron / i386 and Core / x64) and, accordingly, in performance (the number of supported access points).


We are most interested in the more common standalone controllers 2504 , 5508 , and the new WiSM2 module for the 6500 switch. The last (surprise) is again two independent 5508. In reality, all these three models are the same, they differ only in the number of network interfaces and CPU performance (64-bit MIPS architecture).

The virtual controller closes the line, which is sold as a VM image under VMware ESXi (ovf-file). It is logical that its architecture corresponds to the standard hardware of the virtual machine: x64 processor, LSI SCSI disk, Intel E1000 network.

Two years ago, there was no virtual controller. I tried to virtualize the closest in architecture WLCM (NME-AIR-WLC), which, however, required parsing and examining the firmware (approximately as described below), writing the NVRAM emulation driver for MontaVista 4.0, studying Ida Pro, modifying QEMU network offsets, working with the network in ESXi and it took about a year of time in the sluggish mode. And such a controller earned! True, the modern controller software versions (> 7.2) no longer support the WLCM, and we have a vWLC, so my results have only academic value.

In addition to the obvious differences in performance (the number of simultaneously supported access points and wireless subscribers), all controllers differ in functionality. The main differences are reduced to the support of wired guest, guest access, mobility-anchor, multicast, IPV6, etc. rarely required features. The real weighty difference is that support for local mode (traditional mode) is implemented at 2504/5508 / WISM2, while Flex7500 / vWLC is only content with FlexConnect.

Soft

The controller software is a file of about 100 megabytes in size, which you can download on the manufacturer’s website if you have a service contract or google by the same file name from the same place . For a typical AIR-CTYYYY-K9-XX-XX.aes, the .aes extension should not mislead you: it has nothing to do with the encryption protocol . The name of the firmware file (firmware) may contain the word LDPE (Licensed Data Payload Encryption). This means that this firmware activates the ability to encrypt user traffic (the CAPWAP control tunnel is still encrypted via DTLS / AES) with a separate license. This is Cisco specially invented for users from Russia, so that K9 devices do not fall under the legal restrictions on the input of encryption tools.

Inside the firmware file of the proprietary format, you will see some binary garbage, pieces of shell scripts, large blocks that look like tar or gz archives. This is not at all like the tightly packed, monolithic IOS (Internetwork Operating System, not to be confused with Apple iOS) binary image of any traditional Cisco device. Therefore, you should not try to make any updates by directly deleting-pouring the .aes-file to the flash, you will only distort the device.

Take the latest version for today 7.5.102.0 for the controller 5508, AIR-CT5500-K9-7-5-102-0.aes. A curious fact: remember, I said that 2504, 5508 and WiSM2 are the same thing? If you look closely, for all of them the software file of this firmware version has one length (133146180 bytes) and a checksum (62ba852937eefaadaaba25e3b6cc18fc). The software itself determines which platform it runs on. Well, you, if you have software for one of the three platforms, automatically have it for the rest - just rename the file.

Getting root access

As you know, connecting via SSH or console to the controller, you get to the command line interface, which is a bit like iOS. Slightly - because the entire line of controllers is based on the historical code obtained by Cisco as a result of the acquisition of Airespace in 2005. Once we know that the controller is based on Linux OS, the question arises - is it possible to get shift-access to the system itself, preferably root-based. Let's try to do this on the example of a virtual controller installed according to the instructions . After installing version 7.4.100, I additionally updated it to version 7.5.102.

Just because you can not get into his shell (this is not Prime NCS )
Our “virtual controller” CTVM runs as a VMware ESXi virtual machine. Turn off the controller (using the Power Off button) and connect its virtual disk (.vmdk) to some of our other virtual machines on the same host. I use Debian / GNU Linux for similar purposes as the closest option to the original OS. What we see:

root@debian64:~# fdisk /dev/sdb … Disk /dev/sdb: 8589 MB, 8589934592 bytes … Device Boot Start End Blocks Id System /dev/sdb1 * 1 33 265072 83 Linux /dev/sdb2 34 99 530145 83 Linux /dev/sdb3 100 491 3148740 83 Linux /dev/sdb4 492 1044 4441972+ 83 Linux 

Four partitions. Let's try to mount them all:

 mkdir sdb && mkdir sdb/1 && mkdir sdb/2 && mkdir sdb/3 && mkdir sdb/4 mount /dev/sdb1 sdb/1/ ; mount /dev/sdb2 sdb/2/ ; mount /dev/sdb3 sdb/3/ ; mount /dev/sdb4 sdb/4/ 

Section 1 contains a bootloader (grub) and recovery core rescue.img, section 2 is not mounted at all (and is not used by this version of the controller), section 3 contains log files, and section 4 contains the most interesting. I will give a trimmed output ls –la with comments.

 ./sdb/4: drwxr-xr-x 7 root root 4096  24 12:31 application drwxr-xr-x 4 root root 4096  24 12:22 images -rw-r--r-- 1 root root 524288  24 11:58 vmstore.bin 

vmstore.bin is a mounted image of the system storage of certificates and licenses, as discussed below.

 ./sdb/4/application: ---------- 1 root root 611  24 12:00 bsnSslWebadminCert.crt ---------- 1 root root 607  24 12:00 bsnSslWebadminCert.prv ---------- 1 root root 597  24 12:08 bsnSslWebauthCert.crt ---------- 1 root root 609  24 12:08 bsnSslWebauthCert.prv drwxr-xr-x 2 root root 4096  24 12:31 cfg -rw-r--r-- 1 root root 131072  24 11:59 csl.bin ---------- 1 root root 32768  24 12:00 flash_settings.bin drwxr-xr-x 2 root root 4096  24 12:08 ha ---------- 1 root root 4080  24 12:33 log.bin drwxr-xr-x 2 root root 4096  24 11:58 lvl7 ---------- 1 root root 1  24 12:31 mcast_ucast_feature drwxr-xr-x 2 root root 4096  24 12:06 nim -rw-r--r-- 1 root root 125  24 12:25 promptError.txt -rw-r--r-- 1 root root 1  24 12:31 snmpBoots.txt -rw------- 1 root root 668  24 11:59 ssh_host_dsa_key -rw-r--r-- 1 root root 606  24 11:59 ssh_host_dsa_key.pub -rw------- 1 root root 531  24 11:59 ssh_host_key -rw-r--r-- 1 root root 335  24 11:59 ssh_host_key.pub -rw------- 1 root root 883  24 11:59 ssh_host_rsa_key -rw-r--r-- 1 root root 226  24 11:59 ssh_host_rsa_key.pub drwxr-xr-x 3 root root 4096  24 12:33 xml 

It contains controller configuration files, SSH keys, Webadmin SSL certificates and Webauth.

 ./sdb/4/application/xml: ---------- 1 root root 1583  24 12:33 aaaapiCfgData.xml ---------- 1 root root 1068  24 12:33 aaaapiFileDbCfgData.xml … 

You probably know that a comprehensive configuration of a switch and a Cisco router can be obtained via sh run to archive it, or upload it to another device. Initially, in wireless controllers, too, it was. However, now the output of the sh config command is not enough to fully understand what is configured on the device. To do this, you have to use numerous shows .... The fact is that the actual device configuration is now in the set of XML files located in / application / xml, and each launch of the sh config command causes a special code to transform this XML into text CFG. Work on such a converter is delayed in relation to the development of the device (and, perhaps, is abandoned altogether), so you cannot rely on sh config . However, complete device configuration via config ... commands (i.e., without web gui) is possible. Moreover, for a number of tasks there is simply no graphic equivalent to a text command. Naturally, in the depths of the device there are inverse tools for converting commands to XML.

 ./sdb/4/images: drwxr-xr-x 2 root root 4096  24 11:58 ap.bak drwxr-xr-x 2 root root 4096  24 12:24 ap.pri -rw-r--r-- 1 root root 39773258  24 11:58 linux.bak.img -rw-r--r-- 1 root root 40973323  31 13:53 linux.pri.img -rw-r--r-- 1 root root 0  24 12:21 upgrade.log -rw-r--r-- 1 root root 10  31 13:53 vinitrd-primary -rw-r--r-- 1 root root 10  24 11:58 vinitrd-secondary 

Here we see the primary and backup kernels of the operating system of the controller, as well as two directories with the primary and backup versions of the firmware of the access points (see below).

 ./sdb/4/images/ap.pri: -rwxr-xr-x 1 root root 11018240  24 12:22 ap1g1 -rwxr-xr-x 1 root root 40  24 12:22 ap1g1.md5 -rwxr-xr-x 1 root root 10342400  24 12:23 ap1g2 -rwxr-xr-x 1 root root 40  24 12:23 ap1g2.md5 -rwxr-xr-x 1 root root 10383360  24 12:23 ap3g1 -rwxr-xr-x 1 root root 40  24 12:23 ap3g1.md5 -rwxr-xr-x 1 root root 11530240  24 12:23 ap3g2 -rwxr-xr-x 1 root root 40  24 12:23 ap3g2.md5 -rwxr-xr-x 1 root root 7608320  24 12:23 ap801 -rwxr-xr-x 1 root root 40  24 12:23 ap801.md5 -rwxr-xr-x 1 root root 9041920  24 12:24 ap802 -rwxr-xr-x 1 root root 40  24 12:24 ap802.md5 -rwxr-xr-x 1 root root 5201920  24 12:24 c1130 -rwxr-xr-x 1 root root 40  24 12:24 c1130.md5 -rwxr-xr-x 1 root root 10229760  24 12:24 c1140 -rwxr-xr-x 1 root root 40  24 12:24 c1140.md5 -rwxr-xr-x 1 root root 7342080  24 12:24 c1250 -rwxr-xr-x 1 root root 40  24 12:24 c1250.md5 -rwxr-xr-x 1 root root 8468480  24 12:24 c1520 -rwxr-xr-x 1 root root 40  24 12:24 c1520.md5 -rwxr-xr-x 1 root root 3840000  24 12:24 c602i -rwxr-xr-x 1 root root 40  24 12:24 c602i.md5 

What is the core of the OS controller? Judging by the size, it contains initramfs, the root filesystem with all utilities, mounted in memory immediately after the kernel starts. By the way, in previous versions of the controller, the initrd was shipped as a separate ext2fs image file, which greatly simplified the task of modifying it.

 # file linux.pri.img linux.pri.img: Linux kernel x86 boot executable bzImage, version 2.6.21_mvlcge500-octeon-mips64_, RO-rootFS, root_dev 0x801, swap_dev 0x27, Normal VGA 

To get root access, you need to disassemble the kernel into parts, change something in the root file system, and collect everything back. To do this, let's see how the core works. Surprisingly, there is almost no clear description of the structure of the assembled kernel, along with the tools for parsing it on the Internet ( binwalk helps remotely ). It is clear that the kernel is packed, and probably the packer is gzip. The signature of gzip files is simple - all archives begin with 0x1F 0x8B 0x08. We will search for the beginning of the archive, cut, unpack, see what's inside, repeat, etc. As a result, the following structure appears:



The constants K1, K2 and K3 are selected experimentally and depend on the firmware version. 2.gz are at the very end of the kernel, and the gzip magic combination occurs there many times - for example, it is known that there is a packed .config in the kernel used in its assembly. The following script was compiled for unpacking:

 #!/bin/sh K1=38088 K2=6619136 K3=45117311 dd if=linux.pri.img of=0 skip=0 count=1 bs=$K1 dd if=linux.pri.img of=1.gz skip=0 bs=$K1 zcat 1.gz > 1 dd if=1 of=2-h skip=0 count=1 bs=$K2 dd if=1 of=2-f skip=$K3 bs=1 dd ibs=1 if=1 of=2.gz skip=$K2 count=$(expr $K3 - $K2) zcat 2.gz > 2 mkdir initramfs cd initramfs cpio --no-absolute-filenames -idv < ../2 cd .. 

At the output we have the initramfs directory containing the root file system of the controller. To get root access, just correct the following files:

1. Edit ./etc/inittab so that when you start the console starts, not the wireless system code:
   a. Swap comments by unlocking the console:
   con: 2345: respawn: / sbin / getty console
   #con: 2345: respawn: / bin / gettyOrMwar
   b. Let's uncomment from 2 to 6 virtual terminals:
   2: 23: respawn: / sbin / getty 38400 vc / 2
   
2. The root user in / etc / passwd is prescribed a normal shell, / bin / bash
3. You can also make non-executable ./etc/init.d/S95mwar so that the controller does not start without demand

Now we will collect everything back. Remember that archives in the kernel have the maximum compression ratio. With our manipulations, the sizes of the resulting pieces will probably be smaller than the original ones, therefore, to preserve the binary structure, we will add blocks with zeros.

 #!/bin/sh cd initramfs find . | cpio --create --format='newc' | gzip -n -9 > ../2-new.gz cd .. SPACER1=$(expr `stat -c%s 2.gz` - `stat -c%s 2-new.gz`) dd if=/dev/zero of=$SPACER1 bs=1 count=$SPACER1 cat 2-h 2-new.gz $SPACER1 2-f | gzip -n -9 > 1-new.gz SPACER2=$(expr `stat -c%s 1.gz` - `stat -c%s 1-new.gz`) dd if=/dev/zero of=$SPACER2 bs=1 count=$SPACER2 cat 0 1-new.gz $SPACER2 > bz rm $SPACER1 $SPACER2 

Now we need to make sure that the modified kernel is the same size as the original one, and put it in its place:

 # ls -la linux.pri.img bz -rw-r--r-- 1 root root 40973323  27 10:00 bz -rw-r--r-- 1 root root 40973323  25 23:05 linux.pri.img # mount /dev/sdb4 sdb/4/ # cp bz sdb/4/images/linux.pri.img # umount /dev/sdb4 

You can turn off the test virtual machine with Linux, and turn on the controller (ESXi one virtual disk, .vmdk file, will not allow two VMs to use at the same time). Load the controller:

  Cisco Bootloader (Version 7.4.100.0) .o88b. d888888b .d8888. .o88b. .d88b. d8P Y8 `88' 88' YP d8P Y8 .8P Y8. 8P 88 `8bo. 8P 88 88 8b 88 `Y8b. 8b 88 88 Y8b d8 .88. db 8D Y8b d8 `8b d8' `Y88P' Y888888P `8888Y' `Y88P' `Y88P' Booting Primary Image... Press <ESC> now for additional boot options... Booting 'Primary image' Detecting hardware . . . . 3 INIT: version 2.86 booting … 

Bottom line: we have full root access to a working Cisco vWLC virtual wireless controller.

The device is a working controller

It is obvious that the controller is based on the specialized version of Linux production MontaVista . At startup, the above file systems are mounted, standard initialization, loading of kernel modules, checking for the Octeon chip, and downloading of its firmware. The network cards of the controller at this moment do not have IP addresses. At the end, the wireless controller code itself is started with the / bin / bsnmwar binding script. Mwar - Main Wireless Application Routine. The controller code is contained in a monolithic, statically linked / sbin / switchdrvr file (ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU / Linux 2.6.18, stripped), which occupies a good half of the volume the entire controller firmware, and implements fully the logic of its work. It is when it is launched that the familiar controller initialization lines (Starting .... Ok) appear on the console, the network interfaces are initialized, the license management daemon is started by a separate process, the web interface appears and the access points and wireless clients start to be served. Shell access to the console disappears, and the user gets to the standard console login prompt to the controller (but we remember the running getty on the other virtual terminals, which arose as a result of our inittab modernization).
During the switchdrvr startup process, the /mnt/wlc/vmstore.bin file is mounted with licenses and certificates into memory (losetup) and the partition with the firmware of access points is remounted. As a result, the mount points look like this:

 root@(none):/mnt/wlc# df -k Filesystem 1k-blocks Used Available Use% Mounted on tmpfs 1029084 8 1029076 0% /tmp tmpfs 10240 8 10232 0% /dev tmpfs 1029084 0 1029084 0% /dev/shm none 1029084 8 1029076 0% /var/run none 1029084 8 1029076 0% /tmp /dev/sda4 4372140 394588 3755456 10% /mnt/wlc /dev/sda3 3099292 82176 2859680 3% /var/log /dev/loop5 494 176 293 38% /mnt/vmstore /dev/loop3 110 37 67 36% /root/.csl /dev/ram3 122 5 117 4% /root/.csl_tmp tmpfs 40960 9856 31104 24% /mnt/ap_bundle 

Access points

Their mode of operation is determined by the firmware, which can be changed from the AP (now called SAP, standalone access point) to LAP (lightweight access point) and vice versa . Firmware in both cases is IOS compiled for the hardware platform of the point itself (all points are PowerPC of various antiquities). The firmware file for the stand-alone point will have a name like c1130-k9w7-tar.124-3g.JA.tar, and “lightweight” will be c1130-k9w8-mx.124-23c.JA3.tar The difference is in W7 and W8 . There are also “recovery (recovery)” versions of the type c1130- rcvk9w8 -mx. Here, the firmware does not contain the radio code, its purpose is to start, find the controller, and download the “working” version of the software from it. By the way, by the last letters of the file name of the lightweight firmware, you can determine the version of the controller to which it corresponds. For example, 152-2.JB is 7.4.100, and 124-23c.JA3 is 7.0.220.

All controllers carry copies of the firmware supported by their access points. When the access point is connected to the controller, version compliance is checked, and if they are different, software is automatically installed from the controller. At the same time possible downgrade version. The controller will work only with the corresponding software version of the point. Therefore, if you have two controllers with software of different versions on your network, and access points can choose either one or the second, when you jump from one controller to another, they will change their software. This is a long time, and is fraught with breakage of the flash memory of a point from its permanent rewriting.

Although the CAPWAP communication protocol between the controller and the access point is standardized , there is no chance that the Cisco controller will work with third-party access points in the foreseeable future. In a specific implementation, there are a lot of undocuments, and it is not necessary (not profitable) for anyone.

Licensing

For the impatient: the means to "break" the licensing mechanism of controllers today is not.
Old controller platforms were licensed by the number of access points by hardware. Information on the number of maximum serviced points is contained in NVRAM next to the serial number, and is not updated (you cannot buy support for additional points).
All new platforms use a modern approach based on issuing a license based on UDI (product name / platform + Serial Number of the device) on Cisco.com/go/licensing with indication of the PAK key, i.e. confirmation of your purchase of the device and software rights. Thus, licenses can be re-purchased as the number of access points installed at you increases, within the hardware capabilities of the platform. You can also activate a demo license once for 90 days.

The virtual controller generates its serial number the first time it starts up, guided by the MAC address of the device (provided by VMware) and probably some other parameters like CPU identifiers.

This method of licensing platforms and components is used by all devices on IOS 15.0, IOS XR, IOS XE, NX-OS, etc.
The license itself has the following form:

 <?xml version="1.0" encoding="UTF-8"?><CISCO_WT_ARTIFACTS version="1.0"><CISCO_WT_LICENSE version="1.0"><FEATURE_NAME>base</FEATURE_NAME><FEATURE_VERSION>1.0</FEATURE_VERSION><UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI><SOURCE>Cisco HQ</SURCE><CREATE_DATE>2010-10-20T18:29:16</CREATE_DATE> <LICENSE_LINE_HASH hashAlgo="SHA1">Eb86wsdgdsheIdRgxu8SYjnV2kug=</LICENSE_LINE_HASH> <TYPE>EXTENSION</TYPE><EXPIRATION><DAYS>60</DAYS></EXPIRATION><EULA>YES</EULA> <LICENSE_LINE><![CDATA[11 base 1.0 LONG TRIAL DISABLED 1440 DISABLED STANDALONE ADD INFINITE_KEYS INFINITE_KEYS NEVER NEVER NiL SLM_CODE CL_ND_LCK NiL *1B2UN9YKWSE6TLX400 NiL NiL NiL 5_MINS <UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI> IoNEjaiZMvr:SUgPfi7IL7DfUgmILSlzRAumZl96TmLQxk8wOUr9YwwsYn0pd5vsVYhn9K2G:rYugiUzNI2SeH3jL0Fvj9boyHdSgN9heQmw3F1APru5,qKFhvCKGi16CO3A$<WLC>AQEBIf8B///vAvN3WYGs8UKGLXXeaNhRdwitkjqL7s+cOPCdiN04GY47UbtfByUZYOemWEq6ljxHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE+y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t6Xk5y8xo1lbVhvoh/FZfy5iRY3oE=</WLC>]]></LICENSE_LINE> <USER_MODIFIABLE_COMMENT fieldRestrictions="Max 99 ASCII characters in length."></USER_MODIFIABLE_COMMENT></CISCO_WT_LICENSE></CISCO_WT_ARTIFACTS> > IoNEjaiZMvr: SUgPfi7IL7DfUgmILSlzRAumZl96TmLQxk8wOUr9YwwsYn0pd5vsVYhn9K2G: rYugiUzNI2SeH3jL0Fvj9boyHdSgN9heQmw3F1APru5, qKFhvCKGi16CO3A $ <WLC> AQEBIf8B /// vAvN3WYGs8UKGLXXeaNhRdwitkjqL7s + cOPCdiN04GY47UbtfByUZYOemWEq6ljxHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE + y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t6Xk5y8xo1lbVhvoh / FZfy5iRY3oE = </ WLC>]]> </ LICENSE_LINE> <?xml version="1.0" encoding="UTF-8"?><CISCO_WT_ARTIFACTS version="1.0"><CISCO_WT_LICENSE version="1.0"><FEATURE_NAME>base</FEATURE_NAME><FEATURE_VERSION>1.0</FEATURE_VERSION><UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI><SOURCE>Cisco HQ</SURCE><CREATE_DATE>2010-10-20T18:29:16</CREATE_DATE> <LICENSE_LINE_HASH hashAlgo="SHA1">Eb86wsdgdsheIdRgxu8SYjnV2kug=</LICENSE_LINE_HASH> <TYPE>EXTENSION</TYPE><EXPIRATION><DAYS>60</DAYS></EXPIRATION><EULA>YES</EULA> <LICENSE_LINE><![CDATA[11 base 1.0 LONG TRIAL DISABLED 1440 DISABLED STANDALONE ADD INFINITE_KEYS INFINITE_KEYS NEVER NEVER NiL SLM_CODE CL_ND_LCK NiL *1B2UN9YKWSE6TLX400 NiL NiL NiL 5_MINS <UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI> IoNEjaiZMvr:SUgPfi7IL7DfUgmILSlzRAumZl96TmLQxk8wOUr9YwwsYn0pd5vsVYhn9K2G:rYugiUzNI2SeH3jL0Fvj9boyHdSgN9heQmw3F1APru5,qKFhvCKGi16CO3A$<WLC>AQEBIf8B///vAvN3WYGs8UKGLXXeaNhRdwitkjqL7s+cOPCdiN04GY47UbtfByUZYOemWEq6ljxHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE+y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t6Xk5y8xo1lbVhvoh/FZfy5iRY3oE=</WLC>]]></LICENSE_LINE> <USER_MODIFIABLE_COMMENT fieldRestrictions="Max 99 ASCII characters in length."></USER_MODIFIABLE_COMMENT></CISCO_WT_LICENSE></CISCO_WT_ARTIFACTS> 

It is tied to the serial number of the device, and contains some analogue of the digital signature, which carries the hash of the lines indicated at the beginning of the license. When an attempt is made to download a license to the controller (switchdrvr), the latter checks it through interaction with a separate process running the license manager (licensed). There is also a command line utility, license_cli. "Manual" interventions in the license file lead to a processing error. Client and server exchange protocol is not known (goes through unix domain socket). Since licensed is a 32-bit application, it is easily disassembled by interactive disassemblers / debuggers like Ida Pro / HexRays into pseudo- source C texts, analysis of which clearly indicates the use of SafeNet's Sentinel encryption libraries and signatures. For further investigation of my knowledge is not enough, but I do not need it. As far as we know, there is no license generator yet, but self-censorship .

It should be noted that Cisco's Java server systems (CUCM, ACS, WCS, Prime, MSE, NAC, and many others) use a similar license file format, with a digital signature. However, where there is Java, there are decompilers. It is enough just to find out what platform parameters and properties (features) (as strings) are searched for in the license, and that flexlm.jar is used to verify the signature, with all the ensuing consequences. However, I urge you to live honestly.

Afterword

I hope this material will relieve users in general of good wireless systems based on the Cisco WLC controllers from a number of difficult issues of operation, troubleshooting, software updates. On the other hand, the completely trivial method of reverse engineering of firmware described here can help an inquisitive researcher to work on similar Linux-based devices.
This post does not aim to compare the advantages and disadvantages of wireless systems from different manufacturers and is not agitating for anyone. I am in no way affiliated with Cisco Systems.
I learned all of the above as a result of a long study of the files that everyone can download on the Internet, documentation, and based on personal experience. I urge to use this post only for the purpose of troubleshooting and self-education. For learning purposes, a virtual controller demo is sufficient. A license for 5 access points to a (free) virtual controller costs $ 750 (no discount). The used points of the old, but still supported models are cheap - I took three pieces of 1131a / g for 2500 rubles on eBay. with delivery.