Unfortunately, we cannot fix issues that we are not aware of, and it seems we’ve had no such reports until now. Would it be possible for you to create a ticket on support.hex-rays.com and attach the problematic files?

Tried to disassemble about 10 different WASM files. All them failed with different errors:

For example: local type 1 in function 536 is invalid.
Quite surprising for paid app, taking into account that free ghidra and wabt didn’t have issues disassembling those files…

Why IDA advertises WASM support since version 8 then ?

1. the guide could mention vcredist?

2. the installer could detect missing vcredist?

edit: i often prepare a VM for analysis so it is not often likely that this vcredist will be installed ahead of time

Installing the latest MSVC redistributable should fix this issue.

Attempting to start IDA after install, I get error dialog “The application was unable to start correctly (0xc0000142). Click OK to close the application.” I don’t see any extra information in Windows Event Log.

I don’t see any dependencies listed at the guide linked above so I’m not sure what I’m missing.

When doing so now, it creates a structure overlay but doesn’t populate the function offsets, so it’s not assigning the function address to the indirect call.

Is there a better way to do this in 9.3? Am I missing something here?

Since such jump tables are used in the Microsoft compiler, perhaps it would be worthwhile to detect and handle them correctly?

The reason IDA trims the table to 4 entries is because such null entries are not valid:

1405165B0               dd 0
1405165B4               dd 0

IDA allows you to fix it.

First, make sure all table entries have the appropriate type.

Second, identify the branching instruction, in this case the jmp at 0x140515C71.Having your cursor on this address, Edit → Other → Specify Switch Idiom…

In the decompiled switch statement, these null entries will be marked with a red JUMPOUT statement.

If you want to read more on this topic, Igor’s post is worth a quick look.

Let’s look at the sample

A jump table at address 0x1405165A0 contains these entries:

1405165A0 jpt_140515C71 dd offset loc_140515C77 - 140000000h
1405165A4               dd offset loc_140515D02 - 140000000h ; jump table for switch statement
1405165A8               dd offset loc_140515D02 - 140000000h
1405165AC               dd offset loc_140515D02 - 140000000h
1405165B0               dd 0
1405165B4               dd 0
1405165B8               dd offset loc_140515D02 - 140000000h ; jumptable 0000000140515C71 cases 3-5
1405165BC               dd offset loc_140515D4E - 140000000h
1405165C0               dd offset loc_140515D84 - 140000000h
1405165C4               dd offset loc_140515D02 - 140000000h ; jumptable 0000000140515C71 cases 3-5
1405165C8               dd offset loc_140515D27 - 140000000h
1405165CC               dd offset loc_140515D02 - 140000000h ; jumptable 0000000140515C71 cases 3-5
1405165D0               dd offset loc_140515D02 - 140000000h ; jumptable 0000000140515C71 cases 3-5
1405165D4               dd offset loc_140515CB2 - 140000000h

A jump code:

