Leaderboard

Angelico, astia daca ating o femeie pe cur, nu se spala 6 luni crezand ca sunt binecuvantati apoi ies la tovarasii din cartier si le cer cate 5 lei sa-i atinga. Hahahhahaha

https://github.com/xoreaxeaxeax/movfuscator Imi cer scuze, nu dau paste de pe github, ajunge link-ul in umila mea opinie. Sursa unde l-am descoperit: https://twitter.com/emilyst/status/886707159454461952

https://kirschju.re/demov

Incearca versiunea taraneasca de optimizare: ia un server dedicat bun si scump.

E genial tipul care a facut asta. Hacker in adevaratul sens al cuvantului.

https://www.humblebundle.com/books/cybersecurity-wiley Social Engineering: The Art of Human Hacking The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation Threat Modeling: Designing for Security Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd Edition The Shellcoder's Handbook: Discovering and Exploiting Security Holes, 2nd Edition Cryptography Engineering: Design Principles and Practical Applications The Art of Deception: Controlling the Human Element of Security The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code Unauthorised Access: Physical Penetration Testing For IT Security Teams Secrets and Lies: Digital Security in a Networked World, 15th Anniversary Edition CEH v9: Certified Ethical Hacker Version 9 Study Guide Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition // Removed - Am scos link-ul celalalt Ce scrie acolo: "Support charity". Preturile sunt foarte mici, oricine isi poate permite. // Nytro

Rule 1: Restrict all code to very simple control flow constructs—do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion. Rule 2: Give all loops a fixed upper bound. It must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. If a tool cannot prove the loop bound statically, the rule is considered violated. Rule 3: Do not use dynamic memory allocation after initialization. Rule 4: No function should be longer than what can be printed on a single sheet of paper in a standard format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function Rule 5: The code’s assertion density should average to minimally two assertions per function. Assertions must be used to check for anomalous conditions that should never happen in reallife executions. Assertions must be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken such as returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule. Rule 6: Declare all data objects at the smallest possible level of scope. Rule 7: Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller. Rule 8: The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives must be kept to a minimum. Rule 9: The use of pointers must be restricted. Specifically, no more than one level of dereferencing should be used. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted. Rule 10: All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings. All code must also be checked daily with at least one, but preferably more than one, strong static source code analyzer and should pass all analyses with zero warnings. Source & more details here: https://spinroot.com/gerard/pdf/Power_of_Ten.pdf

Farfalle: parallel permutation-based cryptography Guido Bertoni1 , Joan Daemen1,2, Seth Hoffert, Michaël Peeters1 , Gilles Van Assche1 , and Ronny Van Keer1 1 STMicroelectronics 2 Radboud University Abstract. In this paper, we introduce Farfalle, a new permutation-based construction for building a pseudorandom function (PRF). The PRF takes as input a key and a sequence of arbitrarylength data strings, and returns an arbitrary-length output. It has a compression layer and an expansion layer, each involving the parallel application of a permutation. The construction also makes use of LFSR-like rolling functions for generating input and output masks and for updating the inner state during expansion. On top of the inherent parallelism, Farfalle instances can be very efficient because the construction imposes less requirements on the underlying primitive than, e.g., the duplex construction or typical block cipher modes. Farfalle has an incremental property: compression of common prefixes of inputs can be factored out. Thanks to its input-output characteristics, Farfalle is really versatile. We specify simple modes on top of it for authentication, encryption and authenticated encryption, as well as a wide block cipher mode. As a showcase, we present Kџюѣюѡѡђ, a very efficient instance of Farfalle based on Kђѐѐюј-p[1600, nr] permutations and formulate concrete security claims against classical and quantum adversaries. The permutations in the compression and expansion layers of Kџюѣюѡѡђ have only 6 and 4 rounds respectively and the rolling function is lightweight. We provide a rationale for our choices and report on soĞware performance. Download: https://eprint.iacr.org/2016/1188.pdf

