I flew from overseas back to the USA and all my electronic equipment was seized by Homeland Security, including my laptop computer, external hard drives, flash drives, etc.

After more than a month I have finally gotten my stuff back. I have 2 questions:

  1. Is it known whether Homeland Security has ever planted spyware, viruses, tracking devices, etc. on seized computers?

  2. What should I look for, what steps should I take to sanitize my stuff, what would you do?

EDIT: I can't reformat, burn hard drive, etc. as some have suggested because very important work is on the laptop, i.e. software I've been working on for over a year.

Yes, I had backups of all my data. Unfortunately, the backups were all with me, and they seized all of those too (2 external hard drives, 3 usb flash drives). So merely utilizing backups isn't an option.

Also, someone said people can't help me without breaking laws. I am unaware of any laws which state it is illegal to remove spyware/malware/viruses, or that it is illegal to remove anything the government put on your computer.

EDIT: I guess I could rephrase the question as "how would you go about getting source code you had written (text files) off the computer safely, 'safely' meaning scanning text files to detect anything unusual, and then transmitting or somehow putting them on another computer?"

  • 4
    The obvious answer is: format everything and re-install. Though that won't protect you if they've modified the motherboard. More detailed suggestions (if any) will likely depend on what operating system you are running (I assume Windows?), the hardware of the laptop, do you have backups at home of all the data (ie buy a new laptop and take the backup data?) Commented Nov 12, 2015 at 18:34
  • 8
    Well, I would burn it and start with a new one by buying one in a shop and not order it online. Then again, I'm just paranoid. Firmware's can be modified, especially the ones on hard drives, BIOS, video cards etc.
    – Jeroen
    Commented Nov 12, 2015 at 18:37
  • 9
    In addition to the security steps, I would talk to an attorney. If this doesn't constitute unreasonable search and seizure, I can't imagine what would. Such is illegal without probable cause of a crime having been committed.
    – reirab
    Commented Nov 12, 2015 at 21:22
  • 8
    @Iszi Depends on your definition of 'legal,' I guess. The U.S. Constitution hasn't changed since 9/11 and it explicitly states that such is illegal, regardless of what any other law may say. Just because a law hasn't been ruled unconstitutional yet doesn't mean it isn't unconstitutional. Of course, rights for non-citizens can be significantly different, but OP seems to be referring to the U.S. as home, so I assumed he/she was a citizen.
    – reirab
    Commented Nov 12, 2015 at 21:42
  • 4
    This is why there should be an off site backup hanselman.com/blog/TheComputerBackupRuleOfThree.aspx
    – Celeritas
    Commented Nov 13, 2015 at 9:02

11 Answers 11


Given that your laptop was in possession of a government entity with unknown intentions towards you for an extended duration, there's really no way you can restore it to a fully trustworthy state.

If you assume the U.S. DHS to be hostile, then the only secure process to move forward with includes:

  1. Assume all data on the laptop, and all other confiscated hardware, to be compromised.
    • Change all passwords for accounts which may have been stored/cached on the devices.
    • Change all passwords for other accounts which use the same password as the accounts which may have been stored/cached on the devices.
    • Void all payment mechanisms which may have been stored/cached on the devices.
    • Communicate appropriate privacy warnings to potentially-affected third parties.
  2. Assume the laptop, and all other confiscated hardware, was modified to allow future collection of data, or control of the system, by U.S. DHS or related agencies.
    • Destroy the devices. Do not capture any backup images or copy any files. Just burn/shred/pulverize/crush them as-is.
    • Purchase replacement hardware/software from a trusted source, through a trustworthy supply chain, and re-build from scratch.
    • If trustworthy backups exist (backups which were not also confiscated, and would not be remotely accessible with credentials that may have been stored/cached on confiscated devices), restore data from those sources as needed.

Anything short of this leaves open several extremely undesirable possibilities:

  1. U.S. DHS may continue to have access to your online accounts and/or financial resources.
  2. One or more of your devices may have persistent malware which allows U.S. DHS, or related agencies, to spy on you or control your systems. And you're back to #1.
  3. Files stored on one of your devices may have malware which will install itself upon opening. Then see #2.
  4. Hardware or firmware on one of your devices may have been modified to include malware, which may install itself upon connection to another device. See #2 again.
  5. Any software projects you were working on, and/or the tools you use to compile them, may have been modified to include malware. Back to #2 again, and also add further impact to your customers if it's not discovered and dealt with before distribution.

