Sandsifter software finds hidden instructions inside processors.

With the exception of hidden instructions which bypass security, I can't help feeling this is uninteresting. One reason instructions are not documented is that they don't work reliably.

Sylvia.

I fail to see any logic in that. If an instruction does not work reliably why hide it ? When not simply document it as: "This instruction does not work reliably so don't use it"

Why all the secrecy ? The logic does not add up.

Furthermore the SandSifter run flawlessly and executed all these hidden instructions without crashing the system, itself or anything else.

Thus at least on my processor the opposite seems to be the case... at least it's reliably enough that nothing crashes. Perhaps not all variations were tried or perhaps they were... at least not all values/offsets/indexes were tried that's for sure.

However why would some values or indexes fail, again very little logic in that.

Furthermore why would hidden instructions be unreliable ? What is ment with unreliable ? Some times they work and sometimes not ? This would indicate defective transistor gates.

It's not like Intel/AMD/Transmeta can simply sell chips which are defective and then simply hide defective instructions. This is not the way it works... applications would then simply crash or fail to function properly.

One possibility might be "experimental instructions".. the implementation failed/was flawed and thus the instructions were hidden from sight.

Again a bit of strange logic. Why not simply remove them all together ?

Would this indicate "detection of failure" after the chip was produced ? Surely there would be prototypes and failed pieces of design would be removed... possibly to speed up production.

One reason to leave it in might be to not mess with current design to safe development costs and not risky further damaging/upsetting the design.

This would imply that there would have to be some mechanic to hide these instructions from plain sight. Well ofcourse this is the documentation at work... the docs are missing for these.

However if it were known these instructions are flawed/unreliable... wouldn't it be safer to disable them by for example a bios patch ? Or any other patch ?

Surely there would be some way to disable them.

This "disabling" has apperently not be done which could be a very clear indication that these instructions are anything but flawed/unreliable and survive some secret/hidden purpose !

Bye, Skybuck.

Anything "discovered" or posted by Skybuck is uninteresting.

It was actually an interesting video, a very knowledgeable guy presenting

But claiming that "secret" instructions are in the processor, just because the upcode is unused, and millions of them in one processor is just plain naive (like Skybuck)

Cheers

Klaus

I have not viewed the video, but "undocumented instructions" due to incomplete decoding have been there since the early days. Often it could be derived what they would do by locating them in a matrix of instructions (where rows and columns are determined by part of the opcode bits) and check what is in neighboring columns and rows. But sometimes they just do weird things.

In a modern processor one would expect that all unimplemented instructions cause a "illegal instruction" trap. That also allows software emulation of instructions added in future versions of the processor.

Then how do you explain ????????????????? ????????????????? ?????????????????? ???????????????? ????????????????????? o?????????????????? ?????????????????? u??????????????????? ?????????????????? ?????????????????? ?????????????????????? n??????????????? ??????????????? ?

Watch the video, or read the whitepaper -- it's good either way.

Some undocumented instructions are added by the manufacturer. Think of the Intel Optimizing Compiler fiasco -- I mean, obviously, detecting and giving negative optimization to AMD is stupid and beside the point, but it's entirely possible that, in the course of optimizing for Intel, they used some of their undocumented instructions to give just that little edge more. Or, say, hidden deep within drivers; who knows (does anyone regularly audit and deobfuscate drivers?).

It's hard to say if old school instruction-decoder-"do not care" instructions are present today. One would hope they're all trapped (and that the trap fires first, before getting deep into the pipeline, and before affecting registers or caches), but how would you know until they've been tested?

They could easily have missed some, or added some beta version instructions (so to speak?) that are undocumented, and probably require further testing, that could result in "undefined" behavior with respect to registers, access levels, caches, who knows what...

Tim

Idea of this software is basically:

Generate random bytes and feed them to processor.

Observe result of processor if good or bad (error codes).

If good check docs. If bad adjust and retry.

Somebody wrote a nice short explanation of what SandSifter does to give you an idea (it's a new algorithm to find undocumented instructions fast !):

It's guessing possible X86 instructions by exploiting the Instruction Decod er via the (PF) Page Fault result code. Effectively splitting an instructio n across two pages and only having one page of it executable. When the deco der fetches the instruction it notices that it's incomplete, attempts to fe tch the next part that is on a new non-executable page. The decoder then th rows a page fault since it's not executable. So it moves the entire instruc tion one to the left and tries again with various combinations until it doe sn't get a page fault at which point it executes it.

And thus it attempts to 'tunnel' through every possible instruction. That's the general very simplified explanation.

Bye, Skybuck.

Because it may have unintended consequences, like being a big, fat, security hole. No one knows because it's unintended.

Secrecy?

But you don't know what else it does.

yes and no.

The guy was using debian linux. if that's the same video I saw in july.

I am going to issue a warning about all of this software:

SandSifter, Linux Mint 18.2 and install-apt and for windows: git

For now I suspect running two instances of SandSifter at same time on Linux Mint 18.2 caused file system corruption as can be seen on these three screenshots also checkdisk log file is included in web folder:

Possible causes of file system corruptions:

1. Running two instances of SandSifter + Linux Mint 18.2
2. Git on Windows
3. Perhaps a problem was already with file system.
4. BIOS Corruption in recent past.
5. Spark when other person connected laptop to power output... there was a spark.
6. FireFox corruption while browsing or extracting files ! Google detected cooky corruption... so FireFox is also a prime suspect !
7. Capstone disassembler
8. Possibly execution of hidden instructions or corruption because of it ;)

Be carefull !

I still have to investigate checkdisk log further though ! ;)

Bye, Skybuck.

I do remember a very rare and extreme Windows 7 system hang not so long ago.

It was probably caused by having to many FireFox tabs open... and somehow a website/FireFox managed to "hang windows 7".

Windows 7 might have been busy trying to write data to the harddisk and somehow during that process it hang.

After waiting a bit I had no choice but to press the "reset" button.

I think this is what might have caused this file system corruption.

A combination of "FireFox memory hogging" and "Windows 7 writing to disk", possibly FireFox cache or cookie related.

Bye, Skybuck.