Didier Stevens

Thursday 6 March 2008

bpmtk: Replacing Gpdisable

Filed under: Hacking,My Software,Reverse Engineering — Didier Stevens @ 8:52

Gpdisable is a tool to bypass group policy as a limited user, posted by Marc Russinovich on his blog when he was still the owner of Sysinternals. But now that Sysinternals is owned by Microsoft, the tool is not available anymore.

My Basic Process Manipulation Tool Kit can replace Gpdisable, I’ll show how and give you one more trick.

LikeMarc did, you can inject a DLL that will patch the IAT to subvert NtQueryValueKey, but I’ll leave this technique for an upcoming post.

My example doesn’t require you to program a DLL to inject: since we want to hide the TransparentEnabled registry key, we will just rename the key in the process memory of the programs that impose Software Restriction Policies on us (like explorer.exe). Here is the bpmtk config file to achieve this goal:

dll-name advapi32.dll
#rename TransparentEnabled to AransparentEnabled
search-and-write module:. unicode:TransparentEnabled ascii:A

This will patch each process you’ve rights to and who has loaded advapi32.dll (this DLL enforces SRP).

But as Mark writes in his blog, this will not work for running processes because they have already cached the value of TransparentEnabled and are thus not querying the registry anymore. This is why many people reported that Gpdisable didn’t work for them. Gpupdate /force will force a refresh of the policies, and invalidate the cache.

But if you’re in a restricted environment, there’s a chance you’re prevented from doing a gpupdate. Here’s another way: set the variable _g_bInitializedFirstTime to 0, this will also invalidate the cache. For advapi32.dll version 5.1.2600.2180, this variable is at address 77E463C8. Our script becomes:

dll-name advapi32.dll
#rename TransparentEnabled to AransparentEnabled
search-and-write module:. unicode:TransparentEnabled ascii:A
write version:5.1.2600.2180 hex:77E463C8 hex:00

Thursday 28 February 2008

Introducing the Basic Process Manipulation Tool Kit

Filed under: Forensics,Hacking,My Software,Reverse Engineering — Didier Stevens @ 10:01

For about a month or two now, I’ve been working on a toolkit to manipulate processes (running programs) on Windows. I’ve been using it mainly to research security mechanisms implemented in user processes, like Microsoft .NET Code Access Security.

Here are some of the design goals of the toolkit:

  • the toolkit must support limited accounts (accounts that are not local administrators) as much as possible
  • flexibility: provide a set of commands that can be assembled in a configuration file to execute a given task
  • the toolkit must be able to operate as a single EXE, without requiring the installation of supporting environments like Python
  • it must be a command-line tool

The toolkit has commands to search and replace data inside the memory of processes, dump memory or strings, inject DLLs, patch import address tables, … I’ll be posting examples in the coming weeks, illustrating how these commands can be used.

I’m releasing a beta version of the toolkit now, you can download it here.

This is an example of a configuration file (disable-cas.txt) to disable CAS for a given program (exactly like CASToggle does):

process-name CASToggleDemoTargetApp.exe
write version:2.0.50727.42 hex:7A3822B0 hex:01000000
write version:2.0.50727.832 hex:7A38716C hex:01000000
write version:2.0.50727.1433 hex:7A3AD438 hex:01000000

It looks for processes with the name CASToggleDemoTargetApp.exe, and will then write to the memory of these processes to set a variable to 1 (hex:01000000). The address to write to depends upon the version of the DLL containing the variable. If the DLL has version 2.0.50727.42, we will write to address 7A3822B0. For version 2.0.50727.832, we will write to 7A38716C, … So in this configuration file, at most one write command will be successful and write to memory.

Launch the toolkit with the configuration file like this:

bpmtk disable-cas.txt

You can also use the toolkit to audit programs, for example to check if they protect secrets correctly. Let’s investigate how Firefox keeps passwords (I tested this with Firefox 2.0.0.12 English on Windows XP SP2):

I created a new Firefox profile, defined a master password and stored two passwords: one for Google (BigSecretGoogle) and one for WordPress (BigSecretWordpress).

This is the config file:

process-name firefox.exe
strings address:on memory:writable regex:BigSecret

This config file will search inside the memory (only the writable virtual memory) of Firefox for strings containing the string BigSecret, and dump them to the screen, together with the address where they were found.

Let’s start Firefox and search inside the memory (bpmtk demo-firefox-passwords.txt):

bpmtk-0009.png

