Leaderboard

Dupa ce ai preluat raspunsul si ai retinut datele json intr-o variabila, ai 2 cazuri: - fie citesti si interpretezi automat ca json outputul si ai un json object intr-o variabila json_value - fie ai un string ca output si faci json_value = json.loads(output_text) Dupa ce ai variabila respectiva poti accesa valori de la chei in mai multe feluri: 1. main_principal_animals = json_value["mainPrincipalAnimals"] (poti sa verifici daca o cheie 'alpha' exista in dictionar cu < if 'alpha' in json_value: >) 2. main_principal_animals = json_value.get('mainPrincipalAnimals', 'Pisi') <- in cazul in care cheia 'mainPrincipalAnimals' nu exista, variabila va retine stringul "Pisi" Ca sa iti raspund la intrebarile tale acum: 1. dictionary = json.loads(results.getvalue()) 2. cum am zis mai sus un pic 3. depinde de baza de date pe care o folosesti dar daca folosesti baza de date nosql cu documente, ar fi de ajuns sa inserezi jsonul tau cu informatiile dorite.

Mi-e prea lene sa scriu: https://stackoverflow.com/a/8812069/6165050

>>> import json >>> a='{"test":"1","tes2":2}' >>> parsed=json.loads(a) >>> for p in parsed: ... print p ... print parsed[p] ... test 1 tes2 2 >>>

Nu are ce dovezi sa aduca daca zice ca nu l-a primit.E complicat cu produse care nu au tracking number ce poate fi verificat online, din China sau Amazon logistics de exemplu.Doar eu pot urmari coletul, vad ca l-a primit 100%, dar paypalul nu accepta asemenea dovezi, am patit-o de multe ori, sunt sute de scammeri care profita de asta. Sau persoane care se razgandesc si dau "not as described" la produs doar ca sa nu plateasca return shipping-ul.Nu am ce face, dau refund, accept return, in 99% din cazuri paypalul tine cu cel care da banul. Dar una peste alta, datorita paypal-ului castig si eu niste bani, trebuie sa urmez regulilor lui, oricare ar fi ele, nu cred ca exista ceva asemanator care sa aiba macar a 10-a parte din clientii lui.

