Razhan

According to technet: https://technet.microsoft.com/en-us/library/ee617241.aspx?f=255&MSPPError=-2147217396 Accept Pipeline Input? true (ByValue) pipelineInput The Identity parameter is accepted from the pipeline, so the first option: cat users.txt | Get-Aduser -Properties HomeDirectory > C:\demo\home.txt Should work. You can even try something like: cat users.txt | Get-Aduser -Properties HomeDirectory | select Identity,HomeDirectory | epcsv -Encoding UTF8 -Delimiter ';' -NoTypeInfo -Path C:\demo\users.csv To have a nice csv ready to be opened with Excel, or: cat users.txt | Get-Aduser -Properties HomeDirectory | select Identity,HomeDirectory | ogv For a nice window

Try: cat users.txt | Get-Aduser -Properties HomeDirectory > C:\demo\home.txt or (if the Get-AdUser does not properly read those users from the pipeline) cat users.txt | %{Get-Aduser -identity $_ -Properties HomeDirectory} > C:\demo\home.tx I do not have an AD right now to test it, but it won't be hard

My Raspberry is currently inside my main computer, connected to the power button. When I'm outside, if something happens to my computer I can power cycle it by connecting to the Pi (I also have WakeOnLan enabled, but if the computer is toasted, it won't be enough)

Yes, of course it will be optimized in compile time. Simple math operations of const values are calculated beforehand

I found the issue two days ago. It won't happen if I disconnect the Sound Card (Asus D2X) Tested it by connecting and disconnecting the sound card, and the behavior is consistent. I tried with the official drivers (the ones I had installed before) and some unofficial ones (Unixonar), problem still there Anyway, at least now I know why. Thank you guys for your help

long long is indeed a thing in C and it is guaranteed to be at least 64 bits. In Other languages (like Java and C#), long long does not exist, but long is already 64 bits

BTW, if you use this solution, you should either check the value of RAND_MAX on compile time to ensure is still 16bits. If you compile that code against a lib with 32bit rand, it will affect the randomness So, you either check max value o force it to 0x7FFF: #define LLRAND ((long long int)rand()&0x7FFF) // This is a horrible hack, but it will make it work for 16 and 32 implementations. Checking the RAND_MAX value on compile time will generate more eficient code

It is not going to be pretty, but we should be able to keep 15 bits of every 16 bit rand int your library generates. That way, we should achieve a 60 bit random number, big enough to allow us to perform the modulus 9999999999 and still don't face distribution issues. My C++ is a bit rusty, but based on gabriel's code: That should generate a random int between 0 and 0xFFFFFFFFFFFFFFF before the modulus

Ok, so first, the easy question In the code you are using MemoryStream, so yes, you need the using for System.IO. Also, RijndaelManaged (and many other classes in your code) are from System.Security.Cryptography, so both usings are a must Regarding the code, I think it is Ok. I have created a simple program calling your CipherMachine: using System;class Program{ static void Main(string[] args) { string plain = "This is the text to cipher"; string pass = "This is the pasphrase"; string encrypted = CipherMachine.Encrypt(plain, pass); string decrypted = CipherMachine.Decrypt(encrypted, pass); Console.WriteLine("PlainText: {0}", plain); Console.WriteLine("Passphrase: {0}", pass); Console.WriteLine("Encrypted text: {0}", encrypted); Console.WriteLine("Decrypted text: {0}", decrypted); Console.ReadLine(); }} And it seems to work: PlainText: This is the text to cipherPassphrase: This is the pasphraseEncrypted text: KqyR4MLVrFfdWw+BcLRoqs+ijzMTJE/Nbn/X5+JDq/k=Decrypted text: This is the text to cipher I only removed an extra } at the end of your code

As they said, this is a no brainier. No only the pi2 includes 4 cores, it's a new ARM instruction set and every core is faster than the original Only if your friend plans to take a lot of pictures with a xenon flash is the Rpi original better