No BigSecrets here. Now let’s navigate to Google mail. We are prompted for the master password, so that Firefox can complete our credentials on the login screen:

bpmtk-0010.png

bpmtk-0012.png

Let’s take another peek inside the memory of the Firefox process:

bpmtk-0013.png

It should be no surprise that we find our Google password in memory (at 2 different addresses, the U indicates that we found a Unicode string).

Now let’s go to Firefox’s options and display the passwords:

bpmtk-0014.png

bpmtk-0015.png

The password manager displays the stored URLs and the usernames, but not the passwords. Let’s take another peek inside the memory of the Firefox process:

bpmtk-0016.png

This time, Firefox has also decrypted our WordPress password (BigSecretWordpress), although it’s not displayed. It’s only displayed if we provide the master password a second time:

bpmtk-0017.png

bpmtk-0018.png

So although Firefox prompts you a second time for the master password to display all the passwords, the passwords have already been decrypted in memory before you provided the master password a second time.

Now I don’t have issues with this behavior of the password manager of Firefox, I don’t think it’s a security issue (I’ve an idea why it was programmed like this). But if Firefox was a perfect program, all passwords would only be decrypted when a user explicitly asks to display all passwords.

Do you make online payments with your credit card? Now that I’ve showed you how you can look for specific strings inside a running program with my toolkit, you should know how to use it to check how long your browser keeps your credit card number inside its memory. And can you find out how to use bpmtk to erase that number from your browser’s memory?

Let me finish with an appetizer: I’ve also developed a DLL that, once injected inside a process, will instantiate a scripting engine inside said process, and start executing a script inside the process. This allows you to inject a script inside a process, which can be handy for rapid prototyping or when you’re operating in a limited environment where you don’t have a C compiler to develop a custom DLL to inject. Of course, a script is not as powerful as a compiled C program, but I’m adding some objects to provide some missing functionality.

This script injector will be released with an upcoming version of the bpmtk.

Tuesday 2 October 2007

AutoIt Malware Revisited

Filed under: Malware,Reverse Engineering — Didier Stevens @ 10:17

Since I’ve blogged about malware written with the AutoIt scripting language, I got a couple of mails asking for assistance or advice on how to detect and decompile AutoIt malware compiled to executables. In this post, I’m describing a method to identify and reverse AutoIt malware, and I show that old malware packed inside a compiled AutoIt script will elude most AV products.

When you compile an AutoIt script with the Aut2Exe tool, by default, an UPX packed executable is produced. Identifying such a compiled script is easy, the version strings tell you exactly what it is:

autoit_properties.PNG

And the (default) file icon in the Windows Explorer view is also a giveaway:

autoit_msgbox.PNG

Of course, it’s easy for a malware author to change these telltale signs. But you can also identify AutoIt malware with a magic number (see further).

Decompiling is easy, just start the decompiler (Exe2Aut, it’s in the extras folder of the AutoIt ZIP installation package) and point it to the executable.

But what if it was compiled with a passphrase, and you don’t know the passphrase? Well, as I pointed out in my previous post, you can still execute the script without providing the passphrase. And I found out some other interesting things.

Add extra whitespace to a script, or change the indentation, compile & decompile it, and the whitespace is preserved. When compilers compile source-code into machine language or intermediate language (like Java bytecode and .NET MSIL), they ignore whitespace. But because we still see the whitespace as we typed it in the decompiled program, it’s very likely that we’re not dealing with a real compiler. I believe that the source-code is stored inside the “compiled” AutoIt script.
Another test supports this hypothesis: write an AutoIt script with a syntax error and compile it. You won’t get an error! It’s only when you execute the compiled script that you’ll get an error. Decompile it, and you’ll get the script with your syntax error!

Like most seasoned computer users, I don’t RTFM before I start using software. But I skimmed the AutoScript help file for my research, and here is what I found:

Technical Details
The compiled script and additional files added with FileInstall are compressed with my own (Jon) compression scheme.
Because a compiled script must “run” itself without a password it needs to be able to decrypt itself – i.e., the encryption is two-way. For this reason you should regard the compiled exe as being encoded rather than completely safe. For example, if I wrote a script that contained a username and password (say, for a desktop rollout) then I would be happy using something like a workstation-level user/password but I would not consider it safe for a domain/entire network password unless I was sure that the end-user would not have easy access to the .exe file.

The AutoIt author (Jonathan Bennett) is aware of the limitations of his protection scheme and discloses them. That’s very professional of him.

FileInstall is also an interesting feature for malware authors: it allows you to include (binary) files in the compiled script. The script itself is also stored as a file. And it’s not only the file content that is stored, but also file properties like the original filename and timestamps. When a malware is included in a compiled AutoIt script with FileInstall, most AV products will not detect it. Here’s a little test:

I took an old Warezov / Stration e-mail worm that all AV products on VirusTotal detect. Then I included this worm in a compiled AutoIt script with FileInstall, and let VirusTotal do its work. Only 4 AV products detected it, and only 2 of these (F-Secure & Kaspersky) detected it as a Warezov / Stration e-mail worm! I cannot trust the results of the other 2 AV products that detected it, because they will also identify an empty AutoIt script as malware. The 2 reliable AV products even detected the virus inside the AutoIt script when it was compiled with a passphrase and with the new fileformat (see further).

So how about decompiling passphrase protected AutoIt malware? Well, it’s easy. A compiled script contains the MD5 hash of the passphrase, and the obfuscation routine is based on the MD5 hash, not on the passphrase itself (this will work with version 3.2.5.1 and earlier compiled scripts).

Here’s my howto (there are other methods to do this):

  1. Unpack the executable (UPX –d malware.exe)
  2. Open the unpacked executable with a binary editor, and search for the magic number A3484BBE986C4AA9994C530A86D6487D
  3. This magic number will be followed by string AU3!EA05 (if you find AU3!EA06, you’re dealing with the new version that can’t be decompiled with the Exe2Aut decompiler). The MD5 hash of the passphrase is stored in the 16 bytes following this AU3!EA05 string (in fact, an AutoIt script compiled to an executable is just the AutoIt interpreter PE file with the compiled script appended at the end)
  4. Once you’ve recovered the MD5 hash, you have 2 options
  5. Try to reverse the MD5 hashing (brute-force, dictionary, rainbow tables, …) to obtain the original passphrase and use this with the decompiler
  6. If this fails, or you don’t like this option, try the following trick
  7. Start the Exe2Aut decompiler (I’m using version 3.2.4.9 on Windows XP SP2) with a debugger like OllyDbg
  8. Set a breakpoint at 0x00402064
  9. Start debugging, and decompile your file. After clicking the Convert button, the debugger will pause at the breakpoint
  10. At the address pointed to by EBX+ESI (0x0012F520 in my test), you’ll find the 16 bytes of the MD5 hash of the passphrase you entered (it will be equal to the well-known MD5 hash d41d8cd98f00b204e9800998ecf8427e if you’ve left the passphrase empty)
  11. Replace this hash with the MD5 hash you recovered from the malware
  12. Continue debugging
  13. Voilà, the Aut2Exe decompiler produced the source code of the malware

This debugger method also works if the checkbox “Allow decompilation” was unchecked when the AutoIt script was compiled. The reason is that when this flag is unchecked, the compiler will generate a long random passphrase and use this to compile the script.

Since I’ve worked out this method, a new AutoIt version was released with a new fileformat (AU3!EA06). This new obfuscation scheme doesn’t use passphrases (and hence no MD5 hash) and Jonathan Bennett doesn’t release a decompiler for this format. Of course, someday, someone will spend the time needed to reverse this scheme. And Jonathan is aware of this, he warns developers for this on the AutoIt forums.

Browsing these forums, I learned that AutoIt is also used heavily for gamebot development and that developers are urged to move to the new version to avoid decompilation. There is an interesting ecology of reversing and anti-reversing tricks, like this one. When malware developers start picking up these tricks, we will have a harder time reversing AutoIt malware.

Sunday 16 September 2007

Reversing ROL-1 Malware

Filed under: Malware,Reverse Engineering — Didier Stevens @ 7:15

Today I want to explain how I deal with a piece of malware that obfuscates its strings.

After dealing with the packing, we end up with an unpacked PE file. BinText reveals some strings, but not URLs. Searching for HTTP with XORSearch (version 1.1) doesn’t reveal any XOR encoding.

So let’s take a look with IDA Pro:

rol1-01a.png

This is interesting! The strings are somehow obfuscated. Let’s go to this .data segment:

rol1-04a.png

OK, so in this segment, all strings are obfuscated. This malware must have a routine to deobfuscate these strings before they get passed to functions like RegOpenKey…

Now let’s take a look at the code that references the start of this .data segment.

rol1-02a.png

