Bypassing basic Reverse Engineering protections in a skimmer

A lot of skimmers have different levels of obfuscation and code protection built in to hide their actions and protect what they are actually doing. Here’s an example of one with some basic protections.

First, the prettified code. On line 3 there is an anonymous function b which does string deobfuscation. It goes beyond the basic XOR that we’ve seen elsewhere. It is used to decode the items in the c array on Line 37, and the actual digital skimmer code which is loaded on line 49.

Line 36 is a simple check to see if you have your browser’s devtools open and attached to the side of the window.

  if (window['outerWidth'] - window['innerWidth'] > 0xa0 || window['outerHeight'] - window['innerHeight'] > 0xa0) return;

In hex, 0xa0 is equivalent to 160, so the above is just checking to see if the inner width or height is significantly smaller than the outer width or height. If it passes that check it continues onto Line 39 – 47. It loops through the c array, looking to see if the URL path contains any of the deobfuscated values. The values indicate that the skimmer isn’t just looking to capture payment data, but user creds as well:

Assuming one of those values was found, a new script tag is created and appended to the page. Disabling the devtools and URL path check just requires commenting out lines 36-47. Stop the script from being loaded by commenting out Line 50. In this final version, I commented those lines out and dropped a debugger on Line 52, so you can poke around:

Interestingly, the digital skimmer loader is kind of a two-parter. window['user_tracker'] is set to “frontend”, and I believe that value is used elsewhere in the skimmer after it’s loaded.

A modified version of this was originally posted on Twitter:

This entry was posted in Infosec, Magecart and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *