Leaderboard

Partikip!

SOURCE I’ve been investigating different fuzzing approaches on some Android devices recently, and this turned up the following rather interesting bug (CVE 2016-3861 fixed in the most recent Android Security Bulletin), deep in the bowels of the usermode Android system. It’s an extremely serious bug, since the vulnerable code path is accessible from many different attack vectors, and it can be leveraged both for remote code execution and for local privilege elevation into the highly privileged system_server selinux domain. I’m a big fan of single bug chains [1] [2]. The bug is quite straightforward, and since it’s quite readily fuzzable, it’s interesting that it’s been undiscovered for so long. The vulnerable code is in libutils, and is in the conversion between UTF16 and UTF8. This code is used in many places, including the android::String8(const android::String16&) constructor. The Bug There are two functions in libutils/Unicode.cpp that need to match up; the first, utf16_to_utf8_length is used to compute the size of buffer needed to hold the UTF8 string that will be the result of converting the source UTF16 string, and utf16_to_utf8 performs the conversion. These functions are intended to be used together, to first allocate a buffer of the required size and then convert, and so it is obviously important that they agree on how many bytes of output are needed… So, there is obviously some difference in behaviour between the functions; and we can fairly easily construct some input that will produce different behaviour in each. If you can’t see one easily, try walking through the logic in each function with the input string: ‘\x01\xd8\x02\xd8\x03\xdc\x00\x00’ This will be seen by utf16_to_utf8_length as a string consisting of two invalid surrogate pairs, requiring 0 bytes of output to encode. (0xd801, 0xd802), (0xdc03), (0x0000) It will however be seen by utf16_to_utf8 as a string starting with an invalid surrogate pair, followed by a valid surrogate pair; which encodes to 4 bytes of output. (0xd801, 0xd802), (0xd802, 0xdc03), (0x0000) This gives quite a nice exploitation primitive; by creating a string containing valid UTF16, we can control the size of the allocation; and we control the size of the overflow, with the limitation that it must be a multiple of 4 bytes larger than the allocation. The only significant limitation is that the data that we overflow with needs to be valid UTF8, which will prove slightly annoying later on. Attack Vectors We need to identify a nice attack vector we can use to exploit this issue. Now, as I said earlier, this bug was found by fuzzing - can’t we just use the fuzz case? Well, it was found by fuzzing some OEM-specific code (the vendor isn’t relevant). We can find some core Android attack surface, and write an exploit that targets all Android devices instead. The first nice place I found is the following piece of code (in Parcel.cpp), which is interesting because the generated code for every* system service on an Android device calls this function on every parcel it receives. So, this should give us a privilege escalation from the untrusted_app context into any binder service we fancy; there are plenty of choices, but since there are so many inside system_server, why go anywhere else? * Except the service_manager implements this logic itself, and probably some OEMS are rolling their own, but to all intents and purposes, this statement is true. Anyway, I wanted a remote exploit, and it seemed likely that this code was being called in other places that were accessible remotely; maybe WiFi or Bluetooth, or DNS? Anyway, I looked around a bit, but the most obvious places were usually using the (completely distinct) libcutils implementations, and it was all a bit frustrating. Then I remembered, of course, mediaserver! Sure enough, in the processing of ID3 tags, we sometimes need to handle unicode conversions. This is kind of convenient, since I’ve already done a lot of legwork understanding how to exploit libstagefright bugs. Producing a minimal crash PoC was straightforward, although slightly annoying since libstagefright doesn’t appear to parse the same ID3v2 format I found documentation for… The file is attached to the bug report, but it looks like this: 00000000: 0000 0014 6674 7970 6973 6f6d 0000 0001 ....ftypisom.... 00000010: 6973 6f6d 0000 182f 7472 616b 0000 1827 isom.../trak...' 00000020: 4944 3332 4141 4141 4141 4944 3302 0200 ID32AAAAAAID3... 00000030: 0000 300f 5441 4c00 1809 0165 6e67 00fe ..0.TAL....eng.. 00000040: ff41 d841 d841 dc41 d841 d841 dc41 d841 .A.A.A.A.A.A.A.A ... 00001830: d841 d841 dc41 d841 d841 dc41 d841 d841 .A.A.A.A.A.A.A.A 00001840: dc00 00 ... A very simple file; just enough to get an ID3 tag read and processed that will trigger a large overflow out of a very small allocation. I’ve highlighted the first instance of the bad UTF16 sequence that will trigger the overflow; this sequence is just repeated many many times. Mitigating Mitigations My previous stagefright exploit was very crude; I was lazy and the only reason that I was writing the exploit at all was that I couldn’t bear to have another person ask me if the bug was at all exploitable on the latest Android versions. I was happy to stop working the minute I had something that worked and was plausible; but it wasn’t up to the usual standards I hold myself to… So, anyway, this time, with a better bug and with a few of the shortcuts I took previously mitigated in the latest Android versions, it’s time to return to stagefright and do things properly this time. There’s been a fair amount of additional work in the public building on my PoC exploit; one reliable exploit that I’ve seen privately, and the exploit by NorthBit detailed here. I’m not going to go into any real detail on the heap-grooming used here in this blog post; it’s already going to be a long post… Hopefully the exploit code and a debugger can teach you everything you need to know; I think the previous post and papers on stagefright exploitation probably cover everything but the precise specifics in this case, so I’ll just outline the steps that the exploit takes instead. First things first, we need to solve the ASLR problem. The technique I originally considered to do this was implemented already by NorthBit, using the metadata returned to the browser to construct an information leak; this seems to be the simplest way. Another possibility would be to corrupt the objects used for communication with the remote HTTP server; the mediaserver process makes HTTP requests to retrieve the media file, and we could perhaps modify the headers to leak information; but I did not follow this route. I looked at using the metadata corruption technique they implemented, but it seemed somewhat impractical to me. Even if we can predict “fairly reliably” a safe address to read from, there is another issue - Android have enabled the ubsan integer-overflow checking in their libstagefright builds; and the duration field has several arithmetic operations performed on it; and if any of those operations overflow, we don’t just lose bits of information, we abort! So, we can’t practically use the duration. There are two more fields that can be retrieved from Chrome; the width and height of the video. These fields fit our needs perfectly; they’re pointer-sized, and they’re inline in the heap allocation for the metadata. Let’s see how we can use them to get all the information we need. Step 1 - Heap pointer leak Our first step in bypassing ASLR is a partial bypass; we’d like to get data we control at an address that we know. We can do this using the video height to leak the address of some of the data parsed from our media file. For this, we need two things to line up nicely; the allocation that we will overflow out of needs to land directly in front of the SharedBuffer object that is providing the backing data store for the KeyedVector that stores the entries in the MetaData for one of our tracks. The key realisation here is that the ‘hvcC’ chunks that I used in the heap groom for the previous exploit store a pointer to data we control inside the MetaData object; so by corrupting the backing vector we can instead make this pointer into the height of our video, letting us read it back from inside Chrome. So, let’s attach a debugger to mediaserver and see what happens during the first part of the exploit. So to leak the address of the allocation caused by the ‘hvcC’ chunk, we just need to use the overflow to move the height entry down by a row, so that the height is instead the pointer! This value will then be handed back to Chrome as the height of the video, and we can read it back from javascript. This is a powerful primitive; and we’ll use this multiple times in the final exploit. First though, we just need to load this file repeatedly until we get an address that we can safely encode using UTF8; we’ll need a valid address that we can write using the overflow for the next step. Step 2 - Module pointer leak So, we have an address on the heap, next we need to leak the address of some executable code. This is going to be much more fiddly than the previous step; and we’ll actually have to trigger the same vulnerability twice in the same MP4 to achieve our goal. If we look a bit more carefully at the object we are overflowing, another possibility opens up: Instead of overwriting the contents of the SharedBuffer, we can corrupt the metadata and change the capacity of the SharedBuffer, so that it extends to include the next allocation as well. When more track information is parsed and stored in the MetaData object, the KeyedVector backing the MetaData will expect that it needs to resize the backing storage; and will request the SharedBuffer to allocate more data; the SharedBuffer will think it has plenty of space and just carry on. So, as we know, we can only practically use this to leak things which are aligned in the last column of our hexdump; and this is not normally where we’d expect to find a vtable pointer; so we have to investigate the layout of all the objects we can create in the hope that we can find one that will place a useful pointer at an offset we can leak. As it happens, there is one such object; the SampleTable. Allocating a SampleTable after the corrupted SharedBuffer will give us the following: As you can see from the labels, there are a few things of note; the SampleTable vtable pointer is of no consequence to us - we can safely dispose of the SampleTable without calling any methods on it, just as long as we never decrement it’s refcount to 0; but the mWeakRefs pointer inherited from RefBase is a serious problem for us; this needs to be a pointer to somewhere that can be safely decremented and not result in a 0 refcount. Here’s where we will reuse the valid UTF8 pointer we leaked above. Finally, we can see the target pointer; a vtable pointer in libmedia.so. It’s quite a long way down the allocation; and the number of entries in the KeyedVector is stored out-of-line; so we need to perform the following steps: Here’s what everything looks like after the second overflow is completed; There are a few bits of cleanup we need to do at the end of this file; adding a second sample table to the track prevents the other from being referenced, and then we need to add a couple of entries back to the MetaData to ensure the file finishes parsing correctly and the pointer we want will get returned to Chrome! Step 3, 4, 5, 6 - An exercise for the reader Well, we have two powerful primitives; the ability to leak the address of a block of data whose contents we control, and we know the base address of a relatively large and generously gadget-full module, libmedia.so. It’s no major stress from here to getting ROP execution in the mediaserver process using the same technique as my previous exploit; and from there to shellcode on Android M is simply a case of calling mprotect; which is even imported by libmedia.so. The provided exploit performs this on several recent Android versions for the Nexus 5x; and is both reliable and fast in my testing. It would also be possible to make the exploit faster by directly generating the exploit files in javascript, reducing the unnecessary network round-trips retrieving identical mp4 files. The exploit code is attached to the bug tracker here. A slightly useful quirk that will make your ROPing life easier is the reference to mprotect in BnOMX::onTransact - it seems to be there for security reasons. Final thoughts I started working on this exploit on a build of the upcoming Android N release, and anyone sitting near my desk will testify to the increased aggravation this caused me. A lot of general hardening work has gone into N, and the results are impressive. That’s not to say that exploiting this bug was impossible on N - but a full chain would be significantly more complex. The initial steps to get control of the program are identical; the only significant change is that instead of mediaserver, the target process is a new one - mediaextractor, which runs in a more restrictive sandbox and no longer has the ‘execmem’ privilege, ruling out the mprotect route to shellcode, and meaning that a privilege elevation direct from ROP would be required. A day or two later I had a fairly complicated self-modifying ROP chain to make the necessary C++ virtual calls to interact with other services from the new, heavily sandboxed, mediaextractor and I was ready to start working on the privilege elevation into system_server. However, every time I tested, attempts to lookup the system_server services failed - and looking in the logs I realised that I’d misunderstood the selinux policy. While the mediaextractor was allowed to make binder calls; it wasn’t permitted to lookup any other binder services! Privilege elevation on N would instead require exploiting an additional, distinct vulnerability. As a sidenote - my original stagefright exploit used the fact that Chrome on Android provides the build-id in the useragent; an unnecessary weakness that makes fingerprinting versions from the browser completely trivial. It’s still a “feature” of the Android WebView and Chrome browser - hopefully this will be changed soon.

