Ramen Software

Multiline Ultimate Assembler v2.3 is out.

x64_dbg support

Starting from version 2.3, the Multiline Ultimate Assembler plugin supports the x64_dbg debugger in addition to OllyDbg and Immunity Debugger.

x64_dbg is a relatively new project, and thus not all features could be implemented for it. For example, the option to disassemble external code is not available, as the debugger doesn’t expose this information.

Despite of the limitations, x64_dbg evolves quickly, and is already usable for many tasks. It can be extremely useful for 64-bit targets, as the more mature OllyDbg can only handle 32-bit executables at the moment.

Multiline comments

It’s possible to use the COMMENT directive to define a comment which consists of multiple lines, using the MASM syntax:

COMMENT delimiter [[text]]
[[text]]
[[text]] delimiter [[text]]

Other changes

In addition to the above, v2.3 adds drag and drop support to the editor, and fixes a couple of minor bugs.

P.S. The text editor component, RAEdit, was originally written in 32-bit x86 assembly. If you’re wondering how it was ported to 64-bit, refer to the post C as a portable assembly: porting RAEdit to 64-bit.

In the Multiline Ultimate Assembler plugin for OllyDbg, I use an editor component called RAEdit, written by KetilO in 32-bit x86 assembly. It’s a great component, lightweight and simple to use.

Recently, I’ve been working on a port of Multiline Ultimate Assembler for the x64_dbg debugger. After porting the 32-bit version of the plugin, I realized that there’s a problem porting it to 64-bit: the RAEdit component is written in 32-bit x86 assembly. While it’s somewhat similar to 64-bit x86 assembly, there’s no way to automatically port an assembly codebase from 32-bit to 64-bit. I had a couple of options:

• Finding an alternative editor component.
• Using a hack, e.g. running the editor window as a separate 32-bit process.
• Porting RAEdit to 64-bit.

I looked for an alternative, but didn’t find a decent one. Also, I didn’t like the second option, so I’ve decided to port RAEdit. But how do I port an assembly codebase from 32-bit to 64-bit? I’m not familiar with MASM syntax, which the codebase uses. Perhaps it was possible to port the codebase to 64-bit MASM using macros and such. But I came up with a more creative idea: to port it to C first! After all, C is considered by some as a portable assembly.

The code uses MASM macros such as .if/.while extensively, which can be easily translated to C. Most assembly commands can be translated to C as well. I had to manually change some of the exotic stuff (such as usage of the CARRY flag), but most of the code was ready for automatic translation.

Then, I wrote a script which uses regular expression search/replace to translate every line of assembly to C. The initial result can be seen here. After some tweaking, I could get the code to compile. Due to the fact that there’s no type correctness in assembly, GCC displayed more than 1,000 warnings, most of which complain about incompatibility of types. I was actually surprised that it was able to compile.

Obviously, the code didn’t work right away. I had to fix a couple of things manually, but after some tweaking, it actually worked! And after some more tweaks for 64-bit portability (mainly adjusting pointer vs integer types and pointer size constants), the compiled 64-bit library worked as well!

It’s interesting to compare manually written assembly code with code generated by a compiler. Mostly, the original code is slimmer and looks more optimized. For example, assembly vs C of the SkipSpace function (clickable):

So there we have it, originally written in 32-bit x86 assembly, the library can now be (theoretically) compiled on every platform. It would be interesting to check whether it works on ARM/Windows RT, too. The main repository of the C port can be found here: https://github.com/m417z/RAEditC

7+ Taskbar Tweaker v4.5, the stable version that is compatible with Windows 8.1 Update 1, is finally out!

Two months ago, I’ve created a blog post describing why adding support for the new Windows update is not trivial, and provided a way for you, the users, to support the porting effort with donations. I was pleasantly surprised by the quick completion of the goal. I want to thank everybody who supported the porting effort: Charles George, Justin Shillock (Platypus Man), and other contributors.

In addition to the support of Windows 8.1 Update 1, 7+ Taskbar Tweaker v4.5 fixes a couple of minor bugs comparing to v4.4.6. One issue that is still left unsolved is the lack of proper support for Metro taskbar items. Windows 8.1 Update 1 has a separate handling logic for Metro tasks, so it will require some effort. I plan to get this fixed in one of the future versions.

You can get 7+ Taskbar Tweaker v4.5 here.

An update for Windows 8.1, called Update 1 or the Spring Update, was officially released by Microsoft a couple of days ago. This update broke compatibility with 7+ Taskbar Tweaker. I’ve published a post, 7+ Taskbar Tweaker and Windows 8.1 Update 1, explaining the reasons for the breakage.

Today, I’m happy to announce that the first pre-release alpha version is available for testing! If you have donated for the effort, you can get the link here (May 10: link removed).

Currently, only the 32-bit version is available. I hope to get the 64-bit version done within the following week. Stay tuned!

Update (April 17): The 64-bit version is available as well! Please try it, and report any issues you stumble upon.

Update (April 26): A new version is available, which fixes a couple of issues. Also, this is the first alpha version which can be installed, unlike previous alpha version which were available as portable versions only.

Update (May 2): A public beta version is available here.

Update (May 10): 7+ Taskbar Tweaker v4.5, a stable version with Windows 8.1 Update 1 support, was released.

Multiline Ultimate Assembler v2.2 is out.
What’s new:

Added the ability to specify block end address

