• Content count

  • Joined

  • Last visited


  • check
    Agree 45
  • info_outline
    Informative 36
  • tag_faces
    Funny 14
  • thumb_up
    Thumbs Up 47
  • thumb_up
    Likes (Old) 3515


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

12,146 profile views
  1. 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
  2. @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.
  3. Fundamentally, yes. See: 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).
  4. 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.
  5. I'm not saying you can't post pics though. You know, for science, or stuffs.
  6. 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.
  7. Well then, it has been fun. Farewell, captain! And welcome Boogieman!
  8. Oooh, shiny! Logo came out nice.
  9. 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.
  10. 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.
  11. Ah, custom water block stuff. Excellent.
  12. Haha, alright, sounds good. I'll update the list when you make the new post.
  13. Leaving the manufacturing aside: If you want to understand how a CPU functions, I recommend trying to understand the following concepts: - Transistors - Field-Effect Transistors - Metal-Oxide Field-Effect Transistors (those would be those famed MOSFETs we keep hearing about, although the ones in your CPU are obviously not the same as the ones in the power delivery system) - CMOS technology Once you have a rough grasp of how CMOS works, you can start trying to understand some basic CMOS circuits (inverters, AND gates, NAND gates, see here for a bunch of examples). A CPU is basically that, just very much more complicated (billions of transistors instead of just a few). If you want to really understand the details behind the manufacturing process, Analog Integrated Circuit Design by Tony Chan Carusone et al. is a pretty good book (very expensive though, but I'm sure you can find a pdf somewhere around the web ). It has pretty detailed information about the physics behind it all, though it's obviously pretty complicated (I'm currently trying to get through a course on the subject and getting my ass kicked, might have to take it again ).
  14. Primarily to simplify things (though some people have such a hodgepodge of drives it can still be pretty time-consuming to enter their config into the system). But yes, it is of course completely arbitrary.
  15. Alrighty then, time for an update! Note: The list of noteworthy builds will now also hold the decommissioned builds. @MyNameIsNicola Updated. I hope I got it right, so many drives. @scottyseng Updated @maxtch Added your second system, updated your first one. @b3nno Added system to list. Nice box! @Jonny Updated. @Ziggidy Nope, rankings are not dead, but yes, it does usually take me a while to get around to them. Added your system to the list. Thanks for the entry! @username6465 Updated. @leadeater Answered your question in chat already, but just for public info: We'd count each system in a clustered file system as a single entry, if it qualified for the list. @FattyDave Added your system to the list. Thanks! @{EAC} Shoot em UP Added your new system to the list, relegated the old one to the secondary list (no, we don't delete posts). The pics in your new post seem to be broken though! As for the noise: I put noise dampening material into our server, it actually made quite a difference. Wasn't cheap though. @unijab Added your new system, moved old one to secondary list. @kerradeph Added system to list. Very neat. It would also appear that there are a few entries which I've overlooked. The thread seems to be becoming a bit unwieldy, I'm going to think a bit if I can come up with a solution for that. Wouldn't want this to keep happening. Apologies to everyone below. @paps511 Added. @brwainer Fixed that and added to list. Apologies. @weeandykidd Overlooked your last update, fixed that as well. @Ramaddil Updated. Lastly: @Bhav If you post the rest of the system info as per @looney's template, that seems like it would qualify for the list. @saitir Obviously we won't be starting to add work systems to the rankings (would be a bit unfair), but that does sound pretty neat, so if you ever do get a hold of some pictures... wouldn't mind seeing those.