What kind of idiot would buy a cell phone with a non-replaceable battery? That would be even more stupid than if it had a proprietary data-cable port. Nobody in their right mind would but such a crippled device.
Apple Customers....did you see the original iPod? They've never had replaceable batteries. Now others (f.e. Google) are following with their high-end lines (Nexus since Nexus5 phone and Nexus 7 tablet).
i remodeled his house in seattle before i went to school and got a phd in physics. i spent a lot of time with him. he's not an asshole at all. in fact, he's pretty much like on his show, just a bit more real. not arrogant. not full of shit.
Nye, is that you?
A friend of mine suggested such an idea to me 15 years ago. This is what I told him.
You run it inside an x86 interpreter which simulates the CPU all the way through the decryption. Then you snapshot the decrypted code and rebuild the app without the decryption and substitute the decrypted code. Now it's just a plain app. If it tries to "detect it's environment" (read the clock, etc), the simulator just tells it whatever it wants to hear. It cannot know it's being simulated, it's just code.
In a sense, that is exactly what Bochs is. It's a true Virtual Machine in that it software interprets every CPU instruction, and emulates every piece of connected hardware - RAM, motherboard, video, network, usb, chipsets, etc - to do so. A truely fine tool for OS and hardware developers.
Yep that trick totally evaded me... I don't doubt that would work fine though.
Now.. what about if it had to be connected to the internet to validate the installation at startup >:W
And the server had to give it's response in a reasonable amount of time ie 100ms and you couldn't fake it on the PC due to encryption. Now I don't doubt that could be broken but it would be a tad harder at least perhaps
Until you have someone that has a slow internet connection, f.e sat-com where latencies are typically around 500ms or worse. A poor network, or bad mix of equipment, can make latencies really bad even on an otherwise good network.
For example, my Dell D600 from 2003 had a Broadcom networking chipset in it. The 1GBit interface had a problem with some Cisco routers. The previous routers it was on were 10/100 and it had no issue; but when they upgraded the router to 10/100/1000 the new router had an issue with the auto-negotiation. Until I figured that out, the network speed when from 100 megaibts to 17 kilobits. Outlook generally worked okay (no choice at that company) but anything that made more use of the network had big issues. (Outlook worked to view what was in my inbox, because of the small messages; but even then it was slow).
So even doing something like that would be risky - of course, you could also just capture the network traffic and hack that too; since you can control the network in Bochs, if you were really going that far it wouldn't be an issue to capture and adjust it as required to make it think it was talking to the real thing. This is actually relatively easy:
compare the deltas to figure out what is changing
Now you just setup a server to either play back the captured data, making the emulated system think it is running at that point when the older software did, or if you figured out enough of the traffic setup something to fake the other side in a way you control.
FYI - this is how SaMBa got started (at least for Windows compatibility) - network analysis of CIFS/SMB traffic with Windows. They found some interesting things doing so - read their docs for things like single-bit flip reboots the Windows computer kind of stuff.
There's very little that cannot be cracked in this regard.
That's utterly ridiculous. There's a lot more to an OS than just the desktop environment (DE): there's the kernel, the init system and other low-level daemons, the display subsystem, the package manager, and of course lots of apps (beyond just what KDE (or Gnome) include in their software collections). The KDE team has enough work to do, they certainly don't want to become their own distro, when there's already several distros that feature KDE as a prominent DE (Mint, Debian, OpenSUSE for starters).
You do realize that KDE is maintained on more than just Linux - including BSDs, Unix, Mac, and even *gasp* Windows. Some ports (like the Windows port) are not as far along as the others - well, pretty much just the Windows port last I checked, and that's primarily because of Windows not having some of the requisite functionality yet.
I'd avoid SVN for anything that isn't a flat text file, otherwise it becomes a pain to merge or determine what the actual difference between two files is. I'm not aware of anything that will make viewing diffs for Word documents human readable. Never mind that some of the people who need to use it will probably be a afraid of it or have even more basic problems like forgetting to commit.
Which is why you just treat the SVN repository as a WebDAV network drive. They user knows nothing about the underlying versioning going on, and you can always capture back the old version.
Additionally, tools like TortoiseSVN (well, technical TortoiseMerge written by the TSVN devs) have support for comparing MS Office documents. You have to have MS Office installed as it loads both into MS Office and runs the comparison functionality within MS Office to do the diffs.
Most developer VCS are overkill for a business environment. Do you really want to have to explain branching/merging or *gasp* rebasing to an office temp? The ideal system would require initial configuration and then create versions automatically.
Candidates: * Dropbox or equivalent. Good choice. Automatic backup and versioning. Reasonable per user / month pricing ($15/user/mo) * Sharepoint. Love it or leave it.
Individual users can turn on the versioning features of office, but since no way to enforce that behavior, good luck.
http://www.makeuseof.com/tag/not-just-for-coders-top-version-control-systems-for-writers/
That is why I usually recommend Subversion - because you can just mount Subversion like a network drive since it uses WebDAV as its base protocol.
I've done that with several managers and it works well.
And there's no additional cost.
The problem now, though, is that Microsoft is removing their WebDAV FS drivers from Windows.
Just detect if CPU performance is above a certain threshold.... Bochs is slow dead slow as is anything else that emulates adequately enough to make this vector of attach relevant even FPU x86 cpus are at 486 performance levels these days.
Until you adjust the base clock so that the software running under bochs thinks it is running at 1GHz while in reality it may be running at 1 instruction per minute. Yes - it's possible to do since Bochs doesn't rely on host system for any hardware, unless you introduce the qemu module for Linux to bring it to near native speeds but someone employing this kind of reverse engineering wouldn't want to do so.
This is possible because Bochs is a 100% software emulated computer. They emulate everything, and even have their own motherboard and video card (VGA) BIOS stacks.
That's actually the opposite of true. Many techniques (http://static.usenix.org/event/woot09/tech/full_papers/paleari.pdf, http://roberto.greyhats.it/pro..., http://honeynet.asu.edu/morphe..., http://www.symantec.com/avcent...) exist to identify the presence of a CPU emulator, because these things aren't (and will likely never be) perfect. Most of those techniques don't even rely on timing attacks. Once you introduce timing attacks (*especially* if there's an external source of time information), all bets are off.
You do realize that Bochs does software emulation of each instruction, and that you can control every aspect of the emulated computer don't you?
If you are running something under Bochs or something like it and don't care about the performance you can actually make it lie to the software underneath about timing so that the software still thinks it is running at the normal rate but in reality it isn't - Bochs after all implements the base system clock not relying on an external source. This is also why Bochs can be used to run x86 software on a non-x86 platform (f.e Sparc, PowerPC, ARM).
Yes, Bochs is dog slow; but it's a matter of how you configure it. And to be truthful, because of how Bochs is implemented I'm sure that it can be made to fool any of those detections.
Sounds like all you need to analyze this, is a "fake" processor.
EG, running this inside something like BOCHS, which has a built in x86 debugger, and runs a lot like a hypervisor. This encryption would need to be able to detect living inside a fully emulated system and simply refuse to operate in order to be safe from this kind of analysis. BOCHs will let you step through exactly what instructions the emulated CPU is actually doing, regardless of the data that is stored in the memory allocated to the emulator's process.
Don't get me wrong-- this makes a nasty bump in the road for career data thieves, but forensic analysis of the encryption is not completely thwarted.
Not to mention that it is extremely hard for a program to detect that it is inside a VM like Bochs unless the VM exposes something that can be detected - e.g a BIOS string, hardware signature, etc. Even then, that's easy for a cracker to fix by modifying the VM to have a different string or hardware signature.
Your bank may have less secure login methods than gmail, but Google doesn't have access to your bank account.
Google Wallet - they very well may.
If Google is hacked, Google takes the hit and looks bad. If your bank gets hacked, you take the hit, the merchant takes the hit, the bank walks away clean.
It is not identity theft (this makes the individual responsible to resolve.) it is fraud (causing the banks and fed to be responsible to clean it up). Someone needs to sue the bank because they allowed the fraud to happen then called it identity theft so they could wash their hands of it.
Well, not quite. FDIC (e.g government) takes the hit as the bank's insurer. So yes, the bank isn't risking much anything by not implementing strong protections.
This is why government is usually not the solution. However, the FDIC is necessary but perhaps the FDIC should start requiring stronger online protections as part of the insurance program...then again, the FDIC might not care enough....
This is the IoT build, and you would run Visual Studio on another desktop system and upload the programs to the Pi.
Again, compared to existing Pi use-cases where the compiler is on the Pi system itself. So now you can't develop with just a RasberryPi, you have to have another Windows System too.
That too doesn't resolve the Device Driver issue; it also means users have to install and learn how to use the Visual Studios Remote Debugger or learn more advanced (older style) debugging techniques.
All those things are not in the favor of Windows for development of software for a RasberryPi or Pi2 device.
He has not acquired a fortune; the fortune has acquired him. -- Bion