I had some experience transmitting video over long distance. We used converters to CAT5 for the signal. Something like: http://www.amazon.com/IOGEAR-DVI-D-CAT5e-Extender-GVE200/dp/B001FG0JB8/ref=sr_1_1 This model only supports 1080p, but maybe you can find some validated for 1440p. Be aware there may be some input lag (never used them for gaming, but it has to be there) HDMI is not very good over distance, I doubt it will be easy to find one certified for that distance and that resolution. And as you say, you need HDMI 1.3 to do that resolution. So, the adapter will need to take the DVI-D dual link and "convert" the signal to a single HDMI 1.3 link... I don't know if something exists that does that. Ah, this will be SO easy if you were using only 1080p monitors...

No, this is not AES, not even close!!! GetHashCode doesn't use AES either, GetHashCode uses a Hashing algorithm (MD5 if I am correct), not an encrypt one. The reason I wanted to avoid calling GetHashCode is because there are complex math operations there, and if you are going to call a System function that perform this kind of operations, why not call AES directly? I tried to keep all the code samples I provided you easy to understand. Using AES in C# is not hard, although is not trivial either (you may need to set the Key, IV, BlockSize...). Internet is full of examples, but I will get you a few keys to understand it: - AES is a block mode cipher. That means it will block multiple bytes at the same time (128 bytes), not like your cipher that was a stream cipher (one byte/char at a time) - An example of stream cipher would be RC4, however, C# does not provide an implementation (i think the algorithm was registered and was leaked, something like that. Everyone knows how to implement it, but that doesn't mean you are legally allowed (I do not know the current legal state) - Aes does not encrypt Strings directly, it encrypts data streams. That's the reason you will see conversions from strings to bytes and then the bytes to streams - There are two different ways for the code to work. One is to call a .Net function that will perform the encryption. However, Windows offers several Cryptographic services called the CryptoApi (CAPI). If you see they are calling AESManaged, they are using the .NET implementation. If they are using AesCryptoServiceProvider, they are sending the data to windows to be encrypted. - AES algorithm means (Advanced Encryption Standard). Before becoming AES, the algorithm was called Rjindael. AesManaged and RjindaelManaged are "almost" the same (Rjindael accepts different block sizes) - Keys are usually 128 or 256 bytes. Usually, one person needs to know the key, so to avoid extra complexity, an extra algorithm is created that derives the key from a string. That way, instead of the key you only need a Password (the code will always use the same function to calculate a key based on the string password) Here is a nice and clean example of calling AESManaged: http://www.obviex.com/samples/encryption.aspx Any doubts you have, just ask

Ok, here it is, one that shouldn't be so vulnerable to frequency attacks withouth calling an internal method like GetHashCode(): public static int getRand(int number) { return ((number * 1103515245) + 12345) & 0x7fffffff; } static public string Encrypt(string plain, int iv = 0) { StringBuilder cipher = new StringBuilder(); int key = iv % 75; for (int i = 0; i < plain.Length; i++) { key += Charset.IndexOf(plain[i]) + getRand(i); key %= 75; cipher.Append(Charset[key]); } return cipher.ToString(); } static public string Decrypt(string cipher, int iv = 0) { StringBuilder plain = new StringBuilder(); int key = iv % 75; int index = 0; for (int i = 0; i < cipher.Length; i++) { index = key; key = Charset.IndexOf(cipher[i]); index = key - index - getRand(i); index = index > 0 ? index % 75 : (index % 75) + 75; plain.Append(Charset[index]); } return plain.ToString(); } This part: public static int getRand(int number) { return ((number * 1103515245) + 12345) & 0x7fffffff; } Is part of the glibc implementation of rand. It is called linear congruential generator http://en.wikipedia.org/wiki/Linear_congruential_generator Now, when we cipher something like "aaa...." we get: result = "ZLXIY65MRvZdFn_Rtg~7*7~gtR_nFdZvRM56Y3+gzUYuofphJJ4qS)oOB$Ige(^KQK^(egI$BOWzfE#Z)M!Ote)*DEF+W1sJOyDvKi^Ojn6a#ln!~Y+K*PawJWbGeFyPLfe^~W@)aaZKzj~t4lF1n0y9Zm@%FKiHVIEqeR%X+N#Ivx+)FRMQEmldjcBV)$kHwVsGj*Omkqf7tc" As you can see, there are some patterns like: Y65MRvZdFn_Rtg~7*7~gtR_nFdZvRM56Y Or: OB$Ige(^KQK^(egI$BO But is way better than before

