GithubHelp home page GithubHelp logo

Comments (14)

kweatherman avatar kweatherman commented on August 15, 2024

Like it says in the code comments just above that error string:

// Only happens when there is an error in the search algorithm during development/testing

It really shouldn't be happening like it says, but I left that check in there in the unlikely event that it can happen.

It shouldn't really matter but I developed it using IDA 7.6 SDK and Visual Studio 2019.
Are you making modifications, adding things? Replaced the project file with your own?
Partially I ask because of the previous issue reported where you said:

was not configured to be 64-bit

I removed the 32bit build profile from the project so that shouldn't even have happened even when being updated to VS2022.

Does your machine support AVX2. More than likely it does, but you can check using CPU-Z or something.

Also what are your option settings?
Can you post a screenshot of your SigMakerEx options dialog?

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

Great thanks.
And strange okay.
I was planning on upgrading anyhow. I'm going to have to install VS2022 and IDA 7.7 and build under the same environment.

Should be able to build it of course, but from what I saw on a forum people are are able to run the latest release without issue.
Please use the release version for now until I get the new build environment going.

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

Again that error, it indicates the AVX2 search algorithm failed. It only happened to me before during dev when I broke something in the actual search algorithm.

Statistically: This is a popular repo with as of this writing 21 forks. So this probably means at least several hundred users if not a thousand or more even. And no one else has reported the same issue so far.

I wonder now if there is something relatively odd in your config.
Are you running IDA under a VM or x86 emulator? On an ARM MAC?
Maybe something is telling us AVX2 is there, but it really isn't or it's badly emulated.
I would think though this would cause an invalid instruction exception to happen first though.

Since you can build, lets try a test:
In "Search.cpp" comment out the line "hasAVX2 = TestAVX2Support();" and replace it with a temp line "hasAVX2 = FALSE;".
This build will force the plugin to use the non-AVX2 version of the scanner for our testing.
When you build, make sure you use either "IDA_Signsrch64.dlL" for the 64bit targets, or "IDA_Signsrch.dlL" for the 32bit target version. Want to use the modified version not the previous AVX2 one.
When you run the modified version you should get a one time message in IDA with: "* Using non-AVX2 reference search *".

Lets see if the reference scanner works.

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

You found some misspellings, thanks for that.

I still see "** SearchSignatureAVX2: Sig not found! **", so if you did temporarily disable AVX2 I don't see where.
There is no dividing line. Can't tell if/when you ran it without.

Incidentally, a function like this will more than likely not be unique because it's a simple wrapper/accessor type function.
This means the plugin must look for a reference signature instead. And if it can't find one of those it's just not going to find one at all.

Actually seeing this, this doesn't even look right:

Full sig: "48 8B 05 19 AD 98 01 C3"

This shouldn't have happened. The instruction analyzer should have seen the MOV value 0x7FF6EF57CDB0 as something to wildcard. Is this a normal/complete executable, or some memory dump with an incomplete PE header or something?

You don't answer a lot of the questions I ask.
Do you just skip them because you don't understand what I ask maybe?

I'm afraid the only way to resolve is if I can get the same executable and try it myself at the various addresses in your dumps.

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

First I wish you'd go directly to github here and use the web interface.
Maybe you don't see it but you leave big email headers behind because apparently you're replying from email using an iPhone or something.
And like the usual email thing it dumps the whole previous message chain into one.
I've been having to edit your posts to remove that stuff for clarity.
A solution is logging into your github on a phone browser even.

The attachments didn't come across as files, comes across on github as one giant message.

