{"id":19065432,"url":"https://github.com/newaetech/designstarttrace","last_synced_at":"2026-02-12T10:06:22.878Z","repository":{"id":37968346,"uuid":"271864045","full_name":"newaetech/DesignStartTrace","owner":"newaetech","description":"Adding trace to DesignStart for easier side-channel analysis on the CW305 target. Also supports PhyWhisperer.","archived":false,"fork":false,"pushed_at":"2025-02-19T20:34:13.000Z","size":133912,"stargazers_count":17,"open_issues_count":0,"forks_count":2,"subscribers_count":3,"default_branch":"master","last_synced_at":"2026-01-19T19:41:17.309Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"VHDL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/newaetech.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-06-12T18:22:09.000Z","updated_at":"2025-12-07T01:59:12.000Z","dependencies_parsed_at":"2025-08-20T08:40:06.445Z","dependency_job_id":null,"html_url":"https://github.com/newaetech/DesignStartTrace","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/newaetech/DesignStartTrace","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FDesignStartTrace","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FDesignStartTrace/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FDesignStartTrace/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FDesignStartTrace/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/newaetech","download_url":"https://codeload.github.com/newaetech/DesignStartTrace/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FDesignStartTrace/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29363010,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-12T08:51:36.827Z","status":"ssl_error","status_checked_at":"2026-02-12T08:51:26.849Z","response_time":55,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T00:49:54.370Z","updated_at":"2026-02-12T10:06:22.863Z","avatar_url":"https://github.com/newaetech.png","language":"VHDL","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DesignStartTrace\n\nAn Arm Coresight trace sniffer designed for use with the\n[ChipWhisperer](https://github.com/newaetech/chipwhisperer) side channel\nanalysis platform.\n\nDesignStartTrace allows you to leverage Arm trace technology to\n**non-intrusively** learn what your target is doing at what time. You can\nthen combine this information with power traces collected by ChipWhisperer\nhardware to facilitate and speed up your side-channel analysis.\n\n## Examples\nFirst, here's a few examples of what you can do with DesignStartTrace:\n\n1. **Identify when a specific instruction is being executed.**\nThe ETM can generate trace packets when a specific PC value is reached. Here,\nthe target is executing AES, and trace packets are emitted at the start and\nend of the ShiftRows operation:\n![picture](images/aes_shiftrows.png)\n\n\n2. **Identify functions or code segments with periodic PC sampling.**\nThe DWT can emit periodic PC samples. This allows you to easily visualize\nand find functions on your power trace:\n![picture](images/aes_annotate.png)\n\n\n3. **Identify time leakage.** Non-intrusively and quickly check whether\nsensitive code segments are time constant. Here we show the start of every\npoint addition in an ECC P-256 point multiplication. You can't see it here\nbecause there's so many point additions, but there is in fact a significant\ntime variance in the length of each point addition, which could be useful\nfor a timing attack...\n![picture](images/ecc_padd.png)\n\n\n4. **Use any given trace packet as a power trace capture trigger.**\nIf inserting `trigger_high()` in your source code is a problem, this could\nbe the solution for you! Move the trigger anywhere you want, as many times\nas you want, without ever having to recompile!\n\n\n5. **Use any given trace packet as a time reference for fault attacks.**\nSpeed up evaluation of glitch-tolerant code by using trace to quickly get a\ntime reference to when sensitive code is executing. Again you could do this\nwithout trace via `trigger_high()`, but this requires modifying source code\nand recompiling -- unlike trace which is completely transparent and can be\nenabled, disabled, or moved around without touching the source code at all.\n\nArm trace can generate **tons** of information about what your target is\ndoing. These examples are just scratching the surface of what's possible!\n\n\n## Targets and Platforms\nAs its name implies, DesignStartTrace was first developed for the [Arm\nDesignStart FPGA](https://developer.arm.com/ip-products/designstart/fpga)\nplatform, which is a free evaluation platform for Arm Cortex M1 and M3\nprocessors. We ported the reference design to our\n[CW305](https://rtfm.newae.com/Targets/CW305%20Artix%20FPGA/) side-channel\nFPGA target board. Detailed instructions for porting are available here:\n[https://github.com/newaetech/CW305-Arm-DesignStart](https://github.com/newaetech/CW305-Arm-DesignStart).\n\nWe then added trace sniffing logic to this to create \"DesignStartTrace\".\nWhen implemented on our CW305 target board, this provides you with a Cortex\nM3 along with our trace sniffing logic, co-located on the CW305's Xilinx\nArtix 7 FPGA.  If you're already familiar with the ChipWhisperer target\nframework, this target looks like any of our ChipWhisperer reference\ntargets, and so any existing target application can very easily be ported to\nthis platform and gain the power of trace.\n\nIf your target cannot be implemented on the CW305 platform, the trace\nsniffing logic has been ported to the\n[PhyWhisperer-USB](https://rtfm.newae.com/Tools/PhyWhisperer/) and\n[ChipWhisperer-Husky](https://rtfm.newae.com/Capture/ChipWhisperer-Husky/).\nThis can support any target with a parallel trace port or SWO pin. Look to\n[TraceWhisperer repository](https://github.com/newaetech/tracewhisperer) for\nthis variant. Both of these platforms provide all the same capabilities of\ntrace, but with some gotchas related to power trace noise which are\ndiscussed\n[here](https://github.com/newaetech/tracewhisperer/blob/master/trace_noise.md).\n\n\n## Why Is There a Separate [TraceWhisperer Repository](https://github.com/newaetech/tracewhisperer)?\nDesignStartTrace, which is \"TraceWhisperer but specifically for our \n[https://github.com/newaetech/CW305-Arm-DesignStart](https://github.com/newaetech/CW305-Arm-DesignStart)\ntarget\" came first. When TraceWhisperer progressed to include other targets, the \n[TraceWhisperer Repository](https://github.com/newaetech/tracewhisperer) \nrepository was born.\n\nHowever when it comes to *using* TraceWhisperer,  there is a \n[single, common, target-independent API](https://github.com/newaetech/chipwhisperer/blob/develop/software/chipwhisperer/capture/trace/TraceWhisperer.py)\nand so the actual usage experience is not fractured -- only the source\nrepositories are, for historical reasons as explained above.\n\n## How it Works\nThe trace sniffer runs completely in hardware on the FPGA. It is basically\nlike PhyWhisperer-USB, but for trace. (In fact, about half of the Verilog\nsource code is shared with PhyWhisperer-USB.) Raw trace data is time-stamped\nand stored internally in the FPGA. Up to 16Kbytes of trace data can be\nstored. The cycle-accurate timestamping is what allows the collected trace\ninformation to be usefully combined with power traces, as shown in the\nexamples above.\n\n\n## How to Use It\nIf you're already familiar with ChipWhisperer, just add this to your\nnotebook:\n```python\nfrom chipwhisperer.capture.trace.TraceWhisperer import TraceWhisperer\ntrace = TraceWhisperer(target, scope)\n```\n\nand start having fun. This [example Jupyter\nnotebook](jupyter/TraceWhisperer.ipynb) shows a bunch of examples. This\nnotebook supports the CW305, CW610 (PhyWhisperer), and ChipWhisperer-Husky\nplatforms.  If you're using trace on the CW305 or CW610 platform, you'll\nalso need ChipWhisperer capture hardware (e.g. ChipWhisperer-Lite). The\ntarget may be the CWLITEARM; other targets with SWO and/or parallel trace\nports (such as the CW308 K82F target) can also be used.\n\nUse `help(TraceWhisperer)` to see which methods are available.  At a low\nlevel, trace is configured on the sniffing side via configuration and status\nregisters in the FPGA, all of which are accessible via the `fpga_read()` and\n`fpga_write()` methods. On the target side, \"There's More Than One Way To Do\nIt\", but the method supported by `TraceWhisperer.py` uses additional\nSimpleSerial commands to set the trace registers on the target.  See the\n[simpleserial-trace](https://github.com/newaetech/chipwhisperer/blob/develop/hardware/victims/firmware/simpleserial-trace/simpleserial-trace.c)\nexample, which can easily be ported to any SimpleSerial target.\n\n\n## Triggering\nOnce you've gone through the example notebook, read [this note on\ntriggering](triggering.md) to learn all the triggering options and\npossibilities that are added by trace.\n\n\n## Trace Jitter\nDebug trace data has some jitter: if the same operation is run multiple\ntimes on the target processor, and this operation generates the same debug\ntrace data each time, there will be small differences in the timing of this\ntrace data.\n\nThis jitter can be observed by running the [example\nnotebook](jupyter/TraceWhisperer.ipynb) and using trace as the trigger. To\nuse trace for side-channel analysis effectively, this jitter must be\nunderstood and possibly dealt with.\n\nThe observations that follow are just that, observations made during the\ndevelopment of this tooling; there is nothing in Arm's specifications which\nguarantees some permissible range for this jitter.\n\n### Jitter from Parallel Trace Port\nWhen there is no trace data to output, synchronization frames are produced\ncontinuously. These frames are 16 or 32 bits wide. It follows that with any\ntrace port width less than 32 bits, jitter is unavoidable. In practice, up\nto 6 clock cycles of jitter have been observed with a 4-bit trace port.\n\nIn many cases, this jitter can be corrected / eliminated in post-processing,\ne.g.  by re-aligning the power traces.\n\n### Jitter from SWO Pin\nWhen there is no trace data to output on the SWO pin, the link *can* be\nidle, as long as the `SYNCTAP` field of the `DWT.CTRL` register is set to 0\n(reference: ARM DDI 0403E.d, section C1.8.7). If these bits are not zero, a\nperiodic synchronization frame is emitted every 16M, 64M, or 256M cycles. If\na synchronization frame is being emitted when a trace event occurs, the\nobservation of the trace event could be delayed by hundreds of clock cycles!\nUnless your application needs the synchronization frames, disable them to\navoid this situation.\n\nThe SWO baudrate sets a lower bound on jitter; for minimum jitter, set the\n`TPI.ACPR` register to 0: this makes the baud rate equal to the target clock\nrate. With this setting, it may be possible for there to be no jitter at all.\nIn practice, some jitter is frequently observed. The [uecc.ipynb attack\nnotebook](https://github.com/newaetech/chipwhisperer-jupyter/blob/master/demos/uecc.ipynb)\nillustrates this and shows how jitter can be dealt with.\n\nIn addition, if trace acquisition is clocked from PhyWhisperer's SAM3U\nclock, instead of the target clock, the asynchronous nature of these clocks\ncan result in small jitter on a small scale (1-2 cycles was observed with a\n24 MHz target clock), and frequency drift which can build up on longer\ncaptures. For example, for a trace that is 20 million clock cycles long at\n24 MHz, jitter is sometimes seen to increase linearly throughout the\ncapture, starting a 2 cycles and ending at 8 cycles. The solution to this is\nto source the trace acquisition from the target clock, not the SAM3U clock.\n\n## Orbuculum\nRaw trace data has somewhat complex layers of formatting. Fortunately,\n[Orbuculum](https://github.com/orbcode/orbuculum) is a very nice open-source\ntrace parser which can be used to transform raw trace data into something\nmore useful.\n\nFor example, the raw trace data for two alternating matching PC addresses\nlooks like this, which is a bit of a mess to understand:\n```\n03 08 20 af 3a 00 00 84 \n03 08 20 b3 3a 00 00 22 01 84 \n03 08 20 af 3a 00 00 84 \n03 08 20 b3 3a 45 00 00 01 84 \n03 08 20 af 3a 00 00 84 \n03 08 20 8a b2 3a 00 00 01 84 \n03 08 20 af 3a 00 00 84 01 15 \n03 08 20 b3 3a 00 00 84 \n03 08 20 af 3a 00 00 22 01 84 \n```\n\nAfter feeding this through Orbuculum, you can clearly see the two\nalternating addresses:\n```\n0x00003aae\n0x00003ab2\n0x00003aae\n0x00003ab2\n0x00003aae\n0x00003ab2\n0x00003aae\n0x00003ab2\n0x00003aae\n```\n\n(If you must know, section D4.2 of [ARM IHI\n0029E](https://developer.arm.com/documentation/ihi0029/e/) will show you why\nthe raw trace data looks the way it does... don't say I didn't warn you!)\n\nThe [TraceWhisperer.ipynb](jupyter/TraceWhisperer.ipynb) notebook teaches how to\nuse Orbuculum to parse the collected trace data.\n\n\n## Development Notes\nThere is a Verilog simulation environment\n[here](hardware/CW305_DesignStart/sim).\n\nIn order to generate a new bitfile, you'll need to first build the Arm\nDesignStart core, following the instructions\n[here](https://github.com/newaetech/CW305-Arm-DesignStart).\n\nWhen you generate a new bitfile, don't forget to update the .mmi file and\nrun the `make_prog_files.bat` script, as described\n[here](https://github.com/newaetech/CW305-Arm-DesignStart#update-mmi-file).\n\nSimilarly if you wish to modify the firmware, follow the instructions\n[here](https://github.com/newaetech/CW305-Arm-DesignStart#compile-software).\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnewaetech%2Fdesignstarttrace","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnewaetech%2Fdesignstarttrace","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnewaetech%2Fdesignstarttrace/lists"}