Nytro

@nedo: O adresa IPv4 are 4 bytes. Adresa IP RST este: 188.240.88.237 In hexazecimal, fiecare byte: 0xBC = 188, 0xF0 = 240, 0x58 = 88, 0xED = 237 => http://0xBCF058ED Daca compunem un singur "int" de 4 bytes, din aceste numere, adica 0xBCF058ED, in zecimal este 3169868013. @dany: Deci, ce limbaj ai ales?

[h=2]Script to Find All IP Addresses on a Internal Network[/h]Posted by purehate in Code Snippets at 12:56 PM I was working on a presentation this morning and as I was writing I realized I did not have a quick fast way to make a list of all the internal Ips on a LAN (Local Area network). Many of the tools I use including nmap, nessus and nexpose will accept a list of ips so I decided to whip up a quick dirty shell script to get the job done. I may clean it up in the future but for now it does its job. This is meant to work on Backtrack 4 but in its current state it will work on any Debian based distro. As always with any code found on the internet you use this at your own risk. Also I am sure this can be done better but like I said it was a 10 minute fix. Here is the script: Save it as ip_list.sh and give it execute permissions with chmod 755 01 #!/bin/bash 02 # Quick a dirty script to make a list of internal ips on a LAN 03 # Questions, Comments or Death Threats can be sent to crackers@question-defense.com 04 # This is made for Backtrack 4 so every one else is on their own 05 06 #set some variables 07 subnet=$(echo $2 | cut -f 1 -d .) 08 outfile=$subnet"_ip.list" 09 temp=ip.tmp 10 11 #Check for the proper arguments 12 if [ -z "$1" ]; then 13 echo usage: $0 interface subnet 14 echo "example: arp-scan eth0 192.168.1.0/24" 15 exit 16 fi 17 18 if [ -z "$2" ]; then 19 echo usage: $0 interface subnet 20 echo "example: arp-scan eth0 192.168.1.0/24" 21 exit 22 fi 23 24 #check for arp-scan 25 echo "Checking for arp-scan" 26 dpkg --status arp-scan | grep -q not-installed 27 28 if [ $? -eq 0 ]; then 29 echo "Downloading arp-scan...." 30 sudo apt-get install arp-scan -y 31 else 32 echo "arp-scan found!" 33 fi 34 35 #running the scan 36 /usr/bin/arp-scan $1 $2 > $temp 2>/dev/null 37 cat ip.tmp | grep $subnet | awk {'print $1'} > $outfile 38 rm -rf $temp 39 40 count=$(wc -l $outfile | awk {'print $1'}) 41 echo $count "active ip's found" 42 dir=$(pwd) 43 echo "Your file is named" $outfile "and is located in the" $dir "directory" Sursa: Script to Find All IP Addresses on a Internal Network

Aranea é un DNS Spoofer molto veloce e versatile, basato interamente su libpcap. Volevamo un tool più flessibile rispetto a quelli già pubblicati, cosi abbiamo sviluppato aranea come applicazione multithreaded capace di interagire con le richieste utilizzando regular expressions. Download: https://github.com/TigerSecurity/aranea Sursa: Tools – Tiger Security S.r.l.

[h=5]Web Backdoor Finder Light[/h] Web Backdoor Finder Light (WBFL) è uno strumento che permette di rilevare all’interno del proprio filesystem backdoor di tipo web. WBFL è uno script essenziale e veloce che si occupa di rilevare e segnalare funzioni php generalmente malevole utilizzate all’interno di pagine presenti nel filesystem al fine di evidenziare possibili backdoor web presenti. Download: https://github.com/TigerSecurity/Web-BackDoor-Finder-Light Sursa: Tools – Tiger Security S.r.l.

Gerix-Wifi-Cracker Gerix-Wifi-Cracker é un’intuitiva interfaccia grafica per la suite di strumenti aircrack-ng, nonché per altri strumenti complementari (e.g. pyrit). È possibile utilizzare il programma per vari tipi di attacco contro reti wifi: Cracking WEP (chop-chop, fragmentation) Cracking WPA (basato su wordlist o rainbow tables) Attacchi client-side Creazione di fake access-point L’interfaccia é semplice da usare, include numerose utilities per facilitare le operazioni agli utenti, e il salvataggio dei dati ottenuti. Download: https://github.com/TigerSecurity/gerix-wifi-cracker Sursa: Tools – Tiger Security S.r.l.

E de la tara, probabil profesoara in cine stie ce sat de tigani.

In sfarsit cineva care observa.

Lasati prostiile, o sa aveti destul timp si sa lucrati, toata viata. Mai aveti si voi cativa ani de "libertate", folositi-i cu cap. PS: Puteti face ceva proiecte pentru un viitor CV.

Cyber-war...

Poveste: http://www.ovidiuav.com/2012/06/19/acum-5-ani-am-scris-un-e-mail/ Link: http://www.futureme.org/

Exe?

Esti o victima a pirateriei.

[h=1]Confirmat: Virusul Flame, creat de americani si israelieni[/h]de Liviu Petrescu | 21 iunie 2012 Speculatiile cu privire la originea virusului Flame, considerat de Kaspersky Lab prea puternic pentru a fi creat de hackeri, au fost confirmate. Flame a fost creat de americani si israelieni pentru a stopa programul nuclear din Iran, scrie Washington Post. La mai putin de doua saptamani dupa ce virusul a fost eliminat chiar de creatorii sai, oficialii americani au confirmat originea virusului catre Washington Post, citat de ArsTechnica. Virusul Flame este considerat cel mai puternic virus informatic din istoria tehnologiei informatice, deoarece a obtinut acces la toate perifericele PC-urilor infectate, inclusiv webcam-uri si microfoane si a ramas nedetectat timp de aproape 2 ani. Potrivit informatiile de la Washington, virusul informatic Flame folosit in Orientul Mijlociu a fost dezvoltat in cooperare de catre NSA, CIA si Israel. Descoperirea virusului a fost provocata de catre o incursiune unilaterala a israelienilor, sustin oficialii americani. Sursa: Confirmat: Virusul Flame, creat de americani si israelieni | Hit.ro

Smecherii: http://ntcore.com/articles.php

Windows SDK User Interface: How can I emulate keyboard events in an application? - CodeGuru Forums How to use SendInput? » bits and bytes SendInput Example In C# Virtual On-Screen Keyboard Example - CodeProject [C++] Keyboard/Mouse emulation - Classes and Code Snippets - CODECALL Programming Forum

[h=1]5 motive pentru care Microsoft Surface ar putea bate iPad-ul[/h]de Liviu Petrescu | 20 iunie 2012 Odata cu lansarea tabletelor Microsoft Surface, multi analisti IT au ajuns la concluzia ca iPad are in sfarsit un concurent pe masura. Chiar daca Microsoft nu a anuntat inca pretul tabletei, entuziasmul pentru Surface este mare si pare intemeiat. Vezi 5 motive pentru care Microsoft Surface ar putea bate iPad-ul, potrivit CNN. 1. Marimea si grosimea Designul excelent al iPad a facut tabletele concurentei sa para butucanoase. Microsoft a optat pentru o marime de 10,6 inci, putin mai mare decat tableta Apple, dar unul dintre elemente cheie pentru succesul Microsoft Surface este grosimea. Surface RT are o grosime cu o zecime de milimetru mai mica decat noul iPad, deci utilizatorii vor fi multumiti. Totul despre noile tablete Microsoft Surface, cu Windows RT si Windows 8 Pro Surface Pro are insa o grosime semnificativ mai mare, acceptabila insa pentru cei considera noua tableta Windows un ultrabook cu ecran tactil. 2. Tastaturile de tableta Microsoft a decis sa ofere consumatorilor ceea ce a Apple a refuzat de la inceput: tastaturi compacte care usureaza folosirea acesteia. Cu o grosime de numai 3mm, Touch Cover ofera o tastatura tactila integrata in carcasa ce poate fi folosita si ca stand, totul disponibil in variante de culoare: negru, rosu, albastru si roz. Type Cover are o grosime de 5mm, insa ofera si un trackpad integrat, ce permite practic folosirea tabletei Microsoft Surface cu Windows 8 Pro ca desktop. 3. Porturile USB Incapatanarea Apple de a nu oferi cumparatorilor ceea ce si-au dorit de la inceput, un port USB pentru conectarea simpla la orice alt gadget, devine o problema mare pentru iPad. Chiar daca utilizatorii au la dispozitie solutii cloud si Wi-Fi pentru iPad, multi cumparatori ar putea prefera cele doua porturi USB ale Microsoft Surface, prin care se pot conecta cu usurinta drive-urile externe, imprimantele si chiar camerele foto. Surface RT ofera USB 2.0, iar Surface Pro USB 3.0. 4. Performanta Tabletele au fost pana acum un hibrid intre laptopuri si smartphone, dar Microsoft incearca sa ajunga cat mai aproape de specificatiile unui ultrabook cu Surface Pro. Cu procesor Intel Core i5, tableta Microsoft cu Windows 8 Pro va oferi pana la 128GB spatiu de stocare, un alt avantaj in lupta contra iPad, ramas cu limita maxima de 64GB. 5. Xbox SmartGlass Sistemul SmartGlass, prezentat de Microsoft la E3, va lega orice tableta, chiar si Android sau iPad de consola de jocuri Xbox pentru o experienta interactiva. Daca Microsoft optimizeaza Xbox SmartGlass pentru Surface si ofera functii noi, ar putea duce utilizatorii cu un pas inainte in integrarea consumului de media, in care televizorul, consola de jocuri, tableta si smartphone-ul interactioneaza perfect si joaca roluri diferite. Citeste in continuare despre reactia Apple la Microsoft Surface. S-a speriat cu adevarat Apple de Microsoft Surface? Chiar daca Apple a observat de-a lungul anilor cum Microsoft incearca sa-i copieze produsele, dar esueaza - nu s-au gasit prea multi care sa prefere Zune inaintea unui iPod - compania a fost pregatita pentru tabletele Surface. In aceeasi zi cu prezentarea Microsoft Surface, Apple a lansat o noua reclama TV pentru noul iPad, cu sloganul "Do It All!". http://www.youtube.com/watch?v=RksyMaJiD8Y&feature=player_embedded Crezi ca decizia Apple de a lansa noua reclama la iPad este o decizie de afaceri obisnuita sau un semn ca Apple se teme cu adevarat de succesul Microsoft Surface? Sursa: 5 motive pentru care Microsoft Surface ar putea bate iPad-ul | Hit.ro

[h=1]Un hacker sustine ca a exploatat brese de securitate la 79 de banci[/h]de Liviu Petrescu | 20 iunie 2012 Un hacker a publicat date despre 1700 de conturi bancare, sustinand ca a exploatat brese de securitate la 79 de banci din SUA si alte tari. Datele colectate ilegal de Reckz0r timp de 3 luni au o marime totala de 50GB. Hackerul Reckz0r s-a laudat pe Twitter cu realizarile sale si a publicat un document in format text care dezvaluie datele a peste 1700 de persoane: nume, tipul cardului, adresa, numar de telefon si adresa de email, scrie ZDNet. Cele mai multe conturi compromise sunt din SUA, Marea Britanie si Canada, iar hackerul Reckz0r a explicat ca datele provin direct de la banci, nu din bazele de date Visa si Mastercard. Hackerul sustine ca a publicat datele cu un scop nobil, pentru a atrage atentia asupra vulnerabilitatii bancilor in mediul online. Incidentul a fost comentat si de un reprezentat al grupului de hacktivisti Anonymous, care sustine ca datele sunt vechi si nu pot fi folosite pentru frauda. Sursa: Un hacker sustine ca a exploatat brese de securitate la 79 de banci | Hit.ro

[h=1]Researcher: CIA, NSA may have infiltrated Microsoft to write malware[/h] [h=2]Did spies posing as Microsofties write malware in Redmond? How do you spell 'phooey' in C#?[/h] By Kevin Fogarty June 18, 2012, 2:46 PM — A leading security researcher has suggested Microsoft's core Windows and application development programming teams have been infiltrated by covert programmer/operatives from U.S. intelligence agencies. If it were true it would be another exciting twist to the stories of international espionage, sabotage and murder that surround Stuxnet, Duqu and Flame, the most successful cyberwar weapons deployed so far, with the possible exception of Windows itself. Nevertheless, according to Mikko Hypponen, chief research officer of antivirus and security software vendor F-Secure, the scenario that would make it simplest for programmers employed by U.S. intelligence agencies to create the Stuxnet, Duqu and Flame viruses and compromise Microsoft protocols to the extent they could disguise downloads to Flame as patches through Windows Update is that Microsoft has been infiltrated by members of the U.S. intelligence community. [ FREE DOWNLOAD: 68 great ideas for running a security department ] Having programmers, spies and spy-supervisors from the NSA, CIA or other secret government agencies infiltrate Microsoft in order to turn its technology to their own evil uses (rather than Microsoft's) is the kind of premise that would get any writer thrown out of a movie producer's office for pitching an idea that would put the audience to sleep halfway through the first act. Not only is it unlikely, the "action" most likely to take place on the Microsoft campus would be the kind with lots of tense, acronymically dense debates in beige conference rooms and bland corporate offices. The three remarkable bits of malware that attacked Iranian nuclear-fuel development facilities and stole data from its top-secret computer systems – Flame Duqu and Stuxnet – show clear signs of having been built by the same teams of developers, over a long period of time, Hypponen told PC Pro in the U.K. Flame used a counterfeit Microsoft security certificates to verify its trustworthiness to Iranian users, primarily because Microsoft is among the most widely recognized and trusted computer companies in the world, Hypponen said. Faking credentials from Microsoft would give the malware far more credibility than using certificates from other vendors, as would hiding updates in Windows Update, Hypponen said. The damage to Microsoft's reputation and suspicion from international customers that it is a puppet of the CIA would be enough to keep Microsoft itself from participating in the operation, even if it were asked. That doesn't mean it didn't happen. "It's plausible that if there is an operation under way and being run by a US intelligence agency it would make perfect sense for them to plant moles inside Microsoft to assist in pulling it off, just as they would in any other undercover operation,” Hypponen told PC Pro. "It's not certain, but it would be common sense to expect they would do that." The suggestion piqued the imaginations of conspiracy theorists, but doesn't have a shred of evidence to support it. It does have a common-sense appeal, however. Planting operatives inside Microsoft would probably be illegal, would certainly be unethical and could have a long-range disadvantage by making Microsofties look like tools of the CIA rather than simply tools. "No-one has broken into Microsoft, but by repurposing the certificate and modifying it with unknown hash collision technologies, and with the power of a supercomputer, they were able to start signing any program they wanted as if it was from Microsoft," Hypponen said. "If you combine that with the mechanism they were using to spoof MS Update server they had the crown jewels." Hypponen is one of a number of security experts who have said Stuxnet and Duqu have the hallmarks of software written by traditionally minded software engineers accustomed to working in large, well-coordinated teams. After studying the code for Duqu, security researchers at Kaspersky Labs said the malware was most similar to the kind of work done by old-school programmers able to write code for more than one platform at a time, do good quality control to make sure the modules were able to install themselves and update in real time, and that the command-and-control components ahd been re-used from previous editions. "All the conclusions indicate a rather professional team of developers, which appear to be reusing older code written by top “old school” developers," according to Kaspersky's analysis. "Such techniques are normally seen in professional software and almost never in today’s malware. Once again, these indicate that Duqu, just like Stuxnet, is a 'one of a kind' piece of malware which stands out like a gem from the large mass of “dumb” malicious program we normally see." Earlier this month the NYT ran a story detailing two years worth of investigations during which a range of U.S. officials, including, eventually, President Obama, confirmed the U.S. had been involved in writing the Stuxnet and Flame malware and siccing them on Iran. That's far from conclusive proof that the NSA has moved its nonexistent offices to Redmond, Wash. It doesn't rule it out either, however. Very few malware writers are able to write such clean code that can install on a variety of hardware systems, assess their new environments and download the modules they need to successfully compromise a new network, Kaspersky researchers said. Stuxnet and Flame are able to do all these things and to get their own updates through Windows Update using a faked Windows Update security certificate. No other malware writer, hacker or end user has been able to do that before. Knowing it happened this time makes it more apparent that the malware writers know what they are doing and know Microsoft code inside and out. That's still no evidence that Microsoft could be or has been infiltrated by spies from the U.S. or from other countries. It does make sense, but so do a lot of conspiracy theories. Until there's some solid indication Flame came from inside Microsoft, not outside, it's probably safer to write off this string of associative evidence. Even in his own blog, Hypponen makes fun of those who make fun of Flame as ineffective and unremarkable, but doesn't actually suggest moles at Microsoft are to blame. In the end it doesn't really matter. The faked certificates and ride-along on Windows Update demonstrate the malware writers have compromised the core software development operations at Microsoft. They don't have to live there to do it; virtual compromise on the code itself would do the job more effectively than putting warm bodied programmers in the middle of highly competitive, highly intelligent, socially awkward Microsofties with a habit of asking the wrong question and insisting on an answer. The risk of having any such infiltration discovered is far too high to expose the cyberwar version of Seal Team Six to the perils of Redmond. Still, the assumption seems to be true metaphorically, if not physically, so it's safer to assume Microsoft and its software have both been compromised. Given the track record of Stuxnet, Duqu and Flame for compromising everything they're aimed at, that assumption isn't even much of a stretch. Read more of Kevin Fogarty's CoreIT blog and follow the latest IT news at ITworld. Follow Kevin on Twitter at @KevinFogarty. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook. Sursa: http://www.itworld.com/security/281553/researcher-warns-stuxnet-flame-show-microsoft-may-have-been-infiltrated-nsa-cia

L-am gasit azi, din intamplare: http://tutorialeplusplus.blogspot.ro/

.NET Internals and Native Compiling Introduction What is Native Compiling? Native Images Native Framework Deployment The Native Loader Registry Virtualization Issues and Conclusions Native Injection Native Decompiling .NET Virtual Machines Conclusions [h=2]Introduction[/h] This article is the second of a two series of articles about the .NET Framework internals and the protections available for .NET assemblies. This article analyzes more in depth the .NET internals. Thus, the reader should be familiar with the past article, otherwise certain paragraphs of this article may seem obscure. As the JIT inner workings haven't been analyzed yet, .NET protections are quite naïve nowadays. This situation will rapidly change as soon as the reverse engineering community will focus its attention on this technology. These two articles are aimed to raise the consciousness about the current state of .NET protections and what is possible to achieve but hasn't been done yet. In particular, the past article about .NET code injection represents, let's say, the present, whereas the current one about .NET native compiling represents the future. What I'm presenting in these two articles is new at the time I'm writing it, but I expect it to become obsolete in less than a year. Of course, this is obvious as I'm moving the first steps out from current .NET protections in the direction of better ones. But this article isn't really about protections: exploring the .NET Framework internals can be useful for many purposes. So, talking about protections is just a means to an end. [h=2]What is Native Compiling?[/h] Strictly speaking it means converting the MSIL code of a .NET assembly to native machine code and then removing the MSIL code from that assembly, making it impossible to decompile it in a straightforward way. The only existing tool to native compile .NET assemblies is the Salamander.NET linker which relies on native images to do its job. The "native images" (which in this article I called "Native Framework Deployment") technique is quite distant from .NET internals: one doesn't need a good knowledge of .NET internals to implement it. But, as the topic is, I might say, quite popular, I'm going to show to the reader how to write his Native Framework Deployment tool if he wishes to. However, the article will go further than that by introducing Native Injection, which means nothing else than taking the JIT's place. Even though this is not useful for commercial protections (or whatever), it's a good way to play with JIT internals. I'm also going to introduce Native Decompiling, which is the result of an understanding of .NET internals. I'm also trying to address another topic: .NET Virtual Machine Protections. [h=2]Native Images[/h] The internal format of native images is yet undocumented. It also would be quite hard documenting it as it constantly changes. For instance, it completely changed from version 1 to version 2 of the .NET framework. And, as the new framework 3.5 SP1 has been released a few days ago, it changed another time. I'm not sure on what extent it changed in the last version, but one change can be noticed immediately. The original MetaData is now directly available without changing the entry in the .NET directory to the MetaData RVA found in the Native Header. If you do that action, you'll end up with the native image MetaData which isn't much interesting. Also, in earlier native images (previous to 3.5 SP1 framework) to obtain the original MSIL code of a method, one had to add the RVA found in the MethodDef table to the Original MSIL Code RVA entry in the native header. This is no longer necessary as the MethodDef RVA entry now points directly to the method's MSIL code. This is important, since protections like the Salamander Linker need to remove the original MSIL code from a native image before they can deploy it. Otherwise the whole protection become useless, since MetaData and MSIL code are all what is necessary to rebuild a fully decompilable .NET assembly. The stripping of MSIL code was easier in the "old" format, because one only needed the Original MSIL Code RVA and Size entries to know which part of the native image had to be erased with a simple memset. All we need to know about the native images' format in order to write a Native Framework Deployment tool is how to strip the MSIL code from it. Even the Salamander Linker will need time to adapt to the new native image format in order to work with the framework 3.5 SP1. And, as there isn't currently any protection which works with 3.5 SP1 native images, what I'm writing in this article has been only tested against earlier images. Another reason why it is difficult to document native images is the lack of the code which handles them in the Rotor project. It was a deliberate choice made by Microsoft to exclude this part of the framework from the Rotor project. [h=2]Native Framework Deployment[/h] The name I gave to this sort of protection may appear a bit strange, but it will appear quite obvious as soon as I have explained how it actually works. As already said, there's no protection system other than the Salamander Linker which removes the MSIL and ships only native machine code. And, in order to do that, the Salamander Linker relies on native images generated by ngen. The Salamander Linker offers a downloadable demonstration on its home page and we will take a look at that without, of course, analyzing its code, as I don't intend to violate any licensing terms it may imply. In this paragraph I'm going to show how it is technically quite easy to write a Native Framework Deployment tool, but I doubt that the reader will want to write one after reading this. Don't get me wrong, the Salamander Linker absolutely holds its promise and actually removes the MSIL code from one's application, but the method used faces many problems and in my opinion is not a real solution. The Salamander Linker's demonstration is called scribble and it's a simple MDI application. Let's look at the application's main directory: Tutorial: http://www.ntcore.com/files/netint_native.htm

.NET Internals and Code Injection Introduction What is .NET Code Injection? How does .NET Code Injection work? .NET Internals (Part 1: JIT) The .NET Assembly Loader JIT Hooking Example The .NET Code Ejector Code Ejection Demonstration .NET Internals (Part 2: MethodDesc) .NET Internals (Part 3: IEE, Internal Calls, etc.) Other Injection/Ejection Approaches Conclusions [h=2]Introduction[/h] This article is the obvious culmination of the previous effort of writing the Rebel.NET application and the first of a two series of articles about the .NET framework internals and the protections available for .NET assemblies. The next article will be about .NET native compiling. As the JIT inner workings haven't been analyzed yet, .NET protections are quite naïf nowadays. This situation will rapidly change as soon as the reverse engineering community will focus its attention on this technology. These two articles are aimed to raise the consiousness about the current state of .NET protections and what is possible to achieve but hasn't been done yet. In particular, the current article about .NET code injection represents, let's say, the present, whereas the next one about .NET native compiling represents the future. What I'm presenting in these two articles is new at the time I'm writing it, but I expect it to become obsolete in less than a year. Of course, this is obvious as I'm moving the first steps out from current .NET protections in the direction of better ones. But this article isn't really about protections: exploring the .NET framework internals can be useful for many purposes. So, talking about protections is just a means to an end. [h=2]What is .NET Code Injection?[/h] .NET code injection is the "strong" brother of .NET packers (which unpack the entire assembly in memory). What .NET code injectors do is to hook the JIT and when the MSIL code of a method is requested they filter the request and provide the real MSIL instead of the MSIL contained in the assembly, which, most of the times, is just a ret. By injecting one (or quasi) method at a time, the MSIL code will remain conceiled. Even if one manages to dump the code, it isn't to be expected that the protection left the necessary space for the real MSIL code in the .NET assembly, although many commercial protections do so. Rebuilding the assembly from scratch is the universally valid way to proceed. This, of course, is not a problem with Rebel.NET. It should be obvious to the reader that .NET code injectors aren't reliable protections. It's just playing hide and seek with the reverser. But, as many software producers are putting their intellectual property in the hands of such protections, it is necessary to analyze them throughout. [h=2]How does .NET Code Injection work?[/h] One thing should be clear from the beginning: there isn't only one method to inject MSIL. Thus, to remove this kind of protection you have to evaluate the specific case. A very clean approach, though unused yet, would be to inject the MSIL through the .NET profiling API. There's a very in depth article about the .NET profiling API by Aleksandr Mikunov on MSDN. Anyway, as I already said, this approach isn't used by .NET protections. I referred to this approach as clean, simply because it uses the API provided by the framework itself. Thus, it'll work on every .NET framework no matter what. Whereas .NET protections usually hook the JIT and this, although it might work just as well, it is not guaranteed to do so. The .NET framework's JIT is contained in the mscorjit.dll module. To identify the part of the JIT being hooked by the .NET protection there's a very simple an effect way: dumping the mscorjit.dll module from the protection's process and comparing it to the original module on disk. I wrote a little CFF Explorer Script to make a comparision of a PE section which excludes the IAT in the comparision. This is especially useful when comparing the .text section of two executables. -Download the Section Comparer script It was a ten minutes job and it is extremely useful to identify the type of hook applied to the JIT. Let's look at a possible output of this script: Comparision between section 0 of C:\...\mscorjit.dll and C:\...\mscorjit_dumped.dll Differences found at: RVA1 RVA2 000460A0 000460A0 000460A1 000460A1 000460A2 000460A2 000460A3 000460A3 Number of differences found: 4 Tutorial: http://www.ntcore.com/files/netint_injection.htm

