Nytro

Da, frumos bug si frumoasa exploatare.

Asta e echivalentul a "hai sa ne dam parte in parte" in security @Vasile. warn pentru ca a inceput offtopic-ul. Cine se mai abate de la subiect, ban.

Nu stiu daca ajuta: https://support.apple.com/en-us/HT201487

Minte, @Zatarra merge la interviuri cu palaria rosie pe cap (RedHat https://www.google.com/search?q=redhat&source=lnms&tbm=isch) si e acceptat direct.

CV-ul meu e facut random, de mine, nu de pe vreun template anume. De fapt chiar nu arata prea bine ca design, e urat. Nu il pot posta, dar majoritatea lucrurilor sunt publice. De fapt cam tot... Cel mai important lucru e experienta, am fiecare job la care am lucrat cu cateva detalii despre ce faceam acolo. Am o parte de skills in care pun tot felul de lucruri: web security, reverse engineering, limbaje de programare in care am lucrat si mai stiu eu ce, dar pun si lucruri gen certificari, prezentari la conferinte, blog-ul, Twitter sau Github. Pana acum am avut noroc, pe unde am fost ma stia lumea din prezentat pe la conferinte sau chiar Twitter.

"Sistemul este la Administrația Străzilor, deja avem montate camere în câteva intersecții din Capitală. Sistemul are trei rețele neuronale, prima depistează tipul autovehiculului, a doua numărul de pe plăcuțele de înmatriculare, si în baza de date, prin OCR-izare, se scrie fiecare număr de înmatriculare depistat pe camere. Acest sistem transmite unui centralizator dacă are vinieta plătită, dacă are normă de poluare sub normele impuse și decide mai departe emiterea proceselor de sancțiune, trimiterea lor și urmărirea plății. Putem avea și contestații, noi avem și filmulețele cu probele. Nu avem abateri", a explicat acesta. Articol complet: http://mobile.hotnews.ro/stire/23582705 Cred ca va dati seama la ce ma refer

Da, asta e tema de o folosim pe forum. Poate la un update sau poate modificand ceva setari ajunsese temporar albastra.

Tema e verde de cand am dat drumul la forum, nu stiu, poate in timpul unui update sa se fi intamplat ceva.

Unde sa fie schimbata tema? Aici pe forum? Nu am mai facut modificari de ani de zile, poate dupa vreun update, nu am idee.

Sugestia mea e sa ai grija cu un astfel de site, parca acum 2-3 ani ceva persoane au fost arestate (in Romania) din cauza unor site-uri cu acelasi profil.

Salut, la McAfee in Romania (nu stiam ca au birouri aici)? Ce faci acolo, cum e?

@aelius la doctor https://9gag.com/gag/aN0vL5r

Salut, sunt multe firme la care poti apela pentru cursuri de programare. Nu stiu cum sunt, dar nu necesita mare lucru: 2-3 programatori cu cativa ani de experienta e de ajuns ca sa invete incepatorii bazele programarii. Problema, ca si la ce ai zis tu mai sus e simpla: dureaza un cacat de an! Sa fim seriosi, daca esti dedicat si stai minim cateva ore pe zi sa inveti si sa exersezi poti invata orice limbaj de programare la un nivel OK (totusi de incepator) dar sa te descruci sa faci un program cap-coada. La urma urmei, intr-o luna poti invata sa faci bombe nucleare. Sugestia mea e sa iei 1-2 carti pe domeniul pe care ti-l doresti si sa citesti tutoriale sau sa vezi video despre limbaj. Fie ca e Java, JavaScript, PHP, C++ sau orice altceva, nu e atat de greu cum pare, doar nu inveti araba, inveti un limbaj cu ceva cuvinte cheie si o anumita sintaxa. Daca nu stii ce vrei exact, cere aici pareri sa cauta singur. Daca vrei ceva ce se "cauta" sunt o gramada de statistici cu cele mai cautate limbaje de programare, dar sugestia mea e sa vezi foarte rapid cum sunt fiecare si sa alegi ce ti-ar placea mai mult.

Nu stiu daca exista ceva doar pe networking. Cel mai probabil aceasta e o ramura din altele, gen Windows sau Linux (sysadmin). Probabil exista si job-uri mai dedicate, poate legate de switch-uri si root-ere Cisco de exemplu unde sunt carti intregi de documentatie, dar nu stiu cat se cauta.

Eu zic ca merita si ajuta mult pe partea de "defence". E foarte utila in pozitii de SOC sau asemanatoare. Cred ca ar fi o adaugare buna la cunostiintele de networking/servere pe care le ai deja. CISSP incearca sa acopere cat mai mult si doar la suprafata, e utila pentru pozitii de management dar nu e chiar asa "hands-on".

How a nuclear plant got hacked Plugging nuclear plants into the internet makes them vulnerable targets for nation-state attack. By J.M. Porup Senior Writer, CSO | DEC 9, 2019 3:00 AM PST Thinkstock If you think attacking civilian infrastructure is a war crime, you'd be right, but spies from countries around the world are fighting a silent, dirty war to pre-position themselves on civilian infrastructure — like energy-producing civilian nuclear plants — to be able to commit sabotage during a moment of geopolitical tension. What follows is an explanation of how India's Kudankulam Nuclear Power Plant (KNPP) got hacked — and how it could have been easily avoided. [ Learn what you need to know about defending critical infrastructure . | Get the latest from CSO by signing up for our newsletters. ] The KNPP hack The news came to light, as it so often does these days, on Twitter. Pukhraj Singh (@RungRage), a "noted cyber intelligence specialist" who was "instrumental in setting up of the cyber-warfare operations centre of the National Technical Research Organisation (NTRO)," according to The New Indian Express, tweeted: "So, it's public now. Domain controller-level access Kudankulam Nuclear Power Plant. The government was notified way back. Extremely mission-critical targets were hit," noting in a quote tweet that he was aware of the attack as early as September 7, 2019, calling it a "causus belli" (an attack sufficiently grave to provoke a war). [ Prepare to become a Certified Information Security Systems Professional with this comprehensive online course from PluralSight. Now offering a 10-day free trial! ] In a later tweet, Singh clarified that he did not discover the malware himself. A third party "contacted me & I notified National Cyber Security Coordinator on Sep 4 (date is crucial). The 3rd party then shared the IoCs with the NCSC's office over the proceeding days. Kaspersky reported it later, called it DTrack." At first the Nuclear Power Plant Corporation of India (NPCI) denied it. In a press release they decried "false information" on social media and insisted the KNPP nuclear power plant is "stand alone and not connected to outside cyber network and internet" and that "any cyber attack on the Nuclear Power Plant Control System is not possible." Then they backtracked. On October 30, the NPCI confirmed that malware was in fact discovered on their systems, and that CERT-India first noticed the attack on September 4, 2019. In their statement, they claimed the infected PC was connected to the administrative network, which they say is "isolated from the critical internal network." "Investigation also confirms that the plant systems are not affected," their statement concludes. A targeted attack Contrary to some initial reporting, the malware appears to have been targeted specifically at the KNPP facility, according to researchers at CyberBit. Reverse-engineering of the malware sample revealed hard-coded administrator credentials for KNPP's networks (username: /user:KKNPP\\administrator password: su.controller5kk) as well as RFC 1918 IP addresses (172.22.22.156, 10.2.114.1, 172.22.22.5, 10.2.4.1, 10.38.1.35), which are by definition not internet-routable. That means it is highly likely the attacker previously broke into KNPP networks, scanned for NAT'ed devices, stole admin credentials, and then incorporated those details into this new malware, a second-stage payload designed for deeper and more thorough reconnaissance of KNPP's networks. "This was a very targeted attack on just this plant," Hod Gavriel, a malware analyst at CyberBit, tells CSO. "Probably this was the second stage of an attack." The malware discovered, however, did not include Stuxnet-like functionality to destroy any of KNPP's systems. "This phase was only for collection of information, it wasn't sabotageware," Gavriel says. Was North Korea responsible? Numerous security researchers downloaded and analyzed the malware from VirusTotal, and many noted the code similarities with malware previously attributed to North Korea's Lazarus group. A Kaspersky analyst noted similarities dating back to 2013, writing "The vast amount of Dtrack samples that we were able to find shows that the Lazarus group is one of the most active APT groups in terms of malware development." However, given that North Korea has little geopolitical interest in India, the possibility of a false flag operating using stolen North Korean code to muddle attribution seems quite likely. Analysis of the malware The malware hid inside of modified copies of legitimate programs, such as 7Zip or VNC. This technique often successfully escapes notice by antivirus scanners. Adequate checking of program signatures would have mitigated this attack vector; the modified program hash would have differed from the software vendor's signed hash. The fact that this attack was successful strongly suggests that KNPP was not checking software signatures of file hashes. Passively detecting this kind of attack is very difficult, Gavriel notes. "Effective detection of this type of highly targeted malware is likely to generate false-positives that requires skilled analysts." Targeted critical infrastructure security teams need to engage in constant network monitoring for suspicious activity to hunt threats and root them out before they can do any damage. Sursa: https://www.csoonline.com/article/3488816/how-a-nuclear-plant-got-hacked.html

Vulnerability in fully patched Android phones under active attack by bank thieves "StrandHogg" spoofing flaw exploited by 36 apps, including bank trojans. Dan Goodin - 12/2/2019, 11:10 PM A vulnerability in millions of fully patched Android phones is being actively exploited by malware that's designed to drain the bank accounts of infected users, researchers said on Monday. The vulnerability allows malicious apps to masquerade as legitimate apps that targets have already installed and come to trust, researchers from security firm Promon reported in a post. Running under the guise of trusted apps already installed, the malicious apps can then request permissions to carry out sensitive tasks, such as recording audio or video, taking photos, reading text messages or phishing login credentials. Targets who click yes to the request are then compromised. Researchers with Lookout, a mobile security provider and a Promon partner, reported last week that they found 36 apps exploiting the spoofing vulnerability. The malicious apps included variants of the BankBot banking trojan. BankBot has been active since 2017, and apps from the malware family have been caught repeatedly infiltrating the Google Play Market. The vulnerability is most serious in versions 6 through 10, which (according to Statista) account for about 80% of Android phones worldwide. Attacks against those versions allow malicious apps to ask for permissions while posing as legitimate apps. There's no limit to the permissions these malicious apps can seek. Access to text messages, photos, the microphone, camera, and GPS are some of the permissions that are possible. A user's only defense is to click "no" to the requests. An affinity for multitasking The vulnerability is found in a function known as TaskAffinity, a multitasking feature that allows apps to assume the identity of other apps or tasks running in the multitasking environment. Malicious apps can exploit this functionality by setting the TaskAffinity for one or more of its activities to match a package name of a trusted third-party app. By either combining the spoofed activity with an additional allowTaskReparenting activity or launching the malicious activity with an Intent.FLAG_ACTIVITY_NEW_TASK, the malicious apps will be placed inside and on top of the targeted task. "Thus the malicious activity hijacks the target's task," Promon researchers wrote. "The next time the target app is launched from Launcher, the hijacked task will be brought to the front and the malicious activity will be visible. The malicious app then only needs to appear like the target app to successfully launch sophisticated attacks against the user. It is possible to hijack such a task before the target app has even been installed." Promon said Google has removed malicious apps from its Play Market, but, so far, the vulnerability appears to be unfixed in all versions of Android. Promon is calling the vulnerability "StrandHogg," an old Norse term for the Viking tactic of raiding coastal areas to plunder and hold people for ransom. Neither Promon nor Lookout identified the names of the malicious apps. That omission makes it hard for people to know if they are or were infected. Google representatives didn't respond to questions about when the flaw will be patched, how many Google Play apps were caught exploiting it, or how many end users were affected. The representatives wrote only: "We appreciate the researchers['] work, and have suspended the potentially harmful apps they identified. Google Play Protect detects and blocks malicious apps, including ones using this technique. Additionally, we're continuing to investigate in order to improve Google Play Protect's ability to protect users against similar issues." StrandHogg represents the biggest threat to less-experienced users or those who have cognitive or other types of impairments that make it hard to pay close attention to subtle behaviors of apps. Still, there are several things alert users can do to detect malicious apps that attempt to exploit the vulnerability. Suspicious signs include: An app or service that you're already logged into is asking for a login. Permission popups that don't contain an app name. Permissions asked from an app that shouldn't require or need the permissions it asks for. For example, a calculator app asking for GPS permission. Typos and mistakes in the user interface. Buttons and links in the user interface that do nothing when clicked on. Back button does not work as expected. Tip-off from a Czech bank Promon researchers said they identified StrandHogg after learning from an unnamed Eastern European security company for financial institutions that several banks in the Czech Republic reported money disappearing from customer accounts. The partner gave Promon a sample of suspected malware. Promon eventually found that the malware was exploiting the vulnerability. Promon partner Lookout later identified the 36 apps exploiting the vulnerability, including BankBot variants. Monday's post didn't say how many financial institutions were targeted in total. The malware sample Promon analyzed was installed through several droppers apps and downloaders distributed on Google Play. While Google has removed them, it's not uncommon for new malicious apps to make their way into the Google-operated service. Readers are once again reminded to be highly suspicious of Android apps available both in and outside of Google Play. People should also pay close attention to permissions requested by any app. Dan Goodin Dan is the Security Editor at Ars Technica, which he joined in 2012 after working for The Register, the Associated Press, Bloomberg News, and other publications. Email dan.goodin@arstechnica.com // Twitter @dangoodin001 Sursa: https://arstechnica.com/information-technology/2019/12/vulnerability-in-fully-patched-android-phones-under-active-attack-by-bank-thieves/

Cum ți se fură banii din cont când plătești cu cardul la hotel Ciprian Ioana 17:55 29.11.2019 Fie că alegi să te cazezi pentru o vacanță sau o călătorie în interes de serviciu, alegi, de cele mai multe ori, să plătești cu cardul la hotel. Problema e că stocarea acestor date nu e atât de sigură. Specialiștii Kaspersky au analizat campania RevengeHotels, care vizează industria ospitalității, pentru a vedea ce se întâmplă cu datele bancare ale turiștilor. Odată ce acestea au intrat în baza de date a hotelurilor, lucrurile se complică. Așa s-a ajuns la concluzia că peste 20 de hoteluri din America Latină, Europa și Asia au căzut victime ale unor atacuri malware direcționate. Este posibil ca un număr mai mare de hoteluri să fie afectate pe tot tot globul. Datele cardurilor turiștilor, stocate într-un sistem de administrare hotelieră, inclusiv cele primite de la agenții online de turism (OTA), riscă să fie furate și vândute infractorilor din întreaga lume. Ceea ce ar trebui să-ți dea de gândit. Iată cum arată harta atacurilor de acest fel, potrivit Kaspersky. Cum îți fură hackerii banii din cont atunci când te cazezi la hotel Specialiștii explică mecanismul prin care datele tale bancare ajung pe mâinile hackerilor: RevengeHotels este o campanie a diferite grupuri care utilizează troieni tradiționali cu acces de la distanță (denumiți RAT) pentru a infecta companiile din sectorul ospitalității. Campania este activă din 2015, dar a început să-și mărească prezența în 2019. Cel puțin două grupuri, RevengeHotels și ProCC, au fost identificate ca făcând parte din campanie, cu toate că există posibilitatea ca mai multe grupuri de infractori cibernetici să fi pus umărul la așa ceva. Principalul vector de atac din această campanie este reprezentat de e-mail-uri cu documente infectate – Word, Excel sau PDF. Unele dintre ele exploatează vulnerabilitatea CVE-2017-0199, încărcând-o cu ajutorul script-urilor VBS și PowerShell și apoi instalează versiuni personalizate ale diferitelor RAT-uri, precum și alte programe malware personalizate, cum ar fi ProCC, pe dispozitivul victimei, care ulterior ar putea executa comenzi și configura accesul de la distanță la sistemele infectate. Tehnica e cunoscută sub numele de email spear-phishing și a fost elaborată cu o atenție deosebită asupra detaliilor și, de obicei, pretinde a veni din partea unor persoane reale din organizații legitime, făcând o cerere de rezervare falsă pentru un grup numeros. De remarcat este faptul că inclusiv utilizatorii atenți ar putea fi păcăliți să deschidă și să descarce anexele din aceste e-mailuri, deoarece includ o mulțime de detalii (de exemplu, copii ale documentelor legale și motivația pentru care fac rezervarea la hotel) și arată convingător. Singurul detaliu care l-ar da de gol pe atacator ar fi un domeniu de typosquatting al organizației. Ce se întâmplă apoi cu datele bancare Odată infectat, computerul putea fi accesat de la distanță nu doar de grupul de infractori cibernetici. Dovezile colectate de cercetătorii Kaspersky arată că accesul de la distanță la recepțiile hotelurilor și la datele pe care le conțin sunt vândute pe forumuri ilegale, pe bază de abonament. Programele malware au colectat date din fișele hotelurilor, din programele de imprimantă și au făcut capturi de ecran (această funcție a fost declanșată folosind anumite cuvinte în engleză sau portugheză). Deoarece personalul hotelului a copiat de multe ori datele cardului de credit ale clienților din OTA pentru a factura, aceste date ar putea fi, de asemenea, compromise. Telemetria Kaspersky a confirmat existența unor ținte în Argentina, Bolivia, Brazilia, Chile, Costa Rica, Franța, Italia, Mexic, Portugalia, Spania, Thailanda și Turcia. Multe dintre aceste destinații sunt des frecventate de români. În plus, pe baza datelor extrase din Bit.ly, un serviciu popular de scurtare a link-urilor, utilizat de atacatori pentru a răspândi link-uri periculoase, cercetătorii Kaspersky presupun că utilizatorii din multe alte țări au accesat, cel puțin, link-ul periculos, sugerând că numărul de țări cu posibile victime ar putea fi mai mare. Cum te ferești de astfel de atacuri Specialiștii vin și cu câteva sfaturi pentru ca turiștii să se ferească de astfel de situații: – Atunci când plătești o rezervare sau faci heck out la recepția hotelului, ar fi bine să utilizezi un portofel virtual, cum ar fi Apple Pay sau Google Pay, sau un card de credit secundar, cu o sumă limitată de bani disponibili. De asemenea, proprietarii și managerii de hoteluri trebuie să urmeze acești pași pentru a securiza datele clienților: – Efectuați evaluări de risc ale rețelei existente și implementați reglementări privind modul în care sunt gestionate datele clienților. – Utilizați o soluție de securitate fiabilă, cu funcții de protecție web și controlul aplicațiilor. Protecția web ajută la blocarea accesului la site-urile de phishing și la cele infectate, în timp ce controlul aplicațiilor (în modul „white list”) vă permite să vă asigurați că nicio aplicație, cu excepția celor aprobate, nu poate rula pe computerele din hoteluri. – Introduceți training-uri de awareness în domeniul securității cibernetice, pentru personal, cu scopul de a-i învăța pe angajați să detecteze tentativele de spear-phishing și să le arate importanța de a rămâne foarte atenți atunci când lucrează cu e-mail-urile primite. Sursa: https://playtech.ro/2019/cum-ti-se-fura-banii-din-cont-cand-platesti-cu-cardul-la-hotel/

Un fel, nu prinde system call-urile ci API-urile. Cu interfata grafica mai e si API Monitor de la Rohitab sau Process Monitor de la Sysinternal dar functioneaza diferit.

GG! Link sters, prost banat.

Nu am testat desi imi place mult. In principiu da, dar in anumite conditii nu e necesar: https://frida.re/docs/android/

tiny_tracer A Pin Tool for tracing: API calls transition between sections of the traced module (helpful in finding OEP of the packed module) Generates a report in a format: RVA;traced event i.e. 345c2;section: .text 58069;called: C:\Windows\SysWOW64\kernel32.dll.IsProcessorFeaturePresent 3976d;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW 3983c;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress 3999d;called: C:\Windows\SysWOW64\KernelBase.dll.InitializeCriticalSectionEx 398ac;called: C:\Windows\SysWOW64\KernelBase.dll.FlsAlloc 3995d;called: C:\Windows\SysWOW64\KernelBase.dll.FlsSetValue 49275;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW 4934b;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress ... How to build? To compile the prepared project you need to use Visual Studio >= 2012. It was tested with Intel Pin 3.7 and Pin 3.10. Clone this repo into \source\tools that is inside your Pin root directory. Open the project in Visual Studio and build. More details about the installation and usage you will find on the project's Wiki. Sursa: https://github.com/hasherezade/tiny_tracer

ELF Binaries and Relocation Entries 29 Nov 2019 Recently I have been working on getting the OpenRISC glibc port ready for upstreaming. Part of this work has been to run the glibc testsuite and get the tests to pass. The glibc testsuite has a comprehensive set of linker and runtime relocation tests. In order to fix issues with tests I had to learn more than I did before about ELF Relocations , Thread Local Storage and the binutils linker implementation in BFD. There is a lot of documentation available, but it’s a bit hard to follow as it assumes certain knowledge, for example have a look at the Solaris Linker and Libraries section on relocations. In this article I will try to fill in those gaps. This will be an illustrated 3 part series covering ELF Binaries and Relocation Entries Thread Local Storage How Relocations and Thread Local Store are implemented All of the examples in this article can be found in my tls-examples project. Please check it out. On Linux, you can download it and make it with your favorite toolchain. By default it will cross compile using an openrisc toolchain. This can be overridden with the CROSS_COMPILE variable. For example, to build for your current host. $ git clone git@github.com:stffrdhrn/tls-examples.git $ make CROSS_COMPILE= gcc -fpic -c -o tls-gd-dynamic.o tls-gd.c -Wall -O2 -g gcc -fpic -c -o nontls-dynamic.o nontls.c -Wall -O2 -g ... objdump -dr x-static.o > x-static.S objdump -dr xy-static.o > xy-static.S Now we can get started. ELF Segments and Sections Before we can talk about relocations we need to talk a bit about what makes up ELF binaries. This is a prerequisite as relocations and TLS are part of ELF binaries. There are a few basic ELF binary types: Objects (.o) - produced by a compiler, contains a collection of sections, also call relocatable files. Program - an executable program, contains sections grouped into segments. Shared Objects (.so) - a program library, contains sections grouped into segments. Core Files - core dump of program memory, these are also ELF binaries Here we will discuss Object Files and Program Files. An ELF Object The compiler generates object files, these contain sections of binary data and these are not executable. The object file produced by gcc generally contains .rela.text, .text, .data and .bss sections. .rela.text - a list of relocations against the .text section .text - contains compiled program machine code .data - static and non static initialized variable values .bss - static and non static non-initialized variables An ELF Program ELF binaries are made of sections and segments. A segment contains a group of sections and the segment defines how the data should be loaded into memory for program execution. Each segment is mapped to program memory by the kernel when a process is created. Program files contain most of the same sections as objects but there are some differences. .text - contains executable program code, there is no .rela.text section .got - the global offset table used to access variables, created during link time. May be populated during runtime. Looking at ELF binaries (readelf) The readelf tool can help inspect elf binaries. Some examples: Reading Sections of an Object File Using the -S option we can read sections from an elf file. As we can see below we have the .text, .rela.text, .bss and many other sections. $ readelf -S tls-le-static.o There are 20 section headers, starting at offset 0x604: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 000034 000020 00 AX 0 0 4 [ 2] .rela.text RELA 00000000 0003f8 000030 0c I 17 1 4 [ 3] .data PROGBITS 00000000 000054 000000 00 WA 0 0 1 [ 4] .bss NOBITS 00000000 000054 000000 00 WA 0 0 1 [ 5] .tbss NOBITS 00000000 000054 000004 00 WAT 0 0 4 [ 6] .debug_info PROGBITS 00000000 000054 000074 00 0 0 1 [ 7] .rela.debug_info RELA 00000000 000428 000084 0c I 17 6 4 [ 8] .debug_abbrev PROGBITS 00000000 0000c8 00007c 00 0 0 1 [ 9] .debug_aranges PROGBITS 00000000 000144 000020 00 0 0 1 [10] .rela.debug_arang RELA 00000000 0004ac 000018 0c I 17 9 4 [11] .debug_line PROGBITS 00000000 000164 000087 00 0 0 1 [12] .rela.debug_line RELA 00000000 0004c4 00006c 0c I 17 11 4 [13] .debug_str PROGBITS 00000000 0001eb 00007a 01 MS 0 0 1 [14] .comment PROGBITS 00000000 000265 00002b 01 MS 0 0 1 [15] .debug_frame PROGBITS 00000000 000290 000030 00 0 0 4 [16] .rela.debug_frame RELA 00000000 000530 000030 0c I 17 15 4 [17] .symtab SYMTAB 00000000 0002c0 000110 10 18 15 4 [18] .strtab STRTAB 00000000 0003d0 000025 00 0 0 1 [19] .shstrtab STRTAB 00000000 000560 0000a1 00 0 0 1 Reading Sections of a Program File Using the -S option on a program file we can also read the sections. The file type does not matter as long as it is an ELF we can read the sections. As we can see below there is no longer a rela.text section, but we have others including the .got section. $ readelf -S tls-le-static There are 31 section headers, starting at offset 0x32e8fc: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 000020d4 0000d4 080304 00 AX 0 0 4 [ 2] __libc_freeres_fn PROGBITS 000823d8 0803d8 001118 00 AX 0 0 4 [ 3] .rodata PROGBITS 000834f0 0814f0 01544c 00 A 0 0 4 [ 4] __libc_subfreeres PROGBITS 0009893c 09693c 000024 00 A 0 0 4 [ 5] __libc_IO_vtables PROGBITS 00098960 096960 0002f4 00 A 0 0 4 [ 6] __libc_atexit PROGBITS 00098c54 096c54 000004 00 A 0 0 4 [ 7] .eh_frame PROGBITS 00098c58 096c58 0027a8 00 A 0 0 4 [ 8] .gcc_except_table PROGBITS 0009b400 099400 000089 00 A 0 0 1 [ 9] .note.ABI-tag NOTE 0009b48c 09948c 000020 00 A 0 0 4 [10] .tdata PROGBITS 0009dc28 099c28 000010 00 WAT 0 0 4 [11] .tbss NOBITS 0009dc38 099c38 000024 00 WAT 0 0 4 [12] .init_array INIT_ARRAY 0009dc38 099c38 000004 04 WA 0 0 4 [13] .fini_array FINI_ARRAY 0009dc3c 099c3c 000008 04 WA 0 0 4 [14] .data.rel.ro PROGBITS 0009dc44 099c44 0003bc 00 WA 0 0 4 [15] .data PROGBITS 0009e000 09a000 000de0 00 WA 0 0 4 [16] .got PROGBITS 0009ede0 09ade0 000064 04 WA 0 0 4 [17] .bss NOBITS 0009ee44 09ae44 000bec 00 WA 0 0 4 [18] __libc_freeres_pt NOBITS 0009fa30 09ae44 000014 00 WA 0 0 4 [19] .comment PROGBITS 00000000 09ae44 00002a 01 MS 0 0 1 [20] .debug_aranges PROGBITS 00000000 09ae6e 002300 00 0 0 1 [21] .debug_info PROGBITS 00000000 09d16e 0fd048 00 0 0 1 [22] .debug_abbrev PROGBITS 00000000 19a1b6 0270ca 00 0 0 1 [23] .debug_line PROGBITS 00000000 1c1280 0ce95c 00 0 0 1 [24] .debug_frame PROGBITS 00000000 28fbdc 0063bc 00 0 0 4 [25] .debug_str PROGBITS 00000000 295f98 011e35 01 MS 0 0 1 [26] .debug_loc PROGBITS 00000000 2a7dcd 06c437 00 0 0 1 [27] .debug_ranges PROGBITS 00000000 314204 00c900 00 0 0 1 [28] .symtab SYMTAB 00000000 320b04 0075d0 10 29 926 4 [29] .strtab STRTAB 00000000 3280d4 0066ca 00 0 0 1 [30] .shstrtab STRTAB 00000000 32e79e 00015c 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific) Reading Segments from a Program File Using the -l option on a program file we can read the segments. Notice how segments map from file offsets to memory offsets and alignment. The two different LOAD type segments are segregated by read only/execute and read/write. Each section is also mapped to a segment here. As we can see .text is in the first LOAD` segment which is executable as expected. $ readelf -l tls-le-static Elf file type is EXEC (Executable file) Entry point 0x2104 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00002000 0x00002000 0x994ac 0x994ac R E 0x2000 LOAD 0x099c28 0x0009dc28 0x0009dc28 0x0121c 0x01e1c RW 0x2000 NOTE 0x09948c 0x0009b48c 0x0009b48c 0x00020 0x00020 R 0x4 TLS 0x099c28 0x0009dc28 0x0009dc28 0x00010 0x00034 R 0x4 GNU_RELRO 0x099c28 0x0009dc28 0x0009dc28 0x003d8 0x003d8 R 0x1 Section to Segment mapping: Segment Sections... 00 .text __libc_freeres_fn .rodata __libc_subfreeres __libc_IO_vtables __libc_atexit .eh_frame .gcc_except_table .note.ABI-tag 01 .tdata .init_array .fini_array .data.rel.ro .data .got .bss __libc_freeres_ptrs 02 .note.ABI-tag 03 .tdata .tbss 04 .tdata .init_array .fini_array .data.rel.ro Reading Segments from an Object File Using the -l option with an object file does not work as we can see below. readelf -l tls-le-static.o There are no program headers in this file. Relocation entries As mentioned an object file by itself is not executable. The main reason is that there are no program headers as we just saw. Another reason is that the .text section still contains relocation entries (or placeholders) for the addresses of variables located in the .data and .bss sections. These placeholders will just be 0 in the machine code. So, if we tried to run the machine code in an object file we would end up with Segmentation faults (SEGV). A relocation entry is a placeholder that is added by the compiler or linker when producing ELF binaries. The relocation entries are to be filled in with addresses pointing to data. Relocation entries can be made in code such as the .text section or in data sections like the .got section. For example: Resolving Relocations The diagram above shows relocation entries as white circles. Relocation entries may be filled or resolved at link-time or dynamically during execution. Link time relocations Place holders are filled in when ELF object files are linked by the linker to create executables or libraries For example, relocation entries in .text sections Dynamic relocations Place holders is filled during runtime by the dynamic linker. i.e. Procedure Link Table For example, relocation entries added to .got and .plt sections which link to shared objects. Note: Statically built binaries do not have any dynamic relocations and are not loaded with the dynamic linker. In general link time relocations are used to fill in relocation entries in code. Dynamic relocations fill in relocation entries in data sections. Listing Relocation Entries A list of relocations in a ELF binary can printed using readelf with the -r options. Output of readelf -r tls-gd-dynamic.o Relocation section '.rela.text' at offset 0x530 contains 10 entries: Offset Info Type Sym.Value Sym. Name + Addend 00000000 00000f16 R_OR1K_TLS_GD_HI1 00000000 x + 0 00000008 00000f17 R_OR1K_TLS_GD_LO1 00000000 x + 0 00000020 0000100c R_OR1K_GOTPC_HI16 00000000 _GLOBAL_OFFSET_TABLE_ - 4 00000024 0000100d R_OR1K_GOTPC_LO16 00000000 _GLOBAL_OFFSET_TABLE_ + 0 0000002c 00000d0f R_OR1K_PLT26 00000000 __tls_get_addr + 0 ... The relocation entry list explains how to and where to apply the relocation entry. It contains: Offset - the location in the binary that needs to be updated Info - the encoded value containing the Type, Sym and Addend, which is broken down to: Type - the type of relocation (the formula for what is to be performed is defined in the linker) Sym. Value - the address value (if known) of the symbol. Sym. Name - the name of the symbol (variable name) that this relocation needs to find during link time. Addend - a value that needs to be added to the derived symbol address. This is used to with arrays (i.e. for a relocation referencing a[14] we would have Sym. Name a and an Addend of the data size of a times 14) Example File: nontls.c In the example below we have a simple variable and a function to access it’s address. static int x; int* get_x_addr() { return &x; } Let’s see what happens when we compile this source. The steps to compile and link can be found in the tls-examples project hosting the source examples. Before Linking The diagram above shows relocations in the resulting object file as white circles. In the actual output below we can see that access to the variable x is referenced by a literal 0 in each instruction. These are highlighted with square brackets [] below for clarity. These empty parts of the .text section are relocation entries. Addr. Machine Code Assembly Relocations 0000000c <get_x_addr>: c: 19 60 [00 00] l.movhi r11,[0] # c R_OR1K_AHI16 .bss 10: 44 00 48 00 l.jr r9 14: 9d 6b [00 00] l.addi r11,r11,[0] # 14 R_OR1K_LO_16_IN_INSN .bss The function get_x_addr will return the address of variable x. We can look at the assembly instruction to understand how this is done. Some background of the OpenRISC ABI. Registers are 32-bit. Function return values are placed in register r11. To return from a function we jump to the address in the link register r9. OpenRISC has a branch delay slot, meaning the address after a branch it executed before the branch is taken. Now, lets break down the assembly: l.movhi - move the value [0] into high bits of register r11, clearing the lower bits. l.addi - add the value in register r11 to the value [0] and store the results in r11. l.jr - jump to the address in r9 This constructs a 32-bit value out of 2 16-bit values. After Linking The diagram above shows the relocations have been replaced with actual values. As we can see from the linker output the places in the machine code that had relocation place holders are now replaced with values. For example 1a 20 00 00 has become 1a 20 00 0a. 00002298 <get_x_addr>: 2298: 19 60 00 0a l.movhi r11,0xa 229c: 44 00 48 00 l.jr r9 22a0: 9d 6b ee 60 l.addi r11,r11,-4512 If we calculate 0xa << 16 + -4512 (fee60) we see get 0009ee60. That is the same location of x within our binary. This we can check with readelf -s which lists all symbols. $ readelf -s nontls-static | grep ' x' 42: 0009ee60 4 OBJECT LOCAL DEFAULT 17 x Types of Relocations As we saw above, a simple program resulted in 2 different relocation entries just to compose the address of 1 variable. We saw: R_OR1K_AHI16 R_OR1K_LO_16_IN_INSN The need for different relation types comes from the different requirements for the relocation. Processing of a relocation involves usually a very simple transform , each relocation defines a different transform. The components of the relocation definition are: Input The input of a relocation formula is always the Symbol Address who’s absolute value is unknown at compile time. But there may also be other input variables to the formula including: Program Counter The absolute address of the machine code address being updated Addend The addend available in from the relocation entry discussed above Formula How the input is manipulated to derive the output value. For example shift right 16 bits. Bit-Field Specifies which bits at the output address need to be updated. To be more specific about the above relocations we have: Relocation Type Bit-Field Formula R_OR1K_AHI16 simm16 S >> 16 R_OR1K_LO_16_IN_INSN simm16 S && 0xffff The Bit-Field described above is simm16 which means update the lower 16-bits of the 32-bit value at the output offset and do not disturb the upper 16-bits. +----------+----------+ | | simm16 | | 31 16 | 15 0 | +----------+----------+ There are many other Relocation Types with difference Bit-Fields and Formulas. These use different methods based on what each instruction does, and where each instruction encodes its immediate value. For full listings refer to architecture manuals. Linkers and Libraries - Oracle’s documentation on Intel and Sparc relocations Binutils OpenRISC Relocs - Binutil Manual containing details on OpenRISC relocations ELF for ARM[pdf] - ARM Relocation Types table on page 25 Take a look and see if you can understand how to read these now. Summary In this article we have discussed what ELF binaries are and how they can be read. We have talked about how from compilation to linking to runtime, relocation entries are used to communicate which parts of a program remain to be resolved. We then discussed how relocation types provide a formula and bit-mask for updating the places in ELF binaries that need to be filled in. In the next article we will discuss how Thread Local Storage works, both link-time and runtime relocation entries play big part in how TLS works. Further Reading Bottums Up - Dynamic Linker - Details on the Dynamic Linker, Relocations and Position Independent Code GOT and PLT Key to Code Sharing - Good overview of the .got and .plt sections Sursa: http://stffrdhrn.github.io/hardware/embedded/openrisc/2019/11/29/relocs.html

GynvaelEN Part 1: https://www.youtube.com/watch?v=pYrGJ... Table of Content: 00:08 [PROLOG] nervous_testpilot - Focus | http://nervoustestpilot.co.uk/ 02:15 [PROLOG] TheFatRat - Monody (feat. Laura Brehm) | https://youtube.com/user/ThisIsTheFatRat 07:06 [PROLOG] Stellardrone - Bettween The Rings 13:20 ⁂ START ⁂ - Greetings ( ;E ) 13:45 Short agenda about todays' stream; Q&A rules 14:50 Announcements and hypes - introduction of mod's page - foxtrot_charlie | https://foxtrotlabs.cc/ - Paged Out! #2 is out // Call For Papers (one page) until 02/20/2020 (20 Feb 2020); - 16:21 Authors of articles from 1st rel of Paged Out! who have chosen non-TIP/POOL SAA should receive an email; if not get back to me - I've made one of Winja CTF '18 tasks and now it's released | https://github.com/google/google-ctf/... - It looks like Dec 2018 will be exciting contest between TOP 4 of CTF Time | ctftime.org 19:24 Let's get started! 20:44 2Warm / general / 50pts 22:42 picobrowser / web exp / 200pts - on page we see that we are not picobrowser so we are going to change User-Agent - see Dev Tools in web browser, but could be solved in different way, e.g. curl 26:39 Question: Can we use CTFs for prepare for OSCP? Q @ YT chat: are CTFs useful for real life pentesting? 29:03 plumbing / general / 200pts - netcat + "grep to win" technique which is easy and was described previously 30:11 rsa-pop-quiz / crypto / 200pts - tools: netcat + Python CLI as helper for calculations - knowledge: basics of prime numbers and RSA theory - objectives of this task: get to know with RSA - it's really simple 51:31 slippery-shellcode / bin exp / 200pts - tools: checksec.sh (checking protection of running binary) - knowledge: basics of assembly and code review of C-like languages - objectives of this task: old-school basic exploitation with a NOP sled; 32-bit ELF binary (execute shellcode, get the rid of problem with buffering, have no protections, isn't PIE...) + 0:57:44 about shellcodes + 1:00:00 writing a shellcode that uses fopen/fgets found in memory at known locations 1:10:42 Q: Do you know what AVX2 is used for in assembly? - some historical roots of SIMD extensions in Intel CPUs (MMX, SSE, AVX), why was it created, and registers naming (mm0, xmm0, ymm0, zmm0) - note from viewer: there is JSON parser library that uses vectorized instructions 1:15:16 Q: Check whether it is statically linked on the server also, not just the downloaded version. - why this should *not* be true for CTFs because of annoying players and what's the difference from not-lab exploitation cases 1:16:40 vault-door-3 / rev eng / 200pts - reversing Java code 1:27:28 "I'm going to show you another way to do this" - taking a fresh look at the same problem since I got confused by trying to do the reverse mapping in my head on livestream (which I failed hard); so instead, I showed a way to get the mapping to generate itself 1:32:29 Q: What motivates you when doing a hard challenge? 1:34:10 whats-the-difference / general / 200pts - comparing two binary files with use of python Q: What about zip() in Python when the length of lists is not equal? Q: How hard does a challenge have to be to resemble that of a real life scenario in the work force (or as close as it come)? 1:39:58 where-is-the-file / general / 200pts - file starting with . 1:41:20 WhitePages / forensics / 250pts - three code units: E2 80 83 ... - funky ASCII art or binary ASCII encoding? - at the end: a note about ASCII and code pages 1:51:03 c0rrupt / forensics / 250pts 1:51:43 In YT chat Daniel mentioned 24/7 CTF challenges (https://247ctf.com/). Take a look at it - they are really cool! Returning to task: - broken PNG file... - ...but many files are simply based on zlib aka DEFLATE (e.g. ZIP, GZIP, HTTP compression, but also PNG) - we will try to brute force it! - ...and in the end hack it in GIMP. 2:01:55 Q: With zlib compression, can we decompress even without the beginning of the bytes stream? Or if we have "holes" in the bytes stream? 2:03:55 m00nwalk / forensics / 250pts - WAV file with 11MB Please make volume down, because we are m00nwalking with SSTV over the stream sound directly ? - from 2:07:00 to 2:07:56 - from 2:09:57 to 2:10:03 - from 2:10:53 to 2:11:33 2:18:17 Q: What did you study in college/University and what certs did you get? See also (in Polish but Google Translate could do the thing): - https://gynvael.coldwind.pl/?id=337 - https://gynvael.coldwind.pl/?id=338 2:20:36 Epilog Thanks for attending folks! Thank you foxtrot_charlie for being my Moderator today! Next stream is planned on next Wednesday (part 3). 2:21:06 [EPILOG] nervous_testpilot - Our Heroes | http://nervoustestpilot.co.uk (kudos to J.V. for ToC!) Our Discord: https://discord.gg/QAwfE5R Our IRC: #gynvaelstream-en on freenode