iOS applications are protected by a Apple's DRM system. That system encrypts certain segment(s) of the application. The keys to that encryption are, as far as I know, unique per device or per device platform. I haven't spent much to with FairPlay so I don't know what the encryption keys are but I suspect it's either the GID key or the UID key. I would ...
This depends on the compiler originally used as each creates slightly different layouts. You can find tutorials for most compilers on the net, I'm going to focus MSVC as that's the one I have experience with, and since it provides a hidden compiler switch printing how classes will be layouted in memory which I'm going to use for illustration.
As you might ...
I found the solution. Double click the variable name (configSpaceBuffer in this case) which brings up the stack window for the method where you can undefine the invalid variables and then define it as an array.
Here is the output after this change:
_this->ConfigSpace1 = configSpaceBuffer;
_this->ConfigSpace0 = configSpaceBuffer;
Go to the menu Edit -> Plugins -> Hex-Rays Decompiler. A window will appear with information about the Hex-Rays plugin. Click Options and you should see a dialog like this:
Click on Analysis options and uncheck Print only constant string literals:
I learned about this option from the great Life In Hex blog, but I cannot find the post right now...
The numbers denote the basic block number in the microcode where the variable was first used. Microcode basic blocks do not necessarily match the basics block in the disassembly, because during optimization steps the microcode basic blocks may be split, merged, added, or removed.
You can see some samples of microcode in Ilfak's whitepaper on the decompiler ...
Hex-Rays Decompiler is an addition\extension for IDA Pro and I doubt it can work as a separate standalone product.
Please see "Prerequisites" part of Hex-Rays Decompiler Manual:
"The decompiler requires the latest version of IDA..."
But this question, IMO, should be addressed to the Hex-...
COERCE_TYPE(x) is the same thing as *(TYPE *)&x. Hex-Rays uses COERCE_... macros when &x is illegal. For example:
Is the same as *(double *)&__PAIR__(i1, i2), but since & can not be applied to calls, we end up seeing COERCE.
Its name correctly conveys its meaning.
IDA's til files are basically IDA's way of storing type information for particular functions. AFAIK, a .til file doesn't tell IDA how to actually recognize that function in order to apply function prototype information. For that piece you're going to need produce the requisite .sig file using IDA's Flirt utilities.
By default, IDA won't replace existing ...
test is basically an and instruction except it doesn't update the left operand.
In the other hand, cmp is the equivalent of sub instruction except it doesn't update the left operand.
To sum up:
if (v & n)
Is compiled as test instruction.
if (v == n)
Is compiled as cmp instruction (or test reg, reg is n is 0x0)
v = a & n
Is compiled as and ...
Yes. The newer versions of IDA has official bindings for the Hex-Rays decompiler.
Originally, the Python bindings were written by EiNSTeiN around the Hex-Rays Decompiler SDK API. Later it has been merged into IDAPython.
You can find the documentation under "ida_hexrays" in the IDAPython docs.
Examples can be found in IDAPython repository. Check the scripts ...
The issue here is not strings, it's the fact that Hex-Rays didn't guess the right calling convention for sub_4022E0. Notice that the disassembly listing moves values into both ecx and edx before the call, whereas the decompilation for that call shows only one argument? Hex-Rays thinks there's only one argument -- maybe even only one stack argument -- whereas ...
Your hook is wrong because retn 4 is for __stdcalls, not __usercalls, and because you must move arguments to registers, not push them. Do it like this:
mov esi, a1
mov ecx, a2
retn 4 would clean 4 bytes from the stack, but you didn't push anything, so it's not correct, which is why you use ret instead.
As you guessed correctly, you have to find out the correct starting address of the bootloader image. Based on the bootloader in the latest firmware image (TL-WR702N_V1_141203) I recommend you to try 0x80400000 as the start address.
Although I don't know a simple and exact method to calculate the start address I try to explain a little bit more how can you ...
I think it should look like this I am 99.9% feel it's a element shifter something tells me that 0x3FFFFFFF is max bounds of a array so it's some compiler thing that it appends to make sure it gets the end of the array.
I was wrong 0x3FFFFFFF is used to create signed numbers to emulate subtracting by adding. See comment by DCoder
if ( ZonePlayerCount > ...
__PAIR__() seems to be a macro that computes an unsigned long value from its two arguments, which it interprets as containing the high and low bits of that value.
The topic linked by Guntram - Understanding __PAIR__ macro from IDA PRO Pseudo Decompiler to look better contains a definition for the macro and examples of its use, but no explanation of it.
First, OP mentioned several times he'd like to execute the function. Which should be pretty easy using a debugger (IDA has decent debugging capabilities, or you could give ollydbg a try)
I'll answer the questions in the order in which they appear:
what is __usercall and diamond-wrapped registers in a function's definition?
__usercall is a "virtual ...
No, IDA version 6.95 doesn't support it. See hex-rays.com/products/decompiler for more details.
Regarding other news and features see decompiler news page.
The original answer was written ~2017, and since then IDA added MIPS decompiler support. AFAIK it was added in version 7.5.2.
See here for comparison between decompilation and ...
In the Loaded Type Libraries window (View->Open subviews->Type libraries), load ntddk_win10 (or whatever Windows version you want, back to Windows XP and Windows Server 2003).
In the Structures window (View->Open subviews->Structures), import KUSER_SHARED_DATA. You can simply write the name of the type in the dialog box and ...
As I'm working with the malware samples provided by kaggle too, I faced the same problem. I found a solution by the processing in two steps, which extracts all the mnemonics used in the complete set.
Note: As I'm not finished with my work yet, I'm not able to post the full script. The real implementation is realized with threading and the process takes ...
When loading plugins, IDA goes through them alphabetically, and tries to load all the plugins.
When loading a plugin, the loader check the plugin flags (idaapi.PLUGIN_PROC, idaapi.PLUGIN_FIX, and so on) to determine if the plugin should be loaded at the current time.
If it is to be loaded, the init method is called. A plugin can return PLUGIN_KEEP to remain ...
Go to File and select Script file and choose a .idc name for your file, which makes the changes permanent.
Then when you will run the .idc file, you will notice that bytes have been written to those segments successfully.
After that, IDA will ask for saving the new binary file.
I don't think there's a way to add a new function variable, since the decompiler creates those based on registers and stack locations.
However, in situations where it's really annoying, creating a union type in the Structure viewer can be helpful.
Then, in your decompiler, set the type of the variable to the union type (Y is the keyboard shortcut).
In IDA, you can define enums through the Enums view (shift+F10). Enums have the "bitfield" bit set (a checkbox by the same name can be found in the Enum edit and create dialogs). This bit cannot be set for enums with overlapping member bits.
Once an enum is a bitfield enum, setting any operand in the disassembly view to that enum will display all enum ...
BYTE1(v2) is the second byte of value v2. according to the reference it's Zero-Indexed. defined as:
#define BYTEn(x, n) (*((_BYTE*)&(x)+n))
#define BYTE1(x) BYTEn(x, 1) // byte 1 (counting from 0)
for example BYTE1(0x1213141516) is 0x15. (according to Little Endian Byte Order)
HIBYTE(v2) is the higher byte of value v2. defined as:
IDA does support structure member cross-references: it will show you everywhere in the disassembly listing that an instruction operand has had that particular structure reference applied to it. See this picture:
However, this only works if the structure has been applied on the assembly-language level. Generally speaking, changing the type of a variable in ...
Here are the required steps using Igor Skochinsky's answer:
Clone musl git repository:
git clone --depth=1 git://git.musl-libc.org/musl
Compile the code:
cd musl; ./configure; make -s -j2
Extract Flair tool from IDA SDK. Run pelf (ELF parser) with the musl static
library which is compiled in above step: