[Update 3/3/16]John McAfee Reveals To FBI, On National TV, How To Crack The iPhone (RT Interview)

[SpaceNugget]

16 hours ago, Kloaked said:

@No Nrg Here's an update to the whole thing from Ars: http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/

 

2 hours ago, No Nrg said:

Thanks for the update. Backs up the claim that once again McAfee is out there trolling.

 

Guess he's just enjoying his time in the limelight, trying to get his name out there for his campaign for president literally nobody knows he's running.

 

1 hour ago, dimitriianghelov said:

 

he might be but is arstechnica expert in the field ? i wouldn't put my money it

They most definitely are not, They clearly have no idea that many people have full time jobs consisting mostly of reading and writing assembly. Calling it "barely human readable" just highlights how little they know.

[No Nrg]

12 minutes ago, WaxyMaxy said:

 

 

They most definitely are not, They clearly have no idea that many people have full time jobs consisting mostly of reading and writing assembly. Calling it "barely human readable" just highlights how little they know.

I'm not an expert in the field, but I'd assume it would take more than 2 people and 30 minutes to crack as McAfee claims.

 

Who knows though, maybe it really is that easy.....

[SpaceNugget]

2 minutes ago, No Nrg said:

I'm not an expert in the field, but I'd assume it would take more than 2 people and 30 minutes to crack as McAfee claims.

 

Who knows though, maybe it really is that easy.....

Oh it would definitely take much much longer than that, It just seemed like ars was suggesting that going through the disassembled code wasn't an option because people can't read asm.

[SImoHayha]

Lol I found this sure fire way to hack a iphone look here.

 

 

 

basically if the code inputted is wrong. The phone shuts off the battery before it can be registered. So that way no errors are made and can be done with just waiting.

 

 

[suicidalfranco]

46 minutes ago, Ramamataz said:

Lol I found this sure fire way to hack a iphone look here.

 

 

 

basically if the code inputted is wrong. The phone shuts off the battery before it can be registered. So that way no errors are made and can be done with just waiting.

 

 

with iOS's boot time how much would that take???

[Squirrel724]

So I haven't looked to deeply into the specifics of what he is proposing but I gathered this: He wants to use social engineering to get someone to tell him the pin. News flash John: everyone who knows that pin is dead.

 

Then there is the plan he told Russia Today: that you can remove the rom chip from an iPhone, read the data off of it 1 bit at a time until you get the data you want.

 

Sure it is possible to read the data off of the chip and read it one bit at a time but there are some problems:

1) getting to the chip: With the multilayer pcb used in the iPhone (and for that matter almost all complicated electronics) you are not getting to the pins on the chip or removing the chip from the board without destroying it.

2) even if you could get the data of the chip you run into the entire reason for the debate between apple and the FBI: The data is encrypted. You still need to decrypt the data you get from the chip. 

[SpaceNugget]

2 hours ago, suicidalfranco said:

with iOS's boot time how much would that take???

assuming that it is a 4 digit pin from 0000 - 9999 it would only take 9.72 days to try them all.

[Griffscavern]

On 3/1/2016 at 10:31 AM, dalekphalm said:

Don't talk to me about old until you can remember 1994

I can remember 1994, 1984, and 1974. Can't remember 1964 though. Just lived through half of it. In most people's eyes on this forum, I am old. Don't feel it myself. My body does sometimes, but most times I still feel like a young buck.

[LAwLz]

7 hours ago, dimitriianghelov said:

he might be but is arstechnica expert in the field ? i wouldn't put my money it

 

5 hours ago, WaxyMaxy said:

They most definitely are not, They clearly have no idea that many people have full time jobs consisting mostly of reading and writing assembly. Calling it "barely human readable" just highlights how little they know.

 

I did not find anything wrong in the Ars Technica article. Calling assembly "barely human readable", and saying that it would take more than half an hour to look through several hundreds of megabytes of assembly code does not "highlight how little they know". It sounds pretty accurate to me.

[SpaceNugget]

1 minute ago, LAwLz said:

 

 

I did not find anything wrong in the Ars Technica article. Calling assembly "barely human readable", and saying that it would take more than half an hour to look through several hundreds of megabytes of assembly code does not "highlight how little they know". It sounds pretty accurate to me.

So its accurate for me to say Cantonese is barely human readable because I personally cant read it? does that not indicate to you my level of understanding of Cantonese?

[LAwLz]

Just now, WaxyMaxy said:

So its accurate for me to say Cantonese is barely human readable because I personally cant read it? does that not indicate to you my level of understanding of Cantonese?

Very bad analogy.

1) Everything is relative. How many people do you think can read Cantonese fluently, without even having to think for a second? Now compare that number to the number of people who can do that with assembly (which won't even be a single person, since you HAVE to keep track of registers, what is saved where, which computation will happen etc). It's a pretty small number, isn't it? Just because some people can do it doesn't mean it isn't difficult. The world record for holding your breath is over 20 minutes. Quite a few people have been able to do it, but I'd still say it is accurate to describe holding your breath for more than 20 minutes as "barely humanly possible".

 

2) Even if that was a fair comparison, it would still be pretty accurate to say that it would take more than half an hour to read though all that code. iOS is not some tiny thing with a handful of pointers. It is massive if you are going to read it in assembly. Hell it would take more than half an hour to read it in plain C.

[SpaceNugget]

Just now, LAwLz said:

Very bad analogy.

1) Everything is relative. How many people do you think can read Cantonese fluently, without even having to think for a second? Now compare that number to the number of people who can do that with assembly (which won't even be a single person, since you HAVE to keep track of registers, what is saved where, which computation will happen etc). It's a pretty small number, isn't it? Just because some people can do it doesn't mean it isn't difficult. The world record for holding your breath is over 20 minutes. Quite a few people have been able to do it, but I'd still say it is accurate to describe holding your breath for more than 20 minutes as "barely humanly possible".

 

2) Even if that was a fair comparison, it would still be pretty accurate to say that it would take more than half an hour to read though all that code. iOS is not some tiny thing with a handful of pointers. It is massive if you are going to read it in assembly. Hell it would take more than half an hour to read it in plain C.

1) Its a fine analogy, it is literally just replacing the name of one language with another. Your analogy comparing reading a language to holding your breath is an example of a bad analogy. It is an indisputable fact that asm is a human readable language. As I said before, many people read and write asm day in and day out.

 

2) did you read my post? I myself said that it would take much longer than half an hour! That has nothing to do with the fact that assembly is very obviously a human readable language.

[LAwLz]

10 hours ago, WaxyMaxy said:

1) Its a fine analogy, it is literally just replacing the name of one language with another. Your analogy comparing reading a language to holding your breath is an example of a bad analogy. It is an indisputable fact that asm is a human readable language. As I said before, many people read and write asm day in and day out.

And Ars never said humans could not read it. So what is your point?

 

It is an indisputable fact that some people can hold their breaths for more than 20 minutes as well. Many people can do it. It is still "barely" possible though. The number of people that can do it is very small though, especially compared to the number of people who can read Cantonese. 

 

 

10 hours ago, WaxyMaxy said:

2) did you read my post? I myself said that it would take much longer than half an hour! That has nothing to do with the fact that assembly is very obviously a human readable language.

So if you agree with the Ars post then why are you saying it is bad? At this point you are just nitpicking over whether or not something should be called "barely human readable", which is not an objective term do there is no right or wrong answer. What you are arguing over does not even matter in the article. The point they were making wasn't that nobody can read assembly. The point was that it would not be a 30 minute job, and you agree with that. If you're going to criticise the article then you should probably find a better argument than "he called assembly something I don't agree with, although it was completely irrelevant to the points he was making, and I totally agree with his points".

 

 

I though the article was very good and highlighted why McAfee is full of shit. I think McAfee is just trolling though. He doesn't actually believe anything he says. I don't like misinformation even if it is for a good cause. 

[steini1904]

12 hours ago, LAwLz said:

 

 

I did not find anything wrong in the Ars Technica article. Calling assembly "barely human readable", and saying that it would take more than half an hour to look through several hundreds of megabytes of assembly code does not "highlight how little they know". It sounds pretty accurate to me.

 

The article is nonsense. Nobody reads through hundreds of megabytes of code. That's insanity. Even assuming that's what McA meant shows the incompetence of the person who wrote that article.

 

There are 2 ways to do that:

 

1) You run a code emulation that automatically marks ever routine it jumps into. Once you're at the desired moment of execution, you manually trigger a breakpoint and delete every marked inactive routine. What you're left with is exactly what you're looking for.

 

2) Almost like method 1) but instead of emultating the code you run it natively on the phone and use an external debugger. I don't know enough about the iphone for telling you which methods are possible for that, but there are multiple ones. If there is a debugging interface, it's a piece of cake, if there isn't you might even have to do some sldering and code injection. The rest is similar to 1).

 

Second, I have no freaking idea how that ars-guy came to the conclusion McA wants to look for the pin. The idea is to get the unique secret key, that is embedded into the hardware and do the rest by simply bruteforcing the pin.

 

They're probably also going to remove the flash-chip from the board and read all the data of it, so that they can get the data savely and back it up.

 

As I said I do not know how the Iphone looks like from the inside, but I believe someone mentioned here that the chip is embedded in between the layers of the PCB. I never heard of something like that, but even that is anything but a problem.

 

All you need is a highly precise CNC mill and cut the layers from both sides until you get to the chip. Mikeselectricstuff has made a video on that:

 

https://youtu.be/RHqN6CTOdzA

[byalexandr]

I fuckin' love this guy.

 

[KuJoe]

On 3/1/2016 at 2:07 PM, Daring said:

Pretty much. No operating system would store passwords in plaintext. Unless the developer is that stupid, but if they're not, passwords will be hashed and salted.

Not true. If you have an encrypted hard drive, the password is stored in plain text in RAM (at least they were up to last year). I have accessed a hard drive (my own) that was encrypted before but the problem is that the password needs to be entered and stored in RAM, I'm assuming at this point the iPhone in question has been turned off at some point in which case the password is probably no longer in RAM (unless they froze the RAM chip or something).

 

http://hackaday.com/2008/02/21/breaking-disk-encryption-with-ram-dumps/

 

This is also why I tell people that having a VPS/VM with an encrypted hard drive where somebody else has access to the hardware (i.e. a VPS provider) can easily grab your password out of RAM even easier than a physical device).

[LAwLz]

15 minutes ago, steini1904 said:

 

The article is nonsense. Nobody reads through hundreds of megabytes of code. That's insanity. Even assuming that's what McA meant shows the incompetence of the person who wrote that article.

 

There are 2 ways to do that:

 

1) You run a code emulation that automatically marks ever routine it jumps into. Once you're at the desired moment of execution, you manually trigger a breakpoint and delete every marked inactive routine. What you're left with is exactly what you're looking for.

 

2) Almost like method 1) but instead of emultating the code you run it natively on the phone and use an external debugger. I don't know enough about the iphone for telling you which methods are possible for that, but there are multiple ones. If there is a debugging interface, it's a piece of cake, if there isn't you might even have to do some sldering and code injection. The rest is similar to 1).

Both of your methods would still take more than half an hour, which was the point the Ars guy was making. You can nitpick all you want, but the main point is still valid. And don't worry about not knowing enough about iOS to tell which method is possible to use, McAfee don't know anything about the iPhone either but he is still on TV talking about it.

 

18 minutes ago, steini1904 said:

Second, I have no freaking idea how that ars-guy came to the conclusion McA wants to look for the pin. The idea is to get the unique secret key, that is embedded into the hardware and do the rest by simply bruteforcing the pin.

 

They're probably also going to remove the flash-chip from the board and read all the data of it, so that they can get the data savely and back it up.

 

As I said I do not know how the Iphone looks like from the inside, but I believe someone mentioned here that the chip is embedded in between the layers of the PCB. I never heard of something like that, but even that is anything but a problem.

 

All you need is a highly precise CNC mill and cut the layers from both sides until you get to the chip. Mikeselectricstuff has made a video on that:

 

https://youtu.be/RHqN6CTOdzA

By "unique secret key" do you mean the UID? Gee I wonder why the Ars guy didn't think McAfee was referring to that... Maybe because the CPU doesn't have access to it? And no, the CPU does not have access to the UID even at the highest privilege level. Looking at the instructions the CPU uses won't help. We can't even pretend like it was the UID McAfee was referring to because he "explained" what he meant in the comments. He said he wanted to bypass the security enclave. Not only would that be impossible since you know, the 5C doesn't have it to begin with, but bypassing it on phones that does have it would actually make breaking the encryption EVEN HARDER. Now you would need to break a much more difficult password (instead of 4 digits it might be like 50 numbers and digits) and it would need to be done on a file by file basis. Oh and each key is encrypted 10,000 times over (PBKDF2) so brute forcing would take ages.

 

 

Again, there is nothing wrong with the Ars article if you know how iOS handles encryption.

Of course there are some ways they could possibly defeat the encryption, but McAfee was just spewing inane garbage on TV. It was like watching an episode of CSI. What he described would not work. Plain and simple. It might work on some systems, but not iOS or any other encryption method worth a damn. Hell it does not even work on the encryption my hentai uses (trust me, I tried).

 

 

18 minutes ago, KuJoe said:

Not true. If you have an encrypted hard drive, the password is stored in plain text in RAM (at least they were up to last year). I have accessed a hard drive (my own) that was encrypted before but the problem is that the password needs to be entered and stored in RAM, I'm assuming at this point the iPhone in question has been turned off at some point in which case the password is probably no longer in RAM (unless they froze the RAM chip or something).

 

http://hackaday.com/2008/02/21/breaking-disk-encryption-with-ram-dumps/

That's only if you have already typed in the password, and even then it does not store the password (that you inputs) in plain text. It does store a hash of it though which is all you need to decrypt it.

[steini1904]

28 minutes ago, KuJoe said:

Not true. If you have an encrypted hard drive, the password is stored in plain text in RAM (at least they were up to last year). I have accessed a hard drive (my own) that was encrypted before but the problem is that the password needs to be entered and stored in RAM, I'm assuming at this point the iPhone in question has been turned off at some point in which case the password is probably no longer in RAM (unless they froze the RAM chip or something).

 

http://hackaday.com/2008/02/21/breaking-disk-encryption-with-ram-dumps/

 

This is also why I tell people that having a VPS/VM with an encrypted hard drive where somebody else has access to the hardware (i.e. a VPS provider) can easily grab your password out of RAM even easier than a physical device).

Not necessarily, although it's rarely used:

 

By having a unique secret hardware key you can use your own key to mutate that hardware based key instead of decrypting the data.

 

Also there are algorithms that allow you to (asyncrosly) encrypt with two keys but decrypt with a single one. I believe to have anywhere a paper on that stuff. IIRC they're horribly insecure for the amount of calculation and bitdepth needed / used, but it's possible.

 

That allows you to use two devices for decrypting data without having the key at any time on any of the devices. Basically the server encypts the data with one key for storage. Then it requests from the client a second key, that the client generates on a random factor and sends that key to the server. The server encrypts the data with the second key and requests the decryption key from the client, the client generates the decryption key based on the user input (the encryption key on the server depends on that key) and the randomly generated key and sends it to the server.

 

That way there is never a unique decryption key.

 

At least that's how I believe it should work. I'm surely missing something here, since all you would need for decrypting the data is the second encryption key (on the server) and the decryption key (at some point also on the server). But it should have been very similar to this...

 

I'm gonna look it up and post an update. Damnit...

[steini1904]

1 hour ago, LAwLz said:

Both of your methods would still take more than half an hour, which was the point the Ars guy was making. You can nitpick all you want, but the main point is still valid. And don't worry about not knowing enough about iOS to tell which method is possible to use, McAfee don't know anything about the iPhone either but he is still on TV talking about it.

Not at all.

 

If an debuging interface is available, its rather a matter of seconds than minutes. Of course you would still have to analyze the code, but I have seen people who understood a 30,000+ lines C programm in less than the named half hour, so I'm not going to doubt that there are people who are able to do similar with some assembly routines. Especially since assembly is easier to read than most other languages (in my opinion), it's just a lot more steps for a similar task.

 

If you have to alter the hardware itself, well..., give it a week instead of half an hour, but it's still a reasonable period of time.

 

1 hour ago, LAwLz said:

We can't even pretend like it was the UID McAfee was referring to because he "explained" what he meant in the comments.

Well, nobody can argue against that. Except maybe, that the person commenting pretended to be McA. That's why you don't try to appear smart if you got no idea what the hell you're talking about. If there is room for interpretation people are going to make favorable assumptions. Else you're just screwed.

 

1 hour ago, LAwLz said:

By "unique secret key" do you mean the UID? Gee I wonder why the Ars guy didn't think McAfee was referring to that... Maybe because the CPU doesn't have access to it? And no, the CPU does not have access to the UID even at the highest privilege level.

Would have been too easy, would it? Yes, I guess I'm takling about the UID (sorry, I have a fair bit of knowledge about anything EECS related, but not the iphone itself). I assumed it would be possible since Apple argued, that if they wrote a software that could be used to decrypt the phone, that this software would be exploited for sure.

 