You should check out the 10 Immutable Laws of Security. Law #3 certainly applies. Assuming they've exploited that law, you can probably bet Laws #1 & #2 also apply.

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Also check out the 10 Immutable Laws of Security Administration. Here, Law #4 is most apropos.

Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with

  • 1
    Good one, though I would replace "hostile" with "not completely trustworthy". Commented Nov 12, 2015 at 22:14
  • 4
    If you really want to preserve human-readable files safely, your only recourse would be to open them on the compromised device and manually transcribe them to a trusted system. Painful? Yes. But the only device capable of providing sufficient filtering to ensure that compromised data doesn't get onto the new machine is your brain, eyes, and fingers. And of course, if you're talking about source code, make sure you understand the code you're transcribing :P
    – Doktor J
    Commented Nov 12, 2015 at 22:25
  • 3
    @DoktorJ Can't the OP just upload the code via copy-paste to a online service (GitHub, or Google Docs for instance), move to a secure/fresh computer, and copy-past it back down? I don't see how that could hurt anything, as the code has already been read by the government, and once you paste it into GitHub and upload it, then check that it uploaded the right code (not replaced by something else as you copy-pasted), the GitHub repo should be "clean".
    – Numeri
    Commented Nov 13, 2015 at 2:05
  • 17
    "Destroy the devices" is awful advice. Devices that are compromised like this are incredibly valuable for understanding the enemy's capabilities. You could probably even sell them to security researchers if you wanted, though from a standpoint of protecting your privacy it probably makes more sense to work with ones you trust to salvage any data you need and allow them to research what was done to the devices. Commented Nov 13, 2015 at 2:35
  • 3
    @Numeri the reason I suggest transcription is because every single character of the code then goes through the OP's eyes, mind and fingers. If his systems were indeed compromised, I wouldn't put it above a bad actor to modify the code to embed malicious things in it. By manually transcribing, such things would jump out where they'd be completely missed in a copy/paste.
    – Doktor J
    Commented Nov 13, 2015 at 5:01

This is a great question.

Basically, once a device has been seized by an adversary with the level of sophistication as a nation-state, especially the United States, that device and all data contained cannot be trusted. The only safe approach is to not trust that device and destroy it.

The Snowden leaks have exposed the various methods in which the American government can compromise computers. This includes installing hardware bugs in the keyboard itself, the GPU, or other components that make the computer fully rooted and compromised even if an O/S is reinstalled. They have also installed radio transmitters to defeat "air-gapped" computers that never connect to the internet by exfiltrating data via hidden radio. Jacob Appelbaum's talk on the subject is very informative: I highly suggest watching this video as he details the various devices the government is known to use. A wikipedia summary is also available.

Now, it is possible the Homeland Security agents didn't plant any of these devices and do not have the same capabilities as the NSA. However, that cannot be ruled out.

While you may be able to retrieve some data from the hard drive by taking it out and putting it into a USB enclosure/using a SATA to USB cable, this has risks. I would use a throw-away, single-use computer for reading the drive..as the drive's firmware or controller may have had malware installed in it that will try to infect any computer it's plugged into.

To counteract this, I would recommend purchasing a forensic hardware duplicator device (known as a write-block duper). Then, plug the SATA drive from your computer into it and clone it to another disk. Then, copy the files from that cloned disk to another computer. That should prevent firmware-based compromise.

However..you can't be guaranteed some type of worm, etc hasn't been planted in the files themselves. By copying to multiple devices, and not using the device you originally used to plug in the hard drive to, you minimize your chances of prolonged compromise; but there's still a chance something is awry with the files. AntiVirus etc won't help against sophisticated attacks like this.

That's why the computer can no longer be trusted. You can take steps like the hardware duplicator to help minimize the possibility of issues however.

Also this story might be of note: http://www.wired.com/2010/11/hacker-border-search/ .. famous hacker gets his computer inspected at border by DHS, and his conclusion was one I believe that's very valid:

