the lithiums have made impressive strides in energy density, outpacing your Trojans by a fair bit
that said, and I am quite aware of the dangers inherent in H2SO4, if I had one of those power walls it would be installed in an airtight bunker some distance from the dwelling...
when lithium decides to do the bad, it is really bad
True. For a house system weight and energy density aren't as big a problem as in a car (where you have to like move it). So L16 or T105 batteries can get you a lot of power for a reasonable price without the major fire problem of lithiums. As for hydrogen I've never seen issues with lead, however I guy I knew did blow the bed off his battery powered truck with flooded NiCD batteries. Those last forever but really can gas hydrogen on charge. Oh well. 100ah AGM batteries are quite nice as well but a bit more pricey per AH. Any way you go, you need to figure out how much power you need per day, then build your solar panels to put that much power back in 1/2 day (factoring in cloudy days) with a battery capacity of at least 3-4 times your load for rainy days and the like. Thus if you want to run the fridge (200 watts*24=4.8kw) some lights (about 1kw a day) and a toaster (1,500 watts for an hour a day) you're at 7kw. Thus a 28kw battery pack and 14kw of solar will do it. Assuming 5 hours of sun per day (and you factored in the 2x oversize for solar) and you're talking a ~2kw array and if the batteries are 48v then a 500ah battery pack or 16 T105's. Takes more power than you think. Thanks for the info. But you have a unit problem. Watts != Watt-Hours |
|
|
|
These days, I'm happiest with a MacBook Pro keyboard. Go figure.
Really? I have a 2017 Macbook Pro with the butterfly keyboard and it drives me nuts! Its constantly sticking and encouraging me to use excessive amounts of profanity and hit it with a hammer! My last MBP butterfly keyboard started double-striking. Plus, I noticed the case was getting thicker - which I presumed was a battery bulge issue. I took it in to get looked at, and Apple decided they’d just swap it for new 16”. Across the board. After they made that offer, I asked if I could pay the diff between the price of the system that they offered, and what I wanted, and they said yeah. 2.4GHz 5G Turbo 8-core i9 64 GB Mem Upgraded graphics with 8GB VRAM 4 TB SSD. Not too shabby. AppleCare FTW. Apple doesn’t seem to make stuff that is less failure-prone than other top tier vendors, but they stand behind the product. |
|
|
|
(Run your own DNS servers ffs)
Intriguing. I always pictured being a DNS server would require industrial grade infrastructure. Do you run a DNS server? HEY! Maybe my Namecoin will be worth something someday.  you don't have industrial grade infrastructure? I am but a simple hodler. My meager amount of industrial grade infrastructure (such as it is) is dedicated to other things. |
|
|
|
+1 I've been with them last 10 months, nice service IMO. good speeds, great privacy, plenty of hosts to choose from. $80 VALUE paid in BTC per year. 5 devices, monthly updates. Although I can't compare with many others, this is my first paid experience. That's cool and all, but what makes you confident that they are not a honeypot? Seems to me that running VPNs under cloak of shell corporations would be a high priority for prying eyes. |
|
|
|
I keep an 8 inch floppy disk at my desk, beside my 5 pound IBM Model M keyboard. Winderrs keys are for losers! The Model M is a daily driver, the 8 inch floppy is just a momento.
I used to love the heavy click in the keys of an IBM 5250 terminal. These days, I'm happiest with a MacBook Pro keyboard. Go figure. I do still have an old IBM keyboard with the heavy click and the DIN connector lying about somewheres. |
|
|
|
(Run your own DNS servers ffs)
Intriguing. I always pictured being a DNS server would require industrial grade infrastructure. Do you run a DNS server? HEY! Maybe my Namecoin will be worth something someday. |
|
|
|
Indeed, I’ve shipped devices that provided canned boot sector data before - not as an exploit, but because the operating environment needed such in order to function. Of course, that was a ‘from the factory’ thing, not a field exploit. Yeah, that's exactly what THEY wanted you to believe  Just kidding. Or maybe not... Was that "canned boot" somehow easily replaceable with a different one afterwards? Ie: the canned boot residing in another area of the HD which could be updated or using a custom tool? Or just reusing all the developed firmware, replacing the "canned boot" and generating the payloaded firmware? Well, the canonical example would be to package a disk with a 'paddle card' protocol converter which sits between the drive and the system's SCSI | ATA | Fibre Channel | 1553 | Ethernet | InfiniBand | whatever bus. The canned boot sector would be resident in the FW of the paddle card. Used for things such as allowing contemporary HDDs to be used as boot devices on legacy systems built before the dawn of large HDDs. Yeah, well, THAT doesn't look like it would be so easily repurposed for malicious intents. But anyways, the point stands, not only it is theoretically possible but also psycodad has provided some links that would suggest it being exploited in the wild.. even if rare and requiring the exceptional talents and resources of the Equation Group (the malwaretech PoC was not even close). Also note that the malwaretech blog required one solder or otherwise affix a JTAG interface to the drive's PCB. And that it described -- in 2015 -- hacking 'an old drive' - which would precede the era of signature protected FW. Though admittedly, the JTAG exploit could sidestep the FW signature difficulty. From psychodad's quoted article on the NSA: The attack works because firmware was never designed with security in mind. Hard disk makers don't cryptographically sign the firmware they install on drives the way software vendors do. Nor do hard drive disk designs have authentication built in to check for signed firmware. ^^^Obsolete info. Again, (most? all?) contemporary drives do indeed implement FW signature schemes preventing installation of unauthorized FW. Then again, if my past employers had some backdoor agreement with the NSA, I'd likely not know about it. |
|
|
|
Indeed, I’ve shipped devices that provided canned boot sector data before - not as an exploit, but because the operating environment needed such in order to function. Of course, that was a ‘from the factory’ thing, not a field exploit. Yeah, that's exactly what THEY wanted you to believe Just kidding. Or maybe not... Was that "canned boot" somehow easily replaceable with a different one afterwards? Ie: the canned boot residing in another area of the HD which could be updated or using a custom tool? Or just reusing all the developed firmware, replacing the "canned boot" and generating the payloaded firmware? Well, the canonical example would be to package a disk with a 'paddle card' protocol converter which sits between the drive and the system's SCSI | ATA | Fibre Channel | 1553 | Ethernet | InfiniBand | whatever bus. The canned boot sector would be resident in the FW of the paddle card. Used for things such as allowing contemporary HDDs to be used as boot devices on legacy systems built before the dawn of large HDDs. |
|
|
|
CP/M here i come (again). RS232 and a terminal emulator is all i need. stocking up on 8" and 5 1/4" floppies now
I really regret not keeping my Osbourne...like really I still own a pair of (working) Compaq 'sewing machine' 8088-based PC clones. DOS on floppy, store to floppy. Woo-hoo! |
|
|
|
since when?
people write custom BIOS for older stuff all the time
not being snarky, really want to know
To lightfoot's point, I don't doubt that contemporary BIOSs are typically protected by such crypto signature schemes. I used the BIOS example as but one of many possible malware vectors that one exposes themself to, should they be in the habit of investigating various random found USB devices. And more specifically, one that completely sidesteps any filesystem-dependent countermeasures, which some seem to (erroneously) feel is sufficient to protect themselves. |
|
|
|
Most linux distributions can be run on read-only filesystems (same as from cd) BUT the only true security hole is running them as root, because volumes can be remounted in rw mode on the fly. I'm using this strategy on my raspberryPi that is running the game console emulators for the kids. They don't do no shutdown, they just pull the plug/wallwart. Roms are stored on etx4 USB, mounted read-only. This one is just mounted in rw mode on the PC, to manage the roms and emulator binaries.
Just make sure you run linux as unprivileged user. Privilege escalation is a thing though, but unlikely on patched systems. However, when you're not connected to the net, i doubt there is a fair chance of catching a successful exploit via USB.
Again, your postulated security described above is utterly dependent upon the rando USB device implementing only a storage class endpoint. Whatevs. Good luck with that. I would care less if i am running as unpriv. user on a system that is not network connected. I didn't mention that i'd never use a host with actual user data on it. I thought that would be clear because i was replying to Dabs' "frozen sysimage" approach. I would definitely not use a guest VM but a dedicated box that i can reset via dd or similar disc imaging tools, i wasn't clear on that, as i just recognize while typing this. And yes, it's part of the very basics: there is no 100% security, only 100% security against certain (and therefor known) attack vectors. I’m gonna say this one last time. Your postulated recovery is weaksauce against anything other than a disk-resident vector. dd ain’t gonna do nothing for you if malware-containing USB infects the BIOS. my bios has a reset to default button for times it all goes wrong. dont conflate things to 2 options when there are many more possibilities I am not limiting things to two options. I am merely pointing out a single issue with the postulated ‘presumed safe’ activity. Perhaps one of many. I’ll leave it as an exercise to the reader to prove that there is no way for malware to futz with the ‘safe copy’ of the BIOS that could overwrite the other. (Hint: as if) |
|
|
|
Most linux distributions can be run on read-only filesystems (same as from cd) BUT the only true security hole is running them as root, because volumes can be remounted in rw mode on the fly. I'm using this strategy on my raspberryPi that is running the game console emulators for the kids. They don't do no shutdown, they just pull the plug/wallwart. Roms are stored on etx4 USB, mounted read-only. This one is just mounted in rw mode on the PC, to manage the roms and emulator binaries.
Just make sure you run linux as unprivileged user. Privilege escalation is a thing though, but unlikely on patched systems. However, when you're not connected to the net, i doubt there is a fair chance of catching a successful exploit via USB.
Again, your postulated security described above is utterly dependent upon the rando USB device implementing only a storage class endpoint. Whatevs. Good luck with that. I would care less if i am running as unpriv. user on a system that is not network connected. I didn't mention that i'd never use a host with actual user data on it. I thought that would be clear because i was replying to Dabs' "frozen sysimage" approach. I would definitely not use a guest VM but a dedicated box that i can reset via dd or similar disc imaging tools, i wasn't clear on that, as i just recognize while typing this. And yes, it's part of the very basics: there is no 100% security, only 100% security against certain (and therefor known) attack vectors. I’m gonna say this one last time. Your postulated recovery is weaksauce against anything other than a disk-resident vector. dd ain’t gonna do nothing for you if malware-containing USB infects the BIOS. Forget about badUSB/badBIOS as it has already been perfectly documented and evidenced... Maybe you are the right person to ask this, depending on how low level your work or knowledge goes... I have always thought another theoretical attack vector would be in the HD firmware from which it would be possible to on-the-fly replace a call to the boot sector adding some payload to it. I still think so but... have you ever seen any real practical example/exploit of that? Even as a PoC "lab test"? Well, if you can program new drive FW, and you can get it programmed into the drive’s FW store, then yes - that would be trivial. Indeed, I’ve shipped devices that provided canned boot sector data before - not as an exploit, but because the operating environment needed such in order to function. Of course, that was a ‘from the factory’ thing, not a field exploit. However, drive FW development is non-trivial. Embedded computers without public data on memory maps, peripheral specs, etc. Nonstandard SoCs, built on various ISAs, dependent upon lots of in-house developed tools. Very difficult. Albeit doable in theory. However^2, most (all?) contemporary drives will not load FW that does not have a valid crypto signature. I have never heard of any case of a successful exploit of a drive’s FW sig being cracked. Though drive companies are just collections of people, and some people in the chain of custody for the root certs may not fully understand their responsibilities. I could see the possibility of a leak of keys happening some day by some vendor or another. At which point, such an exploit again becomes plausible. |
|
|
|
Right, it’s low enough now. Logging onto laptop to buy 0.5BTC.
Thank you for your service. I’ve bought 4 BTC so far this week. Because incremental ladder trading. Wow, 4 whole coins this week. You wrote btc - as in bitcoin, with no other qualifiers. If I got it right, there goes a little haiku for you. That's just, like, you know five days and a weekend, man Congratulations! Yes, BTC. Just buying back the coins I sold (for more USD) on the way up. Incremental laddered standing orders FTW. Good breher is getting some sense.... now forget the worthless forks and be a true coiner in its purest form once again! What? I’ve been buying (and selling) BTC in laddered incremental standing orders since years. Nonstop. Bought yet another 1 BTC earlier today. Because that’s what the strategy calls for. Nonstop. Incidentally, these buys were not funded via sells of BCH, BSV, nor any other coin. They’re on their own ladders. Because that’s what the strategy calls for. |
|
|
|
Most linux distributions can be run on read-only filesystems (same as from cd) BUT the only true security hole is running them as root, because volumes can be remounted in rw mode on the fly. I'm using this strategy on my raspberryPi that is running the game console emulators for the kids. They don't do no shutdown, they just pull the plug/wallwart. Roms are stored on etx4 USB, mounted read-only. This one is just mounted in rw mode on the PC, to manage the roms and emulator binaries.
Just make sure you run linux as unprivileged user. Privilege escalation is a thing though, but unlikely on patched systems. However, when you're not connected to the net, i doubt there is a fair chance of catching a successful exploit via USB.
Again, your postulated security described above is utterly dependent upon the rando USB device implementing only a storage class endpoint. Whatevs. Good luck with that. I would care less if i am running as unpriv. user on a system that is not network connected. I didn't mention that i'd never use a host with actual user data on it. I thought that would be clear because i was replying to Dabs' "frozen sysimage" approach. I would definitely not use a guest VM but a dedicated box that i can reset via dd or similar disc imaging tools, i wasn't clear on that, as i just recognize while typing this. And yes, it's part of the very basics: there is no 100% security, only 100% security against certain (and therefor known) attack vectors. I’m gonna say this one last time. Your postulated recovery is weaksauce against anything other than a disk-resident vector. dd ain’t gonna do nothing for you if malware-containing USB infects the BIOS. |
|
|
|
How can mounting a USB stick on an AutoRun-disabled VM affect your host's BIOS? Honest question, I want to know.
Don’t lost track of the fact that USB is an acronym for Universal Serial Bus. That device could contain any number of USB endpoints, each implementing a different device class. What if one of the endpoints identifies as a Human Interface Device — for example a keyboard — and injects a number of commands to the system? From the users perspective, invisibly. Or even deeper, a bridge device, giving it access to the underlying I2C bus - maybe even the SMB? Yeah, but who is going to maintain the discipline required to ensure any potential infection does not spread from the separate PC to others in your stable? There is the Yubikey which types for you like a USB keyboard. There is that Rubber Ducky, which types like a USB keyboard and can type like it was there at 100 words per second or something as fast as a keyboard will accept, such as Windows-R, CMD, and do any number of commands from the command prompt. https://shop.hak5.org/products/usb-rubber-ducky-deluxeAs for virgin clean PC's, I used to (and still do) use something called Deep Freeze, reboot to restore thing. If the host computer it's installed on gets infected, before it can propagate any problems to the rest of the network (assuming you disconnected it physically from the rest of the network), you just reboot, and it's back as new, as if it was never updated. Most malware is unaware of it's existence. It's great for setting up kiosks that provide internet access through regular browsers. At the end of the session, reboot, it's back to the way it was. If you need to update anything, reboot, turn it off, update, reboot, and it will stay that way. In theory, it can still be hacked, but in practice it's as if the whole computer is one giant VM. Reboot, and it's back to the way it was yesterday. If you need to save data or files or documents, you save them on a different drive or partition or folder designated as such. But the rest of the OS, reboot, and it goes back to the way it was. Most linux distributions can be run on read-only filesystems (same as from cd) BUT the only true security hole is running them as root, because volumes can be remounted in rw mode on the fly. I'm using this strategy on my raspberryPi that is running the game console emulators for the kids. They don't do no shutdown, they just pull the plug/wallwart. Roms are stored on etx4 USB, mounted read-only. This one is just mounted in rw mode on the PC, to manage the roms and emulator binaries. Just make sure you run linux as unprivileged user. Privilege escalation is a thing though, but unlikely on patched systems. However, when you're not connected to the net, i doubt there is a fair chance of catching a successful exploit via USB. Again, your postulated security described above is utterly dependent upon the rando USB device implementing only a storage class endpoint. Whatevs. Good luck with that. |
|
|
|
Right, it’s low enough now. Logging onto laptop to buy 0.5BTC.
Thank you for your service. I’ve bought 4 BTC so far this week. Because incremental ladder trading. Wow, 4 whole coins this week. You wrote btc - as in bitcoin, with no other qualifiers. If I got it right, there goes a little haiku for you. That's just, like, you know five days and a weekend, man Congratulations! Yes, BTC. Just buying back the coins I sold (for more USD) on the way up. Incremental laddered standing orders FTW. |
|
|
|
As for virgin clean PC's, I used to (and still do) use something called Deep Freeze, reboot to restore thing. If the host computer it's installed on gets infected, before it can propagate any problems to the rest of the network (assuming you disconnected it physically from the rest of the network), you just reboot, and it's back as new, as if it was never updated.
Does your ‘reboot’ re-flash the BIOS with a known-good image? Probably not. Even if so, what ensures that supposedly ‘known-good’ image has not itself been corrupted by the malware? Again. There is NO perfect security. |
|
|
|
When I want to read a "dangerous" USB stick, I launch my "test VM" in VMware and mount it there. AutoRun is disabled on both the host and the guest OS. Never had any issues in 25 years of Windows computing.
How can mounting a USB stick on an AutoRun-disabled VM affect your host's BIOS? Honest question, I want to know.
Well, I must admit that I don’t know all the possible attack vectors. But as one potentially eye-opening matter, your example of ‘AutoRun’ indicates you are assuming that the device identifies only as a storage class device, and that said storage device contains only a filesystem that is know to Windows. Don’t lost track of the fact that USB is an acronym for Universal Serial Bus. That device could contain any number of USB endpoints, each implementing a different device class. What if one of the endpoints identifies as a Human Interface Device — for example a keyboard — and injects a number of commands to the system? From the users perspective, invisibly. Or even deeper, a bridge device, giving it access to the underlying I2C bus - maybe even the SMB? What you're saying makes sense, I did assume that we were talking about a storage class device. I admit I wasn't aware of the "BadUSB" exploit. Will look it up, thanks for this. I guess I was lucky enough to not receive a "BadUSB" device (or maybe I did, and not aware of it?). As others have pointed out, the best option is a separate, clean PC, with everything sanitized after use by restoring from known, clean images. @jojo69, @xyzzy099, @vapourminer, also thanks -- merited. Yeah, but who is going to maintain the discipline required to ensure any potential infection does not spread from the separate PC to others in your stable? What does your sanitization consist of? Just filesystem drive? Just disk? How do you know you’ve not been victim of a BIOS hack, which is unlikely to be recovered from, and may propagate to other machines if you are not careful never to use same storage device between machines. In the end, there is no perfect security. This is true. It is all a tradeoff. I guess all I’d like to advocate for are: have some idea of the risks, and; I doubt the proabability of finding satoshi’s private keys on some rando USB device found in the street is anywhere near the probability of falling victim to a simple intentional exploit. |
|
|
|
Btw last time we past Vegeta we went up pretty fast, remember Vegeta is an iconic character with some real dragon ball Z powers.... One that doesn't let himself to be taken easily... Never saw the episodes? The guy is extremely powerful, probably BTC will be the only one to truly defeat him, time will tell when.
Wait... what? Now, I never was much interested in Dragon Ball Z, but my kid used to watch it all the time, so I’ve been exposed. Accordingly, I may be laboring under a misconception. But... My understanding is that it is not Vegeta whose power is over 9000. Rather, Vegeta is describing the power of some other character. No? Correct https://www.youtube.com/watch?v=eT7u8R2d8hc / https://www.youtube.com/watch?v=17zNW-wz35E (dont click if you have epiletic seizures  ) Goku he is the one on my hat for reference. And to keep it stable. Someone suggested it being him in his Ultra Instinct blue.  We need another hero to emerge for $10,000! Maybe the Hoff?  https://www.youtube.com/watch?v=ZTidn2dBYbY David Hasselhoff - True Survivor from Kung Fury... "hear the ticking of the countdown clocks tonight" "We need some action, if we want to take our love from here!" " The phoenix rises again!" Haha. That’s spectacular. Never seen that before - thanks. By some odd conincidence, last night was the first time I became aware of this: https://www.youtube.com/watch?v=3MMMe1drnZYDip? In these times of hardship, always remember. We. Are. Groot. |
|
|
|
Exactly. I always do this, and also use VM to test-drive apps before installing on my main (host) PC. No viruses, no malware, no corruptions, no problems!
Edit: ...and always disable AutoRun after a Windows installation.
Always do ... what? Always attach found USB to a computer running Knoppix from write-only media? Always attach found USB to a computer running a VM? Always attach found USB to a computer running Knoppix from write-only media within a VM? Great. What protects your BIOS/FW? What protects your hypervisor? When I want to read a "dangerous" USB stick, I launch my "test VM" in VMware and mount it there. AutoRun is disabled on both the host and the guest OS. Never had any issues in 25 years of Windows computing. How can mounting a USB stick on an AutoRun-disabled VM affect your host's BIOS? Honest question, I want to know. Well, I must admit that I don’t know all the possible attack vectors. But as one potentially eye-opening matter, your example of ‘AutoRun’ indicates you are assuming that the device identifies only as a storage class device, and that said storage device contains only a filesystem that is know to Windows. Don’t lost track of the fact that USB is an acronym for Universal Serial Bus. That device could contain any number of USB endpoints, each implementing a different device class. What if one of the endpoints identifies as a Human Interface Device — for example a keyboard — and injects a number of commands to the system? From the users perspective, invisibly. Or even deeper, a bridge device, giving it access to the underlying I2C bus - maybe even the SMB? |
|
|
|
|
Show Posts