Ten Process Injection Techniques: A Technical Survey Of Common And Trending Process Injection Techniques Ashkan Hosseini JULY 18, 2017 Process injection is a widespread defense evasion technique employed often within malware and fileless adversary tradecraft, and entails running custom code within the address space of another process. Process injection improves stealth, and some techniques also achieve persistence. Although there are numerous process injection techniques, in this blog I present ten techniques seen in the wild that run malware code on behalf of another process. I additionally provide screenshots for many of these techniques to facilitate reverse engineering and malware analysis, assisting detection and defense against these common techniques. 1. CLASSIC DLL INJECTION VIA CREATEREMOTETHREAD AND LOADLIBRARY This technique is one of the most common techniques used to inject malware into another process. The malware writes the path to its malicious dynamic-link library (DLL) in the virtual address space of another process, and ensures the remote process loads it by creating a remote thread in the target process. The malware first needs to target a process for injection (e.g. svchost.exe). This is usually done by searching through processes by calling a trio of Application Program Interfaces (APIs): CreateToolhelp32Snapshot, Process32First, and Process32Next. CreateToolhelp32Snapshot is an API used for enumerating heap or module states of a specified process or all processes, and it returns a snapshot. Process32First retrieves information about the first process in the snapshot, and then Process32Next is used in a loop to iterate through them. After finding the target process, the malware gets the handle of the target process by calling OpenProcess. As shown in Figure 1, the malware calls VirtualAllocEx to have a space to write the path to its DLL. The malware then calls WriteProcessMemory to write the path in the allocated memory. Finally, to have the code executed in another process, the malware calls APIs such as CreateRemoteThread, NtCreateThreadEx, or RtlCreateUserThread. The latter two are undocumented. However, the general idea is to pass the address of LoadLibrary to one of these APIs so that a remote process has to execute the DLL on behalf of the malware. CreateRemoteThread is tracked and flagged by many security products. Further, it requires a malicious DLL on disk which could be detected. Considering that attackers are most commonly injecting code to evade defenses, sophisticated attackers probably will not use this approach. The screenshot below displays a malware named Rebhip performing this technique. Figure 1: Rebhip worm performing a typical DLL injection Sha256: 07b8f25e7b536f5b6f686c12d04edc37e11347c8acd5c53f98a174723078c365 2. PORTABLE EXECUTABLE INJECTION (PE INJECTION) Instead of passing the address of the LoadLibrary, malware can copy its malicious code into an existing open process and cause it to execute (either via a small shellcode, or by calling CreateRemoteThread). One advantage of PE injection over the LoadLibrary technique is that the malware does not have to drop a malicious DLL on the disk. Similar to the first technique, the malware allocates memory in a host process (e.g. VirtualAllocEx), and instead of writing a “DLL path” it writes its malicious code by calling WriteProcessMemory. However, the obstacle with this approach is the change of the base address of the copied image. When a malware injects its PE into another process it will have a new base address which is unpredictable, requiring it to dynamically recompute the fixed addresses of its PE. To overcome this, the malware needs to find its relocation table address in the host process, and resolve the absolute addresses of the copied image by looping through its relocation descriptors. This technique is similar to other techniques, such as reflective DLL injection and memory module, since they do not drop any files to the disk. However, memory module and reflective DLL injection approaches are even stealthier. They do not rely on any extra Windows APIs (e.g., CreateRemoteThread or LoadLibrary), because they load and execute themselves in the memory. Reflective DLL injection works by creating a DLL that maps itself into memory when executed, instead of relying on the Window’s loader. Memory Module is similar to Reflective DLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself. In a previous blog post, these two in memory approaches were discussed extensively. When analyzing PE injection, it is very common to see loops (usually two “for” loops, one nested in the other), before a call to CreateRemoteThread. This technique is quite popular among crypters (softwares that encrypt and obfuscate malware). In Figure 2, the sample unit test is taking advantage of this technique. The code has two nested loops to adjust its relocation table that can be seen before the calls to WriteProcessMemory and CreateRemoteThread. The “and 0x0fff” instruction is also another good indicator, showing that the first 12 bits are used to get the offset into the virtual address of the containing relocation block. Now that the malware has recomputed all the necessary addresses, all it needs to do is pass its starting address to CreateRemoteThread and have it executed. Figure 2: Example structure of the loops for PE injection prior to calls to CreateRemoteThread Sha256: ce8d7590182db2e51372a4a04d6a0927a65b2640739f9ec01cfd6c143b1110da 3. PROCESS HOLLOWING (A.K.A PROCESS REPLACEMENT AND RUNPE) Instead of injecting code into a host program (e.g., DLL injection), malware can perform a technique known as process hollowing. Process hollowing occurs when a malware unmaps (hollows out) the legitimate code from memory of the target process, and overwrites the memory space of the target process (e.g., svchost.exe) with a malicious executable. The malware first creates a new process to host the malicious code in suspended mode. As shown in Figure 3, this is done by calling CreateProcess and setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004). The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called. Next, the malware needs to swap out the contents of the legitimate file with its malicious payload. This is done by unmapping the memory of the target process by calling either ZwUnmapViewOfSection or NtUnmapViewOfSection. These two APIs basically release all memory pointed to by a section. Now that the memory is unmapped, the loader performs VirtualAllocEx to allocate new memory for the malware, and uses WriteProcessMemory to write each of the malware’s sections to the target process space. The malware calls SetThreadContext to point the entrypoint to a new code section that it has written. At the end, the malware resumes the suspended thread by calling ResumeThread to take the process out of suspended state. Figure 3: Ransom.Cryak performing process hollowing Sha256: eae72d803bf67df22526f50fc7ab84d838efb2865c27aef1a61592b1c520d144 4. THREAD EXECUTION HIJACKING (A.K.A SUSPEND, INJECT, AND RESUME (SIR)) This technique has some similarities to the process hollowing technique previously discussed. In thread execution hijacking, malware targets an existing thread of a process and avoids any noisy process or thread creations operations. Therefore, during analysis you will probably see calls to CreateToolhelp32Snapshot and Thread32First followed by OpenThread. After getting a handle to the target thread, the malware puts the thread into suspended mode by calling SuspendThread to perform its injection. The malware calls VirtualAllocEx and WriteProcessMemory to allocate memory and perform the code injection. The code can contain shellcode, the path to the malicious DLL, and the address of LoadLibrary. Figure 4 illustrates a generic trojan using this technique. In order to hijack the execution of the thread, the malware modifies the EIP register (a register that contains the address of the next instruction) of the targeted thread by calling SetThreadContext. Afterwards, malware resumes the thread to execute the shellcode that it has written to the host process. From the attacker’s perspective, the SIR approach can be problematic because suspending and resuming a thread in the middle of a system call can cause the system to crash. To avoid this, a more sophisticated malware would resume and retry later if the EIP register is within the range of NTDLL.dll. Figure 4: A generic trojan is performing thread execution hijacking Sha256: 787cbc8a6d1bc58ea169e51e1ad029a637f22560660cc129ab8a099a745bd50e 5. HOOK INJECTION VIA SETWINDOWSHOOKEX Hooking is a technique used to intercept function calls. Malware can leverage hooking functionality to have their malicious DLL loaded upon an event getting triggered in a specific thread. This is usually done by calling SetWindowsHookEx to install a hook routine into the hook chain. The SetWindowsHookEx function takes four arguments. The first argument is the type of event. The events reflect the range of hook types, and vary from pressing keys on the keyboard (WH_KEYBOARD) to inputs to the mouse (WH_MOUSE), CBT, etc. The second argument is a pointer to the function the malware wants to invoke upon the event execution.The third argument is a module that contains the function. Thus, it is very common to see calls to LoadLibrary and GetProcAddress before calling SetWindowsHookEx. The last argument to this function is the thread with which the hook procedure is to be associated. If this value is set to zero all threads perform the action when the event is triggered. However, malware usually targets one thread for less noise, thus it is also possible to see calls CreateToolhelp32Snapshot and Thread32Next before SetWindowsHookEx to find and target a single thread. Once the DLL is injected, the malware executes its malicious code on behalf of the process that its threadId was passed to SetWindowsHookEx function. In Figure 5, Locky Ransomware implements this technique. Figure 5: Locky Ransomware using hook injection Sha256: 5d6ddb8458ee5ab99f3e7d9a21490ff4e5bc9808e18b9e20b6dc2c5b27927ba1 6. INJECTION AND PERSISTENCE VIA REGISTRY MODIFICATION (E.G. APPINIT_DLLS, APPCERTDLLS, IFEO) Appinit_DLL, AppCertDlls, and IFEO (Image File Execution Options) are all registry keys that malware uses for both injection and persistence. The entries are located at the following locations: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options AppInit_DLLs Malware can insert the location of their malicious library under the Appinit_Dlls registry key to have another process load their library. Every library under this registry key is loaded into every process that loads User32.dll. User32.dll is a very common library used for storing graphical elements such as dialog boxes. Thus, when a malware modifies this subkey, the majority of processes will load the malicious library. Figure 6 demonstrates the trojan Ginwui relying on this approach for injection and persistence. It simply opens the Appinit_Dlls registry key by calling RegCreateKeyEx, and modifies its values by calling RegSetValueEx. Figure 6: Ginwui modifying the AppIniti_DLLs registry key Sha256: 9f10ec2786a10971eddc919a5e87a927c652e1655ddbbae72d376856d30fa27c AppCertDlls This approach is very similar to the AppInit_DLLs approach, except that DLLs under this registry key are loaded into every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW, and WinExec. Image File Execution Options (IFEO) IFEO is typically used for debugging purposes. Developers can set the “Debugger Value” under this registry key to attach a program to another executable for debugging. Therefore, whenever the executable is launched the program that is attached to it will be launched. To use this feature you can simply give the path to the debugger, and attach it to the executable that you want to analyze. Malware can modify this registry key to inject itself into the target executable. In Figure 7, Diztakun trojan implements this technique by modifying the debugger value of Task Manager. Figure 7: Diztakun trojan modifying IFEO registry key Sha256: f0089056fc6a314713077273c5910f878813fa750f801dfca4ae7e9d7578a148 7. APC INJECTION AND ATOMBOMBING Malware can take advantage of Asynchronous Procedure Calls (APC) to force another thread to execute their custom code by attaching it to the APC Queue of the target thread. Each thread has a queue of APCs which are waiting for execution upon the target thread entering alterable state. A thread enters an alertable state if it calls SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx, or WaitForSingleObjectEx functions. The malware usually looks for any thread that is in an alterable state, and then calls OpenThread and QueueUserAPC to queue an APC to a thread. QueueUserAPC takes three arguments: 1) a handle to the target thread; 2) a pointer to the function that the malware wants to run; 3) and the parameter that is passed to the function pointer. In Figure 8, Amanahe malware first calls OpenThread to acquire a handle of another thread, and then calls QueueUserAPC with LoadLibraryA as the function pointer to inject its malicious DLL into another thread. AtomBombing is a technique that was first introduced by enSilo research, and then used in Dridex V4. As we discussed in detail in a previous post, the technique also relies on APC injection. However, it uses atom tables for writing into memory of another process. Figure 8: Almanahe performing APC injection Sha256: f74399cc0be275376dad23151e3d0c2e2a1c966e6db6a695a05ec1a30551c0ad 8. EXTRA WINDOW MEMORY INJECTION (EWMI) VIA SETWINDOWLONG EWMI relies on injecting into Explorer tray window’s extra window memory, and has been used a few times among malware families such as Gapz and PowerLoader. When registering a window class, an application can specify a number of additional bytes of memory, called extra window memory (EWM). However, there is not much room in EWM. To circumvent this limitation, the malware writes code into a shared section of explorer.exe, and uses SetWindowLong and SendNotifyMessage to have a function pointer to point to the shellcode, and then execute it. The malware has two options when it comes to writing into a shared section. It can either create a shared section and have it mapped both to itself and to another process (e.g., explorer.exe), or it can simply open a shared section that already exists. The former has the overhead of allocating heap space and calling NTMapViewOfSection in addition to a few other API calls, so the latter approach is used more often. After malware writes its shellcode in a shared section, it uses GetWindowLong and SetWindowLong to access and modify the extra window memory of “Shell_TrayWnd”. GetWindowLong is an API used to retrieve the 32-bit value at the specified offset into the extra window memory of a window class object, and SetWindowLong is used to change values at the specified offset. By doing this, the malware can simply change the offset of a function pointer in the window class, and point it to the shellcode written to the shared section. Like most other techniques mentioned above, the malware needs to trigger the code that it has written. In previously discussed techniques, malware achieved this by calling APIs such as CreateRemoteThread, QueueUserAPC, or SetThreadContext. With this approach, the malware instead triggers the injected code by calling SendNotifyMessage. Upon execution of SendNotifyMessage, Shell_TrayWnd receives and transfers control to the address pointed to by the value previously set by SetWindowLong. In Figure 9, a malware named PowerLoader uses this technique. Figure 9: PowerLoader injecting into extra window memory of shell tray window Sha256: 5e56a3c4d4c304ee6278df0b32afb62bd0dd01e2a9894ad007f4cc5f873ab5cf 9. INJECTION USING SHIMS Microsoft provides Shims to developers mainly for backward compatibility. Shims allow developers to apply fixes to their programs without the need of rewriting code. By leveraging shims, developers can tell the operating system how to handle their application. Shims are essentially a way of hooking into APIs and targeting specific executables. Malware can take advantage of shims to target an executable for both persistence and injection. Windows runs the Shim Engine when it loads a binary to check for shimming databases in order to apply the appropriate fixes. There are many fixes that can be applied, but malware’s favorites are the ones that are somewhat security related (e.g., DisableNX, DisableSEH, InjectDLL, etc). To install a shimming database, malware can deploy various approaches. For example, one common approach is to simply execute sdbinst.exe, and point it to the malicious sdb file. In Figure 10, an adware, “Search Protect by Conduit”, uses a shim for persistence and injection. It performs an “InjectDLL” shim into Google Chrome to load vc32loader.dll. There are a few existing tools for analyzing sdb files, but for the analysis of the sdb listed below, I used python-sdb. Figure10: SDB used by Search Protect for injection purposes Sha256: 6d5048baf2c3bba85adc9ac5ffd96b21c9a27d76003c4aa657157978d7437a20 10. IAT HOOKING AND INLINE HOOKING (A.K.A USERLAND ROOTKITS) IAT hooking and inline hooking are generally known as userland rootkits. IAT hooking is a technique that malware uses to change the import address table. When a legitimate application calls an API located in a DLL, the replaced function is executed instead of the original one. In contrast, with inline hooking, malware modifies the API function itself. In Figure 11, the malware FinFisher, performs IAT hooking by modifying where the CreateWindowEx points. Figure 11: FinFisher performing IAT hooking by changing where CreateWindowEx points to Sha256: f827c92fbe832db3f09f47fe0dcaafd89b40c7064ab90833a1f418f2d1e75e8e CONCLUSION In this post, I covered ten different techniques that malware uses to hide its activity in another process. In general, malware either directly injects its shellcode into another process or it forces another process to load its malicious library. In Table 1, I have classified the various techniques and provided samples to serve as a reference for observing each injection technique covered in this post. The figures included throughout the post will help the researcher recognize the various techniques when reversing malware. Table1: Process injection can be done by directly injecting code into another process, or by forcing a DLL to be loaded into another process Attackers and researchers regularly discover new techniques to achieve injection and provide stealth. This post detailed ten common and emerging techniques, but there are others, such as COM hijacking. Defenders will never be “done” in their mission to detect and prevent stealthy process injection because adversaries will never stop innovating. At Endgame, we constantly research advanced stealth techniques and bring protections into our product. We layer capabilities which detect malicious DLLs that load on some persistence (like AppInit DLLs, COM Hijacks, and more), prevent many forms of code injection in real-time via our patented shellcode injection protection, and detect malicious injected payloads running in memory delivered through any of the above techniques through our patent-pending fileless attack detection techniques. This approach allows our platform to be more effective than any other product on the market in protecting against code injection, while also maximizing resiliency against bypass due to emerging code injection techniques. Sursa: https://www.endgame.com/blog/technical-blog/ten-process-injection-techniques-technical-survey-common-and-trending-process

