76

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?"

Giacomo1968
  • 1,185
  • 5
  • 16
user91785
  • 509
  • 5
  • 5
  • 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?) – Mike Ounsworth Nov 12 '15 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 Nov 12 '15 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 Nov 12 '15 at 21:22
  • 1
    @reirab Generally, your statement would be true. However, recent (post-9/11) laws in the U.S. make things a bit fuzzier at the border. Essentially, if you're traveling into/out of the U.S. (most especially into, and quite especially if you're not a citizen), assume that your possessions and electronic devices are *legally* vulnerable to search and seizure by border authorities. Such cases are relatively rare, especially those involving seizures of such duration as this one, but it's far from unheard of. – Iszi Nov 12 '15 at 21:30
  • 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 Nov 12 '15 at 21:42
  • Save the text of your source code into seperate text files then trash the system. – n00b Nov 12 '15 at 21:58
  • 1
    If they installed anything in/on your computer, and you or someone else is able to find it, this would be an excellent opportunity to leak it. – Simon Richter Nov 13 '15 at 01:34
  • 1
    As noted by @Jeroen-ITNerdbox, [firmware can be compromised](https://blog.kaspersky.com/equation-hdd-malware/7623/). But then, that's [a problem for all of us](http://www.standard.net/Tech-Matters/2015/08/08/What-you-should-know-about-firmware-viruses) anyway. What do you expect to replace your equipment with that's as trustworthy as you seem to want? Why are you particularly concerned? (Other than the overall concern shared by most of us.) – user2338816 Nov 13 '15 at 01:40
  • Do you care if other people access this code ? You can find people that would love to reverse enginner your laptops to expose another U.S scandal ( " U.S has been planting malware on tourists eletronic devices "). Maybe this could teach a thing or two to the US – Freedo Nov 13 '15 at 02:29
  • I get the impression you don't particularly want to disclose what sort of software that you were/are developing (which is certainly your right, and which I'm certainly aware that you could be doing for any number of 100% legitimate reasons). But I think any real, pragmatic answer has to take into account what motivations DHS might have for altering your source code, implanting malicious firmware, etc. Which necessarily depends on what they might see you as doing that would be worth the time/hassle. In other words, if you're a developer of casual games for smartphones you ... – mostlyinformed Nov 13 '15 at 08:43
  • ...almost certainly have little to worry about. If, on the other hand, you're a security software developer for a start-up that's working on a next-gen IDS or something the practical risk might (maybe, possibly) be non-negligible. And if you're a malware-developer-for-hire just coming back from a trip to northern Pakistan... well, you get the point. (Deliberately extreme example.) – mostlyinformed Nov 13 '15 at 08:52
  • 4
    This is why there should be an off site backup http://www.hanselman.com/blog/TheComputerBackupRuleOfThree.aspx – Celeritas Nov 13 '15 at 09:02
  • If I was the government and I planned on monitoring you, I would do hardware mods that would exist even after a reformat. Might want to visually inspect your circuit boards and such for any funky soldering or chips that look out of place.. – Tony Nov 13 '15 at 17:12
  • You can test whether or not Homeland Security has installed undetectable spyware by doing precisely those things that is bound to catch the attention of Homeland Security without actually violating any laws. You can think of writing up a plan to launch a terror attack, use RSA encoding to encrypt the document and then upload that to a mail server, e.g. a throwaway gmail account. You then behave like a terrorist who communicates via a shared gmail account and RSA encryption. – Count Iblis Nov 13 '15 at 18:07
  • Now, if Homeland Security staff can read your unencrypted document then they will have to act on the information in it, assuming that this is sufficiently alarming. Homeland Security will want to keep you in the dark about what they know at this stage to make sure you keep up with spewing information about your plans using your laptop. If you write about some plot against a target that normally has little security and you suddenly see a lot of security there, then that's a sign that Homeland Security has read your document. You then want to get rid of your computer. – Count Iblis Nov 13 '15 at 18:07
  • Jake - Would you mind giving me background as to why this happened? Maybe what behavior we should avoid in the airport? – HorseHair Nov 13 '15 at 19:51
  • Was your year's worth of source code in a version control system that has a checksum mechanism? If so do you have any way (email archives for example) of verifying the checksums at any point? Most of the answers so far are alarmist and generalized. And there is good reason for that but given certain specifics there may be ways to safely recover some of your data. – Caleb Nov 13 '15 at 20:16

11 Answers11

77

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

Iszi
  • 26,997
  • 18
  • 98
  • 163
  • 1
    Good one, though I would replace "hostile" with "not completely trustworthy". – Deduplicator Nov 12 '15 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 Nov 12 '15 at 22:25
  • @DoktorJ: Even that might not be enough (if you're really *that* paranoid). They might have made a tiny alteration to the code which you might inadvertently copy (like: removing a necessary '+1' on a length check). Better might be to get a high-level overview, and re-implement the functionality from scratch. Added bonus: 1. change to improve the design while you're at it, and 2. it forces you to focus on the implementation instead of checking that the characters match 1-by-1. – Sjoerd Job Postmus Nov 12 '15 at 23:06
  • Wouldn't powerful enough encryption protect your data from read and meaningful write operations? – PyRulez Nov 13 '15 at 00:12
  • 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 Nov 13 '15 at 02:05
  • It should be safe to transfer the data over, if you use software you wrote yourself. E.g. connect the compromised computer to a trusted one over RS-232 (a simple protocol that's very unlikely to have remote vulnerabilities), and have the compromised computer dump its hard drive to the serial port, and have the trusted computer read that data to a file. You then have a hard drive image *(which might not be safe to boot in a VM)* – user253751 Nov 13 '15 at 02:18
  • 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. – R.. GitHub STOP HELPING ICE Nov 13 '15 at 02:35
  • @R.. that's exactly what i was going to write here but you wrote before. Lot's of people would pay a lot to get the hands on this devices. In fact I would be very surprised if US is stupid enough to plant malware on all the devices they seize haha. All a spy needs to do is get his devices seized then reverse engineer them (did someone say China?) – Freedo Nov 13 '15 at 02:37
  • 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 Nov 13 '15 at 05:01
  • How about using a camera pointed to the screen of the compromised computer that does on the fly OCR. You need to create a script which lists content of files as plain text so that it is recognizable, and one that does the reverse. Printing would be an alternative that is really annoying. – WalyKu Nov 13 '15 at 16:44
38

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.”

Herringbone Cat
  • 4,242
  • 15
  • 19
  • A write-blocker might not be sufficient in case the hard drive has compromised firmware, which could possibly exploit a vulnerability in its driver. – user253751 Nov 13 '15 at 05: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. – Herringbone Cat Nov 13 '15 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. – user253751 Nov 15 '15 at 02: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. – Herringbone Cat Nov 30 '15 at 23:26
  • or exploit the host computer with a read. – user253751 Nov 30 '15 at 23:28
  • @immibis I'm not sure we're on the same page -- a write block duper *is* the host computer and copies it drive->drive. There is no other computer involved. – Herringbone Cat Nov 30 '15 at 23:42
  • Oh, a separate device that copies the drive, not just a write blocker. – user253751 Nov 30 '15 at 23:48
  • @immibis Yes, that is what makes it a "write block *duper*" – Herringbone Cat Nov 30 '15 at 23:48
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.

Dragonel
  • 397
  • 2
  • 3
  • 1
    You can take pictures of the printed documents and use programs to extract the text from the images. – Count Iblis Nov 12 '15 at 20:21
  • 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 Nov 12 '15 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 Nov 12 '15 at 20:30
  • 1
    @Dragonel Oh, for the first few hours you might. But after it's taken days to get through all the code (you did say *reams*), I expect you're just gonna end up glossing it over at some point. – Iszi Nov 12 '15 at 20:32
  • 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 Nov 12 '15 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 Nov 13 '15 at 01:01
  • OCR answers the tedium objection, but not the alteration issue. In fact, OCR will probably do some altering on its own. – WGroleau Nov 13 '15 at 05:58
  • 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. – Neil Smithline Nov 13 '15 at 07:56
  • 1
    Better take screenshots than paper printing, not with print-screen key, but with a external camera to shot the screen scrolling. – elsadek Nov 13 '15 at 09:54
  • @Iszi: On the other hand, I dont know what exactly is the law about the lawfull acting for departments like DHS, but in germany even such an department would act unlawfull if they just placed spyware without any reasonable suspicion on your device. If that is the case for the DHS aswell, even if your right with your assumption of one might after multiple days stop checking the code line by line, if they really would in case they allready assume you to go through that step, they would risk you detecting this and inferential resulting into making it public they use unlawfull methods. – Zaibis Nov 13 '15 at 13:56
  • 2
    Don't use a color printer: https://en.wikipedia.org/wiki/Printer_steganography – LawrenceC Nov 13 '15 at 14:16
18

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.

Ohnana
  • 4,737
  • 2
  • 23
  • 39
  • 2
    [Here's a great article](https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices) 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. – Mike Ounsworth Nov 12 '15 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 Nov 12 '15 at 19:27
  • He did? Interesting. – Mike Ounsworth Nov 12 '15 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 Nov 12 '15 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. – Dan Is Fiddling By Firelight Nov 12 '15 at 21:28
  • @Ohnana after they took a copy and added hardware bugs ot the keyboard to send back his password? – JamesRyan Nov 13 '15 at 12:49
  • Clarified. I thought popping the drive out would be second nature :) – Ohnana Nov 13 '15 at 17:28
6

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.

piers7
  • 201
  • 1
  • 2
  • 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 Nov 13 '15 at 00: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 Nov 13 '15 at 01: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. – R.. GitHub STOP HELPING ICE Nov 13 '15 at 02:37
3
  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.

user253751
  • 3,885
  • 3
  • 19
  • 15
2

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.

Joshua
  • 1,090
  • 7
  • 11
2

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.

Byron Jones
  • 265
  • 1
  • 4
1

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).

1

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

Easy:

  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.

Falco
  • 1,493
  • 10
  • 14
0

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.

tl;dr

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.

GreatSeaSpider
  • 2,054
  • 16
  • 14