SendInput function

C apoi C++. Lasa porcariile, Python e pur si simplu "altfel". Daca ai incepe cu asa ceva, sau cu Perl sau chiar Shell scripting iti va fi greu sa inveti altceva, pentru ca sunt "diferite". Uita-te pe sintaxe si incearca sa nu te sperii. Invata C, apoi C++. Iti va fi foarte usor sa inveti apoi PHP, Javascript, Java, C#... Pentru ca sunt "la fel" in proportie de minim 80%. Apoi, vei putea programa si pe Windows si pe Linux fara sa ai nevoie de un interpretor/masina virtuala(Java) pentru a executa programul si va fi mai rapid ca in 95% ca unul scris in alt limbaj de programare/scripting (invata diferenta). Abia apoi uita-te la Python, Perl sau alte limbaje, "putin" diferite ca sintaxa de celelalte, mai "clasice". PS: Voi, ceilalti, evitati sa dati astfel de raspunsuri: "Invata limbajul x", spunand asta DOAR pentru ca voi cunoasteti si lucrati in acel limbaj. Daca voua va place si vi se potriveste nu inseamna ca e la fel pentru toata lumea.

Offtopic: iOS6 Tethered Jailbreak Released - Redsn0w iOS6 Tethered Jailbreak Announced ~ Geeky Apple - The new iPad 3, iPhone iOS6 Jailbreaking and Unlocking Guides