// securing tomorrow

Secure what you build, and everything you ship.

Security and software engineering discipline is built into every product we ship and every engagement we run. We close what an attacker could reach in the firmware, binaries and source you ship today, and the same discipline lands in your product when we build it with you. What you ship gets harder to attack, release after release.

Firmware and supply-chain evidence

Know the components in the firmware you ship

Upload the image you ship. The platform unpacks it, identifies the components and versions it can place, and reports the executable bytes it could not attribute. It works from the binary alone, so an SoC vendor's SDK, a supplier's blob or a library nobody has source for is covered like everything else.

Firmware and supply-chain evidence →
The firmware result page: a version's members, its coverage account, and what was refused A browser window showing one firmware version. Under the header are the image digest, its size and the tools that read it. A coverage account gives executable bytes accounted for at 77.53 per cent and bytes the analysis declared it had read at 5.84 per cent, each as a proportion bar. A table lists members with the state each reached. Four counters give functions recovered, opaque regions, unexplained regions and unexplained bytes. A marked paragraph at the foot states what the analysis refused to decode and why. 2atomic.com/app/project/ac10u/firmware/v1.2.4 Projects / ac10u / v1.2.4 v1.2.4 ANALYZED IMAGE DIGEST sha256:d866fd53b7e692d5550355ec SIZE 65,557 bytes FORMAT elf / mips COVERAGE BASIS executable-segment COVERAGE ACCOUNT Executable bytes the analysis accounted for 77.53% of 16,368 Bytes the image itself declares as code 5.84% 81 functions recovered 32 opaque regions 32 unexplained regions 822 unexplained bytes this mips slice declares the MIPS16e instruction-set extension but says which code uses it for only 14 bodies outright and 8 addresses its own stored pointers mark; every other address was refused rather than decoded, so this slice was not read whole

Source code analysis

Focus on the vulnerabilities that are exploitable

We analyse your own C and C++ and report the defects an attacker could actually use. A finding counts as confirmed only once we have made it happen on demand, and the input that triggers it ships with the finding. Your engineer re-runs it on their own machine instead of arguing with a severity score.

Prove it is real →
The findings view: confirmed and likely kept in separate columns A browser window with findings in two columns. The confirmed column holds findings that were reproduced, each row carrying the input that reproduced it. The likely column holds findings the analysis believes but did not reproduce, each with the reason reproduction did not happen. The two are never mixed into one ranked list. 2atomic.com/app/project/gateway-fw/findings Projects / gateway-fw / Findings Findings 3 confirmed, reproduced 11 likely, not reproduced CONFIRMED CLASS WHERE REPRODUCED BY STORED INPUT CWE-78 command injection formSetlanQuality qemu-mipsel poc-0031.bin CWE-134 format string vsnprintf via log qemu-mipsel poc-0044.bin CWE-787 OOB write formSetVpnClient qemu-mipsel poc-0052.bin LIKELY CLASS WHERE WHY NOT REPRODUCED CWE-125 OOB read cfg parser no substrate for this SoC CWE-78 command injection upgrade handler blocked at an auth state

Binary and supply-chain evidence

Verify what your suppliers deliver

Get the full list of what is inside a supplier's delivery, read from the file they sent you rather than from their word, in the standard format an auditor accepts. Every part of it is either named or counted as unexplained. In an engagement we compare each new drop against the one you approved and tell you whether it still behaves the same.

The component report: which versions carry a named component, and which cannot be answered for A browser window asking which of an account's firmware versions carry a named component. A table lists each version with the component's resolved version, how many pieces of evidence placed it, the indexed build it matched, and the bytes attributed to it. Two rows carry no version and are marked as unresolved rather than absent. A line under the table states how many versions the answer covers and how many it cannot answer for. 2atomic.com/app/components Components / busybox Which of my images carry busybox? ANSWER FOR "BUSYBOX" VERSION RESOLVED EVIDENCE INDEXED BUILD ATTRIBUTED ac10u v1.2.4 1.31.1 7 openwrt-19.07 412,880 ac10u v1.2.2 1.31.1 7 openwrt-19.07 412,880 m30 v16.01.10 1.28.4 4 vendor-sdk-4.9 377,104 dir825 v7.12 UNRESOLVED 1 none - tapo v2.1.9 UNOPENED 0 none - Answered for 3 of 5 registered versions. One matched no indexed build, so a version was not established; one is an encrypted container this analysis does not open, so nothing inside it was read. Neither is reported as "not present".

Work directly with our engineers

We help you build what comes next, and build it secure.