Search the Community

Another day of college, another day of hell—I mean, a beautiful day to write a blog! Now, I may not know much about the ’90s, but for sure, nowadays people use mechanisms to defend their software against reverse engineering. However, that doesn’t mean they’re safe. Don’t take me wrong, but if you have a house made out of sticks, it will break easily. Therefore, there are higher and more complex mechanisms to defend themselves from the same branch. Yeah, I’m talking about anti-debugging, even though real-time debugging is so helpful. Signed by Cringe Blogger (i mean me ) Would you liek to tkae a look here? (#full blog post) Blog What is Anti-Debugging? So let’s stop the chitchat and get to the main point: what is this thing called anti-debugging? The name speaks for itself — anti + debugging, meaning “no debugging.” To achieve this, we use various anti-debugging techniques. This term refers to methods a program can use to detect if it is running under the control of a debugger (e.g., attach + exe [x32dbg]). What is Debugging? Stop asking too many questions! Debugging software lets you run the program step by step, checking each instruction as it goes. This helps you see how the program uses the stack, heap, and registers, and how memory and settings change during runtime. You can follow function calls, track data flow, and find potential weaknesses or hidden features in the program. In short, debugging gives you a peek into the program's inner workings, helping you understand its logic, find flaws, or reverse-engineer its functionality. In the end, anti-debugging is meant to ensure that a program isn’t running under a debugger. But still, it's better to have a house made of stones than one made of sticks. It holds the damage better. Debug flags Let's not rush directly to the implementation or bypass, let's talk about debug flags too (I mean, it's a part of anti-debugging, right?). Now of course we dont have a flag here but something like an indicator used to detect the presence of a debugger. It's a special type of flag that is used to signal whether a program is being "analyzed" by a debugger. #debuger-present .(How? Usually by checking specific memory location, registers, or certain conditions in the system.) Most of the time that flag / indicator or binary indicator is set to 0 or 1. These flags can be set in the process environment block (PEB) or in the thread environment block (TEB). If you're wondering: the PEB is a structure that contains information about the process, such as the process ID, the base address of the process, and the path of the executable. The TEB is a structure that contains information about the thread, such as the thread ID, the stack base, and the stack limit. `NtGLobalFlag` : The NtGlobalFlag is a system-wide flag stored in the PEB (Process Environment Block) structure. It is used to indicate whether a process is being debugged or not. The value of it is 0 by default, but it can be changed to some degree under process control. Environment and System-Level Checks Before we dive into the code, let's talk about some environment and system-level checks that can be used to detect a debugger. Debugger-Specific Environment Variables Some debuggers set environment variables to indicate that a debugger is attached. The program can query the system for the presence of these variables to determine if a debugger is attached. Checking for Debugger Processes Another way to detect a debugger is by checking for the presence of debugger processes. This can be done by enumerating the running processes and checking for the presence of known debuggers, such as OllyDbg, x64dbg, or IDA Pro. Enumerate processes using `CreateToolhelp32Snapshot` and check for known debugger process names. Detecting Debugger-Specific System Calls Some debuggers use specific system calls or insert their own hooks. By checking or analyzing the behavior of these system calls, we can detect the presence of a debugger. Functions that may help: NtQueryInformationProcess System Calls: NtCreateThread NtReadVirtualMemory NtWriteVirtualMemory Detection Techniques: IsDebuggerPresent One of the easiest ways to detect a debugger is by using the `IsDebuggerPresent` function. This function checks whether the calling process is being debugged by a user-mode debugger. If the function returns a non-zero value, the process is being debugged. Otherwise, the process is not being debugged. if (IsDebuggerPresent()) return -1; At a lower level, specifically in assembly language, the code would appear as follows: call IsDebuggerPresent test eax, eax jne debugger_detected debugger_detected: mov eax, -1 ret What’s happening here? The code is calling `kernel32!IsDebuggerPresent`, which generally checks the `BeingDebugged` flag in the PEB (Process Environment Block). If the flag is set, it jumps to the `debugger_detected` label, sets `eax` to `-1`, and returns. Otherwise, it continues execution." CheckRemoteDebuggerPresent Another way to detect a debugger is by using `CheckRemoteDebuggerPresent()`, which checks whether a process is being debugged by a remote debugger. This function takes a process handle as input and returns a non-zero value if the process is being debugged. Otherwise, it returns zero. BOOL ProcessIsBeingDebugged; if(CheckRemoteDebuggerPresent(GetCurrentProcess(), &ProcessIsBeingDebugged)) { if(ProcessIsBeingDebugged) { return -1; } } At a lower level, the code would look like this: lea eax, [ProcessIsBeingDebugged] push eax push -1; ;GetCurrentProcess() ;or mov edi, esp call CheckRemoteDebuggerPresent cmp [ProcessIsBeingDebugged], 1 jz debugger_detected debugger_detected: push -1 call ExitProcess What about x86-64?? lea rdx, [ProcessIsBeingDebugged] mov rcx, -1 call CheckRemoteDebuggerPresent cmp [ProcessIsBeingDebugged], 1 jz debugger_detected debugger_detected: mov eax, -1 call ExitProcess What can we observe here? The code is invoking `kernel32!CheckRemoteDebuggerPresent`, a function that determines if the process is being debugged by a remote debugger. This function is also part of Windows API (the same as `IsDebuggerPresent`). If the process is being debugged, it triggers the `debugger_detected` label, sets `eax` to `-1`, and exits the process. Most of the time the logic behind these functions is the same, but the implementation may differ by that i mean the logic of the code. PEB!BeingDebugged Flag We talked about IsDebuggerPresent and CheckRemoteDebuggerPresent, but what about the PEB (Process Environment Block)? The PEB is a structure that contains information about the process, such as the process ID, the base address of the process, and the path of the executable. The PEB also contains a flag called `BeingDebugged` that indicates whether the process is being debugged. If the flag is set, the process is being debugged. Otherwise, the process is not being debugged. By using this method we dont need to call any function. We can directly check the flag in the PEB. #ifdef _WIN64 PEB pPEB = (PPEB)__readgsqword(0x30); #else PPEB pPEB = (PPEB)__readfsdword(0x60); #endif if (pPEB->BeingDebugged) { return -1; } 32-bit: mov eax, fs:[30h] cmp bye ptr [eax+2], 0 jne debugger_detected 64-bit: mov rax, gs:[60h] cmp byte ptr [rax+2], 0 jne debugger_detected In both cases, the PEB address is fetched from the FS or GSsegment, depending on the architecture: For 32-bit, the PEB address is stored at offset `0x30` in the FS segment. For 64-bit, the PEB address is stored at offset `0x60` in the GS segment. FS is used to store the base address of the Process Environment Block (PEB) in 32-bit Windows. GS is used to store the base address of the PEB in 64-bit Windows. The BeingDebugged flag is located at offset `0x2` in the PEB. If this flag is set (non-zero), it indicates that the process is being debugged. If the flag is not set (zero), the process is not being debugged. Bypassing Anti-Debugging Techniques We took a look at some of the most common anti-debugging techniques, but how can we bypass them? Let's take IsDebuggerPresent as an example. call IsDebuggerPresent test eax, eax jne debugger_detected ... [code] We will analyse the code again and see how can we "bypass" it. The code calls `IsDebuggerPresent` to check if the process is being debugged. It tests the return value of `IsDebuggerPresent` by performing a bitwise AND operation with itself. 3. If the result is non-zero, it jumps to the `debugger_detected` Now , IsDebuggerPresent is one of the easiest anti-debugging techniques to bypass. Why? because we can patch the jump instruction to skip the `debugger_detected` label. call IsDebuggerPresent test eax, eax nop ... [code] Final Thoughts You might be wondering, "What about the other functions?" It's important to recognize that not all anti-debugging mechanisms are implemented in the same way. For instance, while an if statement can often be bypassed by patching the jump instruction, a while statement presents a different challenge. This is why I'm preparing a new blog post focused on bypassing various anti-debugging techniques (though not all of them). The examples I'll be discussing will be drawn from PicoCTF and Crackmes. P.S: I'm not going to post only about bypassing anti-debugging techniques, but also about how to implement them. I’m also looking forward to meeting people with experience in Reverse Engineering. I see myself as an amateur that whishes to learn more and more, day by day.

Synopsis: Process Dump is a Windows reverse-engineering command-line tool to dump malware memory components back to disk for analysis. Often malware files are packed and obfuscated before they are executed in order to avoid AV scanners, however when these files are executed they will often unpack or inject a clean version of the malware code in memory. A common task for malware researchers when analyzing malware is to dump this unpacked code back from memory to disk for scanning with AV products or for analysis with static analysis tools such as IDA. Source: http://split-code.com/processdump.html (side-note: unul dintre cele mai interesante website-uri din punc de vedere al design-ului) GitHub Repository: https://github.com/glmcdona/Process-Dump Via:

Fitbit is building a new security team in Bucharest. Full details here: https://grnh.se/gmt7lrkc1 Brief description of the job: The application security team at Fitbit is responsible for overseeing the secure design and implementation of applications. We do this by: Consulting with software engineers to ensure the relevant controls are built into their work Assessing software produced by Fitbit and its partners Participating in the security community to understand new and emerging threats We try to find achieve our mission through innovative ways of collaborating with our software teams that allow them to continue to deliver at scale and ve What You’ll Work On: Conduct threat modelling exercises New security sensitive functionality (e.g. changes to authentication flows) require a security team member to be involved New application infrastructure, e.g. entirely new SOA services required a feedback from a security engineer Provide application security consulting to engineers Perform manual and automated code review Our goal is to automate us much of our role as possible Create rules to help us to identify software that should be manually reviewed by a skilled application security engineer Help enable self-service reviews for engineers Work on tooling to expedite the process of doing software reviews Perform ad-hoc application assessments Assist with Fitbit’s Bug Bounty programs Help with the replication, prioritization and filing of issues identified via our bug bounty programs Assist with Fitbit’s developer outreach efforts Share root cause analysis information with our outreach team to ensure we’re educating our engineers about common security pitfalls and how to avoid them Required Skills: Significant experience in application penetration testing and source code review Knowledge of mobile and web application architecture Ability to read and break code written in different languages, emphasis on Java Strong understanding of applied cryptography Strong understanding of web application security technologies like CORS, OAuth, JSONP and browser security concepts such as the same origin policy Experience with static and dynamic application security tools A passion for security and technology Experience in a variety of software development environments and knowledge of contemporary agile software development methodologies Experience with test-driven development and other agile practices Broad knowledge of all areas of information technology including networking, operating systems and ideally application development Strong software development skills in at least one language Aspires to develop a deep understanding of information security Experience as a system administrator or security engineer Experience with managing information security incidents Solves problems through scripting and automation Willing to learn new things Willing to look at for innovative or non-standard solutions to problems Good sense of humor Calm under pressure Good time management skills Interactions with other teams The application security team is responsible for consulting with software engineering teams about the best and safest way to implement their features. They are also responsible for reviewing the output of software engineering teams for safety. As such, strong interpersonal skills are required. This person needs to be able to diplomatically provide software engineers with advice, and to coach developers through problems that may be identified in their work. The successful applicant will be able to positively influence software engineers’ behaviour through their interactions. Nice-to-Have Skills: Have a strong development background Background in infrastructure penetration testing Experience with compliance such as PCI and/or ISO27000 Experience with exploit/proof of concept development Experience in information security consulting Experience in in-house application security teams at larger technology companies with a reputation for security engineering Had incident response experience Developed tooling to automate information security tasks Have a wide knowledge from diverse parts of IT Worked on open source security projects

Synopsis: Noriben is a Python-based script that works in conjunction with SysInternals Procmon to automatically collect, analyze, and report on run-time indicators of malware. In a nutshell, it allows you to run your malware, hit a keypress, and get a simple text report of the sample's activities. Link: https://github.com/Rurik/noriben

Synopsis: PCILeech uses PCIe hardware devices to read and write from the target system memory. This is achieved by using DMA over PCIe. No drivers are needed on the target system. Link: https://github.com/ufrisk/pcileech/

Disassembler and Runtime Analysis (or how IDA Pro has some difficulties when displaying correctly the assembly of the patched run-time whilst using a Graph view) Link: http://blog.talosintelligence.com/2017/10/disassembler-and-runtime-analysis.html

O carte pentru pasionatii de reverse engineering(incepatori): http://beginners.re/Reverse_Engineering_for_Beginners-en.pdf Have Funk!

Software reverse engineering, the art of pulling programs apart to figure out how they work, is what makes it possible for sophisticated hackers to scour code for exploitable bugs. It’s also what allows those same hackers’ dangerous malware to be deconstructed and neutered. Now a new encryption trick could make both those tasks much, much harder. At the SyScan conference next month in Singapore, security researcher Jacob Torrey plans to present a new scheme he calls Hardened Anti-Reverse Engineering System, or HARES. Torrey’s method encrypts software code such that it’s only decrypted by the computer’s processor at the last possible moment before the code is executed. This prevents reverse engineering tools from reading the decrypted code as it’s being run. The result is tough-to-crack protection from any hacker who would pirate the software, suss out security flaws that could compromise users, and even in some cases understand its basic functions. “This makes an application completely opaque,” says Torrey, who works as a researcher for the New York State-based security firm Assured Information Security. “It protects software algorithms from reverse engineering, and it prevents software from being mined for vulnerabilities that can be turned into exploits.” A company like Adobe or Autodesk might use HARES as a sophisticated new form of DRM to protect their pricey software from being illegally copied. On the other hand, it could also mean the start of a new era of well-armored criminal or espionage malware that resists any attempt to determine its purpose, figure out who wrote it, or develop protections against it. As notable hacker the Grugq wrote on twitter when Torrey’s abstract was posted to SyScan’s schedule, HARES could mean the “end of easy malware analysis. ” To keep reverse engineering tools in the dark, HARES uses a hardware trick that’s possible with Intel and AMD chips called a Translation Lookaside Buffer (or TLB) Split. That TLB Split segregates the portion of a computer’s memory where a program stores its data from the portion where it stores its own code’s instructions. HARES keeps everything in that “instructions” portion of memory encrypted such that it can only be decrypted with a key that resides in the computer’s processor. (That means even sophisticated tricks like a “cold boot attack,” which literally freezes the data in a computer’s RAM, can’t pull the key out of memory.) When a common reverse engineering tool like IDA Pro reads the computer’s memory to find the program’s instructions, that TLB split redirects the reverse engineering tool to the section of memory that’s filled with encrypted, unreadable commands. “You can specifically say that encrypted memory shall not be accessed from other regions that aren’t encrypted,” says Don Andrew Bailey, a well-known security researcher for Lab Mouse Security, who has reviewed Torrey’s work. Many hackers begin their reverse engineering process with a technique called “fuzzing.” Fuzzing means they enter random data into the program in the hopes of causing it to crash, then analyze those crashes to locate more serious exploitable vulnerabilities. But Torrey says that fuzzing a program encrypted with HARES would render those crashes completely unexplainable. “You could fuzz a program, but even if you got a crash, you wouldn’t know what was causing it,” he says. “It would be like doing it blindfolded and drunk.” “IMAGINE TRYING TO FIGURE OUT WHAT STUXNET DID IF YOU COULDN’T LOOK AT IT.” Torrey says he intends HARES to be used for protection against hacking—not for creating mysterious malware that can’t be dissected. But he admits that if HARES works, it will be adopted for offensive hacking purposes, too. “Imagine trying to figure out what Stuxnet did if you couldn’t look at it,” he says. “I think this will change how [nation-state] level malware can be reacted to.” HARES’s protections aren’t quite invincible. Any program that wants to use its crypto trick needs to somehow place a decryption key in a computer’s CPU when the application is installed. In some cases, a super-sophisticated reverse engineer could intercept that key and use it to read the program’s hidden commands. But snagging the key would require him or her to plan ahead, with software that’s ready to look for it. And in some cases where software comes pre-installed on a computer, the key could be planted in the CPU ahead of time by an operating system maker like Apple or Microsoft to prevent its being compromised. “There are some concerns with this from a technical point of view,” says Bailey. “But it’s way better than anything we have out there now.” Another way to crack HARES’ encryption, says Torrey, would be to take advantage of a debugging feature in some chips. That feature allows a hardware device between the chip and the motherboard to read every command the processor executes. But taking advantage of that feature requires a five-figure-priced JTAG debugger, not a device most reverse engineers tend to have lying around. “It’s pretty high level stuff,” he says. “Obviously nation states will have these things, but probably not very many others.” Torrey notes that it may someday be possible to encrypt a program’s code in a way that its instructions can run without ever being decrypted—making software that’s truly unhackable. But such a system, known as “fully homomorphic encryption,” is still largely theoretical. It currently makes computer processes take millions of times longer than they would without encryption. HARES slows down the programs it protects by only about 2 percent. “Fully homomorphic encryption is the holy grail, but it’s an academic math problem,” Torrey says. “This is something you can stick on your existing computer to protect your existing software.” Torrey developed HARES’s TLB split trick with funding in 2013 from Darpa’s Cyber Fast Track program. He plans to release the project’s code not at March’s SyScan conference, but possibly the next month at the Infiltrate security conference in Miami. Torrey says that he wouldn’t be surprised, however, if coders determine from his March talk how to use HARES’s tricks and begin writing malware that’s far harder to decode. Give hackers an unencrypted hint or two, and they have a way of figuring out your secrets. Source

Se da urmatorul executabil compilat: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 begin 644 addr.tar.bz2 M0EIH.3%!629363;W0%@`"%Y_________[__[________W_3^[O]_:9KMSVVD M^'5N?V??X`I_;W`U=P2<=W?;W+X[ITDWSNG6<$@]S-M[/AII$T"IX1HT:::3 M4_5/"9,HTVIFFAJ8GJ>4]&HT-#:)Z1DVB:&F(9&33U,0--`#0TTS0F$,CTC3 M31M33$!H`T;*#0DTQ`:F330FTC2,IM3]32#U`TT:``````-``T#(-````#0& M@``````!H`:F")*::>H`-!H`:!H`!H!H```!B!H```&@&@```&30````-`&C M)H"0I$`1(VTFIY(VIHT#U`&)H``-`&@`>H```-!HT``#U````````&@``#L4 M#0`T&@-`TR`-``-`:`,@`````#U#(T:`R:``T#(&31H```,@`&@)$B$)IJ;* MGZ3$GIJ'IE-/*'I&FFFC0`!IZF@``::#0`#0`!H`T`]0`!H`:``#30``#_JX M&G85F@4L65B:1&0;$UWJ:NU5+GHO;3%JN0F2+9G<.BRET18&W9X[MZ_7D68L MO*RG8M7HGZ6HM.>`WYJ$`5=UKT*MRY6&$V-T=&EP+QRNYC*1QW6+0Y?_9[J- M[XS*\K2W*:;;<318,2E!R(TRO1#C9RZS[91`R9!G9BXS,>:S=S4646)1":\A M-!*46D[J,`VM!0CY:@2Y40?QCT*?A<7HXG*YO.Y.6RYSN'O>'O.EE*<336J$ MIV$+7D`97-67M-%WQ=HQ$'CD(G68UQ-E"74#*MOA?.$28*M@>M<O'<0ZK56^ MY:!U!@+)T,K([5J2K%N1:D"``>:0$1<^:A^CW4Y[1QN(2$0%*Z>_5[']':\S M0=!X%W-CQ>BW(2`(0GS$4'.W.LUSD0((Z2HFI/P??PYF6B0#;UU^QITW%E;< MT72A.ZY5A"3R_Z-DY&B$RZ\Q3#%Q;,B*/)G;C.-=\U!QHH*>()^FDFZ*ED+Z M&.QQRMH16:LN%+`H&\?1ZOP-2VFLY?)B"PK)!?J2NL7$JIK+571'*LM-?*,. M._]1BVN7].4Z&Q[]LKM'IL6U;"6=P(F67?\W^WXKV]^=!Q$8,-(&U#0H8@4- M)8;`+C!)9;21@XA`NK8!<:MUQ!E.C$C9&@1E,"NU#`T5V((+I5$.D"PQ*.PP M",;!M)NE*5LK*U*ZJ*C?0P*W1HJ=RD&PC`J&6&M&W7%AR8&!I6+8'?>!@7&% MUJ-%IK"N1(H[32C&VVPK:2O,C"6K]!1FHS<2L-(*F+4.TP56")"DT@H:2F,) M,`U+`FTE-I"J8&?:0IL0#:0V@W=A?-(DT:%B*S$!)B-.U&&2T$&&_+3TH%3` MC=Z@,<;HB^T9ML:"C"C(P(8\HU21081C&.[@JJ543LL4@VRK#9*(&A2!2$7C M)A\MHFIG'F5=!41AW>'[T[?E6<#7*PKAYB!_Q7L+QFC>P\#?OOW[@_#+0;(5 MEZQAIB.T(84`K2@+EC()<0B;,I71Q0X&EX5/.8`_+4*(JAC6JZ9*CVU2QL0O M:3S`K2]]J+K\.=A>Z^8I>A2VZ#C&RK5-0E@!W%J&T0*"9Z",DT&SR08KOLJ` M;SV3!K&IS@6;8+A&@*^D3(5]H09+TFR@2G'\YCZK]<_H+2W%BNNZ/6-'%?>: M:$Y$(E@)V!P)@N+@,9/X('C[X8:B!C&6"#J`D`>.7Z:J1U)8:&TKP``#.(!$ M`Z`0"-(-M+/,T:K$52C]OMUI43X]Y+#;&'>L1:8&H>4&*CQ<;4@@H*SD/ZV\ MCZ=SI^QF^SD)Q,Q4"-.X*(T,477T&<Q3(8Z]_:[S+A>:-.UK>=@L9FUX<$+: MD#$<K;A#<HV48CW6`9JRHT#"XFK@Z*1M43$VFJQL<8?K^1"T%-%!&1)CGR&Y M)@Y?-Q0FQ#!;!.8B,8CSR#[0XB9F"&K`S:,P\I!2=``RB>B@@(!318D!A7,# M(P\W"!"!*%$(`'!2121`9O1&*!`Q!7I!['"`A'C2[O-'^@6DI\DE3*R7,WN5 M(E`DR$F@.K[.0O](3"2(GI=/(G.5V:"EA8:AV-?T$?/,IR!P!<6CBS.!9#2( MW21I)L39!HPFB`A-G9$(TZHVN8>/38QJA6V!31`AM2S(4VA%ZPU(P"YG:/O= MFA(4(>T^Q(1>/][=K16N3V^H*?<6EDCUM>L<()(L,S"!*7,R)K@I_"H8P<HV M12'9SXZ<0.[9JAI"?2,[\F[<!`Z,K.@L-+&8;PQ4MNFK9)2WR"AW38Z*59T> M?E2"[G=FLS"K>5;6!-`W0GC,*?AF:"=,[QYRM08=B`L/I8@Q7<9F68#P(4BJ M(4LBHRVI-HV?2M7@)!?(_LX,WD,`D'+9R2Q,F;#"6L(`-4%3"VV4#.(-EA#" MVHI/34A3+TL(/&6J(EBY917W0W8U<BK$SY`4#Q_R+$E)F`502=G1:ZQ*=#.W M+IH)D\JG6!SE1V(AZJ676X/Q,\?8Y@NI:-;5"*FC"H@+'<1?.DZZ9CM]'%D9 MPS,BM.ND#ZZ*'?R&X*/)SI9SUG4VBU7KU"81P.7J9XQW0""K9@\XA*_0GB@J M(1$$A,)48%(!B=:,7AM+'/F$!LFMJ],S@6XXPFD&H+0"]Z+FN#0I6#/Q7X MX!GSZZX[Q'I*42F^H='G=#X^#2@:$0T@8M?.&*.>+(9`!UL:4Q'6HY6@TQ]. M<TRV-(;#8;Z_*.MM!B*4+%MW)8ZO^_LA>UR$U2?J[450#R&LCEJ(-P^`Y+ MVSV&G[GSI<F1*L0+`2O/(Y=2L^"Q*&*%L*3@,3@.?T1//J:*9)*;8"6#J2J> MQ8+*(J^_D7F,]4UHTC!U?WS%O:HRJI_FFL)8S,<&%C25,I1,<6@]7/^!Q$Q1 MMN64$&H"C.B+/#2*`=&_QR+PW<6F$`/Q+=-<^T(P2$-[%QWSFIF:-"51(I*P M%?!DI>NCDAEI5'&ER3IKIH(NZA$R@OE5=(A%^7;W+K3`@*J8AT0PS>7.W49D M5RVJ(M1P,.9$8A/"H%-E1S)P%@"(-6'@'"M!&@%$)R;XX*%\1`"\`PEQ9,3P MH.6,(2^Z-)6LY.[:DD"3&A':,L=*P&``V6V@-)0+<FN?(%$94HYUCH1OS21> MWW9BF^Y>$5`KO%P7)"["Y60P!S&$=!EG90"EQ4D>6&V4D+S=[Q6!;H<`M#1W ML%O1I%40NM#PJV*KC$<*%#--A@S#A2=\PF%9(JHOI2B!CI-0I23,.BLIW1U4 MUTY!*`*,$:J)5-%0/"W$,(P!WZ,:>'BE9%P@I#$%07AB%FN14*N1T!+A>O8E M$SSAN"`K<DA02BD2BLV+#`$"U$%`P(A7)NFQNN$@-D!J$#PT(Y0DJ*$.4'SA MBW6B(/-U;I7B!5QBORO)JJE+E,RI.$"D;$QKQ'JA"$[41J$0,5U$$%F9,"&G M,-#$GI;9B*T+U9<W8AF<0&`.1A1@&@S,&$@&REA9FBB<?+$*Q+?JX^X(Y*0_ M':4W.8_(F%0:`\MPW9TY?-"*:9"@R]!*=&>(F<SF9F.7$*K.7J5BZ4KD29YJ MR*]%9ZP#?3=2-]XG;I.SRM1[A,5BW5O'0;_N3_ZWS-_@`,$-//K^#59NQOFK M_6$TLO75(5CT<$6"+.3)IICMU:/:O0O]WMD`L*W40P_7)28YPB^PO`80(-W1 M`8/+I7K=7LA`.@GMBWXRE*U\%.*!4*[)K)(FA:UKBA:&-=4MYRF-!J@HG.L" M*45BAG:EB&--6@&0;%L-12)N9%GO_16<J@OH2?6ULO6K8D9!11I#.RAAHU+P MX3PICW1UGXEI>N#TT/K*K#&!,=?\BF]OLZ-L^PRZU9A",(@$Q:9GJ#_&WTM> M]-<0C14?:?##!"8J#$&P8"ZDRS0T+Y_-ZB.`N[A2?&EHP*GY+04/+VZ6]#>I M-=EAI?T\712SB9>%5:NR\\SYY4[;+&&4HDG457@21(P5:0W<<1B0TD#'^978 M_0>'E3`DK'$H/-%R43:/7=H6H*LM,^%@8@#Y![6]5@!*`4?Y?D,O:"[KAX\Y /\7UO@_XNY(IPH2!M[H"P ` end -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk+7fsEACgkQ7qSRZzZm+uAZpQD9FJYfNCm0eZ6ini/FuUxhrOPx Te40REn3xLmaH83JKdUBAKRj2cQEouVJpbmUnIhzbT7F1gt7dnO0rxkrdveNalH7 =vX0e -----END PGP SIGNATURE----- Se cere: 1.Identificati care sunt variabilele definite 2.Specificati adresa de memorie pentru fiecare variabila 3.Pentru fiecare variabila in parte identificati segmentul adresei de memorie in care a fost stocata variabila

//deleted