Cisco Wireless Controller Device and Root Access



    I am often approached with requests for troubleshootings from Cisco wireless controllers, some of which stem from a lack of knowledge of how they work 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 licensing mechanism, analyze one firmware into parts, 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 not individually configured access points. I wrote about this architecture in detail on Habré ( one , two , three , four) Access points located on 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 access to Wi-Fi subscribers. Almost all models of Cisco access points are available both in a stand-alone version (independent control via CLI or GUI), and in a unified one (limited CLI and control from a controller using CAPWAP protocol). The controller is a hardware-software platform for interaction with access points and a wired network.

    In preparation for CCIE Wireless (two years ago) for experiments, I needed several controllers at once, which were not at hand. Prior to that, successfully running ACS in the virtual machine , the Location Appliance,MSE I tried to virtualize the controller itself in the same way. The task (solved in a year and a half) turned out to be difficult, and there was plenty of experience. I also want to share it 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, flash drive (CompactFlash card in WISM, WLCM, 440x or a chip soldered to the board in other models), network cards. Any doubter can open the device cover and see for yourself.

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

    The Cisco 5760 and Cisco Catalyst 3850 are devices that are close to conventional Cisco routers and switches. The controller code is executed under the control of IOS XE, the same as, for example, in the ASR line. All of which will be discussed below, has little relevance to these yet exotic devices.

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

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


    We are most interested in the more common autonomous controllers 2504 , 5508, and the new WiSM2 module for the 6500 switch. The last (surprise) is again two independent 5508. In reality, all three of these models are the same, differing 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 for VMware ESXi (ovf file). It is logical that its architecture corresponds to the standard equipment 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 architecture closest in architecture to WLCM (NME-AIR-WLC), which, however, required analysis and investigation of the firmware (similar to the method below), writing an NVRAM emulation driver for MontaVista 4.0, studying Ida Pro, modifying QEMU network offsets, and network troubles in ESXi and took about a year of time in sluggish mode. And such a controller has earned! True, modern versions of the controller software (> 7.2) no longer support WLCM, and we have 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. Mainly differences come down to supportwired guest, guest access, mobility-anchor, multicast, IPV6, etc. rarely required features. A really significant difference - support for local mode (traditional mode) is implemented on 2504/5508 / WISM2, while Flex7500 / vWLC are content only with FlexConnect.

    Software


    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 it using the file name known from there . For a typical AIR-CTYYYY-K9-XX-XX.aes .aes extension should not be misleading: it has nothing to do with the encryption protocol. The word LDPE (Licensed Data Payload Encryption) may appear in the name of the firmware file. This means that this firmware activates the ability to encrypt user traffic (the CAPWAP management tunnel is still encrypted via DTLS / AES) with a separate license. This was specially invented by Cisco for users from Russia, so that K9 devices do not fall under the legal restrictions on entering encryption tools.

    Inside the firmware file of a proprietary format, you will see some binary garbage, pieces of shell scripts, large blocks, similar to tar or gz archives. This does not at all resemble a close-packed, monolithic binary image of IOS (Internetwork Operating System, not to be confused with apple iOS) of some traditional Cisco device. Therefore, you should not try to carry out any updates by directly deleting-uploading the .aes file to the flash, you will only brick the device.

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

    Getting root access


    As you know, when connecting via SSH or the console to the controller, you get to the command line interface, which is slightly reminiscent of iOS. Lightly - 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. Since we know that the controller is built on the basis of the Linux OS, the question arises - is it possible to get shell access to the system itself, preferably root. Let's try to do this using 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.

    You just can't get into his shell (this is not Prime NCS for you )
    Our “virtual controller” CTVM runs as a virtual machine running VMware ESXi. 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. For such purposes, I use Debian / GNU Linux as the closest option to the original OS. What do 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 the bootloader (grub) and the rescue.img kernel recovery, 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 the truncated output of 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 store of certificates and licenses, which we will discuss 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
    


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

    ./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 the complete configuration of the Cisco switch and router can be obtained through sh run to archive it, or upload it to another device. Originally, in wireless controllers, that was also the case. However, the output of the sh config command is not enough to fully understand what is configured on the device. For this it is necessary to apply numerous show For ... . The fact is that the actual configuration of the device is now in a set of XML files located in / application / xml, and each run of the sh config command causes a special code to convert this XML to text CFG. Work on such a converter is delayed in relation to the development of the device (or, perhaps, it is completely abandoned), therefore,sh config cannot be guided. At the same time, complete device configuration through commands like config ... (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 bowels of the device there are reverse 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 controller’s operating system, as well as two directories with primary and backup versions of the firmware of the access points (more about them later).

    ./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 controller OS? Judging by the size, it contains initramfs, a root file system with all utilities, mounted in memory immediately after the kernel starts. By the way, in previous versions of the controller, 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 FS, and collect everything back. To do this, let's see how the kernel is arranged. Surprisingly, there is almost no clear description of the structure of the assembled kernel, along with tools for analyzing it on the Internet ( binwalk helps remotely ). It is clear that the kernel is packaged, and probably the packer is gzip. The signature of gzip files is simple - all archives start with 0x1F 0x8B 0x08. Let's look for the beginning of the archive, cut it out, unpack it, see what's inside, repeat, etc. As a result, the following structure emerges:



    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 is found there many times - for example, it is known that the packed .config used in its assembly is in the kernel. For unpacking, the following script was compiled:

    #!/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 fix the following files:
    1. Edit ./etc/inittab so that the console starts at startup, and not the wireless system code:
      a. Swap comments by unlocking the console:
      con: 2345: respawn: / sbin / getty console
      #con: 2345: respawn: / bin / gettyOrMwar
      b. Uncomment virtual terminals 2 through 6:
      2: 23: respawn: / sbin / getty 38400 vc / 2
    2. The root user in / etc / passwd is assigned 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, 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 you need to make sure that the modified kernel is the same size as the original one, and put it in 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, two VMs at the same time will not be used). We 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  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 virtual Cisco vWLC wireless controller.
    And how to get root access to the hardware controller?
    If you really need it (although I don’t understand why), you can try to modify the firmware in a similar way and upload it to the device - if there is a CF card, then through the card reader, if the soldered flash - then through the device’s bootloader, which has the option to download the image kernels by TFTP.


    Device of a working controller


    Obviously, the controller is built on the basis of a specialized version of Linux manufactured by MontaVista . At startup, the above file systems are mounted, standard initialization, loading kernel modules, checking for the presence of the Octeon chip and downloading its firmware. The network interface cards of the controller do not have IP addresses at this moment. At the end, the wireless controller code itself starts with the binding script / bin / bsnmwar. Mwar - Main Wireless Application Routine. The controller code is contained in a monolithic, statically linked file / sbin / switchdrvr(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 entire controller firmware, and fully implements its logic of operation. It is when it starts that the familiar initialization lines of the controller components (Starting .... Ok) appear on the console, network interfaces are initialized, the license management daemon is launched by a separate process, the web interface appears and access points and wireless clients begin to be serviced. 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 other virtual terminals that arose as a result of our inittab upgrade).
    During the launch of switchdrvr, the /mnt/wlc/vmstore.bin file is mounted with licenses and certificates in memory (losetup) and the partition with the firmware of the access points is unmounted. 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


    The mode of their operation is determined by the firmware, which can be changed from AP (now called SAP, standalone access point) to LAP (lightweight access point) and vice versa . The firmware in both cases is iOS compiled for the hardware platform of the point itself (all points are PowerPCs of different antiquities). The firmware file for the stand-alone point will have a name like c1130-k9w7-tar.124-3g.JA.tar, and the “lightweight” one will be named c1130-k9w8-mx.124-23c.JA3.tar The difference is in W7 and W8 . There are also “recovery (recovery)” versions of the form c1130- rcvk9w8-mx. Here, the firmware does not contain a code for working with the radio, 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 of the access points they support. When the access point is connected to the controller, the version is checked for compliance, and if they differ, the software is automatically installed from the controller. At the same time, a downgrade version is possible. The controller will only work with the corresponding version of the software point. Therefore, if you have two controllers running on the network with software of different versions, and access points can choose either one or the second, when they jump from one controller to another, the points will change their software. This is a long time, and is fraught with a breakdown of the flash memory of the point from its constant rewriting.

    Despite the fact that the CAPWAP 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 particular implementation, there are a lot of undocumented ones, and nobody needs this (not profitable).

    Licensing


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

    The virtual controller generates its serial number for the first time at startup, 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 looks like this:

    base1.0AIR-CT5508-K9FCJ00000000Cisco HQ2010-10-20T18:29:16Eb86wsdgdsheIdRgxu8SYjnV2kug=EXTENSION60YESAIR-CT5508-K9FCJ00000000 IoNEjaiZMvr:SUgPfi7IL7DfUgmILSlzRAumZl96TmLQxk8wOUr9YwwsYn0pd5vsVYhn9K2G:rYugiUzNI2SeH3jL0Fvj9boyHdSgN9heQmw3F1APru5,qKFhvCKGi16CO3A$AQEBIf8B///vAvN3WYGs8UKGLXXeaNhRdwitkjqL7s+cOPCdiN04GY47UbtfByUZYOemWEq6ljxHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE+y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t6Xk5y8xo1lbVhvoh/FZfy5iRY3oE=]]>


    It is tied to the serial number of the device, and contains some analogue of a digital signature, which carries a hash of the lines specified at the beginning of the license. When trying to load a license into 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. The client and server exchange protocol is not known (goes through a unix domain socket). Since licensed is a 32-bit application, it is easily parsed by interactive disassemblers / debuggers like Ida Pro / HexRays into pseudo source texts in C, the analysis of which clearly indicates the use of Sentinel encryption libraries and signaturesSafeNet production. For further proceedings, my knowledge is not enough, but I do not need it. As far as is known, there is no license generator yet, but self-censorship .

    It should be noted that Cisco server systems written in Java (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 to simply find out what platform parameters and features (in the form of strings) are searched 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 save users of generally good wireless systems based on 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 the firmware described here can help an inquisitive researcher in working on similar Linux-based devices.
    This post does not aim to compare the advantages and disadvantages of wireless systems from different manufacturers and does not campaign for anyone. I am not affiliated with Cisco Systems.
    I learned all of the above as a result of a long study of files that anyone can download on the Internet, documentation, and based on personal experience. I urge the use of this post only for purposes of Troubleshoot and self-education. For training purposes, a virtual controller demo is sufficient. A license for 5 access points to a (free) virtual controller costs $ 750 (no discount). The second-hand points of the old, but still supported models themselves are cheap - I took three pieces of 1131a / g on eBay for 2500 rubles. with delivery.

    Also popular now: