Fi8sVrs

mai du-te in vest cu ceasul tau tag heuer monaco sixty nine cauta consultant de afaceri

https://worldoftanks.ru/ Cu un pic de imaginatie pui plata btc, si corona ca tot e in trend cap sec

Ceasule omul a intrebat de investitii... Poate contacta un consultant de afaceri nu e obligatoriu btc

joc de strategie cmF6Ym9pdWwscm8= e liber Succes

//grep.app searches code from over a half million public repositories on GitHub. We’re hoping to add more soon… It searches for the exact string you enter, including any punctuation or other characters. You can also search by regular expression, using the RE2 syntax https://grep.app Source.

Searches For Threat Hunting and Security Analytics A collection of known log and / or event data searches for threat hunting and detection. They enumerate sets of searches used across many different data pipelines. Implementation details are for ELK. Adama is part of the SpaceCake project which is a set of hunts, searches, alerts, visualizations and data pipelines for for intrusion detection, security analytics and threat hunting using F/OSS (free and open source) tools Download git clone https://github.com/randomuserid/Adama.git Source

ma baieti, am intrat cu vpn de China, Japonia, am buchisit pe acolo stirile, Stirea e pentru prosti, si e veche de prin 2017 mureau toti din emisiunea Asia Express, Pepe, Capatos, Maruta.. cameramani producatori pana acum, ah.. si toti care va imbracati din Dragonul Rosu (Bucuresti) Cius, avezi grije

The US Navy has deployed ‘Optical Dazzling Interdictor, Navy,’ a new weapon better referred to as ODIN. This device is defensive in nature — it is designed to take down unwanted and potentially dangerous Unmanned Aerial Systems (UAS), more commonly called drones. The laser was installed on the USS Dewey, an Arleigh Burke-class guided-missile destroyer. Naval officials announced the deployment on February 20, explaining that this defensive laser system went from being a concept to a fully installed system in around 2.5 years. This is the first time a standalone system capable of functioning as a ‘dazzler’ has been operationally employed on a destroyer. ODIN was developed because UAS threats have ‘increased significantly,’ the Navy explains. The laser dazzler was installed on the destroyer back in November, but the US Navy has only revealed its deployment as of February. The technical details related to ODIN haven’t been revealed publicly for the obvious reason of needing to keep them a secret — if the way the system works are revealed, it could enable the development of new drone technologies that can beat the system. The USS Dewey will be used to conduct operations and experiments that will help shape the future deployment of this laser dazzler on other ships. This isn’t the first time the US Navy has detailed high-powered laser systems — in early May, for example, officials revealed that the Navy will install the HELIOS laser system from Lockheed Martin on the USS Preble in 2021. Via slashgear.com

https://tails.boum.org/doc/first_steps/startup_options/mac_spoofing/index.en.html#disable

NEW BATTERY HACKS WILL ‘SPARK’ YOUR IMAGINATION 🔋💥 (2020 Magic Hacks by Rick Lax) https://www.facebook.com/realRickLax/videos/2365827827060663/

apropo, de tot ai inviat mortii, cacatul acesta de copil e in blacklist http://panka.ru/9/454050.htm

CNP,, parinti, vecini (de incredere)

Ramburs?

Ah si sa iti reamintesc ca am 50cm in bicepsi, 120 kg si daca ne intalnim din fata tasturii s-ar putea sa numai haha si hihihi cu toti dintii m-ai jignit de 3x pana acum

nici pe mine nu ma amuza, in primul rand trebuia sa posteze in categoria potrivită (RST Bashed)

tu ai inceput, si presupun ca nu ai mai mult de 14 ani, nici nu ti s-a uscat cerneala pe buletin /ti-a bubuit adrenalina in tine cand ai vazut atatea notificari (hahaha) credeai ca te cauta Alba ca Zapada si cei VII pitici, ti le scot ursule //ai dat aiurea dislike, ma referam la ANALOG nu DIGITAL,

Aviz amatorilor: publi24, dormi vine cod filelist si intra pe vvv.alupigus.java si asta e

Bine ai revenit, ce user aveai?

cat oferi sa iti facem un header asemănator cu https://bacaul.ro ?

https://youtu.be/MgN4r1YufcI Tutorial: https://rstforums.com/forum/topic/69481-privacy-monitor-hacked-from-an-old-lcd-monitor/?tab=comments#comment-446411

Researcher published details about a backdoor mechanism he found in HiSilicon chips, but he did not report it to the vendor due to the lack of trust in it. The Russian security expert Vladislav Yarmak has published technical details about a backdoor mechanism he discovered in HiSilicon chips. The backdoor mechanism could allow attackers to gain root shell access and full control of device. The expert also published a Proof of concept code for the vulnerability. The expert did not disclose the flaw to HiSilicon due to the lack of trust in the vendor to address the issue. HiSilicon is a Chinese fabless semiconductor company based in Shenzhen and owned by Huawei, it is the largest domestic designer of integrated circuits in China. HiSilicon is the largest domestic designer of integrated circuits in China, its chips are used by millions of IoT devices worldwide, including security cameras, DVRs, and NVRs. The presence of backdoor mechanisms in the HiSilicon chips was already documented by other experts in the past. More recent versions of the devices had access enabled with a static root can be recovered from with (relatively) little computation effort. More recent firmware versions had Telnet access and debug port (9527/tcp) disabled by default, but they had open port 9530/tcp that could be exploited by attackers to send a special command to start telnet daemon and enable shell access with a static password ([1], [2], [3]). Yarmak explained that it is possible to exploit the backdoor by sending a series of commands over TCP port 9530 to devices based on HiSilicon chips. The commands allow the attacker to enable the Telnet service on a flawed device, then the attacker could log in using one of the following six Telnet credentials, and gain access to a root account. Login Password root xmhdipc root klv123 root xc3511 root 123456 root jvbzd root hi3518 Below the backdoor activation process described by the expert: Client opens connection to port TCP port 9530 of device and sends string OpenTelnet:OpenOnce prepended with byte indicating total message length. This step is last for previous versions of backdoor. Probably telnetd was already started if there no response after this step. Server (device) anwers with string randNum:XXXXXXXX where XXXXXXXX is 8-digit random decimal number. Client uses it’s pre-shared key and constructs encryption key as concatenation of received random number and PSK. Client encrypts random number with encryption key and sends it after string randNum:. Entire message is prepended with byte indicating total length of message. Server loads same pre-shared key from file /mnt/custom/TelnetOEMPasswd or uses default key 2wj9fsa2 if file is missing. Server performs encryption of random number and verifies result is identical with string from client. On success server sends string verify:OK or verify:ERROR otherwise. Client encrypts string Telnet:OpenOnce, prepends it with total length byte, CMD: string and sends to server. Server extracts and decryptes received command. If decryption result is equal to string Telnet:OpenOnce it responds with Open:OK, enables debug port 9527 and starts telnet daemon. Yarmak pointed out that despite the presence of backdoor mechanism was reported by experts in the past, the vendor was not able to address them and only opted to disable the Telnet service. The bad news for the users is that currently even if no patch is available for the backdoor, the expert decided to publish a proof-of-concept (PoC) code. As mitigation, users are recommended to “completely restrict network access to these devices to trusted users.” According to the expert, there are dozens of brands and hundreds of model vulnerable to hack, he referred to previous research conducted by another researcher that listed some of the vulnerable brands. window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = “3121199”; try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag(“762221962”, “300×250”, “762221962”); }); } catch (error) {} Via

CTRL + F

Overview This is a function that calculates the Gini coefficient of a numpy array. Gini coefficients are often used to quantify income inequality, read more here . The function in gini.py is based on the third equation from here, which defines the Gini coefficient as: Examples For a very unequal sample, 999 zeros and a single one, >>> from gini import * >>> a = np.zeros((1000)) >>> a[0] = 1.0 the Gini coefficient is very close to 1.0: >>> gini(a) 0.99890010998900103 For uniformly distributed random numbers, it will be low, around 0.33: >>> s = np.random.uniform(-1,0,1000) >>> gini(s) 0.3295183767105907 For a homogeneous sample, the Gini coefficient is 0.0: >>> b = np.ones((1000)) >>> gini(b) 0.0 Input Assumptions The Gini calculation by definition requires non-zero positive (ascending-order) sorted values within a 1d vector. This is dealt with within gini(). So these four assumptions can be violated, as they are controlled for: def gini(array): """Calculate the Gini coefficient of a numpy array.""" # based on bottom eq: http://www.statsdirect.com/help/content/image/stat0206_wmf.gif # from: http://www.statsdirect.com/help/default.htm#nonparametric_methods/gini.htm array = array.flatten() #all values are treated equally, arrays must be 1d if np.amin(array) < 0: array -= np.amin(array) #values cannot be negative array += 0.0000001 #values cannot be 0 array = np.sort(array) #values must be sorted index = np.arange(1,array.shape[0]+1) #index per array element n = array.shape[0]#number of array elements return ((np.sum((2 * index - n - 1) * array)) / (n * np.sum(array))) #Gini coefficient Notes It is significantly faster than (the current implementation of) PySAL's Gini coefficient function (see pysal.inequality.gini) and outputs are indistinguishable before approximately 6 decimal places. In other words, the two functions are arithmetically identical. It is slightly faster than the Gini coefficient function by David on Ellipsix. Many other Gini coefficient functions found online do not produce equivalent results, hence why I wrote this. Download Source

