Jump to content


  • Content count

  • Joined

  • Last visited


About alpenwasser

  • Title
    2CPU Enthusiast


  • CPU
    2 × Intel Xeon X5680 (6C/12T per CPU), 3.33 GHz
  • Motherboard
    EVGA SR-2
  • RAM
    24 GB Corsair Dominators 1866 MHz
  • GPU
    GTX Titan & GTX 780
  • Case
    Caselabs SMH10
  • Storage
    40-ish TB server w/ ZFS
  • PSU
    Enermax Platimax 1200 W
  • Display(s)
    Dell 24" 1920x1200
  • Cooling
    2 × XSPC Raystorm Copper, MIPS block for EVGA SR-2, 2 × Aquacomputer Titan, 2 × HWLabs SR-1 560 mm, 2 × Alphacool Dominator RAM blocks, 2 × D5, 1 × Alphacool XT45 480 mm, Aquacomputer Aqualis
  • Keyboard
    QPAD MK85 w/ Cherry Blues
  • Mouse
    Wacom Intuos
  • Sound
  • Operating System
    Arch Linux

Contact Methods

Profile Information

  • Gender
  • Location
  • Interests
    all things mechanical, PC's, Unixes, hiking, camping, history, paleontology, biology, movies
  • Biography
    born (1985) -> school -> army (Lt, Infantry) -> work (logistics, web dev) -> college
  • Occupation
    College Student (Electrical Engineering & Information Technology)

Recent Profile Visitors

