Engineering for Continuity
For Gorilla, software evolution was a response to operational weaknesses, not a departure from the Mirai family. This chapter follows the platform through two observed phases and asks what each transition changed: who owned propagation, how the C2 communicated, how attacks were paced, and what remained vulnerable. That way of reading the timeline shows why stronger concealment could reduce interruption without making the system secure.
Phase one: familiar architecture, visible weaknesses
Gorilla's first releases retained the basic Mirai relationship between a C2 and a fleet of bots. The clients connected to an address embedded in the malware, waited for commands, and created attack processes when a command arrived. They also scanned the Internet for devices that could be infected. In this state, the same deployed client helped maintain the fleet and execute attacks. That arrangement was efficient for growth, but it tied propagation to every bot and made the botnet's activity visible in two ways: defenders could observe scanning, and they could study a communication pattern inherited from Mirai.
The C2 connection itself changed over time. Early clients carried four encrypted C2 addresses and cycled through them until one responded. A later version reduced that set to one address while keeping it encrypted, and a subsequent version placed the address in plaintext. This is not a simple story of every release adding more protection. The operators changed the number and presentation of the addresses, but the service still depended on clients being able to find a reachable C2. Address concealment could make casual extraction harder, yet it did not remove the underlying dependency on a working control endpoint.
The communication protocol shows a similar progression. In the first phase, the original Mirai command structure remained recognizable even after Gorilla added a SHA-256 value and a byte-wise transformation. The change made the traffic less obvious than the original format, but the researchers say that its Mirai-like structure still allowed a simple detection rule. Gorilla also added a challenge-response exchange so a client had to demonstrate knowledge of a hardcoded key before receiving commands. That raised the cost of casually listening to the C2, but it did not create an unbreakable boundary. If a defender or researcher understood the protocol and the necessary values, the exchange could be reproduced.
This distinction is easy to lose when encryption and authentication appear in the same description. Obfuscation changes what an observer can recognize quickly. Authentication changes who is supposed to participate in the exchange. Neither one automatically proves that the C2 is trustworthy, that the client is uncompromised, or that a known protocol cannot be analyzed. The paper makes this limit explicit for Gorilla's checksum: knowing the protocol would allow someone who seized the C2 to craft commands that passed the client's validity check. The improvement was therefore best understood as added friction for detection and disruption, not as a guarantee of control integrity.
A later communication revision went further. Gorilla replaced the earlier protection with a custom Feistel-based encryption format whose payload included parameters for decryption, a hash, a key, and the underlying command. The commands still represented the Mirai-style actions the bots knew how to perform, but the path to interpreting them became more complicated. This is an important kind of compatibility. The operators could preserve a familiar execution model on the bot while changing the interface between the bot and the C2. The attack function did not need to be reinvented for the communication channel to become harder to inspect.
That change also illustrates why a software release can improve one property while leaving another unchanged. A defender who relied on the first-phase traffic's recognizable structure would have a harder time identifying the later commands without reverse engineering the client. But the later protocol still required a reachable C2, functioning clients, and a command format that the bots could process. The system moved the failure surface; it did not eliminate failure. A service can become harder to fingerprint and still go offline if its control infrastructure is unavailable.
Gorilla's early rate behavior exposed a different weakness. The first client versions did not limit how quickly bots generated packets. If several attacks ran at the same time, the same fleet had to divide its output among them, and the operators had little control over the amount of traffic each attack produced. That is acceptable for a crude attack tool whose only goal is to send as much traffic as possible. It is a poor fit for a service that sells differentiated capacity. A customer-facing plan needs some relationship between a promised number of simultaneous attacks and the resources available to fulfill them.
The first rate-limiting update introduced that relationship by capping the packet rate. Later changes altered the cap and then changed how commands were issued. The detail is less important as a list of settings than as a change in ownership. Before rate control, each bot effectively decided how quickly to send, subject to its own device and network limits. After rate control, the platform could shape the shared resource at the client and C2 layers. The operator could decide how much capacity one requested attack consumed and how many such requests could coexist.
The lifecycle can be represented as a set of observed operating states. The state labels summarize the evidence; they are not statements from Gorilla's operators about their intentions.
The loop in the later state matters. Gorilla did not move from a “bad” version to a final version and stop changing. Its operators continued tuning the relationship between commands and shared capacity. The platform's later behavior therefore needs to be understood as a service lifecycle, in which changes to deployed clients, the C2, and customer-facing limits could affect one another.
Phase two: move responsibilities, then meter capacity
The clearest architectural change was the removal of the scanning routine from the bot clients. In the first phase, a bot that executed attacks also helped search for more vulnerable devices. In the second phase, centralized infrastructure took over infection and sample delivery. The researchers identified 29 IP addresses used to spread Gorilla and observed a shift from scanning many ports to focusing on a smaller set, especially ADB on TCP/5555. The article does not need the exploit procedure to explain the consequence: propagation had become a separately managed service rather than a background duty performed by every attack node.
This changed what persisted when a component failed. A bot in the earlier design carried both an attack role and a propagation role. If that bot was removed, the platform lost a source of traffic and part of its ability to grow. After the change, a bot could remain a member of the attack fleet while the central propagation system handled new infections. A failure in propagation would slow or stop fleet growth, but it would not necessarily stop already enrolled bots from receiving attack commands. Conversely, a failure in the C2 or bot fleet could interrupt attacks even if the propagation infrastructure remained active. Separating responsibilities did not make any component optional; it made the dependencies more legible and allowed them to be operated independently.
The separation also reduced one form of noise. Distributed scanning by many bots can make an Internet worm conspicuous because the attack fleet itself generates the discovery traffic. Centralized scanning concentrates that behavior in a smaller set of infrastructure. The paper's observations show the result as a change in pattern, not as proof of an operator's exact rationale. The most defensible interpretation is that Gorilla moved a visible, resource-consuming job away from the clients, which allowed those clients to focus on command receipt and attack execution. That is a plausible contribution to longevity, but it was one part of a larger package of changes.
The communication changes and the propagation change worked on different boundaries. C2 hardening affected the information path between an enrolled bot and the control system. Moving scanning affected the path by which new devices entered the fleet. A client could be difficult to inspect yet still depend on a central propagation service. A propagation service could continue finding devices while a C2 outage prevented attacks. Treating these as separate states helps explain why Gorilla's resilience was not one indivisible property. It was a collection of continuities that could fail independently.
The client-update capability added another form of persistence. The later Gorilla client included a utility through which the C2 could stop running attacks or request a new binary from a specified location. The study did not observe the update method being used during its measurements, so its existence should not be confused with proof of frequent live updates. Its architectural importance is still clear. An operator that can update deployed clients does not have to abandon the existing fleet whenever a communication, attack, or control problem is discovered. The capability creates a path from an observed weakness to a future release, although it also creates a high-value control dependency: whoever controls that update path can influence already infected devices.
Rate limiting shows how this engineering lifecycle met the marketplace's need for predictable capacity. An update observed on November 24, 2024 capped bots at 3,000 packets per second. In April 2025, the cap was halved to 1,500 packets per second. About a month later, the C2 began sending duplicated commands, which restored the earlier effective rate by running multiple copies of an attack, each subject to the cap. In this arrangement, a “concurrent” was not a mysterious new kind of bot. It was an additional attack instance consuming another share of the platform's available capacity.
That choice connected three layers. At the client layer, a throttle limited the output of one attack process. At the C2 layer, duplicated commands could ask the fleet to run several such processes. At the service layer, the number of allowed concurrents became something the operator could associate with a subscription tier. A rate limit was therefore not only a defensive-looking technical setting. Inside this platform, it became a way to meter a shared resource and turn it into a product promise.
The observed behavior supports the existence of that relationship, but not a timeless capacity number. The main analysis describes a later 3,000-packets-per-second cap and the use of duplicate commands. Appendix C describes a 1,500-packets-per-second transmission pattern for a particular sample or measurement. Those statements should not be merged into one contradiction-free specification. They most plausibly refer to different versions or measurement contexts, and the evidence does not justify resolving the difference more precisely. The durable conclusion is that Gorilla's packet limits changed and that the operators used command multiplicity to adjust effective capacity.
This is also why “more secure” is too broad a description of the later platform. Stronger command protection increased the cost of understanding traffic. Centralized propagation reduced the need for attack bots to scan. Rate controls made shared capacity more manageable. Each change addressed a concrete operational problem, but each introduced or preserved another dependency: the C2 remained central, the update path became sensitive, and centralized infrastructure became important to growth and attack power. Engineering for continuity meant choosing where failures would appear and how quickly the service could recover, not removing all possible failures.
The study's broader interpretation is that Gorilla's operators learned from earlier releases. That conclusion is supported by the sequence of binary changes and operating observations, but it remains an interpretation rather than a statement of internal intent. We can see what changed and what behavior followed; we cannot see the operators' design meetings or prove that longevity resulted from any one revision. What the evidence does show is a platform moving from a tightly coupled, visibly Mirai-like arrangement toward a more managed system whose attack clients, propagation infrastructure, C2 protocol, and customer-facing capacity could be adjusted separately.
That separation explains continuity, but not yet the full scale of the attacks. A platform can keep its control channel reachable and still appear to produce more traffic than its visible bots should generate. The next question is therefore not another client feature. It is where the attack traffic came from, and how Gorilla's centralized component changed the meaning of its botnet size.