“I can’t trust any of these devices now,” says Marlinspike, who prefers not to divulge his legal name. “They could have modified the hardware or installed new keyboard firmware.”

  • A write-blocker might not be sufficient in case the hard drive has compromised firmware, which could possibly exploit a vulnerability in its driver. Commented Nov 13, 2015 at 5:54
  • @immibis How so? I find it hard to believe that the firmware ROM on a hard drive could have enough space to deliver custom firmware-based attacks to the various duplicator modules on the market; or that even the best adversary has malware capable of infecting firmware of any of the myraid of devices that can read/duplicate SATA drives. Commented Nov 13, 2015 at 18:19
  • I'd imagine the write blocker passes read requests through unaltered, so if there's any vulnerability in the processing of read requests, your computer would still be vulnerable with the write blocker. Commented Nov 15, 2015 at 2:10
  • @immibis I think this is highly unlikely, since you'd have to have found and able to exploit vulnerabilities in every write-block duper on the market...which would probably take up more space than they have available on the firmware ROMs etc. Commented Nov 30, 2015 at 23:26
  • or exploit the host computer with a read. Commented Nov 30, 2015 at 23:28

Depending on your level of paranoia about this and the amount of your code, at the extreme you can move to a LOW-TECH method to circumvent anything that has been done.
Buy a cheap printer. Connect it to your laptop. Print out your source code as reams and reams of text. Print out any graphics, layouts etc. Print out any needed user settings. Destroy the laptop and printer.

Of course you now have to re-input all of your source code, re-create your graphics and so on, but you don't have to actually re-invent any of the IP and there is NO electronic connection for anyone to track.

  • 2
    And of course you have to assume that DHS hasn't soiled your source code with their own malware - or that you'd catch it if they did, in the midst of the mind-numbing process of manually importing (i.e.: typing) reams and reams of source code from hardcopy.
    – Iszi
    Commented Nov 12, 2015 at 20:25
  • 7
    @Iszi I was assuming the OP would know his source well enough to tell if anything has been changed, and that the DHS would not take such a risk. However I would anyway take it as an opportunity to review the code and so be thinking about what the lines do as I re-entered them, and removing anything that is unnecessary or coming up with better and more efficient methods.
    – Dragonel
    Commented Nov 12, 2015 at 20:30
  • 5
    @CountIblis The embedded malware may have encrypted itself into a pattern of seemingly random dots on the printout which encodes itself into new malware when read by any commercial optical reader on the market. [Extremely paranoid smile]
    – Dragonel
    Commented Nov 12, 2015 at 20:42
  • 4
    No, the other answers have it. The difference between "<" and "<=" in a forloop, or "+1" and "-1" or nothing at all, are fully exploitable, and you are psychologically inept to catch [all of] these.
    – djechlin
    Commented Nov 13, 2015 at 1:01
  • 5
    If you're just going to extract the source code, booting form a live CD and copying the source files to a cloud device seems way more efficient than this. Commented Nov 13, 2015 at 7:56

1) So there's no way of knowing they haven't. I feel like that's a bit above their paygrade (and would they have the time to?). It depends on your paranoia level. If your thoughts flow like a tranquil stream after the first spring day, then copy the data to a new machine and move on with life. If you wonder if the dogs howling in your thoughts are messengers for the prince of darkness, burn everything in a thermite-fueled bonfire.

2) For me personally, I would destroy the equipment, weep on its grave, and move on. With backups that aren't physically on me. However, most of the data I keep on my machines either lives in the cloud, or is replaceable.

If this work is truly priceless, an audit is in order. First off, take the drive out of the laptop and plug it into an isolated environment -- new computer with no network. A handy-dandy Linux Live CD is great for this. Mount the drive in question, and look through the files -- do you see anything odd? Is anything missing? Any strange windows files? Using Clam AV is also a good choice. Are there any new files you don't recognize? Delete them.

I'd also do the copy over in small pieces while in the Linux Live CD. Unless they're sophisticated enough to put Windows and Linux malware on there, you'd prevent any surveillance programs from autoplaying and finding a new home. I cannot stress this enough -- know what you are copying. Check your project -- Any new additions you don't remember?