@Jako be aware, upcoming SEO EXPERT SPECIALIST 400$/hour. @Betit nu inteleg ce legatura are IT-ul cu ce postezi tu, coduri GTA sa? C'mon...

betiv.ro

Index of /materials/sg2016 Name Last modified Size Description Parent Directory - COMMSEC D1 - Michael Gianarakis - Reverse Engineering Swift Applications.pdf 2016-08-25 10:02 2.0M COMMSEC D1 - Sanoop Thomas - Halcyon IDE.pdf 2016-08-25 10:02 501K COMMSEC D1 - Sweety Chauhan - Data Driven Software Security.pdf 2016-08-25 08:39 1.4M COMMSEC D2 - Alfonso De Gregorio - A Code of Ethics for the Private Sector.pdf 2016-08-26 09:46 17M COMMSEC D2 - Florian Lukavsky - Fake Presidents Fraud Defrauded.pdf 2016-08-26 09:37 1.5M COMMSEC D2 - Tan Kean Siong - IoT Honeypots.pdf 2016-08-26 10:57 5.0M COMMSEC D2 - Vanessa Henderson - Copy-paste Vulnerabilities.pdf 2016-08-26 08:26 327K D1 - Adam Donenfeld and Yaniv Mordekhay - Stumping The Mobile Chipset.pdf 2016-08-26 05:30 4.1M D1 - Bernhard Mueller - Attacking Software Tokens.pdf 2016-08-25 08:30 44M D1 - Jonathan Levin - The Apple Sandbox - Deeper into the Quagmire.pdf 2016-08-25 10:05 1.8M D1 - Moonbeom Park and Youngjun Park - Understanding Your Opponent Attack Profiling.pdf 2016-08-25 07:45 1.5M D1 - Nguyen Anh Quynh - Keystone - A Next Generation Assembler Framework.pdf 2016-08-25 11:28 1.8M D1 - Olga Kochetova and Alexey Osipov - ATMs and Their Dirty Little Secrets.pdf 2016-08-25 12:02 1.9M D1 - Peter Pi - Attacking NVIDIA's Tegra Platform.pdf 2016-08-25 07:48 726K D2 - Koh Yong Chuan - Fuzzing the Windows Kernel.pdf 2016-08-26 05:18 2.0M D2 - Matteo Beccaro and Matteo Collura - Abusing Smart Cities.pdf 2016-08-26 06:16 19M D2 - Moritz Jodeit -Look Mom I Don't Use Shellcode.pdf 2016-08-26 11:11 2.0M D2 - Shlomi Oberman and Ron Shina - Breaking Exploits with Practical Control Flow Integrity.pdf 2016-08-26 08:39 3.8M D2 - Stefan Esser - iOS 10 Kernel Heap Revisited.pdf 2016-08-26 10:57 3.6M KEYNOTE 1 - Erin Jacobs - I Fight For the Users .pdf 2016-08-25 03:50 61M KEYNOTE 2 - Katie Moussouris - Hacking the Pentagon - Bounty Creation Lessons - NO SLIDES.pdf 2016-08-26 05:20 0 whitepapers/ 2016-08-26 11:11 - Link: http://gsec.hitb.org/materials/sg2016/