Cred ca iesi mai avantajos la Hetzner din motivul ca ai snashot gratis. La ovh trebuie sa platesti suplimentar. Legat de performante cred ca sunt pe acolo ambele.

A highly critical vulnerability has been discovered in the Cisco Systems’ WebEx browser extension for Chrome and Firefox, for the second time in this year, which could allow attackers to remotely execute malicious code on a victim's computer. Cisco WebEx is a popular communication tool for online events, including meetings, webinars and video conferences that help users connect and collaborate with colleagues around the world. The extension has roughly 20 million active users. Discovered by Tavis Ormandy of Google Project Zero and Cris Neckar of Divergent Security, the remote code execution flaw (CVE-2017-6753) is due to a designing defect in the WebEx browser extension. To exploit the vulnerability, all an attacker need to do is trick victims into visiting a web page containing specially crafted malicious code through the browser with affected extension installed. Successful exploitation of this vulnerability could result in the attacker executing arbitrary code with the privileges of the affected browser and gaining control of the affected system. Cisco has already patched the vulnerability and released “Cisco WebEx Extension 1.0.12” update for Chrome and Firefox browsers that address this issue, though "there are no workarounds that address this vulnerability." Download Cisco WebEx Extension 1.0.12 Chrome Extensions Firefox Extension In general, users are always recommended to run all software as a non-privileged user in an effort to diminish the effects of a successful attack. Fortunately, Apple's Safari, Microsoft's Internet Explorer and Microsoft's Edge are not affected by this vulnerability. Cisco WebEx Productivity Tools, Cisco WebEx browser extensions for Mac or Linux, and Cisco WebEx on Microsoft Edge or Internet Explorer are not affected by the vulnerability, the company confirmed. The remote code execution vulnerability in Cisco WebEx extension has been discovered second time in this year. Ormandy alerted the networking giant to an RCE flaw in the WebEx browser extension earlier this year as well, which even led to Google and Mozilla temporarily removing the add-on from their stores. Via thehackernews.com