Welcome to this tutorial series on ARM assembly basics. This is the preparation for the followup tutorial series on ARM exploit development (not published yet). Before we can dive into creating ARM shellcode and build ROP chains, we need to cover some ARM Assembly basics first. The following topics will be covered step by step: ARM Assembly Basics Tutorial Series: Part 1: Introduction to ARM Assembly Part 2: Data Types Registers Part 3: ARM Instruction Set Part 4: Memory Instructions: Loading and Storing Data Part 5: Load and Store Multiple Part 6: Conditional Execution and Branching Part 7: Stack and Functions To follow along with the examples, you will need an ARM based lab environment. If you don’t have an ARM device (like Raspberry Pi), you can set up your own lab environment in a Virtual Machine using QEMU and the Raspberry Pi distro by following this tutorial. If you are not familiar with basic debugging with GDB, you can get the basics in this tutorial. Why ARM? This tutorial is generally for people who want to learn the basics of ARM assembly. Especially for those of you who are interested in exploit writing on the ARM platform. You might have already noticed that ARM processors are everywhere around you. When I look around me, I can count far more devices that feature an ARM processor in my house than Intel processors. This includes phones, routers, and not to forget the IoT devices that seem to explode in sales these days. That said, the ARM processor has become one of the most widespread CPU cores in the world. Which brings us to the fact that like PCs, IoT devices are susceptible to improper input validation abuse such as buffer overflows. Given the widespread usage of ARM based devices and the potential for misuse, attacks on these devices have become much more common. Yet, we have more experts specialized in x86 security research than we have for ARM, although ARM assembly language is perhaps the easiest assembly language in widespread use. So, why aren’t more people focusing on ARM? Perhaps because there are more learning resources out there covering exploitation on Intel than there are for ARM. Just think about the great tutorials on Intel x86 Exploit writing by the Corelan Team – Guidelines like these help people interested in this specific area to get practical knowledge and the inspiration to learn beyond what is covered in those tutorials. If you are interested in x86 exploit writing, the Corelan tutorials are your perfect starting point. In this tutorial series here, we will focus on assembly basics and exploit writing on ARM. ARM processor vs. Intel processor There are many differences between Intel and ARM, but the main difference is the instruction set. Intel is a CISC (Complex Instruction Set Computing) processor that has a larger and more feature-rich instruction set and allows many complex instructions to access memory. It therefore has more operations, addressing modes, but less registers than ARM. CISC processors are mainly used in normal PC’s, Workstations, and servers. ARM is a RISC (Reduced instruction set Computing) processor and therefore has a simplified instruction set (100 instructions or less) and more general purpose registers than CISC. Unlike Intel, ARM uses instructions that operate only on registers and uses a Load/Store memory model for memory access, which means that only Load/Store instructions can access memory. This means that incrementing a 32-bit value at a particular memory address on ARM would require three types of instructions (load, increment and store) to first load the value at a particular address into a register, increment it within the register, and store it back to the memory from the register. The reduced instruction set has its advantages and disadvantages. One of the advantages is that instructions can be executed more quickly, potentially allowing for greater speed (RISC systems shorten execution time by reducing the clock cycles per instruction). The downside is that less instructions means a greater emphasis on the efficient writing of software with the limited instructions that are available. Also important to note is that ARM has two modes, ARM mode and Thumb mode. Thumb mode is intended primarily to increase code density by using 16-bit instead of 32-bit instructions. More differences between ARM and x86 are: In ARM, most instructions can be used for conditional execution. The Intel x86 and x86-64 series of processors use the little-endian format The ARM architecture was little-endian before version 3. Since then ARM processors became BI-endian and feature a setting which allows for switchable endianness. There are not only differences between Intel and ARM, but also between different ARM version themselves. This tutorial series is intended to keep it as generic as possible so that you get a general understanding about how ARM works. Once you understand the fundamentals, it’s easy to learn the nuances for your chosen target ARM version. The examples in this tutorial were created on an ARMv6 (Raspberry Pi 1). Some of the differences include: Registers on ARMv6 and ARMv7 start with the letter R (R0, R1, etc), while ARMv8 registers start with the letter X (X0, X1, etc). The amount of registers might also vary from 30 to around 40 general-purpose registers, of which only 16 are accessible in User Mode. The naming of the different ARM versions might also be confusing: ARM family ARM architecture ARM7 ARM v4 ARM9 ARM v5 ARM11 ARM v6 Cortex-A ARM v7-A Cortex-R ARM v7-R Cortex-M ARM v7-M Writing Assembly Before we can start diving into ARM exploit development we first need to understand the basics of Assembly language programming, which requires a little background knowledge before you can start to appreciate it. But why do we even need ARM Assembly, isn’t it enough to write our exploits in a “normal” programming / scripting language? It is not, if we want to be able to do Reverse Engineering and understand the program flow of ARM binaries, build our own ARM shellcode, craft ARM ROP chains, and debug ARM applications. You don’t need to know every little detail of the Assembly language to be able to do Reverse Engineering and exploit development, yet some of it is required for understanding the bigger picture. The fundamentals will be covered in this tutorial series. If you want to learn more you can visit the links listed at the end of this chapter. So what exactly is Assembly language? Assembly language is just a thin syntax layer on top of the machine code which is composed of instructions, that are encoded in binary representations (machine code), which is what our computer understands. So why don’t we just write machine code instead? Well, that would be a pain in the ass. For this reason, we will write assembly, ARM assembly, which is much easier for humans to understand. Our computer can’t run assembly code itself, because it needs machine code. The tool we will use to assemble the assembly code into machine code is a GNU Assembler from the GNU Binutils project named as which works with source files having the *.s extension. Once you wrote your assembly file with the extension *.s, you need to assemble it with as and link it with ld: $ as program.s -o program.o $ ld program.o -o program Another way to compile assembly code is to use GCC as shown below: $ gcc -c program.s -o program.o $ gcc program.o -o program The GCC approach introduces quite some overhead for the application, such as additional code (libraries), etc. This makes a properly written program to exit normally (without SIGSEGV crashes) and in some cases might be a preferred choice. However, for simplicity reasons as and ld are used throughout the tutorials here by launching the proof of concept code in the debugging (GDB) environment. Assembly under the hood Let’s start at the very bottom and work our way up to the assembly language. At the lowest level, we have our electrical signals on our circuit. Signals are formed by switching the electrical voltage to one of two levels, say 0 volts (‘off’) or 5 volts (‘on’). Because just by looking we can’t easily tell what voltage the circuit is at, we choose to write patterns of on/off voltages using visual representations, the digits 0 and 1, to not only represent the idea of an absence or presence of a signal, but also because 0 and 1 are digits of the binary system. We then group the sequence of 0 and 1 to form a machine code instruction which is the smallest working unit of a computer processor. Here is an example of a machine language instruction: 1110 0001 1010 0000 0010 0000 0000 0001 So far so good, but we can’t remember what each of these patterns (of 0 and 1) mean. For this reason, we use so called mnemonics, abbreviations to help us remember these binary patterns, where each machine code instruction is given a name. These mnemonics often consist of three letters, but this is not obligatory. We can write a program using these mnemonics as instructions. This program is called an Assembly language program, and the set of mnemonics that is used to represent a computer’s machine code is called the Assembly language of that computer. Therefore, Assembly language is the lowest level used by humans to program a computer. The operands of an instruction come after the mnemonic(s). Here is an example: MOV R2, R1 Now that we know that an assembly program is made up of textual information called mnemonics, we need to get it converted into machine code. As mentioned above, in the case of ARM assembly, the GNU Binutils project supplies us with a tool called as. The process of using an assembler like as to convert from (ARM) assembly language to (ARM) machine code is called assembling. In summary, we learned that computers understand (respond to) the presence or absence of voltages (signals) and that we can represent multiple signals in a sequence of 0s and 1s (bits). We can use machine code (sequences of signals) to cause the computer to respond in some well-defined way. Because we can’t remember what all these sequences mean, we give them abbreviations – mnemonics, and use them to represent instructions. This set of mnemonics is the Assembly language of the computer and we use a program called Assembler to convert code from mnemonic representation to the computer-readable machine code, in the same way a compiler does for high-level languages. https://azeria-labs.com/arm-data-types-and-registers-part-2/ https://azeria-labs.com/arm-instruction-set-part-3/ https://azeria-labs.com/memory-instructions-load-and-store-part-4/ https://azeria-labs.com/load-and-store-multiple-part-5/ https://azeria-labs.com/arm-conditional-execution-and-branching-part-6/ https://azeria-labs.com/functions-and-the-stack-part-7/ Sursa: https://azeria-labs.com/writing-arm-assembly-part-1/

The team details what they call “cloak and dagger” exploits which can take over the UI of most versions of Android (including 7.1.2). Given it’s nature, it is difficult to fix and also difficult to detect. Cloak and Dagger is an exploit that takes advantage of two permissions in order to take control the UI without giving the user a chance to notice the malicious activity. The attack uses two permissions: SYSTEM_ALERT_WINDOW (“draw on top“) and BIND_ACCESSIBILITY_SERVICE (“a11y“) that are very commonly used in Android apps. We have outlined this in the past, but what makes this vulnerability so acute is the fact that applications requesting SYSTEM_ALERT_WINDOW are automatically granted this permission when installed via the Google Play Store. As for enabling an Accessibility Service, a malicious application is able to quite easily socially engineer a user into granting it. The malicious application could even be set up to use an Accessibility Service for a semi-legitimate purpose, such as monitoring when certain applications are open to change certain settings. Once these two permissions have been granted, the number of attacks that could occur are numerous. Stealing of PINs, two-factor authentication tokens, passwords, or even denial-of-service attacks are all possible. This is thanks to the combination of overlays to trick the user into thinking they are interacting with a legitimate app and the Accessibility Service being used to intercept text and touch input (or relay its own input). We theorized such a vulnerability a few months back, wherein we would create a proof-of-concept application that uses SYSTEM_ALERT_WINDOW and BIND_ACCESSIBILITY_SERVICE in order to draw an overlay over the password entry screen in the XDA Labs app and intercept key input to swipe passwords. This application we envisioned would be an auto-rotation managing application which would use an overlay for the purposes of drawing an invisible box on screen to control rotation (rather than request WRITE_SETTINGS which would raise flags) and an Accessibility service to allow the user to control auto-rotate profiles on a per-app basis. In theory, this would be one example of an application using “cloak-and-dagger.” However, none among our team were willing to risk their developer accounts by challenging Google’s automated app scanning systems to see if our proof-of-concept exploit would be allowed on the Play Store. In any case, these researchers did the work and submitted test applications to prove that the use of these two permissions can indeed be a major security issue: As you can see, the attacks are invisible to users and allow full control over the device. Currently all versions of Android starting from Android 5.1.1 to Android 7.1.2 are vulnerable to this exploit, given the fact that it takes advantage of two permissions otherwise used for completely legitimate purposes. Don’t expect a true fix for this issue to come to your device anytime soon, though it should be noted that the changes made to SYSTEM_ALERT_WINDOW in Android O will partially address this flaw by disallowing malicious apps from completely drawing over the entire screen. Furthermore, Android O now alerts with via notification if an application is actively drawing an overlay. With these two changes, it’s less likely that a malicious application can get away with the exploit if the user is attentive. How do you protect yourself on versions before Android O? As always, install only apps that you trust from sources that you trust. Make sure the permissions they request line up with what you expect. As for the hundreds of millions of regular users out there, according to a Google spokesperson Play Store Protect will also provide necessary fixes to prevent the cloak and dagger attacks. How exactly it will accomplish this is unclear, but hopefully it involves some way of detecting when these two permissions are being used maliciously. I doubt that it would be able to detect all such cases, though, so in any case it’s best for you to monitor what permissions are being granted to each application you install. SOURCE: https://www.xda-developers.com/cloak-and-dagger-exploit-uses-overlays-and-accessibility-services-to-hijack-the-system/

