I was just wondering what the difference between the virtual these keyboard commands is:
KEYEVENTF_EXTENDEDKEY and KEYEVENTF_KEYUP is.
Everywhere I have looked it just gives me a description based off integers and what not but I just want to know simply what each of them does.
You've tagged the question VB.NET, but these actually have nothing at all to do with VB.NET. They're constants defined in the Windows header files, for use with Win32 API functions.
As far as the difference, you can't tell much by looking at their values. The individual values are not particularly important, that's why the named identifiers are used. What's important is where they are used and what the documentation for those functions tells you that they mean.
The first one, KEYEVENTF_EXTENDEDKEY, is used with the KEYBDINPUT structure (which is used along with e.g. the SendInput function) to pass information about synthesized keyboard input. If this flag is used, it means that the scan code should be interpreted as an extended key. Technically, this means that the scan code is preceded by a prefix byte with the value 224 (&HE0 in hexadecimal notation).
The second one, KEYEVENTF_KEYUP, is another one of the flags available for use with this structure. It means that the key is being released (going up), rather than pressed (going down).
There is a general overview of keyboard input available here on MSDN. It explains in more detail what a virtual key code is, what an extended key is, etc.
Related
I've been working on a project that analyzes EVM-assembly of Solidity smart contracts. Currently I am stuck with the problem of finding the endings of all the contract functions in the assembly. There is a bruteforce approach with simulating the EVM and simply tracking at what line the execution reaches the finish, but producing a complete EVM simulator is, I am afraid, well beyond my capabilities. I am searching for a simpler solution if there is one.
So far I've managed to (almost) consistenly find beginnings of the functions (corresponding JUMPDESTs) in the assembly assuming that I have access to the contract's ABI. The idea there is quite simple. At the top of the EVM assembly file there are multiple blocks looking as such:
PUSH4 0x8ac28d5a
GT
PUSH2 0x191
JUMPI
DUP1
and also as such:
PUSH4 0xfeaf968c
EQ
PUSH2 0xc82
JUMPI
PUSH2 0x2f4
JUMP
JUMPDEST
DUP1
Let's call them "header blocks" (if there is an official name, I am sorry for my illeteracy :) ). Each header block compares the hash of the method signature that came in the calldata and decides whether to jump on the JUMPDEST that corresponds to the beginning of the desired function. But there is a catch. As you can see, there is a GT at the top of the first header block. Why would we compare hashes with less/greater? So the header blocks do not perform a linear search over all the signatures. Instead, they do some kind of a logarithmic search as I deduced (please correct me if I am wrong). And, as we can see in the second header block, in some cases they can decide to unconditionally proceed somewhere else seemingly in the middle of the search process. But in reality, they just have enough information at that moment to infer that there is no function in this assembly that has the required hash of the signature. So we can deduce that those "else" JUMPs jump right to the fallback.
So this is the context of what I have done so far. I am able to obtain the list of the beginnings of all the functions including the fallback. Obtaining the list of the ends of the functions is what I am currently struggling with. So far I've had a hypothesis that I can split the whole assembly file by JUMPDESTs of the beginnings of functions (and the dispatch part with header blocks) and each part except the first will correspond to each Solidity function. Unfortunately, it can be easily disproven by looking at what is the assembly of a basic contract with only a couple of functions. You can experiment yourself at godbolt.org (a little example here). There will be a number of auxiliary "functions" created by the Solidity compiler. So my approach is not viable here. Are there any approaches of finding the endings of the functions without simulating the EVM?
I am using a Keygen application (.exe). There are two input fields in it's GUI:
p1 - at least 1 digit, 10 digits max - ^[0-9]{1,10}$
p2 - 12 chars max - uppercase letters/digits/underscores - ^[A-Z0-9_]{0,12}$
Pressing generate button produce a key x.
x - 20 digits exactly - ^[0-9]{20}$
For each pair (p1,p2), there is only one x (in other words: f(p1,p2) = x is a function)
I am interested in it's encryption algorithm.
Is there any way of reverse engineering the algorithm?
I thought of two ways:
decompiling. I used snowman, but the output is too polluted. The decompiled code probably contains non-relevant parts, such as the GUI.
analyzing of input and output. I wonder if there any option to determine the used encryption algorithm by analyzing a set of f(p1,p2) = x results.
As you mentioned, using snowman or some other decompiling tools is probably the way to go.
I doubt you would be able to determine the algorithm just by looking at the input output combinations, since it is possible to write any kind of arbitrary algorithm, that can behave in any way.
Perhaps you could just ask the author what algorithm they're using ?
Unless it's something really simple, I'd rule out your option 2 of trying to figure it out by looking at input and output pairs.
For decompiling / reverse engineering a static binary, you should first determine whether it's a .NET application or something else. If it's written in .NET you can try this for decompilation:
https://www.jetbrains.com/decompiler/
It's really easy to use, unless the binary has been obfuscated.
If the application is not a .NET application, you can try Ghidra and/or Cutter which both has pretty impressive decompilers built in:
https://ghidra-sre.org/
https://cutter.re/
If static code analysis is not enough, you can add a debugger to it. Ghidra and x64dbg work really well together, and can be synced via a plugin installed in both.
If you're new to this, I can recommend both that you look into basic assembler for the x86 platform so you have a general idea of how the CPU works. Another way to get started is "crackme" style challenges from CTF competitions. Often there great write-ups with the solution, so you have both the question and answer available.
Good luck!
Type in p1 and p2. Scan the process for that byte string. Then put a hardware breakpoint for memory access on it. Generate the key, it will hit that hardware breakpoint. Then you have the address which accesses it and start reversing from there in Ghidra(Don't forget to use BASE + OFFSET) since ghidra's output won't have the same base as the running application. The relevant code HAS to access the inputs. So you know where the algorithm is. Since it either directly accesses it, or somewhere within that call chain is accessed relatively fast. Nobody can know without actually seeing the executable.
I am trying to make a dyld extractor similar to dyld_decache and dsc_extractor. But I am having trouble parsing the __objc_selrefs section.
For testing purposes I used libsystem_trace.dylib, and was able to find and parse its mach_header and its segments and sections. But looking at the __DATA.__objc_selrefs section I find pointers like 0x201b8647fc8 and 0x201b860d716, which are way too high and point outside the cache.
In contrast, in a normal Macho file, the pointers in the __objc_selrefs section point to their corresponding string in the __TEXT.__objc_methname section.
I know that dyld slides and rebases sections, but after a lot of tinkering, I still could not fix the pointers. Any guidance would be amazing, especially given how little resources there is out there.
These "addresses" don't just point outside the cache, they point outside the maximum range iOS allocates for the userland address space.
The thing is that these aren't raw addresses, they're addresses with some flags mixed into them. I've seen at least 0x20000000000 and 0x40000000000, and they seem to be exclusive to Objective-C code. I have no idea what they mean or what the true bitmask for these flags is, but so far keeping the lower 40 bits (0xffffffffff) of the addresses has done the job for me.
That would turn e.g. your 0x201b8647fc8 value into 0x1b8647fc8, which should be well inside the shared cache boundaries.
I often heard Snippet Expansion by an IDE, but I searched and couldn't figure out that it means. Could you explain what it is?
Snippet expansion allows you to type short sequences of characters, hit another key, and have it expanded out into a larger amount of code. This is useful for quickly writing common chunks of code.
The above image shows me writing a simple C++ program with the use of snippet expansion. I include the header, I just write inc and hit tab. To write the main function, I write main and hit tab. Similarly for the for loop and cout expression.
It means typing in a sequence of characters, e.g. "if()", pressing a keystroke, and having the IDE look up in a database for the replacement, e.g. "if(|) {\n}", and putting it in the editor in place of the sequence.
It is the feature of some ide's to expand on a certain sequence of keys which is useful to type something faster on not type it at all. Like when you start typing for and it expands to a for loop.
Personally, I use vim, and snipMate.vim enables just that. The example video is here.
My VB.NET application has a very important boolean variable. I need to be able to save it "somewhere" and read it back in the future (even if the application is closed).
Currently, I store the variable as a .bin file somewhere. But I fear that the user can simply grab the file and do some magic to edit the value.
I need to make this value completely unavailable from the user's eyes. Or at least, make it impossible to edit. What is the best way to hide such value?
I managed to store the variable in my online MySQL database. But honestly, that doesn't work very well for my purposes. I need to store it locally...
Any ideas?
Theoretically, you can never hide this variable at all. However, you can make it harder to find or read. To know how to hide the variable, you must first know some common ways of retrieving it.
Typical problems and solutions
How others could theoretically retrieve your variable value
Decompiling your program with a single click using .NET Reflector or any other .NET Decompilation program.
Analyze the memory of the PC while the program is running, and retrieve the value from there.
If your value was saved in a file, the user could easily find it by analyzing harddrive IO activity through a hook or a dump comparison.
If your value was saved in the registry, a simple registry hook or registry dump comparison tool could figure out where the value is stored.
If your value is encrypted, method #1 (decompiling the program) could be used to figuring out how a decryption could be done.
Solving the possible issues above
A general obfuscation program can be used to make it harder to decompile applications. For this, I suggest SmartAssembly. Other than that, there's a tool called Spoon Studio (previously called PostBuild) which will recompile your application into assembly code (and also make it run without the .NET Framework installed).
The SecureString class could be used to make it harder to find and decrypt the value while it's in the memory. This class also cleans itself up after usage, but is generally slightly slower to use than a normal string.
Storing things in a file is not nescessarily a bad idea (even if people can sniff file activity), since you can always store the variable in a non-pretty way. For instance, you could have a file called IsFullScreen.bin, that contained the value of your boolean variable (1 or 0, or true or false), even though it has nothing to do with full-screen rendering. This would make it a bit confusing, but also not very pretty programming-wise.
For the registry, everything in solution #3 still applies.
Encryption is not a bad idea either, and it is hard to decrypt some encryption types (for instance public/private key encryption if you have a server), or hashing (such as MD5 or SHA1).
In your scenario, could you store the value on a server instead?
So to summarize ...
You can't protect your application entirely. But you can use some of the solutions above (or combine them) for a better protection making it harder.
Of course, premature security is bad. If that boolean isn't VERY important, then some simple encryption would be fine too in my opinion.
There's more ...
Edit 1
I just noticed that you've commented on your own answer saying that the file should not be "valid" after copying it to another computer and reading it from there.
If that's the case, you could use some key-based encryption such as XOR encryption, and then use the MAC-address of the PC or the motherboard serial number as key for that encryption.
Being on the computer that the file was created on would then be needed to read the file as well. If you're interested in this, add a comment and I'll give you a code example.
I would store it in the registry in a non-obvious way. For example, make the name of the registry entry appear to be important and store a random numeric value then ensure it ends in 0 or 1 or contains a 0 or 1 embedded at a fixed position in the number.
You can then read the value from the registry and extract the 0 or 1 from the appropriate location.
Encrypt the value before storing it. Use .NET Cryptography Model. For more on how to implement something using that model see