See the LOOP and the ROR instructions? They form a very good candidate for our deobfuscation routine. The loop goes through each byte of the .data segment (0x2600 is the size of the .data segment), and performs a ROR 7 on it.

We want to decode the strings, but unfortunately, the free XVI32 binary editor doesn’t support rotate operations, only shift operations. So we will use the 010 Editor, another binary editor (not free). This editor also supports binary templates. Let’s take a look at our malware file with the PE2 binary template. We select the .data segment like this:

rol1-12a.png

And then we rotate all bytes in this segment 7 bits to the right:

rol1-08.png

Bingo:

rol1-14a.png

Let’s save this deobfuscated piece of malware and analyze it with IDA Pro:

rol1-10a.png

Now the reversing becomes more easy, because we can read the strings.

This obfuscated malware prompted me to update my XORSearch tool and to write a Python script to manipulate bits.

Saturday 8 September 2007

Disabling UserAssist Logging for Windows Vista

Filed under: Forensics,Reverse Engineering — Didier Stevens @ 20:14

For Windows XP, there is a secret trick to disable the creation of entries under the UserAssist registry keys:

under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist, create a key named Settings and under this new key create a DWORD value named NoLog with value 1. My UserAssist tool has a menu toggle (Logging disabled) to do this easily.

I call this a secret, because there is no official Microsoft documentation about this key, but of course, there are many pages on the Web about this switch.

This switch doesn’t work with Windows Vista. For Vista, you have to set the following key to 0 to disable logging:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_TrackProgs

But now, it’s not a secret anymore. Open the properties of the Start Menu:

userassist-privacy.png

The Store and display a list of recently opened programs checkbox allows you to toggle this Start_TrackProgs registry value.

Like for Windows XP, changing this switch only has effect after restarting Windows Explorer.

Monday 3 September 2007

The New Windows Vista, Now With Less Spying! ;-)

Filed under: Forensics,Reverse Engineering — Didier Stevens @ 5:56

I’m conducting research into the different types of values the UserAssist registry keys can adopt and what user actions cause a particular value to be created/updated. You know, I mean values like UEME_RUNPATH, UEME_RUNPIDL, UEME_UITOOLBAR, …

But this is for an upcoming blogpost. Today, I want to talk about something surprising I found with the UserAssist keys in Windows Vista.

When trying to understand a system, you often acquire valuable insights by comparing the system under scrutiny with slightly different systems. I’ve reported in the past that the UserAssist keys also exist on Windows Vista and that there is an extra Count key. Now, I wanted to find out which new types of values have been added to Windows Vista. I had quite a surprise looking for UEME strings in the browserui.dll of Vista (version 6.0.6000.16386). Contrary to what I expected to find, Microsoft didn’t add new types but removed many existing types. Here are the only UEME strings I found in the Vista DLL:

UEME_RUNPATH
UEME_CTLCUACount:ctor
UEME_CTLSESSION
UEME_RUNPIDL
UEME_RUN

Compare this to all the UEME strings present in the XP DLL (version 6.00.2900.3157):

UEME_CTLCUACount:ctor
UEME_CTLSESSION
UEME_DBSLEEP
UEME_DBTRACE
UEME_DBTRACEA
UEME_DBTRACEW
UEME_DONECANCEL
UEME_DONEFAIL
UEME_DONEOK
UEME_ERROR
UEME_ERRORA
UEME_ERRORW
UEME_INSTRBROWSER
UEME_RUN
UEME_RUNCPLA
UEME_RUNCPLW
UEME_RUNINVOKE
UEME_RUNOLECMD
UEME_RUNPATHA
UEME_RUNPATHW
UEME_RUNPIDL
UEME_RUNWMCMD
UEME_UIHOTKEY
UEME_UIMENU
UEME_UIQCUT
UEME_UISCUT
UEME_UITOOLBAR
UEME_USER

Why do I find this surprising? It’s not often that the functionality of a feature decreases when a new version is released, the opposite is often true. But I assume that some of the values didn’t make sense anymore in the redesigned Start Menu of Windows Vista. Hence the Microsoft programmers cleaned-up their code.

Here’s a little experiment you can try to confirm the removal of the UEME_UITOOLBAR value:

Open an Explorer window on Windows XP SP2 and click on the Search button on the Toolbar. With my UserAssist tool, you can check that an UEME_UITOOLBAR:0x1,123 entry has been added (or updated). 123 is the ID (hexadecimal) of the Search button.