Recomand tuturor care vor sa invete C++ sa se uite si pe noile standarde C++ 17. Hai sa incepem si noi sa fim mai contemporani asa. Relevante: http://stackoverflow.com/questions/38060436/what-are-the-new-features-in-c17 https://en.wikipedia.org/wiki/C%2B%2B17

Defeating Antivirus Real-time Protection From The Inside 28 July 2016 on assembly, hacking, antivirus Hello again! In this post I'd like to talk about the research I did some time ago on antivirus real-time protection mechanism and how I found effective ways to evade it. This method may even work for evading analysis in sandbox environments, but I haven't tested that yet. The specific AV I was testing this method with was BitDefender. It performs real-time protection for every process in user-mode and detects suspicious behaviour patterns by monitoring the calls to Windows API. Without further ado, let's jump right to it. What is Realtime Protection? Detecting malware by signature detection is still used, but it is not very efficient. More and more malware use polymorphism, metamorphism, encryption or code obfuscation in order to make itself extremely hard to detect using the old detection methods. Most new generation AV software implement behavioral detection analysis. They monitor every running process on the PC and look for suspicious activity patterns that may indicate the computer was infected with malware. As an example, let's imagine a program that doesn't create any user interface (dialogs, windows etc.) and as soon as it starts, it wants to connect and download files from external server in Romania. This kind of behaviour is extremely suspicious and most AV software with real-time protection, will stop such process and flag it as dangerous even though it may have been seen for the first time. Now you may ask - how does such protection work and how does the AV know what the monitored process is doing? In majority of cases, AV injects its own code into the running process, which then performs Windows API hooking of specific API functions that are of interest to the protection software. API hooking allows the AV to see exactly what function is called, when and with what parameters. Cuckoo Sandbox, for example, does the same thing for generating the detailed report on how the running program interacts with the operating system. Let's take a look at how the hook would look like for CreateFileW API imported from kernel32.dll library. This is how the function code looks like in its original form: 76B73EFC > 8BFF MOV EDI,EDI 76B73EFE 55 PUSH EBP 76B73EFF 8BEC MOV EBP,ESP 76B73F01 51 PUSH ECX 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F41 E8 35D7FFFF CALL <JMP.&API-MS-Win-Core-File-L1-1-0.C> 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C Now if an AV was to hook this function, it would replace the first few bytes with a JMP instruction that would redirect the execution flow to its own hook handler function. That way AV would register the execution of this API with all parameters lying on the stack at that moment. After the AV hook handler finishes, they would execute the original set of bytes, replaced by the JMP instruction and jump back to the API function for the process to continue its execution. This is how the function code would look like with the injected JMP instruction: Hook handler: 1D001000 < main hook handler code - logging and monitoring > ... 1D001020 8BFF MOV EDI,EDI ; original code that was replaced with the JMP is executed 1D001022 55 PUSH EBP 1D001023 8BEC MOV EBP,ESP 1D001025 -E9 D72EB759 JMP kernel32.76B73F01 ; jump back to CreateFileW to instruction right after the hook jump CreateFileW: 76B73EFC >-E9 FFD048A6 JMP handler.1D001000 ; jump to hook handler 76B73F01 51 PUSH ECX ; execution returns here after hook handler has done its job 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C There are multiple ways of hooking code, but this one is the fastest and doesn't create too much bottleneck in code execution performance. Other hooking techniques involve injecting INT3 instructions or properly setting up Debug Registers and handling them with your own exception handlers that later redirect execution to hook handlers. Now that you know how real-time protection works and how exactly it involves API hooking, I can proceed to explain the methods of bypassing it. There are AV products on the market that perform real-time monitoring in kernel-mode (Ring0), but this is out of scope of this post and I will focus only on bypassing protections of AV products that perform monitoring in user-mode (Ring3). The Unhooking Flashbang As you know already, the real-time protection relies solely on API hook handlers to be executed. Only when the AV hook handler is executed, the protection software can register the call of the API, monitor the parameters and continue mapping the process activity. It is obvious that in order to completely disable the protection, we need to remove API hooks and as a result the protection software will become blind to everything we do. In our own application, we control the whole process memory space. AV, with its injected code, is just an intruder trying to tamper with our software's functionality, but we are the king of our land. Steps to take should be as follows: Enumerate all loaded DLL libraries in current process. Find entry-point address of every imported API function of each DLL library. Remove the injected hook JMP instruction by replacing it with the API's original bytes. It all seems fairly simple until the point of restoring the API function's original code, from before, when the hook JMP was injected. Getting the original bytes from hook handlers is out of question as there is no way to find out which part of the handler's code is the original API function prologue code. So, how to find the original bytes? The answer is: Manually retrieve them by reading the respective DLL library file stored on disk. The DLL files contain all the original code. In order to find the original first 16 bytes (which is more than enough) of CreateFileW API, the process is as follows: Read the contents of kernel32.dll file from Windows system folder into memory. I will call this module raw_module. Get the base address of the imported kernel32.dll module in our current process. I will call the imported module imported_module. Fix the relocations of the manually loaded raw_module with base address of imported_module (retrieved in step 2). This will make all fixed address memory references look the same as they would in the current imported_module (complying with ASLR). Parse the raw_module export table and find the address of CreateFileW API. Copy the original 16 bytes from the found exported API address to the address of the currently imported API where the JMP hook resides. This will effectively overwrite the current JMP with the original bytes of any API. If you want to read more on parsing Portable Executable files, the best tutorial was written by Iczelion (the website has a great 90's feel too!). Among many subjects, you can learn about parsing the import table and export table of PE files. When parsing the import table, you need to keep in mind that Microsoft, with release of Windows 7, introduced a strange creature called API Set Schema. It is very important to properly parse the imports pointing to these DLLs. There is a very good explanation of this entity by Geoff Chappel in his The API Set Schema article. Stealth Calling The API unhooking method may fool most of the AV products that perform their behavioral analysis in user-mode. This however does not fool enough, the automated sandbox analysis tools like Cuckoo Sandbox. Cuckoo apparently is able to detect if API hooks, it put in place, were removed. That makes the previous method ineffective in the long run. I thought of another method on how to bypass AV/sandbox monitoring. I am positive it would work, even though I have yet to put it into practice. For sure there is already malware out there implementing this technique. First of all, I must mention that ntdll.dll library serves as the direct passage between user-mode and kernel-mode. Its exported APIs directly communicate with Windows kernel by using syscalls. Most of the other Windows libraries eventually call APIs from ntdll.dll. Let's take a look at the code of ZwCreateFile API from ntdll.dll on Windows 7 in WOW64 mode: 77D200F4 > B8 52000000 MOV EAX,52 77D200F9 33C9 XOR ECX,ECX 77D200FB 8D5424 04 LEA EDX,DWORD PTR SS:[ESP+4] 77D200FF 64:FF15 C0000000 CALL DWORD PTR FS:[C0] 77D20106 83C4 04 ADD ESP,4 77D20109 C2 2C00 RETN 2C Basically what it does is pass EAX = 0x52 with stack arguments pointer in EDX to the function, stored in TIB at offset 0xC0. The call switches the CPU mode from 32-bit to 64-bit and executes the syscall in Ring0 to NtCreateFile. 0x52 is the syscall for NtCreateFile on my Windows 7 system, but the syscall numbers are different between Windows versions and even between Service Packs, so it is never a good idea to rely on these numbers. You can find more information about syscalls on Simone Margaritelli blog here. Most protection software will hook ntdll.dll API as it is the lowest level that you can get to, right in front of the kernel's doorstep. For example if you only hook CreateFileW in kernel32.dll which eventually calls ZwCreateFile in ntdll.dll, you will never catch direct API calls to ZwCreateFile. Although a hook in ZwCreateFile API will be triggered every time CreateFileW or CreateFileA is called as they both eventually must call the lowest level API that communicates directly with the kernel. There is always one loaded instance of any imported DLL module. That means if any AV or sandbox solution wants to hook the API of a chosen DLL, they will find such module in current process' imported modules list. Following the DLL module's export table, they will find and hook the exported API function of interest. Now, to the interesting part. What if we copied the code snippet, I pasted above from ntdll.dll, and implemented it in our own application's code. This would be an identical copy of ntdll.dll code that will execute a 0x52 syscall that was executed in our own code section. No user-mode protection software will ever find out about it. It is an ideal method of bypassing any API hooks without actually detecting and unhooking them! Thing is, as I mentioned before, we cannot trust the syscall numbers as they will differ between Windows versions. What we can do though is read the whole ntdll.dll library file from disk and manually map it into current process' address space. That way we will be able to execute the code which was prepared exclusively for our version of Windows, while having an exact copy of ntdll.dll outside of AV's reach. I mentioned ntdll.dll for now as this DLL doesn't have any other dependencies. That means it doesn't have to load any other DLLs and call their API. Its every exported function passes the execution directly to the kernel and not to other user-mode DLLs. It shouldn't stop you from manually importing any other DLL (like kernel32.dll or user32.dll), the same way, if you make sure to walk through the DLLs import table and populate it manually while recursively importing all DLLs from the library's dependencies. That way the manually mapped modules will use only other manually mapped dependencies and they will never have to touch the modules that were loaded into the address space when the program was started. Afterwards, it is only a matter of calling the API functions from your manually mapped DLL files in memory and you can be sure that no AV or sandbox software will ever be able to detect such calls or hook them in user-mode. Conclusion There is certainly nothing that user-mode AV or sandbox software can do about the evasion methods I described above, other than going deeper into Ring0 and monitoring the process activity from the kernel. The unhooking method can be countered by protection software re-hooking the API functions, but then the APIs can by unhooked again and the cat and mouse game will never end. In my opinion the stealth calling method is much more professional as it is completely unintrusive, but a bit harder to implement. I may spend some time on the implementation that I will test against all popular sandbox analysis software and publish the results. As always, I'm always happy to hear your feedback or ideas. You can hit me up on Twitter @mrgretzky or send an email to kuba@breakdev.org. Enjoy and see you next time! Sursa: https://breakdev.org/defeating-antivirus-real-time-protection-from-the-inside/