You should be able to just just upload the executable to mega.nz or dropbox. Not the IDA DB because right it will have your IDA user name. You can strip it out using a Python file found in a github here (don't have the URL) but your license ID will still be there. I'm concerned though if it's copyright thing. I found your handle on Reddit and gave you a message there if it's yours.

If that's the case, you predate me even. But maybe by not much..

At any rate I look at these issues as an opportunity to learn.
But then I don't want to spend too much time on what might be rabbit holes either.

I have attached the ida debugger (local windows debugger) to a running game instance and saved the ida database after it analyzes process memory. You won't be able to do that without having the associated game launcher. I need to verify there is no PII in my ida database, and if not, I can send you my ida database too.

Okay now this is making more sense.
You are running the plugin on live memory then, IDA as a debugger?
If this is the case there will undoubtedly be issues.
There is a distinction in IDA between states that probably wasn't so obvious.

From the IDA SDK I use "get_db_byte()" which WILL read from live memory in a debugger, but not so sure about some of the API other functions (like decode_insn()).
From that AVX2 error, it does look like there is some difference between reads some place.
Maybe reading from live memory in one case, but then referring to IDA's DB (stored in a BTREE) for another.

Global DB "database parameters" like inf.omax_ea might be wrong while debugging.
This will mess up the instruction analyzer because part of it looks if some operand values are inside the IDB address space or not.
Which also might explain why you got a "siglet" (as I call them) of "48 8B 05 19 AD 98 01 C3" when at least four (relative address) bytes of that mov rax, cs:qword_7FF6EF57CDB0 should have been wildcards.

Unfortunately, I didn't develop/design this into the plugin.
The assumption, thus the development and testing setup, has been static analysis only.

Which incidentally you should try so you can see how the plugin normally works.
Try it on an executable that isn't packed and that doesn't have any obfuscation in the signature path which I suspect your target might have.

Maybe a fix is not that difficult.
Might just need a few "is_debugger_on()" calls to switch behaviors, and/or using other IDA SDK functions that will work from the debugging state. On the other hand, the changes or addition support could be extensive too.
Would need to setup a test bed for this also. At times debugging the plugin while IDA is debugging a test target.

Anyhow I will probably not be doing this myself since I don't have a need for this scenario at the moment.


Alternatively, there are some pretty good process dumpers on the web.
You might be able to just make a decent dump you can load into IDA after.
If the PE header is trashed or something then it might take more work.
forum.tuts4you.com is a good source for this as it might fall into the "unpacking" realm.

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

First I wish you'd go directly to github here and use the web interface.

Sorry about that - I didn't realize it was doing that by responding to the email.

I found your handle on Reddit and gave you a message there if it's yours.

If you sent something to mistahmikey, it appears I don't own that one on reddit.

You are running the plugin on live memory then, IDA as a debugger?

I was running it on a database that I have saved after I attached a debugger, not while I had a debugger attached. I just tried the latter to see if it acted any differently, but it had what looked like the same result.

You can strip it out using a Python file found in a github here (don't have the URL)

According to Ilfak at Hexrays, you can strip out PII by using the del_user_info() IDC function.

Which incidentally you should try so you can see how the plugin normally works.

I'll give that a try.

Anyhow I will probably not be doing this myself since I don't have a need for this scenario at the moment.

Ah, ok. Well, let me know if you ever want to give it a go. I can send you the exe and the db file. Thanks for clearing up why its not working for my situation.

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

No problem.

Okay, yea so not during debugging.

I was only saying that for the in debugger case.

Don't need the .i64 file, just the executable.
The problem is AFAIK game executables are copyrightable.
So I can't ask you to post a file share link to it.

I'm pretty sure the situation is not quite as bad as being under a debugger.
Probably something to do with it being an executable dump.
Maybe not all of the segments are intact, etc.

I've seen many of these through the years unpacking VM protected executables, etc.
Although if you skilled at it you can capture all the missing pages (memory) and make a near perfect clean dump.
I usually don't take the time to do this myself and just work with what I can get going; hopefully at least most of the imports are still there, etc.

Maybe a solution for you:
The original Sigmaker was a lot more permissive. It doesn't do the checks I do.
Mine assumes a complete executable with all segments accounted for, no broken up VM protected sections, or other issues.
For your case with a semi-broken exe file the original one will probably do be better.

To have it work with SigMakerEx here I'd probably have to do some quick analysis to first see if the exe is broken.
Or maybe just have a checkbox with "permissive mode" or something where it would be more looser with operand values.

Here is a version that will hopefully work with 7.7:
https://github.com/ajkhoury/SigMaker-x64

There is also a Python version of it:
https://github.com/therealzoomgod/pySigMaker

Play around. While I was researching to make a better "SigMaker" tool I found out a lot of experienced folks manually edit their signatures. Tweak them so the signature will still be valid over multiple versions of the same executable, etc. It takes some knowledge of x86 instructions. Learning which parts of them are the operand bytes. Pretty easily, most of the time it's the last four bytes (but can be from one to eight'ish), depending on the instruction.

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

The problem is AFAIK game executables are copyrightable.

I'm not sure if you are saying you would like me to send you the executable or not. But in any event, if you're ever feeling ambitious about looking into this, you can create a game account and start a free trial which would allow you to download the exe yourself. Have a look at https://na.finalfantasyxiv.com/

Here is a version that will hopefully work with 7.7:

Yep, I tried that one, but I had trouble building it. I tweaked a few things to get it to build, but it crashed ida when I ran it. Then I saw yours, and thought I give it a try before trying to delve into how the other plugin works so I could fix it.

I found out a lot of experienced folks manually edit their signatures

Yes, the example signature I gave you is like that. It finds a call instruction for the function I was trying out your plugin on. The signature provides the address of the call instruction, which you can then use to get the offset from the instruction to the function.

Thanks for all the information and your help!

from sigmakerex.

mistahmikey avatar mistahmikey commented on August 15, 2024

from sigmakerex.

kweatherman avatar kweatherman commented on August 15, 2024

Strange okay.
Can you post a screen shot of the target executable segment list? Default IDA hotkey CTRL-S.
Will look like this:
image
In this case a Windows driver but it will look similar.

Which of the the SigMakerEx options are you using to make this signature: "Function", "At address", or "From address range"?

from sigmakerex.

Related Issues (11)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.