You can now specify the end address of a block, which the code shouldn’t exceed.
Read More…

As some of you know, Microsoft is working on an update for Windows 8.1, called “Update 1”. Also, some of you might know that 7+ Taskbar Tweaker doesn’t work with this update installed. There’s a topic on UserEcho about it, and users are wondering how come I don’t fix the issue. In this post, I’d like to shed some light on the situation.

Why doesn’t the tweaker work with the update installed?

It’s just an update, right? Not a new Windows version. The taskbar looks the same. How come that the tweaker is not working anymore?
Well, the thing is that the tweaker depends on the exact structure of many internal elements of explorer. Any small change can make the tweaker break, and the fact that it doesn’t can be attributed to the great care of Microsoft for backwards compatibility. At least, that’s the way it was until “Update 1”.

Since Windows 7, the earliest OS supported by the tweaker, Microsoft didn’t introduce major changes to the OS while the NT version number stayed the same. Even with Windows 7 SP1, the tweaker worked without adjustments. With Windows 8.1 Update 1, the situation is different: the OS has changed, but its version stayed the same.

What does it mean in the short term?

In order to add support for Windows 8.1 Update 1, lots of adjustments have to be made, similar to the adjustments I had to make when adding support for Windows 8 and Windows 8.1.
While I’d be glad to add support right away, there are a couple of things to consider:

• Availability of the final RTM version of Windows 8.1 Update 1. To be able to add support for the OS, I need to be able to work with it. They say that there’s a leaked build of the RTM version, but recent news mention a newer version, which means that the leaked one is probably not RTM. Google for Windows 8.1 9600.17042.
• Availability of debug symbols. While they’re not a must, they significantly simplify the porting process. As far as I know, there are no debug symbols available for the binaries of Windows 8.1 Update 1 yet.
• Time. Porting requires time, and there’s not always plenty of it.

What does it mean in the long term?

The fact that Windows 8.1 Update 1 is the first time when the OS changes, but the OS version doesn’t, means that Microsoft is changing its tactics. It seems like Microsoft tries to move to a more rapid development cycle. The question is – how rapid is it going to be? If the updates are going to be too frequent, I might not be able to keep the tweaker updated.

How can I help?

Unless you work at Microsoft, you probably can’t help me with the first two points mentioned above. But you can help me with the third one.
You can donate the project to help me dedicate time for the porting.
Include the w8u1p (Windows 8.1 Update 1 Porting) word in the donation comments to specify that your donation is targeted for the porting.

Below is a progress bar of the donations, with the goal set as the estimated time the porting is going to take, with an average wage.

$1204 out of $1000

All donors will get access to early alpha versions during the porting process.
Also, the top three donors will get mentioned in the changelog.
If the goal is hit before the RTM is released or before the debug symbols become available, I’ll start working with what we have.

Thanks in advance for your help!

Update (April 14): The goal was reached! I want to thank everybody who took part and donated for the porting. The first alpha version is available for testing (more details).

Starting from today, I’m going to publish beta versions of 7+ Taskbar Tweaker along with the regular, stable releases.

There are several rationals for this decision:

• Avoiding bugs in stable releases. This is usually the main purpose of beta versions.
  Two of the tweaker’s most recent releases were followed by a hotfix the day after, just because I missed a minor thing or two. This is also quite relevant to the next point.

• Minimizing the frequency of update notifications. The tweaker automatically notifies when a new version is available. While this is a great feature, it can be annoying if the notification appears frequently, especially if it appears two days in a row.
  Silent updates were suggested as an alternative solution, but first, they have to be implemented. Second, I’m not sure that 7+ Taskbar Tweaker is the right tool for this feature. It’s a low-level system tool, and it can screw things up, so if something goes wrong you can see it was caused by an update. Silent updates are available (off by default) starting with v4.5.10.

• Providing fixes which affect a very limited amount of users. There are issues which affect only users with a particular setup, a unique combination of options, etc. In such cases, it’s important to provide them with a fix, but it’s not a good idea to push this update to most of the other users, especially if the latest version was just recently released (see previous point).

• (Added in 2018) Providing limited support for Windows 10 insider builds. See the following blog post: 7+ Taskbar Tweaker and Windows 10 insider builds.

Read More…

Version 0.2 of Unchecky was just released!

The main and most visible change is the new interface of the main Unchecky program.

Read More…

About two weeks ago I introduced the Unchecky program. In this period of time, Unchecky was translated to 8 languages, the Unchecky website was translated to 3 languages, Unchecky was reviewed by numerous well-known websites, and I’ve received lots of positive feedback.

But Unchecky has one important limitation, which was raised right after Unchecky was released – It can’t handle the web. While most programs present their offers in the installation process, some are showing a checkbox in the browser, before downloading. And obviously, this checkbox is checked by default.
Read More…

Nowadays it’s a reality that many software installations are bundled with potentially unwanted programs, such as toolbars or scareware system cleaners. If you’re a power user, you probably know that you have to be very careful while installing software, because if you miss a checkbox you might spend hours afterwards cleaning up the mess. If you’re an average PC user, you possibly leave everything by default, thus installing lots of additional unwanted programs without even knowing it.

I always thought that it’s wrong to provide these potentially unwanted programs by default, but the reason for this is clear: the more users install these, the more money the setup owner makes, usually at the expense of your privacy. Well, it doesn’t have to be that way anymore, thanks to Unchecky!

Read More…