Ghosts in the fleet: knowing the IMEI is not knowing the device

In early November, in Mexico, families set up the ofrenda, the Day of the Dead altar, to welcome those who are gone. Those visitors are expected: they have their place, their photo and their candle.

A tracking platform can get visitors too, but uninvited ones: a device that shows up in two places at once, a session that stays open although nobody is on the other end anymore, a vehicle that according to the inventory should not be reporting, and reports.

Before calling any of them a “clone,” it is worth knowing what kind of ghost it is.

The IMEI is a declaration

Every tracking device introduces itself with an identifier: the IMEI, or the terminal identifier its protocol defines. The server reads it and, from that moment on, everything that arrives over that connection is attributed to that device.

But the device declares that identifier itself. It is not cryptographic proof of who it is. That is why two connections presenting the same IMEI can mean very different things:

• a legitimate reconnection;
• an earlier session that has not been closed yet;
• a wrong configuration;
• or two devices that really share an identifier.

The platform has to tell them apart before deciding anything.

I have no documented case in which it was confirmed that two physical devices were using the same IMEI at the same time, and I am not going to tell one. What is real is the architecture problem: the server can receive perfectly valid positions over a TCP connection and still attach them to the wrong identity.

Three different ghosts

They are worth separating, because each one leaves different evidence:

• Session ghost: a connection the server still considers current, although there is no longer any communication with the device. It is the half-open connection from the sockets note.
• Identity ghost: two devices, or two sessions, presenting the same identifier.
• Inventory ghost: a device that does report, but whose administrative link to a vehicle is wrong or out of date.

The first is a transport problem; the second, an identity problem; the third, an administrative one. Treating them the same way is how you end up calling a device that only lost coverage a clone.

Five signals, and what none of them proves alone

This is what I would do today if I designed the mechanism from scratch. I cannot claim that every gateway I have worked with has these policies today.

Inventory. Each identifier tied to a registered device, with its model, its administrative status and its assignment history. That way, a decommissioned device that keeps reporting is seen for what it is. But the inventory only knows what somebody registered.

Sessions. A registry of active connections per identifier: the gateway instance, the session identifier, the connection time and the last valid activity. Two sessions with the same IMEI are a condition for review, not proof of a clone. It may simply be that the old one has not finished dying.

Geography. Consecutive positions, compared using their original timestamps. If the same identifier shows up in two places no vehicle could travel between in that time, there is an inconsistency. But first you have to rule out GPS errors, historical data, wrong clocks and out-of-order messages: arrival time is not the time of the data, as in the right position at the wrong time.

Sequences. In JT808, every message carries a sequence number that the device keeps incrementing. A gap, a repeat or a crossing gets attention, but on many devices the counter goes back to zero on a restart, and a retransmission usually repeats the number.

Correlation. I would not declare an IMEI cloned on a single anomaly. I would look for agreement: simultaneous sessions, incompatible trajectories, counters that cross, what the device declares about itself and what the inventory says. The output should be a grounded suspicion, not a verdict.

The detector

To see the difference I built a detector that runs in the browser. It reads a synthetic day of twelve identifiers. Behind eight of them there is a single device:

• a normal day;
• a session left half-open after two minutes without coverage;
• a wrong position, 18 km from where the vehicle is;
• twenty minutes without coverage on the highway, and the stored data arriving afterward, mixed with the new;
• a restart on the road: the counter goes back to zero and the time reads January 1, 2000 until the GPS gets a fix;
• retransmissions: each message has a 3 % chance of arriving twice;
• a firmware update, which restarts the device;
• a device the inventory has as decommissioned.

Behind the other four there are two devices with the same identifier: a clone of a different model 145 km away; two of the same model driving around the same city; a replacement device configured with the old one’s identifier, while the old one stays powered on in the warehouse; and a second, identical device that powers on for forty minutes 150 meters from the first, both parked.

To keep it simple, here the device declares its model and firmware every time it starts a session. In JT808, depending on the protocol version, that travels in the registration, in the authentication or in a separate query.

