cooper

The legality is quite simple. You're allowed to reverse engineer stuff in all sensible developed countries, which is basically any western country except for the USA. The EFF has a page on the legal issues in the USA. The process of mostly legal reverse engineering of a proprietary product (hardware) is something like this: You take 2 teams, A and B. Team A takes the original hardware and works out how it responds to different signals that reach it over its device interface (PCIe/USB/GPIO, whatever). They work out the various states the device can be in, work out how these states are reached and how they react to the various inputs while in those states. Then they write a design document describing all of this. When they're done, Team A is potentially legally fucked - the maker of the original device can sue them claiming Team A somehow had access to confidential documents so they must disappear. Nobody knows who they were and all knowledge of their existence is expunged from any system. Their design document is leaked onto some forum in china or whatever. Enter Team B. These are genuinely different people from Team A. There *MUST* be ZERO overlap (plausible deniability). They 'discover' Team A's design documents through the magic of the internet. They then develop a new device that adheres religiously to the specifications described in the design document. This device is now a functional and technical copy to the original device, but might still do things slightly different when confronted with the original driver because certain elements of behaviour weren't described sufficiently specifically in the document. During normal operation things are as expected, but in weird edge cases registers contain different default values or certain routines take substantially longer/shorter because certain device optimizations made in the original weren't done for the copy or vice versa. What you then end up with is the current standoff FTDI has with counterfeiters of their hardware. In case of the nouveau driver, things are thankfully less complicated. NVidia _wants_ an open source driver, but they worry that people might discover, looking at the driver, what methods and operations are embedded in their device and assume they violated someone's patent. Initially the lawyers called the shots, so all the driver developers could do was look at what the binary blob was doing, working out what these actions did to the hardware and trying to replicate this behaviour in a sensible manner via their driver. This, I might add, with the exception of a developer doing this to circumvent some copy protection scheme (USA! Land of the free, except when it comes to Mickey Mouse!), is entirely legal. Things get murky when you do this with design info in hand after having signed an NDA. If you never signed anything and you never looked at confidential manufacturer documents you know you shouldn't, you're in the clear. By now some legal issues have mostly worked themselves out and NVidia is occasionally helping the nouveau developers by providing information about the more basic elements of the device to at least reach the level of a working device. Bottom line is that, for the most part, software development is seen as no different than writing a book. So long as you don't outright plagiarize someone else's work without their permission, it's all good.

You should simply install VPN service like libreswan on your home router and connect home over that if this is all you need. It'll be faster, at least as secure and you'll be in full control. I hope you realize the irony here. With this you're now already saying you want to sacrifice security for convenience. Security is a layering process, and you're asking for the removal of a layer. That didn't take long, did it?

I was under the assumption that by now there would be something of a generic USB SDR device driver. I'm guessing you're asking here about this sort of thing with the assumption "Here are hackers who know how to interface with devices like the one we're making" but I'd say most people here operate at the application level. My suggestion to you would be to find a gnu radio forum like this one and see if they may have something sensible to say.

You're describing it a bit weird, so I'm just going to rephrase it and you tell me where I get it wrong. There's an SDR and you want to make it do stuff. To enable this, you connect it, via USB, to a machine that runs Linux. You're now wondering about drivers for this setup. The USB support in Linux is basically the built in support for the chipset that's available on the machine. There's quite literally 0 variation here. On top of this you need support, in Linux, to drive the SDR. So pick the appropriate SDR and you now know what driver to use. The device dictates the driver you may (might? It might just work out of the box without a special driver) need. Your remaining problem is the program that drives the SDR. You need to write/configure/whatever it to make it do what you need it do. This is potentially limited by the SDR you choose, so start there.

It would be the second because they're asking for the HOST and not the URL or PATH.

The hardware being cheap junk is forgivable. The big problem was the assumption "Install this and you're anonymous" would somehow become valid. Relevant old post of mine.

Not really (really not). But it shouldn't be hard to consider what I'm saying. My assumption is that, as you say, Windows only retains the hashed password on disk - never unencrypted. You have a memory dump on disk which I'm assuming to be the full memory. So not just the Windows OS relevant bits but the whole shebang. If there's a program running at the time of the dump that, for whatever reason, had the string "BendOverAndTakeItLikeAConvict" in memory, and this program hadn't been swapped out to disk yet, it would show that exact string somewhere in the memory dump. If you think this string was in memory because of some program you yourself wrote, there are ways to prevent them from ending up in swap: Linux Windows & Linux (2nd answer) Your friends at IBM provide some more details on how to do it in code and, specifically, in managed languages like Python and Java.