After that, use a clean Windows environment and be on the watch for any suspicious activity. Build a good security policy, and next time encrypt your drives! Oh, and toss everything once you've recovered the data. Firmware attacks are real.

  • 2
    Here's a great article with tips for bringing sensitive data over the border. It's not clear to me that encrypting your drive would help once they've seized your laptop; they would ask you for the password and if you refuse they certainly wouldn't return the laptop to you. Commented Nov 12, 2015 at 19:24
  • 2
    I know it helped Moxie Marlinspike when he got harassed -- he got his stuff back. If nothing else, it'll give you the peace of mind that everything within the encrypted container might be okay.
    – Ohnana
    Commented Nov 12, 2015 at 19:27
  • He did? Interesting. Commented Nov 12, 2015 at 19:28
  • 2
    @Ohnana Everything within the container might be okay, but if the container itself (e.g.: hard drive firmware) isn't then you're still hosed.
    – Iszi
    Commented Nov 12, 2015 at 19:48
  • If you're being really paranoid, I'd go with an OS less widely used than Linux on your live CD if possible. BSD at a minimum, something weirder like Haiku (a BeOS) clone would be better. Commented Nov 12, 2015 at 21:28

As others have pointed out, for the source code you need do more than just copy it out safely - you need to be able to detect tampering. And for that you need to do a substantial code review.

If the code is highly complex, or you don't know enough about it to adequately do so, you do have another option: crowdsource your review. Just publish the code as open source, and invite people to find the implant. I imagine some people would relish the challenge.

  • 7
    ...and failing that, post it a file at a time to Stack Overflow, with a related noob question as bait. I swear that's how some people do their QA.
    – piers7
    Commented Nov 13, 2015 at 0:19
  • +1 for creativity, and maybe a practical step toward salvaging the untrusted source code (i.e. lowering the probability it is bugged, although not destroying it).
    – djechlin
    Commented Nov 13, 2015 at 1:03
  • 8
    If the source code was kept in git, just knowing the correct hash for a recent commit from some source that's not compromised would give you a reasonable level of confidence that none of the history was tampered with. Commented Nov 13, 2015 at 2:37
  1. Get another (trusted) computer.
  2. Get two USB/serial adapters, and a null modem cable (to connect them). It's unlikely that your trusted computer is remotely exploitable over a serial connection. Connect one adapter to each computer.
  3. On the trusted computer, run cat /dev/ttyS0 > hd.img. (Your serial adapter might not be /dev/ttyS0; you might want to check this somehow)
  4. Connect the two computers.
  5. On the untrusted computer, run cat /dev/sda > /dev/ttyS0 (or whichever hard drive you want to image, and whatever the serial adapter is called on that computer)
    (If that computer isn't running Linux already, then use a Live CD or a throwaway Live USB)
  6. When this finishes, ctrl-C the trusted computer's cat process (since it will keep waiting for more data).

(If you have more drives you want to image, attach them to the untrustworthy computer and repeat the procedure)

You now should have a hard-drive image, and you obtained it without making your trusted computer vulnerable. As the contents of the image are untrustworthy, do not boot it in a virtual machine.

You could open it with a hex editor and try to search for the data you want, but it will take you forever to piece together the files.

Instead, write a program (in a memory-safe language such as Java or Python) to parse the filesystem's data structures and extract the files you want. Make sure to review each extracted file in a hex editor before using it for anything else, in case it's been tampered with. (Don't even use cat. xxd is fine as long as it's not set to display ASCII characters)

Destroy the untrustworthy computer and devices (including any Live USBs you used on that computer); you don't know they haven't added any tracking devices. They have (probably) done that in the past, so this concern is not unjustified.


I've never faced this scenario; however from what I know the reverse cleanup procedure works. Boot external media and carefully copy your work files out one by one, auditing them as you go. Then reformat.

Be glad that up-to-date systems do not have attacks via text or image files (at least known ones). If mysterious processes do appear, submit your work files for malware analysis. If you got any, the DHS will regret having targeted you and wasted their most sophisticated malware on a low-priority target.


For future reference, both for yourself and others, I would recommend performing a full SHA256 hashing of all files on the computer, and of the firmware, before and after such a trip. Be sure to leave the SHA1 hash list at home.

I would also recommend that for trips out of country that you take an older laptop that you've erased and given a fresh install of your OS of choice prior to the trip. Take only the files you need. Smaller files should be cloud hosted or remotely accessed. Larger files should be encrypted individually and given innocuous names and nonstandard file extensions that don't reveal their purpose.

Prior to returning, you should remove any files that you don't want the Customs agents accessing.

At the very least, these steps will narrow down your focus for determining what files might have been added/modified/deleted.


As stated in other answers, there could be spyware in the BIOS or otherwise hidden in modified hardware. (For example, in theory, one can imagine a complex attack where a processor is replaced by a chip that emulates the original processor but also does additional things for spying purposes.)

To be absolutely sure that you had removed any such spyware would require expertise in the electronics, and even then, the time to do so might be worth more than the value of the hardware.

However, recovering data (not executable code), especially plain text, from it is possible, provided that you never run code that came - directly or indirectly - from the compromised machine (including any files directly written by hardware from the compromised laptop). That means:

  1. You can't use the laptop itself to copy the data.
  2. You can't recover compiled code (assuming that you aren't going to disassemble and read it all thoroughly).
  3. Any source code that you recover must be manually inspected. If it's your own code, checking for added spyware should be feasible, but time-consuming.
  4. The above two points apply to any document types that can include macros or scripts (e.g. Microsoft Word and Excel documents).
  5. You could recover document types that support macros by using trusted software to check for and remove the macros.