Mie mi s-a intamplat problema asta odata anul trecut prin august, si a doua oara acum o luna. Chiar daca aveam un cont personal, verificat cu proof of address si ID, mi-au cerut diverse date despre dovezile de livrare a bunurilor, fiind un raspuns automat al PayPal din pricina numarului mare de tranzactii pe o perioada scurta de timp (aparent de la 200 de tranzactii pe luna in sus esti considerat business si trebuie sa oferi documentele si dovezile de livrare a bunurilor) . Cu cazul de anul trecut mi-am batut capul, am vorbit si am ajuns la inchiderea contului si blocarea banilor timp de jumatate de an, ce i-am putut recupera in primavara asta. Daca nu esti din US si esti persoana fizica, aici gasesti singurul document pe care poti sa-l dai: https://www.irs.gov/pub/irs-pdf/fw8ben.pdf Part I, fill out all fields. Line 5 and 7 can often be left blank, if applicable. Part 2 - Skip Part 3 - Sign and date the form. la 6 Foreign tax identifying number (see instructions) este CNP-ul tau .

[*] Hack instagram accounts with bruteforce [*] for more proxy - go to https://www.torvpn.com/en/proxy-list Download instahack-master.zip Source

Researchers warned that subtitles can be hacked and made malicious, allowing attackers to take complete control of devices running vulnerable versions of Kodi, Popcorn Time and VLC. Do you use Kodi, Popcorn Time, VLC or Stremio? Do you use subtitles while you watch? If so, then you need to update the platform as Check Point researchers revealed that not all subtitles are benign text files and hackers can remotely take control of any device running vulnerable software via malicious subtitles. The attack is not in the wild, since Check Point developed the proof of concept attack vector; however, with news of the attack vector and an estimated 200 million video players and streaming apps running vulnerable software, attackers might jump on the malicious subtitle wagon to gain remote access to victims’ systems. Check Point pointed out that Kodi has nearly 40 million visitors per month, VLC has over 170 million downloads and Popcorn Time likely also has millions of viewers. With all being vulnerable, researchers called the malicious subtitle attack “one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.” Subtitles are often treated as a trusted source, automatically downloading from third-party repositories. There are dozens of subtitle formats and numerous shared online repositories like OpenSubtitles.org. The repositories can be gamed, allowing attackers “to take complete control over the entire subtitle supply chain.” After an attacker manipulates subtitle rankings, a subtitle with malicious code would have the highest rank and automatically be downloaded without any user interaction required or even a man-in-the-middle attack. In different attack scenarios, instead of a video player or streamer automatically downloading the malicious subtitle file, a user can be tricked to visit a site using one of the vulnerable players or opting to download a tainted subtitle file to use with a video. You can see Check Point’s proof of concept attack in the video below. Do you use Kodi, Popcorn Time, VLC or Stremio? Do you use subtitles while you watch? If so, then you need to update the platform as Check Point researchers revealed that not all subtitles are benign text files and hackers can remotely take control of any device running vulnerable software via malicious subtitles. The attack is not in the wild, since Check Point developed the proof of concept attack vector; however, with news of the attack vector and an estimated 200 million video players and streaming apps running vulnerable software, attackers might jump on the malicious subtitle wagon to gain remote access to victims’ systems. Check Point pointed out that Kodi has nearly 40 million visitors per month, VLC has over 170 million downloads and Popcorn Time likely also has millions of viewers. With all being vulnerable, researchers called the malicious subtitle attack “one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.” Subtitles are often treated as a trusted source, automatically downloading from third-party repositories. There are dozens of subtitle formats and numerous shared online repositories like OpenSubtitles.org. The repositories can be gamed, allowing attackers “to take complete control over the entire subtitle supply chain.” After an attacker manipulates subtitle rankings, a subtitle with malicious code would have the highest rank and automatically be downloaded without any user interaction required or even a man-in-the-middle attack. In different attack scenarios, instead of a video player or streamer automatically downloading the malicious subtitle file, a user can be tricked to visit a site using one of the vulnerable players or opting to download a tainted subtitle file to use with a video. You can see Check Point’s proof of concept attack in the video below. Check Point summarized the damage as: The attack vector “relies heavily on the poor state of security in the way various media players process subtitle files and the large number of subtitle formats.” The researchers added, “Media players often need to parse together multiple subtitle formats to ensure coverage and provide a better user experience, with each media player using a different method. Like other, similar situations which involve fragmented software, this results in numerous distinct vulnerabilities.” Check Point isn’t giving out too many technical details on how to pull off the attack, since the company believes there are similar flaws in other media players. However, Kodi, VLC, Popcorn Time and Stremio were all contacted and have issued fixes for the vulnerability. After Kodi rolled out a fix, XBMC Foundation’s Project lead Martijn Kaijser urged Kodi users to install the newest version as “any previous Kodi version will not get any security patch.” Via networkworld.com

Exploit Tutorials - Primal Security Podcast Hello RST : Contents : 0x0 Exploit Tutorial: Buffer Overflow – Vanilla EIP Overwrite 0x1 Exploit Tutorial: XSS 0x2 Exploit Tutorial: Web Hacking with Burp Suite 0x3 Exploit Tutorial: Buffer Overflow – SEH Bypass 0x4 Exploit Tutorial: Social Engineering Toolkit (SET) 0x5 Exploit Tutorial: Porting Your First Exploit to Metasploit 0x6 Exploit Tutorial: msfpayload and Backdooring EXEs 0x7 Exploit Tutorial: Bad Character Analysis 0x8 Exploit Tutorial: The Elusive Egghunter 0x9 Exploit Tutorial: Web Shells Source : http://www.primalsecurity.net/tutorials/exploit-tutorials/ Copyright 2012-2015 Primal Security | All Rights Reserved iF U LoVe PyThOn : Python Tutorials Regards NO-MERCY