Maybe you could describe your process, as you're doing this, in a new topic here? I'd be interested to read about your challenges in developing this, and how you overcame/come any obstacles.

It works like this. You have BigProvider.com where people can purchase hosting for joomla sites. This normally results in 2 URLs for the same website: http://BigProvider.com/JoomlaFanboi http://JoomlaFanboi.com In this case JoomlaFanboi.com is the target vhost on BigProvider.com If it's just JoomlaFanboi.com self-hosting the site, punch them in for RHOST and leave VHOST blank (as it says, it's not required). If it isn't and you know the main provider (whois should tell you all you need to know) give those values.

Start reading here for a 2014 discussion on the anonabox. Basically, if you want all your traffic to flow through tor, feel free to go this route. If you want to be anonymous while on the internet, you've got another thing coming.

Apologies. I had this thing mixed up with a different device.

I would make a new csv file. To append to the file, don't invoke CreateTextFile but invoke OpenTextFile.

new Date().toString()

But it won't do anything until lost & found actually plugs it in. There's no power source within the device itself (or, for that matter, room to add it yourself). edit: I'm an idiot.

My first thinking is that the pwning of the box resulted in a program being resident in memory with the unencrypted domain admin password at its disposal. So it's not so much the OS that had it in plain text but rather the attacker. Even storing the actual password, encrypted or not, is a bad idea. The user should provide it and the target platform should retain information about it without actually storing the thing itself (a.k.a. a password hash).

Could you maybe describe what you want with a little more detail?

Mine's been collecting dust, sadly, because I'm too busy with other projects. Specifically, I've been really busy putting together video rigs and taking them to security conferences to record them, then see what I can improve in the workflow to make things less time-consuming.