Now on Windows Vista, the ability to customize the layout and buttons on the toolbars has been removed. But try the new search function anyway. No UEME_UITOOLBAR entry will be created. It’s only logical that if you cannot customize the toolbar anymore, the need to collect data about frequently used programs on that same toolbar disappears.

Another experiment you can try is starting a Control Panel Applet, like Power Options. Launch the Power Options control panel. On XP, you’ll see an UEME_RUNCPL entry referencing powercfg.cpl. While on Vista, you’ll see an UEME_RUNPATH entry referencing control.exe. So on Vista, you can still tell the user started a Control Panel Applet, but you’ve lost the ability to tell which one.

Important conclusion for forensic investigators: be aware that less data is collected in the UserAssist keys on Windows Vista than on Windows XP/2003.

Now if you still find other keys on Windows Vista than the 5 I mentioned, I’m interested in hearing from you. But first, check that you’re not dealing with a workstation that has been upgraded from XP to Vista or with a user data migration scheme. Because in such cases, these entries stem from Windows XP and not from Windows Vista.

I’m also working on a new feature for my UserAssist tool. It allows you to select an UserAssist entry and get an explanation, like this:

userassist_explain_1.png

BTW, there are many of the UEME strings I listed for Windows XP, that I’ve never seen in actual UserAssist registry keys. It wouldn’t surprise me that they serve another internal, unknown purpose.

Tuesday 28 August 2007

Analyzing a Suspect WMF File

Filed under: Malware,Reverse Engineering — Didier Stevens @ 6:48

Randy Armknecht detected a malformed WMF file and put a post up over at the Security Catalyst Community (I’m a member).

My analysis will show that this WMF file doesn’t contain shellcode. I use a tool I discovered recently, the 010 Editor, a professional hex editor with binary templates. Binary templates allow you to define the structure of a binary file with a C-like scripting language. A binary file parsed with a template is much easier to understand, as you will see. Unfortunately, I found no free alternative for this tool.

There are binary templates available for many file formats on the 010 Editor site, but none for the WMF file format. So we’ll just have to make our own.

Back from the hectic days of the WMF exploit (December 2005), I remember that the WMF file is composed of a header followed by records. There are several sources of information for the WMF file format, like this one and this one.

We copy the C struct definition of the header and put it in our template. Then we tell the 010 editor that our file is in LittleEndian format (this is the case for Intel processors) and we declare that our file starts with the WMF header.

wmz-001.png

We run our template against our file:

wmz-002a.png

Now it’s easy to see that the values for FileType, HeaderSize and Version are not correct. Looking a bit further (22 bytes to be exact), we see the correct values for these parameters.

wmz-003a.png

So let’s just assume that this WMF file has something else before the standard header, and declare that the file format is an array of 22 bytes (the unknown part), followed by the WMF header.

wmz-004a.png

Let’s switch the template display to hex:

wmz-005a.png

And now we see the correct values:

wmz-006a.png

This is a good example of the power of binary templates: you can make them on the fly, while you are trying to understand the file format.

Now let’s add the WMF records. We define the structure (copied from the fileformat document), and declare the size of the Parameters array to be the Size of the record minus 3 (remember, this is not real C, but a scripting language, and thus it is very flexible, allowing dynamic array definitions).

Now we don’t need just one record, but many records, up till the end of our file. So we instruct the editor to declare records as long as it doesn’t reach the end of the file:

wmz-007a.png

Here we can see the individual records, showing us that the file looks normal in this respect.

wmz-008a.png

Each record has a Function. To better understand our file, we will instruct the editor to display the name of the Function instead of its number. We do this by defining a function (ReadFunction) that will lookup the meaning of the Function numbers and translate them to something meaningful. This ReadFunction is linked to the Function value with the <read=> construct.

wmz-010a.png

So now we have the name of our first record:

wmz-011a.png

And we add the other functions to our template:

wmz-012a.png

Again, the file looks normal (no infamous SetAbortProc function), and it is closed with the correct record (EOF).

Let’s go back to our first 22 bytes. Further reading in the file format documents reveals that some special WMF files (called placeable WMF files) have a special header. We include this header in our template:

wmz-013a.png

wmz-014a.png

This looks much better, this is indeed a special WMF file.

wmz-015a.png

Of course, not all WMF files start with this special header. The presence of such a header is detectable by its magic byte sequence, 0x9AC6CDD7. We will make our template flexible and only declare the special header when we detect the magic byte sequence:

