Electronic Evidence in a China Cybercrime Case

A Hangzhou software engineer is detained in a cybercrime investigation. Police seize two phones and a laptop and rely on chat groups, server logs, payment records and code repositories. The engineer admits writing software for the company but says he did not know customers were being defrauded. The Criminal Procedure Law governs evidence and defense rights, while the 2016 electronic-data provisions set detailed rules for collection, extraction and judicial assessment of digital evidence.^[1][2] The defense needs to separate three issues that are often conflated: whether the electronic record is authentic, whether it can be attributed to this defendant, and what legal inference the content actually supports.

Counsel needs to examine how each device or data source entered the case. Was the phone seized from the client personally? Was a server imaged or were selected screenshots copied? Were extraction records, hashes or other integrity information created where required? The electronic-data rules address collection, extraction and review and require attention to authenticity, legality and relevance.^[2] A technical defect does not automatically exclude every item. The legal consequence depends on the nature of the issue and applicable evidence rules. The defense needs to therefore avoid generic objections such as “screenshots are invalid.” It should identify the specific problem: missing source, incomplete collection, inconsistent timestamps or inability to verify account ownership. A structured evidence inventory makes those issues easier to present. The first comparison should place account attribution beside code history; system permissions then tests whether the explanation is consistent. If those sources point in different directions, the disagreement should be stated expressly rather than hidden. The file should state whether the issue affects ownership, value, custody, charge, role, amount, coercive measure, or sentence. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion.

The specific problem#

Authentication begins with collection and preservation#

Attribution is different from authenticity#

A genuine message can still be attributed to the wrong person. Shared office computers, group accounts, cloud synchronization and saved passwords can complicate identity. The defense needs to examine login records, device identifiers, IP information, account registration, physical possession and user behavior. A phone registered to the client may have been used by colleagues; conversely, an unregistered account may still be controlled by the client. Patterns can matter. Repeated login from the client’s device combined with personal messages can support attribution even if formal registration is different. The defense needs to test both prosecution and alternative explanations. Attribution analysis is particularly important where criminal liability depends on a single message or administrative action.

Attribution is different from authenticity should be approached as a proof problem with a defined beginning and end. A short evidentiary matrix linking code history, account attribution, and payment evidence is usually more persuasive than a broad narrative. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion. Missing material should be identified as a gap, not replaced with an assumption favorable to either side. A sound position should also survive the practical question of how it will be implemented the month after the decision. The discipline matters because the broader aim is to tie technical evidence to the charged elements and the client's actual role.

Completeness can change the meaning of conversations#

Investigators may extract a large chat history but the prosecution may cite only selected messages. Counsel needs to review surrounding conversation, earlier explanations and later corrections. A phrase that appears incriminating in isolation may have a legitimate technical meaning in the project context. The opposite can also occur: a harmless-looking message may become significant when read with explicit earlier instructions. Deleted or missing messages create another question. The defense needs to determine whether the gap resulted from ordinary application behavior, selective extraction or intentional deletion. The purpose is not to demand impossible completeness. It is to assess whether the evidence presented supports the inference claimed. Conversation context should be linked to other records such as work tickets, code commits and payment data. The most useful cross-check usually comes from reading forensic source data together with payment evidence and then testing the result against account attribution. Where code history materially changes the picture, it should be addressed separately rather than folded into a global conclusion. The exercise often removes peripheral accusations and leaves a smaller dispute that can actually affect the result. The next question is implementation: what order, payment, parenting term, charging position, or evidentiary ruling would follow if the point is accepted?

Code and technical work do not prove criminal knowledge automatically#

A programmer may build software later used for unlawful purposes. The prosecution must still establish the elements of the charged offense and the individual’s knowledge or intent where required. The defense needs to identify what the software actually did, what project description the client received, what access the client had to customer or victim data and whether suspicious requirements were visible. Code repositories can show which modules the client wrote and when. Issue trackers may document legitimate product requirements or reveal explicit instructions to bypass controls. The lawyer needs to work with technical experts where necessary but remain responsible for the legal question. A technical employee should not be treated as either innocent or guilty merely because the system could facilitate crime.

Before expanding discovery on Code and technical work do not prove criminal knowledge automatically, counsel can identify the minimum factual chain the decision-maker must accept. A short evidentiary matrix linking payment evidence, forensic source data, and account attribution is usually more persuasive than a broad narrative. Contradictions are useful because they show exactly where further evidence or expert work is justified. Where code history materially changes the picture, it should be addressed separately rather than folded into a global conclusion. A focused consequence also helps keep settlement or mitigation from swallowing the underlying legal analysis. It also makes the file easier to defend later while working toward the goal to tie technical evidence to the charged elements and the client's actual role.

Financial and access evidence can test the role theory#