When you design the new card, you are aware of the instructions the old driver is sending to the card. If you can make the new card react identically to those commands as the old card did, you wouldn't need to develop a new driver. But this assumes the new card only does the exact same thing as the old one, just faster. The more common thing you see is that the new card has additional features or instructions that make it really shine. So you'd at least want a driver that also provides those instructions when the situation allows it to benefit from their use. Windows and Apple will do FUCK ALL for you. There are some standard drivers (VGA, USB...) whose instructions you can engineer your devices to support in a proper manner. For some devices that level of support is all you need. You don't need a new driver for another USB memory stick, harddisk, keyboard or mouse, but if that keyboard or mouse has some funky keys the typical devices don't have you're going to have to provide your own driver to make the OS understand about them. Until this driver is installed, chances are the device will work just fine, except for those funky keys who will just be ignored. In some cases a manufacturer has created a device that's become MASSIVELY popular. When a new version of the OS comes out and the OS vendor knows the driver model has changed in incompatible ways, they'll actively approach the device maker to make sure their drivers are ready for the new OS, to ease adoption of that new OS. Sometimes the OS vendor even includes this vendor's driver in their OS to make it easier on the user. This benefits both the OS vendor (easy transition to the new OS) and the device vendor (out of the box support for the new OS) so if any money is exchanged for this service, it'll not be a large amount. Exactly. Old driver knows about the 'normal' instructions for that device range, but if you want the special features (like, say, how to operate the duplexing add-on to the AVH356D model) you're going to need to install the device-specific driver. Note that hardware vendors prefer to have drivers that support everything within the same range from a single driver because each driver you make demands more time from the driver development team. If you only have 1 driver to maintain, it'll be cheaper. The OS is an abstraction to the programs running on it such that the programs don't know the peculiarities of the various drivers. That's the point of the driver model. Your program can say to the OS "I want a triangle here". The OS determines which of the 4 graphics adapters is responsible for that specific screen and then tells the adapter of that screen to draw the triangle. The adapter is effectively the driver but the driver translates the standardized instructions that can be sent to the adapter (DirectX, OpenGL...) to the low-level primitives the card itself operates on (assembly, really) which then makes the card do its magic. Given that, you'll hopefully understand that the OS actually doesn't have that much to do with the way your card operates. Just with the operations the card can expose to the outside world. You may now think "But what about new features added after those standardized instructions were set in stone?" Well, if you do some sensible API design, you allow for proper detection of the hardware which would allow any program that wants to to provide specialized support for the funky features of the card. These instructions are at that time not part of the official API so if a different vendor implements something similar chances are your software will need to provide a unique code path within the application to cater to that hardware too. This is why some games work really well on cards by vendor A and only so-so on cards by vendor B. Vendor A was either targeted from the start as the platform to optimize for, or vendor A paid the developer to make this happen. Because here, too, the extra codepath(s) makes for more work by the application developer and so this needs to be compensated for by the device manufacturer. A pure PC manufacturer tries to assemble the cheapest bits of hardware that work with the least amount of hassle. They make money by getting you to purchase the hardware and they lose money by providing excessive support (there's always _some_ support, but if some component is very flaky it will result in a lot of calls so expensive support). This means their challenge is that they want to provide the cheapest possible hardware that still works well. The driver is certainly a component of that, but it's just something that's considered when they work out which hardware they're going to combine. Something else they do is talk to hardware manufacturers where they want X discount on the guarantee that they'll ship at least Y items of hardware but manufacturer has to keep making this exact device for the next Z months. When you talk about those big 'PC Manufactorers', they often pay some company to not only provide their device for their PC configuration but even employ their brand-specific label. So it's not a Seasoonic power supply anymore, but a Dell power supply. They might even have the hardware vendor develop the driver to include the manufacturer's logo. If you pay for it, they'll do anything. What happens is that NVidia designs the card and then tells hardware makers to actually create a physical card based on that design. Some hardware makers "improve" this design with more elaborate power handling or more memory because marketing says it'll make it sell better. But it's an NVidia chip on a card based on the NVidia reference design. Unless they deliberately did something to prevent it (and there's very little incentive to device manufacturers to do this) the standard NVidia driver will work just fine. For common types of devices the OS vendor has already made a driver which very clearly specifies what a device maker should do to make their device compatible with this driver. This means that a device maker now has a choice: Develop your own features that don't fit the existing driver which might give it a unique selling point but a driver to make use of this needs to be developed, increasing cost, or to hell with that feature, and let's work on features that are unrelated to the software functioning of the driver (smoother action, scroll wheel with LEDs inside, that sort of 'feature'). The short answer is that they don't. If a device manufacturer wants to get paid to allow someone else to develop a driver for their device, for free, that device maker can go punch sand. Just buy the device made by their competitor who might be more accommodating. What you typically see is that a driver writer asks for specs of the device. The device maker is HUGELY protective of this (our IP! Our PRECIOUSSSS!) but sometimes a developer is allowed to sign a massively penalizing NDA that would allow that developer to see the specs and develop a driver for it. These specs can't be disclosed but the driver allows you to make some assumptions about how the device works (which is where the danger lies to the hardware maker - looks like you're doing X and I have a patent on that. Pay up, sucka!). The upshot for the device maker is that if your device is now supported under Linux aswell, that's another market you can sell your device to. For many types of devices this is a small market, but if your device is intended for servers (smart card readers, say, to provide the machine with a HSM) this market can be quite significant. Another trend is that sufficient people get together and pay the maker to develop a driver for their platform of choice. It's not very common, but as always, if you give enough money a business will make it happen. They don't _hate_ your OS, they just don't see the return on investment so prefer to spend their money elsewhere.

When setting up hardware for a lab, the storage is typically the less-relevant of your concerns. The biggie tends to be memory when you want to be running several VMs. You can set up some of that SSD storage as a swap space to compensate lack of RAM. Going with disk storage for this will tank your performance to a massive degree. You can use a few of the USB sticks for playing with things like TAILS or other live distros, but you're then dedicating one entire machine to running that OS which would be somewhat inefficient for your lab. You could get your VM to boot off of that USB drive, but why even go with this cumbersome route when you should have ample diskspace for pretty much anything. Maybe you should take a slightly closer look at what you want to do with your lab, discover what you actually need for that and focus on this. Spare hardware on a shelf can be quite a comforting thought.

I don't know what puzzles me more about this thread - that someone can't decide on what phone to pick so he asks a random group of strangers or that every response to that question boils down to "I have it and I like it" rather than stating WHY people chose that one over the other options...

How about telling us what you're experiencing? Logging, screen output, things you've tried and how that (didn't) seem to fix anything. Your current message is basically "it doesn't work" and since my crystal ball is in the shop this week you're going to have to describe things in rather more detail before I can suggest solutions.

Oh, you think this was about criminals? That's so cute...

Because IBM tools used is as a switch character and its use was already ingrained within the 'platform' (we're talking DOS here) Microsoft chose to go for the \ char because it was the most similar-looking one to the UNIX path separator /. http://www.howtogeek.com/181774/why-windows-uses-backslashes-and-everything-else-uses-forward-slashes/

I'm going to bookmark this thread under "Reasons ActiveX must die."

Because you need to log in to a network location?