15,502 profile views
  1. what







    1. EvanTech




      Title PSU Mod on evantechtips.com


      I'm done upgrading, and although I lost all data during the transfer, but I kinda think it was worth it because the UI is so much better, and there is an S after the evan in my domain.

      -Evan, ETT Admin

    2. JDE



      looks good


      signing up

  2. LTT Storage Rankings

    Just thought I'd give a quick status update: I have been terribly busy with offline life; working on my thesis and all that good stuff, so I basically haven't been around at all. Lectures will be finished by mid-June though, so I will have some breathing room again at that point and will trawl through the thread and update it at the latest in a few weeks. Thanks for your patience, and sorry for the delays. Cheers, aw
  3. dvds: md5sum/ sha256: represent all data?

    Well, I already went into this in my above posts: I recommend reading up on the various CD and DVD standards. If you want to be sure about this, you will need to truly, properly understand those standards, or more precisely: How data is written to, stored on and retrieved from the disks. And no, I've not done this, because I no longer have an optical drive anywhere. But when in doubt, always go to the primary source. Also, as said: If your burner/reader has a compromised firmware, then it can do pretty much whatever it wants without you noticing. When you burn the disk, it can embed a payload without telling you, and then when you read the disk (in the same drive, of course), it can ignore the payload and only give you the data you think should be there (thus giving you a correct checksum), while doing something else with the payload. This would probably no longer work on a drive with a clean firmware (again, depending on how the standard is implemented). How the firmware gets infected is another question though. So, if you cannot trust your burner, then you're screwed. Do you generate these iso files locally, or do you download them? As a starting point, I'd suggest reading up on some of this stuff, and then maybe go from there (copied from Wikipedia): SFF ATAPI/MMC Mount Rainier (packet writing) Mount Fuji (layer jump recording) Rainbow Books File systems ISO 9660 Joliet Romeo Rock Ridge / SUSP El Torito Apple ISO 9660 Extensions Universal Disk Format (UDF) ISO 13490
  4. dvds: md5sum/ sha256: represent all data?

    @Alir Alright, I let the md5 collision generator run over night, results are as follows: For a 15 kilobyte input file, it took 36 minutes to generate the hash collision. For 33 megabyte input file, it took 3 hours and 40 minutes. Granted, this is just one way to generate MD5 collisions; maybe there are faster ones out there. But at least based on these results, if the iso you downloaded was clean, infecting it and generating the data needed to generate a hash collision locally on your machine does not really seem practical to me, because iso files tend to be significantly larger than the files I tested with, so the malware would likely need several days to do its work, at which point you'd have already burnt the disk I presume. The software could probably be optimized some more to make it faster. It only runs on a single core at the moment. But if you allow it to utilize more cores, I would expect that you as a suspicious and paranoid user would notice that your machine is suddenly being heavily loaded with some software which you don't know. Heck, even if it's allowed to load a single core to the max, that would already make me very suspicious (I tend to keep a close eye on CPU usage in general). So if the malware wanted to do its work undetected, it would need to throttle CPU usage quite a lot, at which point it might take weeks to infect a CD-ROM-sized iso file and generate the appropriate hash collision data.
  5. dvds: md5sum/ sha256: represent all data?

    Fundamentally, yes. See: http://www.mscs.dal.ca/~selinger/md5collision/ But: Assuming your initial iso file is clean, I'm not sure how practical it is for a malware to infect it on your machine. Attacks using hash collisions which I've read about so far were written with specific files in mind, files which were known to the attacker at the time when the malware was written (if I'm wrong, feel free to correct me). As @mariushm said, this step can take hours to days, depending on the files (for MD5, that is). This is no problem when you write a malware for a known iso, then send it onto its way via its attack vector. But: If your initial iso is clean, but the malware is instead locally on your machine and targets the iso, this seems to become significantly less practical for an attacker. They would have to run all those calculations locally on your machine. If they want that done fast, they will use lots of resources, which would mean you would suddenly see your CPU usage spike, thus (hopefully) becoming suspicious. And even if you don't notice, if that takes several hours, you'll probably have burnt the image to disk before the malware has done its job. And if they try to be stealthy and run with low CPU usage, the chances of you burning the iso before they're done become even higher. There's an example program for creating MD5 hash collisions on the website I linked above. I'm currently running it with a very small example, and that seems to be taking about half an hour (20% done after six minutes). I'm curious to see how it scales with bigger files; will report back once that's done (might take a few hours though). If it doesn't matter much how big the file is, the problem is much bigger than if it takes longer for big files (since iso files tend to be pretty sizeable and my first test program was only a few kilobytes).
  6. dvds: md5sum/ sha256: represent all data?

    Ah, so your basic concern is: Download iso Verify w/ checksum. iso is clean (as said, this could already be unreliable if the website has been compromised and a false checksum provided) Malware which is already somewhere on your computer injects a payload into the iso after you have checksummed it You then burn that compromised iso to a disk You do a checksum of the entire disk, but it shows up with the same checksum as originally because the malware payload is somewhere which you can't access on the disk This seems difficult, but not entirely impossible at first glance (again, disclaimer: I'm no security expert). The difference between an optical disk and a USB drive is that a USB drive actually has firmware (which, as you rightly point out, can be compromised). An optical disk doesn't really have that, it just carries data and metadata as far as I know. But: your optical drive of course has firmware. And theoretically, that firmware could be compromised, though I'm not sure how difficult that would be. Absolute security doesn't really exist. There will come a point at which you will have to say "Alright, this is good enough.", unless you intend to re-design a CPU from scratch, along with everything else in your PC (it's just as possible that your hardware is compromised, after all, if we're being truly paranoid; what if there's a backdoor in our networking chips?). For this particular problem, if you wanted to be about as sure as you can reasonably get, I would recommend reading up on the various CD and DVD standards from reliable sources, see how the data is stored on those optical media, and whether or not this would provide an opportunity to inject a payload in an undetectable manner.
  7. LTT Storage Rankings

    I'm not saying you can't post pics though. You know, for science, or stuffs.
  8. dvds: md5sum/ sha256: represent all data?

    Just to be sure I understand your question right: Are you asking if an install medium image you can download from a linux distro site can be compromised? Or just any old sort of data? In the case of install media: It depends a bit on the source of your image and reference checksum. If the install medium can be compromised, it's not entirely unlikely that the website has been compromised as well (after all, how else does a malicious party upload a compromised image onto the server in the first place?), in which case they can just supply you with the "correct" checksum for the compromised image. You grab the image, you checksum it, you compare with the reference, you think it's all good, and you're screwed. In general, if you want two different files to have the same hash (called a hash collision), you'll need to: create your malicious payload embed it into the image you want to compromise make sure that the image with the payload has the same checksum as the image by itself Particularly the last step can get tricky, though it's not impossible. It depends a bit on the hash; MD5 is comparatively weak and hash collisions have been demonstrated if I remember right (haven't read up on it in a while, sorry). Other hash algorithms like SHA1 (used by git) or better are more difficult. However, getting that hash collision is still not impossible, just pretty difficult. If the last step fails, and you have the checksum for the clean file, you will notice the corruption. Otherwise, your'e shit-out-of-luck. The only way to really be sure that you're not installing anything compromised on your system is to download the source code and manually review it (a practical impossibility, of course) before compiling. Checksums are useful for making sure that your download went fine and your image hasn't been downloaded incompletely or corrupted through the download process, or, if you feel so inclined, to verify the integrity of the data on your HDD (ZFS uses checksums internally for that), but it's no means to ensure perfect security IMHO (which doesn't exist anyway). I'm not a security expert though, could be that I've overlooked something. But this is what comes to mind off the top of my head.
  9. Time for me to say goodbye

    Well then, it has been fun. Farewell, captain! And welcome Boogieman!
  10. Old school TJ07 Project

    Oooh, shiny! Logo came out nice.
  11. Buying a server rack

    Assuming you're talking about 19" racks: The 19" standard doesn't really define the outer dimensions of the rack cabinet, which is how you end up with different widths. Around here, the common widths you can easily buy are 600mm and 750mm, with the latter offering more space for cable routing (useful if your cables are stiff and you don't want to violate their minimum bend radius, for example). 600mm offerings are more common here though (might be different in other markets). Other things like depth, hole shape and such have already been mentioned. Since information on server-grade equipment is often hard to come buy on the internet, I have often resorted to reading the documentation/user manuals of manufacturers for getting a better impression of a product's capabilities and characteristics. APC make quite a few racks, it might be worth just picking a bunch at random and having a look at their user manuals, for example this one.
  12. Project Forged: Handforged computercase

    Sadly, I have but one upvote to give per post, but I would give more if I could! Well, at least not without gaming the system, but our overlords would probably revoke my database privileges for such shenanigans.
  13. M.2 SSD Waterblock

    Ah, custom water block stuff. Excellent.
  14. LTT Storage Rankings

    Haha, alright, sounds good. I'll update the list when you make the new post.