140515C59 ; __try { // __except at loc_140516520 ; switch 4 cases
140515C59               lea     eax, [rsi-2]
140515C5C               cmp     eax, 13
140515C5F               ja      def_140515C71   ; jumptable 0000000140515C71 default case
140515C65               cdqe
140515C67               mov     ecx, ds:(jpt_140515C71 - 140000000h)[rdx+rax*4]
140515C6E               add     rcx, rdx
140515C71               jmp     rcx             ; switch jump

A microcode explorer shows that only 4 cases are used (0, 1, 2, 3) + default case:

; ????-BLOCK 14 PROP [START=140515C65 END=140515C73] STK=0/ARG=1D0, MAXBSP: 0
14. 0 mov    rax.8, kr10_8.8                      ; 140515C65
14. 1 xds    eax.4, rax.8                         ; 140515C65
14. 2 jtbl   kr08_8.8, {0 => 15, 1,2,3 => 22, def => 136} ; 140515C71

So, cases 6-13 are missed.

So the bug is minor and it was just a strange error message that also created an unwanted file that I wanted to report. You can use None or empty string as the signal to “use the normal IDB path”, it doesn’t really matter.

Reports are always welcome, there’s no such thing as “necro-ing” the thread here.

The first parameter of save_database() is outfile, which can represent the name of the new database file, or the current database in case outfile is None (or nullptr in C++). Passing an empty string fails because "” will be interpreted as a file name.

We could catch that earlier and show a better error explanation. Would that work for you as the expected outcome, or do you have a particular reason for passing an empty string?

If calling it with an empty string

ida_loader.save_database("")

I get the following unreadable popup:

And if I click the X in the top right corner the function returns True and I get the log line:

Leaving database unpacked and packed copy in .$$$ and there is a file created named .$$$ in the working dir.

Hello,

I recently saw in the Hex-Rays newsletter that swag is available at offline events. I’m from South Korea, and unfortunately the total cost of airfare, conference tickets, and accommodation would be about twice the average monthly salary here, which makes it very difficult for me to attend in person.

I would still love to get some Hex-Rays swag or merchandise. If possible, have you considered opening an online store? I’m not exactly sure what kinds of items are usually included as swag, but I think things like T-shirts, mugs, or stickers would be really great. I’m sure many international users who can’t attend events would appreciate the opportunity as well.

Thank you for your amazing work and for supporting the community!

sample function sub_287DC

Generally, on V850 gp is used as a global register. If this is not the case, enable the corresponding setting in the processor-specific options.

If it’s still not working as expected, please create a ticket on support.hex-ray.com and add a sample.

Thank you for the update. We found some possibly problematic situations we’re investigating. We have a few questions:

• which device are you using?
• does single stepping work for you otherwise?
• what specific scenario leads to the crash for you? It seems to happen for us on second attach attempt only (first time is OK).

The plugin implements constant folding and instruction combining passes for these intrinsics. I think IDA team did the same thing.

ida_kernwin.process_ui_action('LuminaPullAllMds')

to pull names from Lumina and

ida_kernwin.process_ui_action('LuminaPushAllMds')

to push info to Lumina

Just a thought: I’m not sure how this is implemented internally, but I ran into something similar when developing a plugin with Qt. I needed to trigger a second action after a UI element became visible. I solved it using a QTimer::singleShot with a short delay. The sequence was:

Click button → open UI element + start single-shot timer → when the timer ran out, run the second action (e.g., jump to member).

If the delay was too short, the UI element would appear, but the second action wouldn’t do anything because the window wasn’t fully ready when the timer ran out. Since my computer is kinda slow, it takes a bit more time for the UI to become ready — longer than the timer delay.

Since @bes mentioned this only happens when the IDB has a lot of types (although for me it happens in every IDB - slower machine), it makes me think this could be said timing issue — the second action (jump to member) might run before the Local Types window is completely ready.

EDIT:
My understanding could be wrong, but the call to callui(ui_open_builtin2, BWN_TITREE, ordinal, &cursor) eventually reaches another function that checks !strcmp(..., "Local Types") and calls get_module_data(...) . That function determines whether the Local Types window already exists, sets an out-parameter flag accordingly and creates the window if neccesary. However, when the window doesn’t exist, the flag is set to 1 early and never updated after the window is successfully created. The caller then sees the flag as 1 and skips the jump to member logic entirely. Ignoring the flag altogether in caller function solves the issue. Hope that helps.

There is no specific API because all that the action does is to change the function’s color to the one configured in the decompiler options. To get it you can use, for example, idc.get_func_attr(funcea, idc.FUNCATTR_COLOR).

Does anybody know how to get it? Thanks!

import ida_funcs
import ida_lumina

pfn = ida_funcs.get_func(0x401000)

# calc_func_metadata returns (size, md5_hash)
fi = ida_lumina.func_info_t()
size, md5 = ida_lumina.calc_func_metadata(fi, pfn)
score = ida_lumina.score_metadata(fi)
print(f"{fi.name}: {fi.size} bytes, score={score}")

Pressing shortcut ‘z’ on structure field in pseudocode often (not always) jumps to wrong position of “Local Types”. If switch back to pseudocode, and try ‘z’ again - jump to correct position.
Cannot share IDB, sorry.

What is the (simplest) way in the Hex-Rays decompiler to “merge” 2 separate 32-bits register-based local variables into a single 64bits one. Example:

int v37; // r5
int v38; // r9
...
v37 = array[0];
v38 = array[1];
...
function(__SPAIR64__(v38, v37))

How do I create a single __int64 variable whose location is r9:r5 ?

Thanks for your insights!

AFAIK our debug server is signed with proper entitlements, so normally it should work when debugging normal apps. The only known issue I’m aware of is debugging Apple or hardened runtime binaries which requires turning off SIP.
Can we have a confirmation of this issue from another macOS user?