Jump to content

alpenwasser

Retired Staff
 View Profile  See their activity

  • Posts

    4,129

  • Joined

  • Last visited

 Content Type 

Everything posted by alpenwasser

  1. alpenwasser
    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
  2. alpenwasser
    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
  3. alpenwasser
    @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.
  4. alpenwasser
    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).
  5. alpenwasser
    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.
  6. alpenwasser
    I'm not saying you can't post pics though. You know, for science, or stuffs.
  7. alpenwasser
    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.
  8. alpenwasser
    Well then, it has been fun. Farewell, captain! And welcome Boogieman!
  9. alpenwasser
    Oooh, shiny! Logo came out nice.
  10. alpenwasser
    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.
  11. alpenwasser
    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.
  12. alpenwasser
    Ah, custom water block stuff. Excellent.
  13. alpenwasser
    Haha, alright, sounds good. I'll update the list when you make the new post.
  14. alpenwasser
    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 ).
  15. alpenwasser
    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.
  16. alpenwasser
    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.
  17. alpenwasser
    Okidoki, I've cleaned out some of the more pointless arguing. Please keep in mind that depending on where your'e from and your personality, this question is completely harmless to some and rather loaded for others (as we've seen). We're going to keep this open, but please keep it respectful. You can't handle it... just leave the thread alone and move on. Thanks.
  18. alpenwasser
    Hey folks, Please note that as per the Community Standards, we'd prefer not to have these sorts of general "X vs. Y" threads. They just lead to flamewars too frequently (yeah, I know, such a surprise!). However, since people are actually behaving nicely around here so far, I'm going to keep this one open. It will be locked if things go sideways though. Thanks. Threads which ask specific questions about specific products are fine though, just FYI ("Which of these CPUs/GPUs/hickymadoodads would be more well-suited for task dothethingies?", that sort of thing).
  19. alpenwasser
    I took the original SATA power cable from the PSU, removed the original power connectors and mounted new ones in the needed number and spacing. Bought them from Lutro0's store if I remember right. You can probably pick them up at other modding stores or eBay as well.
  20. alpenwasser
    Oy, Andre, you're still alive! Long time no see. I'm quite liking the A41 to be honest. Can't say much on the rest of the hardware though, I haven't really been keeping up (still rocking my LGA1366 Xeons ).
  21. alpenwasser
    I run 12 SATA drives off a single cable in my server without issues, like so: (Not all drives are connected in that pic, but I've tested it with 12 drives and it works without problems.) What you need to ensure if you want to do this is: 1) Can your PSU deliver enough power on the connector at the right voltages? 2) Can your wires carry the required amount of current? To answer the first question, you can check your drive or your drive's spec sheet, if you can find it. Sometimes manufacturers will indicate max power draw or max current draw. Most of the time I've only seen averages/typical values though, which aren't very useful. I think I've actually measured drives up to 25 W when powering up (it's been a while, don't remember all the details). Only for short amounts of time, of course, but still... Naturally there's a margin of error, power brick losses (it was just a watt meter -> AC/DC converter brick -> drive setup, not inside the computer), but I was pretty astonished. This was a 7,200 rpm desktop drive btw. Just thought I'd mention this. Either way, this: would seem to be the primary issue with this plan. Basically: Yes, you can power 12 drives off a single cable, if your PSU and wires are up to the task. But that cable needs to provide the correct voltages, a PCI-E connector won't do.
  22. alpenwasser
    Jesus, people take this stuff so seriously, one might think it actually matters. Seriously, calm the fuck down folks. No reason to get personal. You want to argue the cons and pros of optical disks vs. HDDs, fine, but either do it like civilized people, or don't do it at all.
  23. alpenwasser
    If you don't spend at least 75% of your yearly salary on your PC and sell one of your kidneys, you are obviously a heretic! More seriously though, I think a lot of people around here (myself included) frequently buy not so much what they need, but what they desire. You are among the more pragmatic folks, nothing really wrong with that.
  24. alpenwasser
    I think my SR-2 cost me about 700 USD back in the day. Then again, it was and still is a board which doesn't really have an equal. Still, not exactly the most pragmatic purchase I've ever made. But I just wanted one, and it is an awesome board, even today (it's about six years old now).
  25. alpenwasser

    .

    alpenwasser replied to soldier_ph's status update on alpenwasser's profile

    Sorry foer d Verzoegerig, ben oeber de Summer ned worklich ome gsih. Aber jo, das esch korrekt.
×