You would connect the hard disc to a new machine, to copy from it, and discard it afterwards.

There is still the risk of buffer overrun attacks in documents, targeting a particular application that you might use to view the document. A possible defence against these (apart from checking for known vulnerabilities) would be to use less common applications (and not ones that were installed on your laptop, since they're the ones they'd expect you to use) to view the documents, or converting them to another format (using software from a trusted source to do so), and possibly back.

The hard disc(s) from the compromised laptop could have modified firmware, but that can't directly cause code to run on the machine you use to copy from them (it could alter data as it is read or written). Though in theory, it could have a buffer overrun exploit targeting a disc driver.

Ideally, all copying and conversion (and macro removal) would be done on a machine that you would reinstall (or discard) afterwards. (A Raspberry Pi or similar is quick to set up and can be expendable).


You want to copy your sourcecode from the compromised machine without the risk of infecting your new computer?


  1. Get access to an open WiFi Network
  2. Copy your Sourcecode-Files to a free storage cloud service (or paste-bin)
  3. download the source-files with your home computer
  4. Carefully inspect all your sources for tampering (which is rather unlikely, because they usually would think you have backup-copies somewhere and wouldn't bother, but depends on the complexity of your software)

In this way you don't have any direct connection from the (possibly) compromised machine to your home computer. The only files you transfer are raw text files and inspected by hand. So the only attack-vector left is underhanded code in your sourcecode files. The only way to be bullet proof against that would be to rewrite every method in a new Project. Look at the old sourcecode and write each method anew with some minor fixes and cleaning up.


Others have covered the dangers & issues here perfectly so I'm not going to try to reproduce that. I just wanted to add a suggestion for after the inevitable code review. I realise that the question is about santizing the computer, but I'd suggest you need to take steps regarding your code too.

So let's assume that you've treated all the hardware as though it's a total write off and hostile, and you need to get the code back from it. There's already been suggestions of how to get the code off and on to another machine using a throw away printer and let's say you've done that (I'd have phycisally removed the wireless adaptor from the compromised machine before booting it as an extra precaution too).

So you've typed in your code again and reviewed it for modifications already and you're happy with it. The extra step I'd take now is to also assume the code has been examined and needs reviewing at a functional level and, if necessary, changing.

This might be the way you hash and store passwords, perhaps a licencing mechanism if it has one, or perhaps your code communicates over the internet with users in a particular way. I'm just thinking if I was carrying the code which ran something which would be of interest to a nation state actor, I'd look at modifying it so that if they've gleaned anything from it's inner workings, the next time they see it in use it will behave differently to how they'd expect it to behave.


I'd suggest giving some thought to the functonality of the code you were carrying; would a potentially hostile actor gain any benefit from having an understanding of how it works? If so consider how you'd mitigate the fact that someone has that knowledge.

This is assuming of course, that the code you were carrying would potentially be of interest to them.

Final note; this step would be necessary in my mind even if I'd restored the code from a known safe backup, as it's the way the code works which has been exposed.

Your situation doesn't sound like much fun regardless - good luck in getting it all sorted out.

Not the answer you're looking for? Browse other questions tagged .