Elkenson

A software bill of materials, or SBOM, is an inventory of the components within a software product. It can record their versions, suppliers, licenses, and dependency relationships. This helps organizations keep track of what their software contains and identify components affected by known vulnerabilities.

An Elkenson investigation includes this inventory and dependency work, then examines how the app actually operates rather than relying solely on developers’ and suppliers’ descriptions. When packing conceals the implementation, we use nonpublic unpacking tools and custom runtime instrumentation to help recover hidden code and inspect its execution. We can examine native libraries and memory, trace function calls, and follow information through the app to external services. This lets us investigate what activates a particular function, what information it accesses, and how its behavior changes under different conditions. Those details matter: an SDK’s presence alone cannot establish whether its collection features are enabled or what information it receives.

We also investigate where components originate and which companies develop, supply, or operate them. Comparing distinctive code across apps and historical releases can reveal a shared implementation beneath different product names, providing leads about common suppliers or development histories. We check those connections against corporate records, technical documentation, and sources in the relevant language. Country context helps explain why particular integrations exist, the commercial or institutional requirements they serve, and how those relationships extend across borders.

For businesses, an investigation could reveal emerging trends in a software market, uncover collaborations that are not apparent from product branding, and examine the consequences of relying on particular technologies or suppliers. It could also trace how investments in technology and infrastructure are being put into practice across apps and services. Someone in a sensitive profession may need to understand whether an app exposes information about their work, movements, or personal life. Policymakers could use the research to assess how sanctions or other interventions affect software supply chains, including whether dependencies disappear, persist, or shift through different companies. Combined with evidence about how products are adopted and used, the findings could also inform research into social behavior and user preferences.

We can investigate the data handling and supplier dependencies an organization would take on by adopting a product. A local government department considering an app may need to establish whether photographs, location records, or device identifiers reach services beyond the named operator. A business choosing software for essential operations may need to understand which functions depend on outside providers, and whether its preferred alternative relies on the same infrastructure. Organizations handling confidential information may need evidence about how a product behaves before approving it for employees or clients.

We examine the product versions, features, and workflows relevant to the proposed deployment. Code inspection and controlled testing can help establish what information is accessed, which services receive it during testing, and what happens when a dependency is unavailable or a permission is denied. Where protections conceal relevant code, our nonpublic unpacking tools and custom instrumentation can support deeper examination. Additionally, we investigate the companies behind those services and the local commercial and institutional arrangements shaping the product. Combining that research with technical evidence helps explain what a dependency does and the relationship an organization would accept by using it.

Products sold under different brands may rely on the same underlying technology, infrastructure, or service providers. Elkenson can investigate those connections across a market, identifying where dependencies are concentrated, which suppliers are gaining ground, and how relationships differ between regions. This can reveal commercially significant connections that are difficult to establish from product descriptions or company announcements alone.

If a business is considering an acquisition or investment, an investigation could examine which product capabilities depend on third parties and whether essential services remain connected to the target’s current parent company. Those findings could identify dependencies that need to be retained, replaced, or separated after a transaction. Comparing historical releases could also help assess claims about technological development and show how reliance on particular suppliers has changed.

For a proposed partnership, licensing agreement, or market entry, the questions may be different. Which capabilities does a potential partner provide directly, and which depend on other organizations? Where does its technology appear in deployed products? Which local payment, identity, or distribution relationships would a business need to operate in that market? Examining these questions could help assess a partner’s role, identify additional parties relevant to negotiations, and anticipate dependencies a commercial agreement would introduce.

Elkenson combines comparisons across software products and releases with research into corporate ownership, supplier documentation, and local market conditions. An investigation could produce a documented map of relevant suppliers and relationships, evidence supporting or challenging commercial claims, and specific questions to resolve during technical and commercial due diligence. This gives buyers, investors, and prospective partners concrete findings to bring into negotiations and planning.

Yes. We can investigate claims made by suppliers, public officials, researchers, or the media and assess whether the evidence supports them. That includes examining assumptions behind a claim and distinguishing demonstrated findings from interpretations that still need verification.

Our Grindr investigation examined whether the end of Chinese ownership was reflected in the app’s dependencies. Across 18 Android versions, Amap and WeChat indicators disappeared during the divestiture period, while Agora components remained. This provided evidence about which technical relationships changed and which persisted beyond the ownership change.

In our investigation of China’s app for overseas students, we examined code and public APIs to establish what functions existed beyond student administration. We documented features concerning rewards for embassy and student association events, patriotic education, and reporting political speech. These findings provided specific evidence to assess the app’s role and capabilities, rather than relying on a general description of its purpose.

Software can be built around local payment networks, identity systems, distribution channels, and public institutions. Understanding that setting helps explain why particular functions and suppliers appear in a product. An integration might support an everyday commercial service, satisfy an institutional requirement, or connect users to a government program. Those distinctions matter when interpreting what the software does and what its use could mean across borders.

Language skills also change what evidence an investigator can find. Technical manuals, developer discussions, company records, and procurement documents may contain details absent from English-language sources. Searching with local terminology can uncover connections that an English product name misses. Reading the original material helps distinguish a proposed feature from a deployed one, or an optional integration from a requirement.

Our research on Telegram and digital dependence examines the tension between efforts to restrict a platform and its use for official communication. Understanding that relationship requires examining institutional practices and established habits alongside the technology.

This also informs our work on language learning tools for researchers and analysts. Useful progress can begin before fluency: recognizing an alphabet, common technical terms, or recurring names can help someone navigate unfamiliar sources and identify leads worth pursuing. Our tools offer a practical starting point for building that understanding and bringing more original-language material into an investigation.

Yes. We can develop tools around a specific research problem, such as capturing an event inside a running app, extracting information from an undocumented format, or comparing a large collection of software releases. The tool’s purpose, required outputs, and checks would be defined alongside the investigation.

To discuss the software, research question, or technical obstacle you have in mind, contact Elkenson.

Yes. Foreign software reaches across industries and disciplines, so investigating it often calls for expertise beyond any one field. Elkenson can contribute to an existing project, take responsibility for a particular research question, or help pursue a finding that your team wants to understand in greater depth. Your knowledge of the subject can also help us recognize the significance of details that might otherwise be overlooked.

We would agree on responsibilities, ways to share evidence, and points for reviewing progress so our contribution fits the project’s existing workflow. With technical teams, we can work through methods and findings in detail. With researchers, policy specialists, or other colleagues without a technical background, we can explain what the evidence establishes, where interpretation is needed, and which next steps could answer the remaining questions.

We’re keen to hear about research already underway, including unexpected discoveries and questions that have proved difficult to resolve.

No. Client investigations and their findings are private unless public release is an agreed purpose of the project.

Some research may be undertaken specifically for publication, including work commissioned by a public organization for public benefit. In those cases, we would agree on what information would be made publicly available before the investigation begins.