need to make this work on windows as well

[Anora]

would be nice if it worked on windows

[crozone]

No joy on Bash on Ubuntu on Windows either.

I installed it with:

sudo apt-get install python-capstone libcapstone-dev and then ran make and it all worked.

However, running sudo ./sifter.py --unk --dis --len --sync --tick --low-mem -- -P1 -t -N returns almost immediately, with:

#
# ./sifter.py --unk --dis --len --sync --tick --low-mem -- -P1 -t -N
# ./injector -P1 -t -N -t -R -0 -s 4189029885
#
# insn tested: 0
# artf found:  0
# runtime:     00:00:00.03
# seed:        4189029885
# arch:        64
# date:        2017-09-06 17:18:27
#
# cpu:
# processor     : 0
# vendor_id     : GenuineIntel
# cpu family    : 6
# model         : 158
# model name    : Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
# stepping      : 9
# microcode     : 0xffffffff
#

[BaderSZ]

@crozone I get the same output on Fedora running on a Pentium M. Seperate bug?

[crozone]

@BaderSZ Possibly, I'm running on an Intel 7700K. I'll try to get a native linux instance up and running and see if the problem is still there.

[red-scorp]

Does not work under Windows 10 in Unbuntu/linux emulation mode:

user@XXXXX:~/sandsifter$ sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t
[sudo] password for gsuser:
#
# ./sifter.py --unk --dis --len --sync --tick -- -P1 -t
# ./injector -P1 -t -t -R -0 -s 159236810
#
# insn tested: 0
# artf found:  0
# runtime:     00:00:00.14
# seed:        159236810
# arch:        64
# date:        2018-10-05 17:11:18
#
# cpu:
# processor     : 0
# vendor_id     : GenuineIntel
# cpu family    : 6
# model         : 94
# model name    : Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz
# stepping      : 3
# microcode     : 0xffffffff
#                               v  l  s  c

and the summary does not work too

user@XXXXX:~/sandsifter$./summarize.py data/log

beginning summarization.
note: this process may take up to an hour to complete, please be patient.

loading sifter log:
[                                        ]   0.0%

...

binning results:ot found, but can be installed with:
Traceback (most recent call last):
  File "./summarize.py", line 538, in <module>
    (c,_) = bin(instructions, 0)
  File "./summarize.py", line 517, in bin
    example=instructions[0].raw, valids=valids, lengths=lengths,59
IndexError: list index out of rangesleeping,   0 stopped,   0 zombie

Do not understand why it does not work. Has anyone an idea what sandsifter does that system depended and does not work under Linux emulator under Windows 10?

Native port to Windows is also welcome!

[LoganDark]

No, this doesn't need to be ported to Windows. Why are you using Windows for something that would require this? If you're doing something that critical, Linux or macOS should be a requirement.

[crozone]

@LoganDark

If you're doing something that critical, Linux or macOS should be a requirement

This is pretty elitist, but if we're going to be elitist, why are you lumping OSX in there? It's as secure as a sieve.

Nothing realistically "requires" this. If the porting effort to get this running on Windows is too large, so be it, but dismissing Windows as a "critical" OS (while including OSX) makes no sense.

As it stands, there are issues running this on certain hardware configurations regardless. The issues in this thread appear to be OS independent.

[LoganDark]

Elitist...?

First of all, where did you get the idea that macOS is "as secure as a sieve"? I'm genuinely interested in knowing how you got to the conclusion that full-disk encryption + a Unix-like OS + System Integrity Protection is bad. Windows has none of that. Higher-tiered versions of Windows have BitLocker, though.

I "lumped" it with Linux because the two are quite similar when it comes to the underlying CLI. macOS has a CLI quite similar to Linux (because Linux was made to act like Unix when it was first being developed). It's a fairly competent OS with almost 1% of the support of Windows. That's a surprisingly large amount, mind you...

Why are we arguing about this anyway? Why is it so mission-critical to get this application running on a completely different OS? If you want it so bad, why not use a live USB or a dual boot or something?

[red-scorp]

@LoganDark your opinion about critical-ness of Windows/Linux/other OS is really childish and not a topic of this discussion.

The question remains the same: how can we run sandsifter under Windows and potentially other OS?

[LoganDark]

really childish

:wave:

[crozone]

@LoganDark Just because macOSX is based on BSD and is UNIXish doesn't magically make it a holy grail of security. Apple let bugs like this through.

Nevertheless I agree that security has nothing to do with whether this should run on Windows or not. It's a testing tool. It realistically doesn't need to run on anything except Linux. However Windows has the most market share and a native port would be a nice to have.

The more pressing issue is that sandsifter failes on certain system configurations, like WSL and even native fedora. Fixing this issue should allow it to run on WSL which is a nice stopgap for Windows users.

[LoganDark]

@crozone And windows lets bugs like this through.

List of dangerous Windows viruses

Anyway, yes, the native Fedora thing is also an issue...

[TheTape]

@LoganDark Gtfo with your illogical circlejerk bs you petty cog in the wheel of technological advancement.

Support Windows and get 90% more published results. I won't bother booting Linux for this; I have too much shit running that I wanna keep running. Would have been fun seeing what the first i7 processor (920) hides.

[LoganDark]

@TheTape Illogical circlejerk? Elaborate more, please?

If you refuse to run Linux for a Linux application, that's not my fault. That's not the app's fault. That's your fault for refusing to run the app where it's intended to run.

The fact that 90% of the masses run Windows has nothing to do with this. Sandsifter only runs on Linux at the moment.

I'm not saying there's not a possibility for a Windows port - I'm just saying it doesn't exist right now. Complaining and insulting others about an "illogical circlejerk" isn't anyone's fault but yours. If you want a Windows port - subscribe to the issue and wait.

I never told you to do anything anyway. If you're getting so mad at what I'm saying, maybe you should consider the fact that the advice wasn't even for you in the first place.

[red-scorp]

@TheTape, the question is not that we refuse to run Linux on the CPU we would like to check, but it might be impossible or forbidden for some another reason to install linux there. And it is clear for us the sandsifter is written to run only under linux, which is per se nowadays with wide variety of portable libraries and tools is kind of odd.

How would you check what commands AMD Geode from an real-time industrial running QNX controller has if you can't deconstruct the controller and install linux there? (nuclear power plant)

How would you check how virtual machine hosted under OS/2 guesting Windows XP emulates CPU is you can't install linux guest because it is not supported by VM? (banking system)

How would you check behavior of a CPU of some smart network router if the OS is hard-coded there and it is not a linux? (big internet router)

The question was how can we run/port/emulate sandsifter to run in such kind of critical locations without spending weeks of work installing linux there?

Thanks for your cooperation! With best regards, AG

[HenkPoley]

The end of a strace when sifter is run under sudo is sadly already in an abort on error situation. Top page or so is in function get_cpu_info(). Which is called from dump_artifacts(). Which is called from cleanup() on an error condition. So without digging further into the strace I don't think I'll find much in there.

I can report sifter does work without sudo on Windows 10 1903. Running without sudo will not (attempt to) do the page mapping at page 0, so some working instructions will be seen as triggering a segfault error (see README).

And leaving out -t (tunnel option) that goes into injector keeps it running for a long time.

injector [OPTIONS...]
[-b|-r|-t|-d] ....... mode: brute, random, tunnel, directed (default: tunnel)

So the command I run on WSL: ./sifter.py --unk --dis --len --sync --tick -- -P1 -N

Running summarize.py over the data, it might be that it just records a SIGTRAP for lot of one byte instruction. But it could be that my ancient Intel U9400 is just so slow it never gets into anything fancy for the time that I give it to run. A second option is, that with -t it's just very effective, so it scans all options very efficiently, and is finished in 2 seconds. Tunneling is the new method described in the paper, so I guess it's this latter option.

[NobodyFAH]

Pardon me for starting this issue again, but is it known, if it's a problem with Sandsifter itself or Windows 10? My first best guess would be the idea, that Windows 10 is the problem, but factually I'm walking in the dark.