Finding the samples with leaking bits


my overall plan is to analyze the remote control for my garage door, that is using the keeloq algorithm. So the attack will use the cipher output only.

For this, I am using the cwnano at the maximum sampling rate (30Msps) and added some trigger offset in the ATSAM firmware to start sampling at specific points in time after “pressing” the remote control button using the cwnano’s GPIO4.

I have recorded 200 traces with 40k samples each. From pressing the button until the first rf pulse, >16 ms elapse, so I tried at two different offsets and want to see any correlation with the encrypted output. For other examples, I saw these rainbow color spikes, showing the sample positions where the 32 bits leak.

But so far my eyes see no rainbow colors :frowning:

So I compare my situation to what this guy in 2016 did:
48Msps using the CW1002
The chip analysed there was the original microchip HCS301, runnint at ca. 1MHz
I am analyzing the EG301, a chinese clone:

Also my power trace shows two clocks spikes fast, followed by little pause (2 clocks pe instruction?). Whereas the HCS301 shows four spikes going down (four clocks per instr.?).

Anyhow, the HCS seems to leak the bits at the second largest spike (out of the four).
This was kind of surprising to me today, since I was about to consider the maximums only.

What next?

  • Does my powertrace look usable with respect to sampling frequency/resolution?
  • Are some counteremeasures known, that might be implemented in this chip released in 2013?
  • Any hints, how to find the leaking samples when only the textout is known?


Hello everyone,

I am still experimenting in finding the leaking bit positions. Let me show my current findings, maybe someone can comment on this.

First, I recorded a trace of the power consumtion, triggered by the remote control button. Settings: 3Msps, 100.000 samples:

My interpretation/assumtion of this trace:

  • 0-40k: busy wait loop for timing, since it is the lowest power consumtion.
  • 40k-60k: encryption/ keeloq algorithm (528 rounds (=instructions?)) calculating the encrypted portion to be sent.
  • 60k-100k: eeprom/flash writing, highest power consumtion with remarkable spikes.

So I recorded 200 traces at 30Msps, 20k samples at the end of the suspected encryption.

… continued:

Since the encoder chip uses an internal rc oscillation, I have considerable clock drift.

My preprocessing is:

resync_traces = cwa.preprocessing.ResyncSAD(project)
resync_traces.ref_trace = 0

resync_traces.target_window = (17200, 17800)
resync_traces.max_shift = 400

This is fine for the target Windows, but I am still observing some minimal drift in the preceeding encryption rounds. So, second, I apply this SliceToSlot preprocessing:

This apparently fixes the drift.
I saved these preprocessed traces to csv and imported them in a CW4 VM, using the keeloq patitioning to see the instructions leaking the status register bits.

In the powertrace view, you can see the instructions before the suspected flash writing occured at samples >17400.

Unfortunately the Partition Comparision does not reveal where the bits are leaking?

Any idea, where the issue is?

Best regards,

just for reference, what I expected to find using the Keeloq Partitioning: the lined up rainbow spikes, that are visible when processing the sample traces:

My assumtion is, the leaking bits are not visible, because the measuring was not precise enough. Therefore I increased the number of traces to 800. For preprocessing means, I also apply the SAD for filtering out the worst 50 traces. Then, resync, then slice-to-slow, and finally filtering out the worst ca. 50 traces, leading to around 700 good traces.
Anyhow, the rainbow spikes are still not visible.
looking at one of the preprocessed spikes in details shows the following:

The peaks are of only one sample. So the spikes are really narrow, and the 30Msps samplingrate might not be enough. Because of the CWNANO’S hardware limitations, I need to find another way to get the spikes with more detail.

My idea is, to put a little capacitor in parallel to the measuring amplifier input.
This should spread the spike over more samples, so I can measure the power consumtion for each mcu cycle more accurately.
Any comments on this idea?


Hi Henning,

I don’t think this would work, since you’re just filtering those higher frequencies out, not shifting them. I’m not sure how much you can really do to work around this limit, short of just using a device with a higher sampling rate.


Here is my update.

I captured traces with a more decent scope at 125 MSa/s. No rainbow. :frowning:

Now, with that scope I made another more detailed overview trace, to decide about the interesting point to trace with higher resolution later.

Here my findings:

(1): The rf transmission with 12 sync pulses for gain control starts.
(2): You can see the encrypted bits start here.


  1. RF sending overlaps with EEPROM operation. Maybe its done timer/interrupt based?
  2. It the CPU is idle during (1), there might also happen the encryption, that will be finished when reaching (2). I have doubts about this, but it might be possible based on my current knowledge. Comments?

What about the ? parts?

I captured 100 traces (with really precise peaks, well aligned) at the end of those areas, but no correlation in the charts.

According to this paper:
30 traces at 200MSa/s for the SO8 package, or 60 traces at 50MSa/s for the DIP are enough for recovering the key.

Even if the 100 traces I have might not recover the complete key, should not I at least see the correlation via the rainbow bars? Or will it behave like binary, all or nothin?

Comments? Any idea what to do next?