Chapter 1: The discovery I have a Wacom drawing tablet. I use it to draw cover illustrations for my blog posts, such as this one: Last week I set up my tablet on my new laptop. As part of installing its drivers I was asked to accept Wacom’s privacy policy. Being a mostly-normal person I never usually read privacy policies. Instead I vigorously hammer the “yes” button in an effort to reach the game, machine, or medical advice on the other side of the agreement as fast as possible. But Wacom’s request made me pause. Why does a device that is essentially a mouse need a privacy policy? I wondered. Sensing skullduggery, I decided to make an exception to my anti-privacy-policy-policy and give this one a read. In Wacom’s defense (that’s the only time you’re going to see that phrase today), the document was short and clear, although as we’ll see it wasn’t entirely open about its more dubious intentions (here’s the full text). In addition, despite its attempts to look like the kind of compulsory agreement that must be accepted in order to unlock the product behind it, as far as I can tell anyone with the presence of mind to decline it could do so with no adverse consequences. With that attempt at even-handedness out the way, let’s get kicking. In section 3.1 of their privacy policy, Wacom wondered if it would be OK if they sent a few bits and bobs of data from my computer to Google Analytics, “[including] aggregate usage data, technical session information and information about [my] hardware device.” The half of my heart that cares about privacy sank. The other half of my heart, the half that enjoys snooping on snoopers and figuring out what they’re up to, leapt. It was a disjointed feeling, probably similar to how it feels to get mugged by your favorite TV magician. Wacom didn’t say exactly what data they were going to send themselves. I resolved to find out. Chapter 2: Snooping on the snoopers I began my investigation with a strong presumption of chicanery. I was unable to imagine the project kickoff meeting in which Wacom decided to bundle Google Analytics with their device, which - remember - is essentially a mouse, but managed to restrain themselves from also grabbing some deliciously intrusive information while they were at it. I Googled “wacom google analytics”. There were a couple of Tweets and Reddit posts made by people who had also read Wacom’s privacy policy and been unhappy about its contents, but no one had yet tried to find out exactly what data Wacom were grabbing. No one had investigated Wacom’s understanding of the phrase “aggregate usage data” or whether it was anywhere near that of a reasonable person. I told my son to clear my schedule. He bashed two wooden blocks together in understanding, encouragement, and sheer admiration. In order to see what type of data Wacom was exfiltrating from my computer, I needed to snoop on the traffic that their driver was sending to Google Analytics. The most common way to do this is to set up a proxy server on your computer (I usually use Burp Suite). You tell your target program to send its traffic through your proxy. Your proxy logs the data it receives, and finally re-sends it on to its intended destination. When the destination sends back a response, the same process runs in reverse. +-------------------------------+ |My computer | | | | +------+ +------+ | +---------+ | |Wacom +------->+Burp +-------->+Google | | |Driver+<-------+Suite +<--------+Analytics| | +------+ +-+----+ | +---------+ | | Log requests and responses | v | | /track?data=... | | | +---------------------+---------+ Some applications, like web browsers, co-operate very well with proxies. They allow users to explicitly specify a proxy for them to to send their traffic through. However, other applications (including the Wacom tablet drivers) provide no such conveniences. Instead, they require some special treatment. Chapter 3: Wireshark I started with a simple approach that was unlikely to work but was worth a try. I opened Wireshark, a program that watches your computer’s network traffic. I wanted to use Wireshark to view the raw bytes that the Wacom driver was sending to Google Analytics. If Wacom was sending my data over unencrypted HTTP then I’d immediately be able to see all of its gory details, no extra work required. On the other hand, if Wacom was using encrypted TLS/HTTPS then I would be foiled. The traffic would appear as garbled nonsense that I would be unable to decrypt, since I wouldn’t know the keys used to encrypt it. I closed any noisy, network-connecting programs to reduce the chatter on the line, pressed Wireshark’s record button, and held onto my hat. Unfortunately, no unencrypted HTTP traffic appeared; only encrypted, garbled TLS. But there was good news amidst this setback. Wireshark also picks up DNS requests, which are used to look up the IP address that corresponds to a domain. I saw that my computer was making DNS requests to look up the IP address of www.google-analytics.com. The DNS response was coming back as 172.217.7.14, and lots of TLS-encrypted traffic was then heading out to that IP address. This meant that something was indeed talking to Google Analytics. I switched tactics and fired up Burp Suite proxy. Chapter 4: Burp Suite I now had two problems. First, I needed to persuade Wacom to send its Google Analytics traffic through Burp Suite. Second, I needed to make sure that Wacom would then complete a TLS handshake with Burp. To solve the first problem, I configured my laptop’s global HTTP and HTTPS proxies to point to Burp Suite. This meant that every program that respected these global settings would send its traffic through my proxy. Happily, it turned out that Wacom did respect my global proxy settings - my proxy quickly started logging “client failed TLS handshake” messages. This brought me to my second problem. Since Wacom was talking to Google Analytics over TLS, it required the server to present a valid TLS certificate for www.google-analytics.com. As far as Wacom is concerned, my proxy was now the server that it is talking to, not Google Analytics itself. This meant that I needed my proxy to present a certificate that Wacom would trust. (Burp must present a valid cert for www.google-analytics.com) | +---------------------|---------+ |My computer | | | v | | +------+ +------+ | +---------+ | |Wacom +------->+Burp +-------->+Google | | |Driver+<-------+Suite +<--------+Analytics| | +------+ +-+----+ | +---------+ | | Log requests and responses | v | | /track?data=... | | | +---------------------+---------+ The most difficult part of presenting such a certificate is that it needs to be cryptographically signed by a certificate authority that the program trusts. Burp Suite can generate and sign certificates for any domain, no problem, but since by default no computer or program trusts Burp Suite as a certificate authority, the certificates it signs are rejected (I’ve written much more about TLS and HTTPS here and here). Once again, the process of persuading a web browser to trust Burp’s root certificate is well-documented, but for a thick application like Wacom I’d need to do something slightly different. I therefore used OSX’s Keychain to temporarily add Burp’s certificate to my computer’s list of root certificates. I assumed that Wacom would load its list of root certificates from my computer, and that by adding Burp to this list, Wacom would start to trust Burp and would complete a TLS handshake with my proxy. I sat and waited. I watched Wireshark and Burp at the same time. If Wacom failed to connect to Burp, I’d see this failure in Wireshark. I was quite excited. Nothing happened. I wondered if the data dumping was triggered by a timer, or by some particular activity, or by both. I tried drawing something using my Wacom tablet. Still nothing. I plugged and unplugged it. Nothing. Then I went into the Wacom Driver Settings and restarted the driver. Everything happened. When I restarted the Wacom driver, rather than lose all the data it had accumulated, the driver fired off everything it had collected to Google Analytics. This data materialized in my Burp Suite. I took a look. My heart experienced the same half-down-half-up schism as it had half an hour ago. Some of the events that Wacom were recording were arguably within their purview, such as “driver started” and “driver shutdown”. I still don’t want them to take this information because there’s nothing in it for me, but their attempt to do so feels broadly justifiable. What requires more explanation is why Wacom think it’s acceptable to record every time I open a new application, including the time, a string that presumably uniquely identifies me, and the application’s name. Chapter 5: Analysis I suspect that Wacom doesn’t really think that it’s acceptable to record the name of every application I open on my personal laptop. I suspect that this is why their privacy policy doesn’t really admit that this is what that they do. I imagine that if pressed they would argue that the name of every application I open on my personal laptop falls into one of their broad buckets like “aggregate data” or “technical session information”, although it’s not immediately obvious to me which bucket. It’s well-known that no one reads privacy policies and that they’re often a fig leaf of consent at best. But since Wacom’s privacy policy makes no mention of their intention to record the name of every application I open on my personal laptop, I’d argue that it doesn’t even give them the technical-fig-leaf-right to do so. In fact, I’d argue that even if someone had read and understood Wacom’s privacy policy, and had knowingly consented to a reasonable interpretation of the words inside it, that person would still not have agreed to allow Wacom to log and track the name of every application that they opened on their personal laptop. Of course, I’m not a lawyer, and I assume that whoever wrote this privacy policy is. Wacom’s privacy policy does say that they only want this data for product development purposes, and on this point I do actually believe them. This might be naive, since who knows what goes on behind the scenes when large troves of data are involved. Either way, while I do understand that product developers like to have usage data in order to monitor and improve their offerings, this doesn’t give them the right to take it. I care about this for two reasons. The first is a principled fuck you. I don’t care whether anything materially bad will or won’t happen as a consequence of Wacom taking this data from me. I simply resent the fact that they’re doing it. The second is that we can also come up with scenarios that involve real harms. Maybe the very existence of a program is secret or sensitive information. What if a Wacom employee suddenly starts seeing entries spring up for “Half Life 3 Test Build”? Obviously I don’t care about the secrecy of Valve’s new games, but I assume that Valve does. We can get more subtle. I personally use Google Analytics to track visitors to my website. I do feel bad about this, but I’ve got to get my self-esteem from somewhere. Google Analytics has a “User Explorer” tool, in which you can zoom in on the activity of a specific user. Suppose that someone at Wacom “fingerprints” a target person that they knew in real life by seeing that this person uses a very particular combination of applications. The Wacom employee then uses this fingerprint to find the person in the “User Explorer” tool. Finally the Wacom employee sees that their target also uses “LivingWith: Cancer Support”. Remember, this information is coming from a device that is essentially a mouse. This example is admittedly a little contrived, but it’s also an illustration that, even though this data doesn’t come with a name and social security number attached, it is neither benign nor inert. Chapter 6: Conclusion In some ways it feels unfair to single out Wacom. This isn’t the dataset that’s going to complete the embrace of full, totalitarian surveillance capitalism. Nonetheless, it’s still deeply obnoxious. A device that is essentially a mouse has no legitimate reasons to make HTTP requests of any sort. Maybe Wacom could hide in the sweet safety of murky territory if they released some sort of mobile app integration or a weekly personal usage report that required this data, but until then I’m happy to classify them as an obligingly clear case of nefariousness. Nonetheless, I’m not about to incinerate my Wacom tablet and buy a different one. These things are expensive, and privacy is hard to put a price on. If you too have a Wacom tablet (presumably this tracking is enabled for all of their models), open up the “Wacom Desktop Center” and click around until you find a way to disable the “Wacom Experience Program”. Then the next time you’re buying a tablet, remember that Wacom tries to track every app you open, and consider giving another brand a go. Epilogue I finished the first draft of this article three weeks ago. I set up Burp Suite proxy again so that I could grab some final screenshots of the data that Wacom was purloining. I restarted the Wacom driver, as per usual. But nothing happened. Wacom weren’t illegitimately siphoning off my personal usage data any more. The bastards. I contemplated pretending I hadn’t seen this and publishing my post anyway. Then I contemplated publishing it with an additional coda explaining this latest development. However, the title “Wacom drawing tablets used to track the name of every application that you open but now seem to have stopped for some reason” didn’t feel very snappy. I decided to do some more investigating. I had previously noticed that, before sending data to Google Analytics, the Wacom driver sent a HEAD request to the URL http://link.wacom.com/analytics/analytics.xml. I hadn’t been able to work out why, and until now I hadn’t thought much of it. However, now Wacom was responding to this request with a 404 “Not Found” status code instead of 200 “OK”. I realized that the request must be some kind of pre-flight check that allowed Wacom to turn off analytics collection remotely without requiring users to install a driver update. Now that the request was failing, Wacom were not sending themselves my data. I dug around in the driver’s logfile and found the following snippet that confirmed my suspicions: I wondered if Wacom had gotten wise to what I was up to and panic-disabled their tracking. This seemed unlikely, although the timing was rather coincidental. I decided that Wacom had probably simply made a boneheaded mistake and accidentally broken their own command-and-control center. I impatiently waited for them to realize their goof and bring their data exfiltration operation back online. I contemplated emailing Wacom to alert them to their problem, but couldn’t come up with a sufficiently innocuous way of doing so. I decided to wait until the end of the month before doing anything, in case the data was used for generating monthly reports. I hoped that on January 31st Wacom would notice that their graphs were broken and bring their system back online. On February 3rd I checked in and was elated at what I saw: I had no idea who Rick was, but I was glad he was back. Wacom were illegitimately siphoning off my personal data again, and I couldn’t be happier. I grabbed some better screenshots, fixed some grammar, and hit publish. The rest is history. Source