DE CE????? Nu te lasă că sugi pula scump + vrei bonus niște token-uri.

Pff numai dujmani pe chiatu ala

@aelius

Hi, If anyone needs the entire collection here is the link: aHR0cHM6Ly9tZWdhLm56LyMhQjNoU0ZBUUEhRjRwMFZWYU9qM2hrRy1Ub1NVQ2FzemNZeGw2S2ZsbVB2eHQ2R0M0cTRmOA== PS: I agree with what Nytro said. The only reason for posting the entire collection is that I want to help the community and specially the ones that cannot afford the money yet. I am posting the link for a definite amount of time and then it will disappear. The link is base64 for those who do not know. By the way, Vivek`s English is ok (believe me, others are far worst at English than he is). Fave fun!

Salut. OVH, Debian, Apache, PHP 7, MSQL, nu are nimic special. Bine, doar pe parte de security e hardcore, l-am configurat cu ./nytro.sh --force

Mai bine spune detalii despre ce si cum folosesti pentru a stii ce sfaturi sa-ti dam. - Platforma web: wordpress, magento, forum ... etc - De ce ai ales sa treci prin cloudflare - un php.ini si config-ul pool-ului de php-fpm ar ajuta. - my.cnf (fisierul de configuratie mysql) - Daca folosesti MySQL sau Percona, MariaDB - Ce engine folosesti pe tabele din baza de date - Ce resurse hardware ai pe server (ssd, hdd, memorie, procesor) - Daca ai SSD, ce procent este utilizat din capacitatea lui (spatiu folosit) - Ruleaza din alta locatie httping catre site-ul tau si arata-ne un timp mediu de raspuns. (ms.) - Ce scor are site-ul tau pe PageSpeed Insights - Daca servesti sau nu continutul prin https

Deci va rog frumos sa mi se transmita de ce sunt banata aici pe chat. Nu vorbesc urat.pe cei care stiu a vorbi urat ii lasa , si pe mine ma scoate afara. DE CE????? Astept imediat raspunsul. Este rusinos.!!!!!!!!! A trebuit sa imi fac trei email yahoo si unul google,.si tot m-a scos afara de pe chat!!!! Vreau sa stiu motivullll!!!!!!