2025 September 25
By Stephen Bunting
When was the last time you deliberately turned off your phone and left it off for several hours — many times, over days, weeks, and months?
If you’re like most people, the answer is probably never — unless there was a problem. That single question frames the heart of this case and the technique that grew out of it.
This investigation involved a man now serving seven life sentences, with more in the pipeline — a Philadelphia-born serial killer who engaged in extreme anti-forensics measures. Hooded, masked, gloved, he shot victims execution-style with frangible ammunition from a revolver — leaving no casings and little ballistic evidence. He regularly changed clothes and took steps to frustrate investigators at every turn. When he was arrested while fleeing from a robbery, he was wearing soft-body armor. Anti-forensics and anti-ballistics!
This was NOT his first time in the system. A decade earlier, Gibson had served a lengthy sentence for manslaughter — a conviction secured through traditional forensic evidence, specifically shell casing analysis. Having learned from that case, he adopted extreme anti-forensics practices in his later crimes, determined not to leave behind the very kinds of evidence that once sealed his fate.
When I was first brought in, the focus was entirely on placing him at various crime scenes using location data, the traditional approach and one that usually worked. What I was not told initially — and what would have changed my approach — was just how thoroughly he engaged in anti-forensics. I was “hunting for something,” not realizing the most important evidence might be in the absence of activity. “Hunting for nothing” is a much different approach than “hunting for something”.
The Request
When investigators reached back out, after the initial examination and soon before trial, they still weren’t asking me to look for anomalies — they were focused on location data. The request, which referred to the Elsmere homicide on May 15th, read:
“For May 15 you were asked to look at:
- May 15th, 2021 from 1700-1730 hours – 930 Kirkwood Highway Elsmere, Delaware 19805
We know the suspect is on his phone walking on 2421 N. 19th Street in Philly at 8:30 p.m., at the location where the victim’s car is recovered.
Can you look at data on Gibson’s phone download for 05/15/2021 until 9:00 p.m and see what it shows as to his location?
If you can write a supplement to your report when this is done, so we can have it documented.
— John”
Location, location, location — that was the focus, and understandably so, as you want to place the defendant at the scene of the crime. But, as in real estate, that single-minded focus on location can blind you to other things. Even our forensic tools are artifact-based; they are programmed to find activity, i.e. artifacts, not silence — and silence can be just as telling.
Unified Logs vs. fsevents
When I pulled the unified logs and other databases (KnowledgeC.db), I found something crucial: the data covered his most recent crimes — including the June 5–8 robberies and homicides — and clearly showed SBPowerDownViewController events and other power-related traces, clearly showing he was powering off his iPhone during these robberies and murders. But May 15, when the Elsmere homicide occurred, was outside the typical 30-day TTL (time-to-live) for those logs. That data, low-hanging fruit, was simply gone.
What was still present were several months of fsevents, Apple’s low-level file system journal. Another recent civil case had reinforced in me just how much these events can reveal, so I turned to them again. Instead of looking for where the phone was, I focused on when it wasn’t doing anything at all.
Understanding “Quiet Time”
It’s important to clarify what “quiet time” actually means. fsevents is generated whenever the file system is active — apps running, system processes writing data, background tasks syncing. When we see extended periods of zero events, that typically means the phone was completely powered off, in a hard-crashed state, or in very rare cases, sitting idle with no user or background activity.
Three-hour gaps, repeated over days and weeks, are not normal iPhone behavior. They are deliberate. When you measure this quiet time, you are essentially measuring when the phone was unavailable to generate evidence — and that intentional unavailability becomes evidence in itself.
That’s when I discovered what we now call the Elsmere Gap: on May 15, his phone was turned off for hours (1643 to 2003 hrs) — and during that gap, video footage showed him dragging 28-year-old Leslie Liceth Ruiz-Basilio to the back of a Metro by T-Mobile store in Elsmere, Delaware, where he shot her in the head, and then stole her keys and her car. This occurred during that gap, 1700-1730 hrs. He was identified later that evening on a video surveillance camera in Philadelphia at 2030 hrs, walking and talking on his phone near where he abandoned the victim’s car, just 17 minutes after powering his phone back on in Philadelphia.
Enter fsevents Gap Analysis
Every iOS device keeps a log of file system events — millions of them. Let’s face it: examiners don’t typically scroll past these records, they simply fail to process them at all. By default, most tools have fsevents parsing disabled. In XRY, the capability is available but you have to specifically enable it during image import. In Magnet Axiom, it’s also off by default unless you manually select it. The result is that one of the richest behavioral datasets on an iPhone often goes untouched.
To make this practical, I built a Python-based fsevents gap finder that:
- Loads millions of events from CSV or SQLite in seconds
- Detects and reports every gap exceeding a chosen threshold (30 min, 1 hr, etc.)
- Produces daily summaries to visualize “quiet time” by day/hour
- Exports a case exhibit table with the top gaps, ready for reports or slides
Beyond fsevents: Unified Logs
Disabling location services is another anti-forensics technique. I’ve developed a series of bash shell scripts on my Mac to run against unified logs to detect such anti-forensics activity. Unified logs are difficult to properly parse in a Windows environment. It’s Apple data — and it is best parsed and viewed in an Apple environment.
Neither fsevents timestamps nor detecting location services on/off periods are invasive of the defendant’s personal information or privacy. As such, including anti-forensics discovery language in a search warrant should be nearly a non-issue.
Suggested Search Warrant Language
“Non-content system artifacts (operating system file-system events, unified logs, power-state traces, and location-toggle records) are requested for [date range] because they record whether the device was operational or intentionally unavailable during windows relevant to the charged offenses and cannot reliably be reconstructed from other sources.”
Note: If a crime is known to occur between specific hours (e.g., 10:00 p.m. and 2:00 a.m.), your date range should extend reasonably beyond that window to account for the suspect traveling to and from the crime scene, potentially a considerable distance. Experience has shown that time window to be quite wide indeed!
The Pattern of Darkness
When we step back from individual gaps and look at Gibson’s phone over months, a striking pattern emerges. The daily fsevents summary shows the device was flashed on January 9, 2021, configured by Gibson on February 9, and then largely dormant until May. His first personal photo marks the beginning of use, but even then, “normal” was anything but.
From February 17 to May 1, the phone spent long stretches completely dark. Only in May did it enter regular use — though “regular” for Gibson still meant repeated days of extended inactivity, when the phone was powered off. Even in the week before his arrest, entire days show as near-idle, powered off.
It is ironic that Gibson went to such lengths to avoid leaving digital breadcrumbs and location traces, yet his downfall came not from his own device at all, but from a simple GPS tracker slipped into the Rite Aid cash pack — technology he could not anticipate or evade.
The behavioral picture is clear: Gibson weaponized silence. He kept the phone powered off by default, only switching it on in what he considered safe zones — away from crime scenes, or after time had passed to blunt investigative value. This made him an opportunistic predator, free to act without the device recording his movements.
No other form of forensic evidence paints this picture so completely. Ballistics may explain a gun. DNA may prove presence. But the phone — or more precisely, the absence of its activity — shows how the offender actually lived.
A Call to Action
This case has changed how I work. Today, every time I receive an iPhone extraction, one of my first steps is to measure the quiet time. Long unexplained gaps almost always tell a story.
And let’s be clear: turning off one’s phone before committing a crime demonstrates clear intent. This isn’t a crime of passion or sudden escalation — it’s premeditation, removing the device deliberately so it will not record or reveal movements.
I was the forensic examiner who testified in the Delaware trial, where this quiet-time evidence was presented to the court.
Think about other situations where this is useful: burner phones, drug mules, sex trafficking victims, coercion scenarios. Quiet time isn’t just data — it’s a behavioral clue.
If the user is frequently toggling location services on and off, why those gaps. Again, it’s another behavioral clue.
Let’s face it — we are in an anti-forensics world. Criminals are learning. CSI and the media are showing how forensics results in convictions. Jail time is a learning experience, one that teaches offenders how to not get caught the next time.
If you’re an examiner, stop ignoring the gaps. Start measuring them. You might just solve your next case by proving what didn’t happen.
In the end, it was not just what Gibson did that mattered, but what his phone did not do — and that lesson should reshape how we all approach digital forensics.
Reproducibility and the Python Script
To ensure this workflow is reproducible and not just theoretical, I’ve provided the Python script that powers the fsevents gap analysis described above. The idea of “gap hunting” started for me the hard way — manually wading through millions of records, parsed into tables, looking for stretches of nothing. It was excruciating, hours of mindless scrolling, and not something I (or anyone else) would want to repeat. When I finally hit upon it, the result was a wow moment — but it also showed me why a script was essential. Automating the process turns what was once painful and impractical into something fast, reliable, and repeatable. This ensures that what I describe here isn’t just anecdote — it can be independently reproduced by any examiner with the same data.
👉 Download the Python script and package: https://buntingdigitalforensics.us/tools/fsevents-gap-finder/