Compensation and system permissions can help show position inside the organization. An engineer receiving a fixed salary with no access to payment systems may be differently situated from a developer receiving a percentage of victim proceeds and managing account infrastructure. The defense needs to map administrator privileges, server access, wallet or bank access and internal authority. Payment records can also establish whether the client profited unusually from the alleged scheme. Again, these are evidentiary factors, not automatic rules. A role map should combine technical access, financial benefit, communications and organizational authority. This integrated approach is more useful than treating electronic evidence as a separate forensic issue.

Financial and access evidence can test the role theory is strongest when counsel can show why a particular record matters, not merely that many records exist. Counsel can narrow the factual dispute by reconciling account attribution with forensic source data before turning to server logs. Where code history materially changes the picture, it should be addressed separately rather than folded into a global conclusion. That discipline makes alternative legal positions easier to maintain without contradicting the factual record. That link between proof and consequence is particularly important when several alternative arguments remain open. That approach advances the central objective: tie technical evidence to the charged elements and the client's actual role.

Early defense should identify data that police may not have seized#

The prosecution file may contain the accused devices but not necessarily exculpatory records held by the company, cloud provider or third parties. Counsel needs to identify source-code history, ordinary client contracts, product demonstrations, emails or compliance materials that could explain the project. Those records may be deleted under normal retention cycles if no preservation occurs. Family or colleagues should not alter systems or coordinate testimony. The lawyer can identify lawful preservation measures and later seek appropriate evidence through procedure. The defense needs to also preserve the client’s employment and role documents. Digital cases are particularly vulnerable to asymmetry if the prosecution has seized one set of devices while favorable business records disappear elsewhere. The most useful cross-check usually comes from reading code history together with payment evidence and then testing the result against account attribution. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion. Once the sources are reconciled, counsel can separate facts that are established from those still genuinely contested. The remedy or defense consequence should be specified at the same time as the factual theory.

Prosecution-stage review should connect objections to legal elements#

Once counsel has file access, objections should be organized around the charge. A dispute over one login record matters only if that login proves a material act or knowledge. The defense can create a matrix: legal element, prosecution evidence, attribution issue, contrary evidence and conclusion. Technical experts can address narrow questions such as whether timestamps are consistent or whether a server log could be generated automatically. Counsel needs to avoid asking experts to decide legal guilt. Where the electronic record is strong, the defense can focus on legal characterization, role or amount rather than raising weak technical objections. Credibility improves when valid evidence is acknowledged and the real dispute is isolated. A short evidentiary matrix linking server logs, account attribution, and system permissions is usually more persuasive than a broad narrative. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion. The legal team can then decide whether the remaining uncertainty warrants a court request, an expert, negotiation, or a revised position. Counsel can avoid over-lawyering the issue by defining the exact decision it is supposed to change.

Server logs require understanding of automated events#

Server and application logs can record actions that occur without a human user clicking anything. Scheduled jobs, API calls, synchronization and automated scripts may generate entries attributed to a service account. The defense needs to understand the system architecture before treating every log event as a deliberate act by the defendant. Technical documentation and developer testimony can help identify automated processes. Conversely, unique administrator commands or manual login patterns may strongly support personal attribution. An expert can explain technical operation, while counsel connects the explanation to the legal issue. Log analysis should also account for time zones, clock drift and retention periods. A precise understanding of automation can prevent both prosecution and defense from overstating what a digital trace proves. Instead of starting with conclusions, the file can align payment evidence, server logs, and account attribution on the same timeline. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion. Once the sources are reconciled, counsel can separate facts that are established from those still genuinely contested. The file should state whether the issue affects ownership, value, custody, charge, role, amount, coercive measure, or sentence.

Source-code history can establish chronology and developer responsibility#

Version-control systems often preserve commit dates, authors, branches and code review. These records can show which developer created a feature and whether later changes occurred after that person left the project. The defense needs to verify account attribution because developers may share credentials or commit through automated systems. Code comments and issue tickets can reveal the stated purpose of a feature. A module that later facilitates fraud may originally have been built for lawful use. The prosecution may nevertheless show that the client continued modifying it after learning of unlawful activity. A chronological code map therefore helps identify when technical contribution and alleged knowledge intersect. This is far more informative than presenting the entire codebase as one incriminating object.

Before expanding discovery on Source-code history can establish chronology and developer responsibility, counsel can identify the minimum factual chain the decision-maker must accept. The first comparison should place payment evidence beside forensic source data; account attribution then tests whether the explanation is consistent. The exercise often removes peripheral accusations and leaves a smaller dispute that can actually affect the result. Legal analysis is incomplete until the team identifies what concrete procedural or economic consequence the point is meant to produce. Where code history materially changes the picture, it should be addressed separately rather than folded into a global conclusion. That evidentiary economy supports the broader aim to tie technical evidence to the charged elements and the client's actual role.

Financial attribution should not be inferred solely from technical access#

System administrators may be able to see transaction data without controlling money. The defense needs to distinguish read access, transaction approval, wallet keys and bank authority. Payment-system logs can show which accounts initiated transfers. Compensation can also help explain whether the developer had an economic stake in the scheme. Where cryptocurrency is involved, wallet attribution and exchange records may require specialist review. The legal team should avoid assuming that because a client built payment infrastructure, the client received or controlled the proceeds. Equally, technical separation does not eliminate liability if messages show knowing assistance. Combining financial and technical evidence produces a more accurate role assessment. That chain can be tested against system permissions, payment evidence, and code history. Where forensic source data materially changes the picture, it should be addressed separately rather than folded into a global conclusion. An adverse document should be analyzed directly; ignoring it usually weakens the rest of the submission. The remedy or defense consequence should be specified at the same time as the factual theory. Where wallet keys, payment approvals or bank credentials are held by others, that separation should be documented with system and account records rather than assumed from job title.

Trial presentation should simplify technical disputes without distorting them#

By trial, the defense may have thousands of technical records but limited time to explain the issue. Counsel needs to identify the few digital facts that matter to each legal element. A timeline, architecture diagram or account map can help where permitted and properly supported. Experts should use clear language and disclose assumptions. The defense needs to avoid technical jargon designed merely to make the evidence appear uncertain. Judges need to know what can be verified, what is disputed and why the dispute affects guilt or role. A narrow, demonstrable technical point often has more persuasive force than dozens of minor forensic objections. Preparing that presentation early also helps the defense decide which expert work is genuinely necessary.

Trial presentation should simplify technical disputes without distorting them is strongest when counsel can show why a particular record matters, not merely that many records exist. A short evidentiary matrix linking forensic source data, server logs, and payment evidence is usually more persuasive than a broad narrative. Where account attribution materially changes the picture, it should be addressed separately rather than folded into a global conclusion. That discipline makes alternative legal positions easier to maintain without contradicting the factual record. A sound position should also survive the practical question of how it will be implemented the month after the decision. The result is a record better suited to tie technical evidence to the charged elements and the client's actual role.

Case study: developer of a payment platform#

Assume the client wrote backend software for a payment platform later used to collect fraudulent investment deposits. Chat records show developers discussing “conversion rate” and customer complaints, but no message directly instructs the client to deceive victims. He had server administrator access but no bank access. The defense verifies the forensic extraction, identifies the client’s code commits and reviews the full chat context. It also preserves earlier product documents showing the platform was initially developed for a lawful payment service. Later messages may still show that the client learned of fraudulent use and continued supporting the system. The legal analysis therefore focuses on when knowledge arose and what assistance followed. The case cannot be resolved by saying either “he was only a programmer” or “he had admin access.” Attribution, chronology and knowledge need proof.

Assume the prosecution’s key server log records administrator actions from the engineer’s credentials, but the system used automated deployment scripts and shared service accounts. A technical expert can explain which entries require manual action and which can occur automatically. At the same time, code commits from the engineer’s personal account show that he modified a payment-routing module after internal messages explicitly discussed fraudulent customer acquisition. The defense therefore cannot rely on a broad “logs are unreliable” objection. It must separate automated events from provable human conduct and then address what the later code changes reveal about knowledge.^[1][2] The case study illustrates how technical uncertainty and incriminating evidence can coexist in the same file. Trial preparation would then focus on the small number of log and code events that actually bear on knowledge, rather than presenting the entire technical record as equally important.

Where the defense uses a technical expert, the expert report should distinguish observed system behavior from assumptions about the defendant’s knowledge. That boundary is important because a reliable forensic conclusion about a server or device can still leave the criminal-intent question unresolved for the court.

Conclusion#

Electronic evidence is powerful because it can preserve detailed conduct, but its existence does not answer every legal question. The Criminal Procedure Law and electronic-data provisions require courts and counsel to examine collection, authenticity, legality and relevance.^[1][2] Defense strategy must add attribution, completeness and legal inference. A disciplined digital evidence matrix allows the case to move from thousands of files to the specific facts that prove—or fail to prove—the defendant’s knowledge and role.

Legal and regulatory sources#

^[1] Criminal Procedure Law of the People’s Republic of China — [official source](https://www.npc.gov.cn/c2/c12435/201905/t20190521_276591.html) ^[2] Supreme People’s Court, Supreme People’s Procuratorate and Ministry of Public Security, Provisions on Collection, Extraction and Review of Electronic Data in Criminal Cases — [official source](https://www.court.gov.cn/fabu/xiangqing/26431.html)

General legal information only; not legal advice for a specific cybercrime case.