wmz-016a.png

The checksum field in the special header is an XOR operation performed on the 10 preceding words (20 bytes). That’s also something we can script, again by defining a <read=> function:

wmz-017a.png

wmz-018a.png

And we can confirm that the checksum is correct:

wmz-019a.png

This is how it looks when we tamper with the header (setting Reserved to 1):

wmz-020a.png

The checksum is incorrect.

By building this template as we analyze the file, we are able to ascertain that the file format is normal and that the values are normal (except NumOfObjects, which should be 7 instead of 0).

wmz-021a.png

So there is no place where shellcode can be hidden in this file.

BTW, we can add a function to check the NumOfObjects like this:

wmz-022a.png

wmz-023a.png

My template for WMF files can be downloaded here.

Now, who can tell me what is drawn by this WMF file?

Tuesday 7 August 2007

A Second SpiderMonkey Trick

Filed under: Malware,Reverse Engineering — Didier Stevens @ 8:13

My first SpiderMonkey trick is more than 6 months old, and I still haven’t released the source code. Let’s do it now, but let’s also talk about a new trick.

Obfuscated JavaScrip has become a trademark of cybercriminals, and they are ever perfecting their tools, read what Bojan and Ismael have uncovered. This reminds me of another trick I’ve been learning my SpiderMonkey: whenever the eval function is called, it will write its argument to a file, giving you the possibility to analyze the code. Eval is used in some obfuscation schemes.

When eval is called the first time, for example eval(“a=10;”), my SpiderMonkey will create a file eval.001.log containing the argument, a=10; For each new eval call in the current JavaScript session, a new eval file will be created: eval.002.log, eval.003.log, … (if you’re wondering, after eval.999.log, we just move to eval.1000.log). Unlike the document.write trick, I will not append to the existing file, but create a new file for each call.

Internally, SpiderMonkey works with Unicode strings. Hence, I programmed SpiderMonkey to create 2 files for each call, one ASCII file and one Unicode file, like this: eval.001.log and eval.001.uc.log. eval.001.log is the ASCII file (actually, it’s just the first byte of each Unicode character) and eval.001.uc.log is the Unicode file. When analyzing obfuscated JavaScript, you’ll mostly see ASCII.

spidermonkey1.png

BTW, can you guess why I added ; echo to the cat command of this demo?

Adding this king of logging feature is not difficult: just find the source code of the JavaScript function that needs logging, locate the arguments and write them to a file.

spidermonkey2.png

Download the source code here.

Tuesday 31 July 2007

F-Secure Reverse Engineering Challenge 2007

Filed under: Reverse Engineering — Didier Stevens @ 19:08

Be ready to compete in the F-Secure Reverse Engineering Challenge (http://www.khallenge.com) this Friday. I expected the challenge to start on Thursday like last year, so now I have a scheduling conflict!

It looks like the challenge is organized like last year: go to the website and download the first challenge. Start the program, and provide the correct password (this is where reversing skills come in handy). You’ll be given an e-mail address in exchange for the correct password (a wrong password yields no e-mail address).

level1.png

Send an e-mail to the address and you’ll get an URL in reply. Download the second challenge and repeat the process. And finally: download the third challenge and repeat the process.

Don’t forget my tools to help you with this challenge:
Challenger
OllyStepNSearch

Now honestly, I don’t expect Challenger to be of any help, except with a dictionary attack on the first challenge. Last year, the passwords for the second and third challenge were so long that brute-forcing was no option.

Think it’s too difficult for you? Think again, this movie (YouTube) shows how easy the first level of last year’s challenge was, XviD hires here.

YACoSTO, One Year Ago

Filed under: Reverse Engineering — Didier Stevens @ 6:04

One year ago, to the day, I posted YACoSTO. I explained how I reversed a program that “protects” data. This is one of my favorite posts, but it hardly gets any hits. I encourage you to read it, because this time, I focus on reversing the protected data rather than the program itself. You might learn a couple of new and simple techniques.

The binary tools I used for the YACoSTO post can be found here, I published them afterwards.

Contrary to what some of you might think, this is not a “I’m on holiday” post 😦 . We took a short cruise in June. My sister-in-law, a professional wedding film producer, shot this movie (YouTube) during our holiday, hires version here. Absolutely no malware, hacking, revering, … in the movie, just holidaying.

Oh, and BTW, until now, nobody ever asked me what YACoSTO means…

« Previous PageNext Page »

Blog at WordPress.com.