It still would only change the point of leverage if one of these two cases would be true:

 

1) There is hardware modul that delivers encryption and decryption keys based on the PIN

 

2) There is a hardware modul that does the encryption/ decryption itself

 

In both cases it is absolutely necessary that this hardware module, doesn't change the UID, even after the 3 failures.

 

The hardware module could/should have a reset for the counter or an input vector that feeds the current amount of failed tries. Disabling that could (or in case of a reset enabling it) would also solve the problem, even if the UID changes.

 

Or in a worst case scenario, all you can do is determining processing times of the chip in case of a correct and incorrect input, use an oscilloscope for triggering on that delay and hook the trigger to the module's powersupply.

[No Nrg]

Updated OP to include video of interview McAfee did on CNN yesterday butting heads with former FBI officer Steve Rogers. McAfee is squarely against a backdoor key.

[SpaceNugget]

6 hours ago, LAwLz said:

And Ars never said humans could not read it. So what is your point?

 

It is an indisputable fact that some people can hold their breaths for more than 20 minutes as well. Many people can do it. It is still "barely" possible though. The number of people that can do it is very small though, especially compared to the number of people who can read Cantonese. 

 

 

So if you agree with the Ars post then why are you saying it is bad? At this point you are just nitpicking over whether or not something should be called "barely human readable", which is not an objective term do there is no right or wrong answer. What you are arguing over does not even matter in the article. The point they were making wasn't that nobody can read assembly. The point was that it would not be a 30 minute job, and you agree with that. If you're going to criticise the article then you should probably find a better argument than "he called assembly something I don't agree with, although it was completely irrelevant to the points he was making, and I totally agree with his points".

 

 

I though the article was very good and highlighted why McAfee is full of shit. I think McAfee is just trolling though. He doesn't actually believe anything he says. I don't like misinformation even if it is for a good cause. 

You need to go back and read my first two posts again. You are arguing against things I didn't say. I never said the ars post was bad. I said they clearly don't know much about the topic at hand, that being reverse engineering software. That's not an insult or slander, its the truth and its not even a bad thing. For example, I don't know much about chemistry or medicine and that doesn't hurt me to say because that's not my field of expertise.
 

No matter how hard you try to dance around it and use terrible analogies (which don't even prove your point anyway) Assembly is a human readable language.

 

"So if you agree with the Ars post" - I don't usually agree or disagree with an entire article. I am capable of agreeing and disagreeing with separate points in the same article.

 

"At this point you are just nitpicking..." No, I have just been "nitpicking" that one thing since the start. If you hadn't been so blindly defensive (and actually read my posts about the article) you might have noticed that.

 

P.S.

I never said that McAfee wasn't full of shit either, the guy is a moron.

[dalekphalm]

3 hours ago, No Nrg said:

Updated OP to include video of interview McAfee did on CNN yesterday butting heads with former FBI officer Steve Rogers. McAfee is squarely against a backdoor key.

Steve Rogers? He squared off against Cap'n 'Murica himself

 

EDIT: Just watched the video - While John McAfee might be completely fucking insane, he makes some good points in the debate against the FBI agent. The FBI's reasoning is basically "Welp, foreign agents and hackers will break into it sooner or later... Fuck it, might as well get it first!"

[Tic-Tac]

There is no such thing as PRIVACY or SECURITY.

[LAwLz]

6 hours ago, steini1904 said:

Not necessarily, although it's rarely used:

 

By having a unique secret hardware key you can use your own key to mutate that hardware based key instead of decrypting the data.

 

Also there are algorithms that allow you to (asyncrosly) encrypt with two keys but decrypt with a single one. I believe to have anywhere a paper on that stuff. IIRC they're horribly insecure for the amount of calculation and bitdepth needed / used, but it's possible.

 

That allows you to use two devices for decrypting data without having the key at any time on any of the devices. Basically the server encypts the data with one key for storage. Then it requests from the client a second key, that the client generates on a random factor and sends that key to the server. The server encrypts the data with the second key and requests the decryption key from the client, the client generates the decryption key based on the user input (the encryption key on the server depends on that key) and the randomly generated key and sends it to the server.

 

That way there is never a unique decryption key.

 

At least that's how I believe it should work. I'm surely missing something here, since all you would need for decrypting the data is the second encryption key (on the server) and the decryption key (at some point also on the server). But it should have been very similar to this...

 

I'm gonna look it up and post an update. Damnit...

What you are talking about is called asymmetric encryption and that is most certainly not used for FDE. That is also irrelevant to the attack described in the video.

If you want to look it up search for "public-key cryptography". It is extremely slow compared to symmetrical encryption though, which is why it is not used for these purposes.

It has nothing to do with how iOS, BitLocker, Truecrypt or any other FDE program works.

 

5 hours ago, steini1904 said:

Not at all.

 

If an debuging interface is available, its rather a matter of seconds than minutes. Of course you would still have to analyze the code, but I have seen people who understood a 30,000+ lines C programm in less than the named half hour, so I'm not going to doubt that there are people who are able to do similar with some assembly routines. Especially since assembly is easier to read than most other languages (in my opinion), it's just a lot more steps for a similar task.

 

If you have to alter the hardware itself, well..., give it a week instead of half an hour, but it's still a reasonable period of time.

Define "debugging interface". And lol at assembly being easier to read than most other languages. The only explanation why you'd think that is because you don't know other languages. Even if you are a God at assembly you will still think it is harder to read than other languages, except maybe if you compare it to LOLCODE or brainfuck. And yes, according to McAfee himself you would need to "alter the hardware" since his method would require a hardware engineer as well. Not quite sure what he would do though.

This:

section     .text
global      _start

_start:

    mov     edx,len
    mov     ecx,msg
    mov     ebx,1
    mov     eax,4
    int     0x80

    mov     eax,1
    int     0x80

section     .data

msg     db  'Hello, world!',0xa
len     equ $ - msg

Is not easier to understand than this:

#include<stdio.h>

int main(void)	{
	printf("Hello, World!");
}

 

 

5 hours ago, steini1904 said:

Well, nobody can argue against that. Except maybe, that the person commenting pretended to be McA. That's why you don't try to appear smart if you got no idea what the hell you're talking about. If there is room for interpretation people are going to make favorable assumptions. Else you're just screwed.

Except you know, it's his YouTube channel and he linked to it on his Twitter, Facebook, Instagram and official website. You are really grasping at straws if you try to argue that it wasn't a statement that he made. There is also no room for interpretation here. He just flat out said " I will simply sidestep calling the secure enclave and pretend it doesn't exist.". That does not leave any room for interpretation at all. It is very clear what he meant, and it is very clear that he has no idea what the hell he is talking about.

 

5 hours ago, steini1904 said:

Would have been too easy, would it? Yes, I guess I'm takling about the UID (sorry, I have a fair bit of knowledge about anything EECS related, but not the iphone itself). I assumed it would be possible since Apple argued, that if they wrote a software that could be used to decrypt the phone, that this software would be exploited for sure.

The software Apple could potentially write would not extract the GUI. It would not use any method even remotely similar to what McAfee described.

 

5 hours ago, steini1904 said:

Or in a worst case scenario, all you can do is determining processing times of the chip in case of a correct and incorrect input, use an oscilloscope for triggering on that delay and hook the trigger to the module's powersupply.

That's what someone did. There is a video of it earlier in the thread. It is really slow though and the FBI would rather just have an easy way to break into whichever iPhone they want in the future.

 

 

2 hours ago, WaxyMaxy said:

You need to go back and read my first two posts again. You are arguing against things I didn't say. I never said the ars post was bad. I said they clearly don't know much about the topic at hand, that being reverse engineering software. That's not an insult or slander, its the truth and its not even a bad thing. For example, I don't know much about chemistry or medicine and that doesn't hurt me to say because that's not my field of expertise.

I still don't think there are any inaccurate statements in their post. The only thing you can argue is whether or not assembly is "human readable" or "barely human readable", which is a subjective statement. You're arguing semantics in order to discredit the article.

 

 

 

1 hour ago, Tic-Tac said:

There is no such thing as PRIVACY or SECURITY.

Of course there are. Both security and privacy are alive today, but it's thanks to people with your attitude that they are being threatened.

"The only thing necessary for the triumph of evil is for good men to do nothing".

-Edmund Burke

 

 

 

Edit:

McAfee had some very good responses to Steve Rogers in the interview. I will give him a thumbs up for that video.

[Tic-Tac]

Wake up boy. If you're not yet then you will be with all those "immigrants", that's for sure.