I must only use my powers for good.

September 24, 2006 10:17 PM

How can I transfer a large file from a secure Windows XP computer?

I want to transfer a 3GB file from a secured computer running Windows XP. The file is in the public domain, but for various good reasons I can't burn a CD ROM or write to a USB drive. I can't even boot off a CD ROM or USB drive.

So far my best idea is breaking the file into little tiny chunks and emailing it to myself. This will take a while, especially since I can only transfer 170MB per week.

I do have access to the shell, but I don't have administrative rights to the computer involved.

Any suggestions? My next step is seeing if I can get RS232 to work ... please save me from this.

posted by Joe in Australia to computers & internet (21 comments total)

Who secured the computer, and why? I work at a place with secure computers, and we have a "trusted download" process to get files off them via burnt CDs or USB drives. It seems like whoever secured the machine should be able to provide you a mechanism for working around it, in a safe manner.

Unless, of course, you're trying to surrepticiously circumvent these protections.
posted by knave at 10:26 PM on September 24, 2006

You can get a crossover cable (or maybe even a plain Cat5 cable) and connect it to another computer, share the file, and get it that way. Of course if you're trying to do this discreetly, this won't work.
posted by Brian James at 10:26 PM on September 24, 2006

I do have access to the shell

FTP?

I think you're going to have to explain quite what you mean by 'secured'.
posted by pompomtom at 11:07 PM on September 24, 2006 [1 favorite]

How aggressively are you allowed to attack this computer?

If you want to go in boots and all:

First, copy the file into a non-encrypted folder (assuming it's in an encrypted folder now). Even with non-admin rights, you should be able to set up a non-encrypted folder inside your own user profile.

Next, open the case, find the CMOS-clearing jumper on the motherboard and jumper it for a few seconds. That gets rid of your BIOS password.

Next, use the BIOS setup menu to enable booting from a CD-ROM.

Next, boot a Linux live CD, and use that to copy your file onto a CD-ROM or external USB drive.

Of course, this procedure will make covering your tracks quite hard.
posted by flabdablet at 11:47 PM on September 24, 2006

Bring another HDD, place inside computer. Boot. Copy file to new HDD. Shut down. Remove new HDD. Done.
posted by beerbajay at 12:27 AM on September 25, 2006

What about that hack that everyone was talking about a month ago, which allowed anyone to get admin access to an XP computer using at? I can't find the link right now but someone will know what I mean.

I'm terribly intrigued. This is some kind of test or exercise? Can you tell us any more? If the file is in the public domain, by definition, you can get it somewhere else, right?
posted by AmbroseChapel at 12:39 AM on September 25, 2006

Bring another HDD, place inside computer. Boot. Copy file to new HDD. Shut down. Remove new HDD. Done.

Opening the case can trigger the BIOS and alert the fedsIT staff.
posted by Blazecock Pileon at 12:44 AM on September 25, 2006

The computer is secured because it's in a public area at my college. There's a package accessible through those computers that isn't available through the network generally, and I'd like to get the resulting data off the computer without "breaking the rules". I guess I'm trying to surreptitiously circumvent the controls because I think that (in this case) they're silly. The controls were introduced because people were burning too much bandwidth. They're designed to stop you getting information off the computer other than by email - I haven't actually tried ftp within the local network, which is an interesting suggestion.

I don't think we were explicitly told that we're not allowed to open computer cases, but it would be obvious and unwelcome. The same goes for resetting the admin password and so forth. Basically, I don't want to irritate the IT staff.

Anyway, I know I can write to to a local HD, but not to any system directories. I have no idea what would happen if I plug a different ethernet cable in.
posted by Joe in Australia at 3:53 AM on September 25, 2006

I tried to escalate a limited account's privileges using the at trick on my XP Home box. Didn't work (limited user couldn't run at). I think it's bogus.
posted by flabdablet at 4:00 AM on September 25, 2006

If you can get ANY ports out to a machine you control, you can run SSH over that connection and use SCP. It is unlikely that the admins will see this traffic as being unusual in and of itself, although the sheer volume of it may set off flags somewhere.

Port 80 is often allowed to outside machines, and port 53 is too. You would need to run an SSH demon on a friendly machine somewhere on one of these ports, and then use an SSH client to connect to it, like Putty. I think putty comes with an scp clone... I'm not sure. You can also use a slightly older standard called SFTP, which is basically FTP over Secure Shell. Most servers support it, and many clients do too. (if Putty doesn't, the payware-but-excellent software from Vandyke would work.)

Another method is to use your SSH client to connect to the remote machine, and also forward a port from your local machine to the remote one. You might, for instance, forward the FTP port. Then you'd run an FTP connection to the local computer, and the SSH client would invisibly redirect that to the one on the other side of the link.

You can also use SSH as a 'bounce', where you connect to a remote machine, and then link a port on your local computer to a link on some THIRD machine. When you connect to the local port (machine A), SSH will forward that connection to machine B, which will then forward it to machine C on your behalf.

If you have no ports open to the outside world at all (unusual, but possible), I have also seen techniques described wherein data can be transferred via DNS requests, which are hardly ever blocked. I don't know of any programs offhand to do this, but I'm sure they exist somewhere. DNS traffic is often not monitored, as admins rarely think of it as being a security problem. This would likely be quite slow, because there's a lot of overhead bytes for every payload byte, and because it's rather asynchronous and lossy it requires good error-checking in the transfer protocol, but it would likely work.

Oh, note that it might be a good idea to split the file into smaller chunks with a program like WinRAR. If you send the data more slowly, over time, you'll improve your likelihood of escaping the eyes of Big Brother.
posted by Malor at 4:26 AM on September 25, 2006

1) Burn to CD
2) Place in Drive
3) Reboot
4) If BIOS supports CD Booting, wait 5 mins and recieve windows passwords
5) ???
6) Profit
posted by gregschoen at 4:35 AM on September 25, 2006

The fastest you can drive a PC's RS-232 connection is 115200 bits/s. At that speed, a 3GB file would take 3,000,000,000 bytes * 10 bits/byte / 115200 bits/second seconds = over three days to transfer. It's faster than 170 MB/week but it's still very slow.

I'd go the Ethernet cable route. The steps are:

1. Set up a shared folder on a laptop computer that runs XP. Make sure the folder's underlying NTFS permissions are at least Modify for Everyone, and that the share permissions are Full Control for Everyone.

2. Don black cloak and wide-brimmed black hat. Try not to look conspicuous.

3. Enter the college public area with the laptop computer and a crossover Ethernet cable concealed under the cloak.

4. Copy the file you want to a folder on the desktop's local hard disk.

5. Open a cmd window on the desktop machine and run ipconfig /all to discover its IP address and netmask. Set the laptop's IP address by hand to any other address on the same subnet. I'll use 10.132.157.63 to represent the laptop's IP address.

6. Unplug the desktop machine's Ethernet cable, and connect it to the laptop via the crossover cable. In the desktop machine's cmd window, run ping 10.132.157.63 and make sure you get a response from the laptop.

7. Open My Computer on the desktop machine, then type \\10.132.157.63 into the address bar. You should see an icon for the laptop's shared folder; double-click it to open.

8. Drag the desktop machine hard drive's copy of the file and drop it into the laptop share. When the copy finishes, close the laptop share's window.

9. Put the desktop machine's Ethernet cable back the way you found it. Tuck the laptop and cable back under your cloak. Leave the building.
posted by flabdablet at 4:36 AM on September 25, 2006 [1 favorite]

gregschoen: if Joe could boot the machine off a CD-ROM, he wouldn't need the Windows passwords; any modern Linux live CD will read NTFS files without regard for permissions. All he'd need to do in advance is copy the file he wanted to a non-encrypted folder.
posted by flabdablet at 4:41 AM on September 25, 2006

Well a Windows live CD will certainly read NTFS - and might make things a bit easier if you're a Windows man.
posted by ed\26h at 5:00 AM on September 25, 2006

You may not be able to boot off a USB device but I presume that you can write to one. Right?
posted by rdr at 6:08 AM on September 25, 2006

The original question specifies that Joe can neither write to nor boot from USB devices and CD-ROMs.

Joe, can you boot from a floppy? Because if you can, Smart Boot Manager will then allow you to boot from anything else.
posted by flabdablet at 6:34 AM on September 25, 2006

at my university public computers where reimaged quiet frequently, more often than once a week. i dont know if this is a practice at yours school or if you are trying to back up something you downloaded, rather than something that is part of the machines normal set up, but it is worth thinking about.
posted by phil at 6:49 AM on September 25, 2006

Talk to the IT staff. Ask in the context of "I was thinking of X or Y, but I thought I'd ask you if there's an easier way." Once you've impressed them with your intent and Geek-fu, they'll probably swing something simple for you.
posted by mkultra at 7:30 AM on September 25, 2006

Joe in Australia writes "I don't think we were explicitly told that we're not allowed to open computer cases, but it would be obvious and unwelcome."

I'd bet you signed or otherwise agreed to abide by a computer code of conduct when you received your account or paid your fees. The codes are usually written broadly enough that opening a case to install your own hardware on a shared resource machine could result in disciplinary measures. Ours is. Remember that for the most part your university holds all the power. An account suspension while your case is under review may kill your GPA even if you win.

Joe in Australia writes "The computer is secured because it's in a public area at my college. There's a package accessible through those computers that isn't available through the network generally, and I'd like to get the resulting data off the computer without 'breaking the rules'. I guess I'm trying to surreptitiously circumvent the controls because I think that (in this case) they're silly."

I'd take mkultra's advice but be prepared to be thwarted. The restrictions may not be IT's fault or within their power to change. We have a few packages that tie our hands on allowing unlimited access because of vendor licencing restrictions.
posted by Mitheral at 8:17 AM on September 25, 2006

There are some forums that allow file attachments. Perhaps find one that allows 3gb attachments? Probably not possible. Also, popping out the motherboard battery will reset the bios so you can boot from a livecd or something, but that requires a case intrusion.

these kids will send a file via browser for $5.00.
posted by mecran01 at 9:02 AM on September 25, 2006

mecran - Joe's said there's a bandwidth limit per week.

If this is for remotely academic purposes I'd ask a Person of Authority for this computer if you could schedule a time to plug in a USB drive (if you have one) and copy the information off so you can work with it. Someone with administrator access can log in, let you plug in the drive and copy the data, then log back off.

Social engineering is almost always easier and faster than technical solutions.
posted by phearlez at 9:22 AM on September 25, 2006