Two detectors read what the gateway would see: the sessions, each message’s sequence number, the time it carries, the position, and the model and firmware the device declares. They never know which device sent what.

The naive one calls it a clone on a single anomaly: a login while another session of the same identifier is open, an impossible jump between two consecutive positions in arrival order, or a sequence number that does not follow the previous one.

The correlated one first rules out what has another explanation. With what is left, it speaks of a duplicate identity only if there is evidence from two different families: sessions and counter (which count as one, because they come from the same connections), geography, and declared identity.

With the gateway set so the new session closes the old one:

	Naive	Correlated
One device behind it (8): called a clone	6	0
Two devices behind it (4): flagged	4	4, one only as “review”

With the gateway letting both sessions live, the figures are the same.

Why the naive one falls

Every false alarm has its explanation, and it is the one the correlated detector looks for first:

• The half-open session: the device comes back with a new session. If the new login closes the old one, it is a single replacement, not flapping. If both live, the old one sends nothing more, and a silent session is not a second device.
• The wrong position: it is a stray point. It does not form a trajectory of its own; it is set aside.
• The stored data: on the default day, the 40 stored positions interleave in arrival order with the new ones and draw 7 impossible jumps. Ordered by the device’s time, the jumps vanish.
• The restart: the counter jumps once, to zero, and the new chain never crosses the old one again: that is not two counters. The positions with factory time stay off the map.
• The retransmissions: the same number with the same content, seconds later, is the same message.
• The update: it also restarts the device, so the naive one falls for the same reason. And the declared firmware changes once and never goes back: it is an update, not two devices taking turns.

The decommissioned device, on the other hand, the naive one does not even see: it has no communication anomaly at all. The correlated one flags it separately, as an inventory ghost, because it is not an identity problem.

What the verdict does not say

“Duplicate identity” means there are two devices with the same identifier. It does not say whether one is a clone or someone misconfigured a device: in the replacement case, the evidence is the same as for a clone. That is found out in the field, not on the server.

And the forty-minute device stays at “review.” The sessions flip back and forth, and there are two counters crossing, but both devices are parked 150 meters apart, closer than the kilometer the detector tolerates as GPS noise, and with the same model and the same firmware: there is no geography or declared identity to confirm it. With that evidence, “review” is the honest answer. A person has to look.

What this detector does not prove

I made the twelve cases on purpose, and I chose the detector’s thresholds while looking at them. The code’s tests run fifty different days, and in all of them the correlated detector gives the expected answer; that is by construction, not a measure of how it would do on real data. Real data would bring cases that are not here: a clone that also imitates the counter or the firmware, clocks that drift little by little, devices that lose messages.

Each control case has a single event, and the thresholds sit just above it. With a single device, it would not take much to reach “review”: three restarts in a day or, with the policy that closes the old session, five one-minute outages in an hour.

It also shows how much depends on each threshold. With that same policy, if flapping is declared at a single session replacement per hour, the half-open session, the restart and the update move to “review.” If the retransmission window is set to zero, the retransmissions look like a second counter.

To see each case from the inside, with its map, its sessions, its counter and the timeline of the evidence, there is the ghost detector: it runs in the browser and sends nothing. You can move the thresholds and the gateway policy, and see which cases change their verdict.

No anomaly is enough alone

On a tracking platform, knowing the IMEI does not necessarily mean knowing the device. That is why identification, session, location and inventory have to be kept apart.

An impossible jump on the map is an anomaly. Two connections with the same IMEI are an anomaly. An unexpected sequence can be one too. But none of them, on its own, proves that a cloned device exists.

A good ghost detector should not find clones where there are only communication errors. It has to gather enough evidence to tell a duplicate identity from a session that has not finished dying.

Israel Negrete Lepe is an electronics engineer. Twenty-five years making different systems work together under real conditions: from the sensor, the vehicle or the transaction to the backend, the data, security and operations. Today, increasingly, edge AI. I take on projects by the hour or by deliverable: israel0negrete@gmail.com.