Curious, I was aware something like this could happen, although I did not know the chances to happen so soon. You can call it an armonic, resonance or something similar. This is an extremely simple algorithm, and to calculate the cipher of a character pn, we only take into account the value of pn and the encoding of cn-1. Than means if pn is constant, only one value is taken into account to calculate cn, an that is cn-1. While we keep feeding the algorithm with a constant plaintext, at some point, it will generate a value of cn that is the same as cn-x (x could be any value between 1 and 75), so the value of cn+1 is the same as cn-x+1, and the ciphertext will repeat itself. As there are only 75 possible outputs for a char in the algorithm, at some point the algorithm will start to repeat itself. For "aaaa..." this happens every three chars, but this will also happen for "bbbb..." if the string is long enough: result = "F9H5D1JqSaKzAsLwTxYdReUcEfIrWvOgQtPb+h_y)n(j*u&m^k%i$p#l@o!V~C0B8X4N2Z6M3G7F9H5D1...." Did you see how at the end F9H5D1 will start repeating itself? So... our little algorithm is vulnerable to extreme cases of frequency analysis. When attempting to break an algorithm, one of the most potent attacks is called the chosen plaintext attack, where you can feed the encryption function a message to encrypt and see the results. Feeding things like an empty message or a message made of the same character is a common operation, as it reveals weaknesses of the algorithm like you did So... can we improve the security of our algorithm from none to almost none? Sure. We just need to make the value of cn to depend on something else. For example, the position of cn (stored in the variable count) static public string Encrypt(string plain, int iv = 55) { string cipher = ""; int key = iv % 75; int count = 0; foreach (char i in plain) { key += Charset.IndexOf(i) + count; key %= 75; cipher += Charset.ElementAt(key); count++; } return cipher; } static public string Decrypt(string cipher, int iv = 55) { string plain = ""; int key = iv % 75; int oldkey = 0; int count = 0; foreach (char i in cipher) { oldkey = key; key = Charset.LastIndexOf(i); int index = (key - oldkey - count) % 75; if (index < 0) index += 75; plain += Charset.ElementAt(index); count++; } return plain; } Now, if we check the value of encoding a single char string...: result = "kU2hD*qjHP8xjNLP$2qdvhjmkkmjhvdq2$PLNjx8PHjq*D" It may look better, but actually the patter will keep repeating (do yo see how there is a simmetry aroung hjmkmjh?) So maybe not so evident (and now, I think the patter will only start repeating after 75 chars, never as before after 3, although don't quote me on this) The main problem here is generate some randomness, something that will create a sequence that avoids repeating itself. This is quite difficult. I will go further, extremely difficult. Sure, we can do something as: static public string Encrypt(string plain, int iv = 55) { string cipher = ""; int key = iv % 75; int count = 0; foreach (char i in plain) { key += Charset.IndexOf(i) + plain.Substring(0, count).GetHashCode(); key %= 75; if (key < 0) key += 75; cipher += Charset.ElementAt(key); count++; } return cipher; } static public string Decrypt(string cipher, int iv = 55) { string plain = ""; int key = iv % 75; int oldkey = 0; int count = 0; foreach (char i in cipher) { oldkey = key; key = Charset.LastIndexOf(i); int index = (key - oldkey - plain.Substring(0, count).GetHashCode()) % 75; if (index < 0) index += 75; plain += Charset.ElementAt(index); count++; } return plain; } Using the GetHashCode() I haven't been able to find a pattern: result = "QN6CM5uJII(na_javx^uC9F^bawQmc(ORwuey20B1~1CFWTYDyg7c8J$HbtpgaUh+v&noYzevX(vH*iL2S7qZY4S&1wMg_va5lT$rY*HdV8FrYnRlwK(njv*Gt$p2Nw_qPYynIbb@[member=bzzerc]_" But if we are going to call GetHashCode() we might as well directly call the AES cipher As you can see, cipher algorithms can get nasty really fast

Many years ago (more than 10) I was able to do this with a patch for XFree86 in linux. I doubt this is possible in Windows, but I guess it should be possible in linux