Daca aveti nevoie sa faceti mount la o anumita partitie dintr-o imagine. 1. Aici se poate vedea flash cardul la care urmeaza sa fac imagine: root@hp:~# fdisk -l /dev/sdb Disk /dev/sdb: 15.9 GB, 15931539456 bytes 230 heads, 21 sectors/track, 6442 cylinders, total 31116288 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 * 8192 31116287 15554048 b W95 FAT32 2. Aici fac imaginea utilizand dd root@hp:~# dd if=/dev/sdb of=test.img bs=4M 3798+1 records in 3798+1 records out 15931539456 bytes (16 GB) copied, 1494.65 s, 10.7 MB/s root@hp:~# 3. Aici verific imaginea cu fdisk root@hp:~# fdisk -l test.img Disk test.img: 15.9 GB, 15931539456 bytes 230 heads, 21 sectors/track, 6442 cylinders, total 31116288 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System test.img1 * 8192 31116287 15554048 b W95 FAT32 4. La punctul 3 am vazut Start si End la partitia pe care doresc sa o mountez. Voi utiliza mount + offset pentru a face acest lucru root@hp:~# mount -o ro,offset=$((8192*512)) test.img test/ root@hp:~# df -h|grep test /dev/loop0 15G 2.2G 13G 15% /root/test Note: - Poate va intrebati la ce va este utila mountarea partitiilor din imagini. In cazul in care ati pierdut date de pe un hdd, puteti face imagine la el si apoi sa analizati imaginea, astfel incat evitati sa gresiti ceva si sa nu mai puteti recupera acele date. - Am facut o imagine la un flash card pentru a va da un exemplu la obiect. - In loc de fdisk puteti utiliza gdisk. (in special cand lucrati cu GPT) Man pages: - http://linux.die.net/man/1/dd - http://linux.die.net/man/8/fdisk - http://linux.die.net/man/8/gdisk

There is a server, where there is problem in connecting to mysql db. It uses mysql sockets etc.. etc.. and command line (mysql & mysqldump) not working (just blank output after successful connection)+backconnect shell blocked due to firewall but netcat working. Only skilled people contact me. Jabber/XMPP: thanks.

https://dataflow.su