Hi.
Due to the many threads about dongle I think this one could offer a nice startup up, it's not really easy but... who cares.
The readme file says all:

-----------------------------------------------------
The aim of this crackme is an analysis of the works of some hardware key.
The key is simulated through a process named DongleBlackBox, which is run
along the protected program. The program (JPEGConv) will have been cracked
when it's fully operational and you don't need the key process to make it
work. Physically it's equivalent to elimination of the need for the dongle.

As it's only a software simulation of the dongle, there's only one rule:
YOU MAY NOT IN ANY WAY ANALYSE THE WORKS OF THE DONGLEBLACKBOX PROCESS.
You musn't disassemble, debug or patch it, nor even look into the file,
in which it's code is located (DongleBlackBox file).
Let's assume that the hardware key is a black box which you can't peek into.

Aside from that rule, anything goes You may use debuggers, disassemblers,
hook the DLL, modify and patch the code (it's a real crackme), simulate
the key on your own, communicate with the key through pipes, as it's done
in the DLL, etc.

As it's pretty easy to give a full solution by simply breaking the rules
and just looking into the DongleBlackBox file, a much more interesting thing
would be the description of the way itself to deal with the problem.
Write how (if ever) you'd crack this protection, how long would it take,
and how strong you think it is.
-----------------------------------------------------

I hope you'll have fun and... let the discussion begin!

Good luck,
ZaiRoN

Hello ZaiRoN.. long time no see.. as alwasy you found nice target to play with : so will try to contribute some infos for newbies in this discussion!!

First :we can see 3 files : JPEGConv.exe , sm.dll ,DongleBlackBox(which is also exe..and represents dongle) ... so we musNT touch it .


If we delete DongleBlackBox and start exe in olly ,it doestn run?? You can see this :

7C90EB94 C3 RETN
7C90EB95 8DA424 00000000 LEA ESP,DWORD PTR SS:[ESP]
7C90EB9C 8D6424 00 LEA ESP,DWORD PTR SS:[ESP]
7C90EBA0 90 NOP
7C90EBA1 90 NOP

which means olly exits ..crap





Apprently dll is loaded before Oep. so ..where did i see article about it?? Hint :google.



in olly you can see this : at OEP (all files in dir ) :

00464538 > $ 55 PUSH EBP ; |ExceptionCode = 12FFF0
00464539 . E8 AECCF9FF CALL <JMP.&sm.RaiseException> ; \RaiseException <== Trace with F7 to get into dll ..
0046453E . 0F0B UD2
00464540 . 6202 BOUND EAX,QWORD PTR DS:[EDX]
00464542 . 90 NOP
00464543 . E8 F419FAFF CALL JPEGConv.00405F3C
00464548 . A1 4C694600 MOV EAX,DWORD PTR DS:[46694C]
0046454D . 8B00 MOV EAX,DWORD PTR DS:[EAX]
0046454F . E8 44E8FDFF CALL JPEGConv.00442D98
00464554 . A1 4C694600 MOV EAX,DWORD PTR DS:[46694C]
00464559 . 8B00 MOV EAX,DWORD PTR DS:[EAX]
0046455B . BA B0454600 MOV EDX,JPEGConv.004645B0 ; ASCII "JPEG+TGA+LZW"
00464560 . E8 4FE4FDFF CALL JPEGConv.004429B4
00464565 . 8B0D A4684600 MOV ECX,DWORD PTR DS:[4668A4] ; JPEGConv.0047CCA0
0046456B . A1 4C694600 MOV EAX,DWORD PTR DS:[46694C]
00464570 . 8B00 MOV EAX,DWORD PTR DS:[EAX]
00464572 . 8B15 CC374600 MOV EDX,DWORD PTR DS:[4637CC] ; JPEGConv.00463818
00464578 . E8 33E8FDFF CALL JPEGConv.00442DB0
0046457D . 8B0D 886A4600 MOV ECX,DWORD PTR DS:[466A88] ; JPEGConv.0047CC98
00464583 . A1 4C694600 MOV EAX,DWORD PTR DS:[46694C]
00464588 . 8B00 MOV EAX,DWORD PTR DS:[EAX]
0046458A . 8B15 08324600 MOV EDX,DWORD PTR DS:[463208] ; JPEGConv.00463254
00464590 . E8 1BE8FDFF CALL JPEGConv.00442DB0
00464595 . A1 4C694600 MOV EAX,DWORD PTR DS:[46694C]
0046459A . 8B00 MOV EAX,DWORD PTR DS:[EAX]
0046459C . E8 8FE8FDFF CALL JPEGConv.00442E30
004645A1 . E8 2AF2F9FF CALL JPEGConv.004037D0
004645A6 . 0000 ADD BYTE PTR DS:[EAX],AL



so it looks like all our hide infos are in dll ..so fire up ida and check it..



bye NeO

ok some more info : so if we trace

00464539 . E8 AECCF9FF CALL <JMP.&sm.RaiseException> ; \RaiseException <== Trace with F7 to get into dll ..

you get into here


004011EC $-FF25 94D14700 JMP DWORD PTR DS:[<&sm.RaiseException>] ; sm.RaiseException

trace more :

you will see this :


10001240 > FF35 1C500010 PUSH DWORD PTR DS:[<&KERNEL32.RaiseExcep>; kernel32.RaiseException
10001246 ^E9 B5FDFFFF JMP sm.10001000


trace more :



10001000 874424 04 XCHG DWORD PTR SS:[ESP+4],EAX
10001004 9C PUSHFD
10001005 66:8138 0F0B CMP WORD PTR DS:[EAX],0B0F
1000100A 74 06 JE SHORT sm.10001012 <== it jumps
1000100C 9D POPFD
1000100D 874424 04 XCHG DWORD PTR SS:[ESP+4],EAX
10001011 C3 RETN


if me trace a little more :

10001012 0FBA35 30700010 >BTR DWORD PTR DS:[10007030],0
1000101A ^73 F6 JNB SHORT sm.10001012
1000101C 83C0 04 ADD EAX,4
1000101F A3 C4720010 MOV DWORD PTR DS:[100072C4],EAX
10001024 58 POP EAX
10001025 83C4 04 ADD ESP,4
10001028 A3 CC720010 MOV DWORD PTR DS:[100072CC],EAX
1000102D A1 C4720010 MOV EAX,DWORD PTR DS:[100072C4]
10001032 83E8 02 SUB EAX,2
10001035 66:8B00 MOV AX,WORD PTR DS:[EAX]
10001038 0FB7C0 MOVZX EAX,AX
1000103B A3 C8720010 MOV DWORD PTR DS:[100072C8],EAX
10001040 58 POP EAX
10001041 A3 D0720010 MOV DWORD PTR DS:[100072D0],EAX
10001046 890D D4720010 MOV DWORD PTR DS:[100072D4],ECX
1000104C 8915 D8720010 MOV DWORD PTR DS:[100072D8],EDX
10001052 891D DC720010 MOV DWORD PTR DS:[100072DC],EBX
10001058 8925 E0720010 MOV DWORD PTR DS:[100072E0],ESP
1000105E 892D E4720010 MOV DWORD PTR DS:[100072E4],EBP
10001064 8935 E8720010 MOV DWORD PTR DS:[100072E8],ESI
1000106A 893D EC720010 MOV DWORD PTR DS:[100072EC],EDI
10001070 6A 00 PUSH 0
10001072 68 34750010 PUSH sm.10007534
10001077 6A 28 PUSH 28
10001079 68 C8720010 PUSH sm.100072C8
1000107E A1 3C750010 MOV EAX,DWORD PTR DS:[1000753C]
10001083 50 PUSH EAX
10001084 FF15 04500010 CALL DWORD PTR DS:[<&KERNEL32.WriteFile>>; kernel32.WriteFile
1000108A 6A 00 PUSH 0
1000108C 68 34750010 PUSH sm.10007534
10001091 6A 28 PUSH 28
10001093 68 F0720010 PUSH sm.100072F0
10001098 8B0D 30750010 MOV ECX,DWORD PTR DS:[10007530]
1000109E 51 PUSH ECX
1000109F FF15 00500010 CALL DWORD PTR DS:[<&KERNEL32.ReadFile>] ; kernel32.ReadFile
100010A5 A1 F4720010 MOV EAX,DWORD PTR DS:[100072F4]
100010AA 50 PUSH EAX
100010AB 9D POPFD
100010AC FF35 C4720010 PUSH DWORD PTR DS:[100072C4] ; JPEGConv.00464542
100010B2 8F05 C0720010 POP DWORD PTR DS:[100072C0] ; JPEGConv.00464542
100010B8 A1 F8720010 MOV EAX,DWORD PTR DS:[100072F8]
100010BD 8B0D FC720010 MOV ECX,DWORD PTR DS:[100072FC]
100010C3 8B15 00730010 MOV EDX,DWORD PTR DS:[10007300] ; ntdll.KiFastSystemCallRet
100010C9 8B1D 04730010 MOV EBX,DWORD PTR DS:[10007304]
100010CF 8B25 08730010 MOV ESP,DWORD PTR DS:[10007308]
100010D5 8B2D 0C730010 MOV EBP,DWORD PTR DS:[1000730C]
100010DB 8B35 10730010 MOV ESI,DWORD PTR DS:[10007310]
100010E1 8B3D 14730010 MOV EDI,DWORD PTR DS:[10007314] ; ntdll.7C910738
100010E7 C705 30700010 01>MOV DWORD PTR DS:[10007030],1
100010F1 -FF25 C0720010 JMP DWORD PTR DS:[100072C0] ; JPEGConv.00464542

hmm exe runs :P is this all where is protection :P

find it ??




bye NeO

NeO, you effectively found the code where the protection is...

But the application is NOT completely crackable without looking inside the dongle...

We can only build some approximate crack, trying to emulate the dongle. But that crack could run just on one machine, the one where we run the program.


Best regards, bilbo

Well, I am wrong in this specific case, I think...
Strange that nobody contradicted me...

Well, who dares contradict the son of Bungo, really?

Hi NeO, bilbo.
Seems like you are not sure, why do you think we can't build a full working emulation?

Maybe no one is playing with this toy

OK, it is time to close this thread, I think...

PART I - The type of protection, in few words, is the following:

The author (Victoria) stole many snippets of code from the application and stuffed them in the dongle, each one identified by a two-byte identifier. Every time the flow of the program lands to a stolen snippet, a CALL RaiseException is issued.
RaiseException is an API hooked from KERNEL32.DLL and located inside SM.DLL: the name is misleading. There, the function checks first if the caller intended to invoke the real RaiseException by controlling the two bytes following the call itself. If the two bytes are the magic 0F 0B, the caller intended to invoke the spoofed function because it is inside a stolen snippet, and two other bytes are fetched after the magic ones: these are the identifier of the current snippet. It is time to pass the control to the dongle: it gets in input the current values of registers and flags, executes the stolen snippet, and returns as output the new values. Now the code flow can go on until the next stolen snippet.
Restoring the original executable, in a general way of speaking, would mean guessing all the stolen snippets, since we cannot look inside the dongle (assume it is a write-only memory), and it is a near to impossible work.
It is not enough to have a live image of the registers before and after the snippets. First, that image is not available for ALL the snippets, it depends on the program flow; second, that image can be system/machine dependent. We also have to reverse engineer the code before and after the stolen snippets to have a good chance of a correct restoration. And nobody told us what is the length of the stolen snippets.

PART II - So. Game over? No! That was the general case... Let's try to guess how the author implemented the protection in this specific case. The application is a Delphi one, and he presumably coded it in Pascal. He couldn't play a lot with assembly code, and we are lucky! IMO the author took two steps:

(1) After having builded the full-working application, he, with a binary editor, replaced the name of the imported library KERNEL32.DLL with SM.DLL. We can see that because, following the SM.DLL string in the executable, there are some nulls, in a number exactly needed to stuff in the name KERNEL32.DLL. SM.DLL simply redirects all the imported functions to the ones inside KERNEL32.DLL, except - guess what? - RaiseException(), which has the code to implement the protection. Furthermore SM.DLL DllMain(), which is automatically invoked by the loader, has the code to start the dongle emulator as a separate process, and to open a couple of pipes to communicate with the protected app.
(2) little chunks of bytes (9 or 10, just the space to fit in the call to RaiseException + magic 0F 0B + two-bytes snippet identifier) are replaced here and there. Let's see for example the first snippet we encounter, at the program entry point

If we compare it with another Delphi application entry point:

We see that 10 bytes have been replaced: 8B EC 83 C4 F4 B8 xx xx xx xx
with E8 AE CC F9 FF 0F 0B 62 02 90.
Now it's also evident the reason of the NOP (which is not always present): the author could not truncate an asm instruction.
The value to assign to EAX, in this specific snippet, can only be inferred looking the registers values AFTER the dongle call.
Put a breakpoint at address 100010A5: we find at 100072C8 ten longs with registers and flags values (preceded by the snippet id) BEFORE the dongle call; and at 100072F0 the values AFTER.

PART III - Finally, to restore the application, we have to reverse the two steps above:

(step 1) Search for SM.DLL inside the .EXE bytes, and replace it with KERNEL32.DLL. In this way all the dongle stuff is eliminated. This was easy!

(step 2) Patch back all the 9-10 bytes snippets that were overwritten in the executable. Is this ever possible? Take into account the fact that that there are many hundreds of them (have a look at xrefs created by IDA)! Yes, it is theoretically possible! Why?
It seems that nearly all the snippets have been stolen from Delphi library functions. So I know of three ways to restore them:
(a) search in delphi5/lib directory for all the patterns to be replaced... I am too lazy, this work would require many and many hours!
(b) try to DeDe-ize the project, compile it back and compare the two executables... I didn't dare it!
(c) infringe the rules and make a little proggie that will search the stolen bytes into DongleBlackBox and replace them into Jpegconv.exe. That's a work of less than an hour, but we are not allowed to do so, isn't it?

Any other idea?

Best regards, bilbo

Good work, bilbo, but...



Nearly all the snippets? What happens to the rest of them? Surely if just one of the stolen snippets is taken from user code then the process is no longer reversible. Or is there something you're not telling us?

Regards
Admiral

Thx, Admiral, for having read carefully my post.
I wrote nearly all the snippets because I'm not completely confident about the structure of a Delphi program.

These are the facts: if you sort by address all XREFS to RaiseException() - there are 339 of them (we assume that IDA has recognized all, but it is not completely sure)! - you will see that the last one is at address 00464539, and that is exactly the snippet which we encounter at program entry point.

Now, it seems that in a Delphi program all the code preceeding the entrypoint is taken from library functions (anyone can confirm this?). In this case we can say without any doubt that all the snippets are overwritten on bytes inside library functions.

What puzzles me is that, when we apply DeDe to the program, a file DIALOGS.PAS is created, containing some code for the methods of the class TSaveDialog, as if those methods had been overloaded by the programmer.
In this module there are 5 references to RaiseException (followed by 0F 0B pattern). Have these functions really been overloaded (but they reside at addresses below entrypoint). or DeDe has been confused?

In no other file, among the ones created by Dede, a call to RaiseException is contained, excluding JPEGCONV.DPR which holds the code for the entry point.

Best regards, bilbo.

Curious.

I guess the first step would be to compile a few sample Delphi programs and check out the resulting structure. Perhaps one could insert into each user function (including a few overloads) a rare API call; one that doesn't feature in Delphi's library functions, say GetTimestampForLoadedLibrary. This way, a quick IDA scan could quickly give us some information about how Delphi deals with function overloading.
Perhaps if someone (who owns a Delphi complier) has ten minutes to spare, they could shed some light on the subject.

Hi.

As always nice explanaition bilbo


The last two-bytes represents a sort of counter. From a little idc script I found out that there are 610 calls to
RaiseException and the calls are all numerically marked in an ordinal way. The first called is signed with 1, the second
with 2 and... the last with 610 (which 0x262)


At the moment this seems to me the most ragionable way to follow if we want to solve the puzzle. Writing a simple program
able to compare the bytes between the original exe and the one from the lib(s) shouldn't be so hard - hoping to find all the stolen bytes.

Any Delphi guru outside?

Hi,

I've just noticed that there's a discussion going on here about my DongleCrackme (thanks Bilbo for the tip at the crackmes.de site ). For this crackme I've prepared a very simplified version of my anticracking system and protected a small and uncomplicated program. The program's in Delphi and a lot of its code is composed of library fuctions (that's obvious considering its size). As for some of your insights:
1. It's possible to find some of the snippets by comparing the library code, especially that I've removed the obfuscation procedures from the simplified system. Still, there are many snippets that you won't find in the libraries, because they come from the program's own code. The library snippets are just an addition, to make it more interesting.
2. Delphi organises its code in such a way that the entry point is located at the end of the whole code section, not only at the end of the library functions.
3. It's correct that the behaviour of some of the snippets is environment dependent.

I've also removed the jumps emulation from this crackme (didn't want to make it too hard ). Take a look at one of the jpegconv snippets that is emulated in the normal version:

TO Victoria : First of i would like to say that i dont really understand point of rule :
"As it's only a software simulation of the dongle, there's only one rule:
YOU MAY NOT IN ANY WAY ANALYSE THE WORKS OF THE DONGLEBLACKBOX PROCESS.
You musn't disassemble, debug or patch it, nor even look into the file,
in which it's code is located (DongleBlackBox file).""

why?Because if you are cracker you cant limit him to were we can go with his debuger.I am sure now you will say ,its HD key and you cant get it.. bytes on key are alwasy possible to read or dump ..that is why so many emulators are made .... The companies alwasy rlz SDk of protection which has apis ,dumper and all usefull things which can make you read the dongle itself..

Now you will say..but app will be distributed without key ..yes its NOT possible to refix exe without key ..but if you get key takes you like 3 min to do it...
Imagine this ..if i take like half of exe away ..would you be able to fix it?? i dont think so.. so were would be a point of crackme???

All dongles are emulated with ppl who actually have dongle key there,present on pc.

Same way goes with your protection if we can call it that ... you didnt do anything else like armadillo does with his int3..,Code split

You just took randomly snipped bytes with your engine and putted into dongle and when RAise.. happens you execute it inside dongle.. ALl this would be ok if you wouldnT be able to go there with debuger when you are running process itself..but actually you can ..and very easy..There is also one thing process is also created and you can also dump that..( i didnt,and i didnt disasmble the file)
Normally you set traps which makes cracker trace harder but you can never say to him there you cant go...


Otherwise the only 2 things i really find good about your crackme is ..excuting bytes without refixing original exe (i would like to see coding style)..and loading ms.dll ..
ALl other stuff its pointless.. imagine like i said.. devide file into 2 peaces and .. use just one try to fix it if you can...
Algo is short.. so even if you use obfucation code will not help you much..

I think i know why post on here .. you wanted us to test your protection ...actually its nothing new .. and it can be broke in 3 min..

My suggestion to you would be .. how you would know that your protection is hard? next time you code .. put all files at same place ,and start to crack !when you are done ,,multiplay the time you used for it by 3.. and that is normally time a cracker will need to get by it
That is the best way you will know how good your protection is!!!




Bye NeO

Just one thing - would you mind telling me HOW exactly would you break a secure microcontroller in 3 minutes?

You may crack this crackme in 3 minutes by breaking the rule and going into the process because it's a SOFTWARE SIMULATION. I can't provide you with a real HARDWARE dongle over the Internet, now can I?

I didn't ask you to crack it without the DongleBlackBox process - I said you could communicate with it just as you'd with a real dongle. You just wouldn't be able to break into a secure microcontroller (which is simulated by the black box) without vast hardware knowledge and a few hundred thousand dollars for the research.

You've just misunderstood the whole thing.

And BTW, the snippets are surely not chosen at random.

I'm going to make a leap of faith here and say it is welcome to have a feminine point of view on these forums. We don't get many that, at least, openly appear to be of the female persuation and while it tends to bring out the testerone in the younger crowd, it often also improves the general civility. We probably have had others, but I don't recall another with a decidedly female name. Of course there was that movie Victor/Victoria.

I would want to caution you, however, that the concept of "cheating" is actually part of the definition of Reverse Code Engineering. After all, we actually aren't supposed to be doing ANY of what we generally do with the software and hardware we challenge.

But your point IS well taken. If the exercise was to "behave" as if the dongle were a sealed container, then we would have to acknowledge that Neo is behaving as an over-testosteroned adolecent male, pounding on his chest about his self-preceived mastery of this or that. In truth, he is merely demonstrating that he lacks certain social skills we generally learn in childhood from our elders. Among them are that if one accepts a challenge within a certain set of rules, be it a race or a crackme, you do not succeed and you do not win when you run off the course to get to the finish line.

Neo thinks he has scored, but he's just too young to realize he's actually just lost "face." Hopefully, with time, he will learn another way. In the mean time, we will try to make allowances for his youth.

Regards,

Yeah, I agree with Victoria, exactly how the hell would you trace into the microcontroller NeO? I'd really like to see that anyway. Watch your tone when you don't know what you're talking about...

Thanks for the nice crackme Victoria.

Yup, JMI reveals himself...

Glad you believe it's uncrackable


The DongleBlackBox process behaves very much like the original dongle. There are no additional APIs, the DLL uses the ReadFile and WriteFile functions to send and receive registers. You'd get the same response from the dongle as you receive from the process.
If however by dumping you mean getting the internals of the dongle, then you have to break into it somehow.


Sure, but you'd have to carefully choose what and when to emulate. We're talking efficiency and flexibility here. You'd have to find a code to emulate that would be crucial in operation, hard to reverse, fast to execute, independent of other modules, with serializable data. It's not that easy and it requires work from the programmers who usually don't enjoy tinkering with anticracking stuff.
You can't just move half of the code into a dongle - I'm sure you've never tried that.


That way you could break pretty much every other crackme by simply patching the code.
Besides, my crackme is not intended for newbies.


AFAIR that's a simple static crypto dongle. It's a totally different kind of protection.

JMI and dELTA: thanks for the support, guys

With a correctly designed piece of code running inside the Dongle, the proposition of just "reading the content of the dongle" is not practical.

So Victoria's rule, not to look inside the DongleBlackBox is fair.

But there are still ways to attack this crackme.
Each snippet is a function executing a few processor instructions. I can instrument the code and record the state of the processor before and after each snippet and also record the snippet length.
After running the code for a while, for most of the snippets I have several pairs of before/after state that allow me try to guess the function.
To expediate my guesses I can build a dictionary of snippets by just diasm several similar not protected programs. If my dictionary is reasonnably complete, I will directly find the match for most of the snippets, especially all the library ones.
To confirm my matches and to disambiguate the remaining guesses I can run the Blackbox in a slightly (or completely) modified program with input of my choice to snippet of my choice.
In this quest, I can also carefully monitor the execution timing of the Blackbox and learn a lot by just looking at the variation of elapsed time for different input values.
In a real dongle I can also look at power consumption profile, etc...

Granted, those attacks at not trivial, but the bulk of the work can be automated and the library of snippets can be completed over time to simplify the attacks.

jcc

I'm not joining any side here, but I'm not sure I've ever heard of a dongle which actually has code snippets in it...I thought usually they just contained decryption keys and stuff. So really having a dongle with code in it really wouldn't simulate real world would it - since on a real dongle I doubt the processor actually jumps to execute some code in that hardware chip.

But I know &#&#*@!* about dongles

So, just curious

-nt20

First of all, it will not be the PC processor that actually "jumps" inside the dongle, but it would rather deliver its current processor state to it, and then tell it to perform "code #" processing on this data on the dongle's own microcontroller. The PC processor would then read back the results from it, and assimilate this new processor state as its own, whereafter it will resume execution at the place it left off before the dongle acrobatics.

Second, the reason for not seeing this, and many other quite fancy, advanced and hard to break protections much in the "real word", is mostly because with the increased complexity of a protection comes also an increased probability for incompatibility problems and problems with future upgrades of the software (Xtreme Protector, anyone? ). This does not make the protection any less real or efficient though, and therefore makes an excellent exercise in preparation for different sorts of dongle protections one might encounter in the "real world".

I'm pretty sure what is being described is already in use, but not for commercial uses, I did some work for acompany that manufactures "dongles" and all I know, (I was not privy to anything sensitive), is that it involved using an entire laptop pc card. Obviously this is far different than using a USB, serial or parallel port.

SiGiNT

That is one way of analysing the snippets, however I believe there would be a lot of code which would be just too complicated for such an analysis, eg. snippets with branches, series of overlapping instructions, etc.

That wouldn't be much of use because of latency constraints of the USB, which add a considerable delay to any snippet evaluation, regardless of its content.


When using dongles in such way that I do, there's no need for any advanced antidebug/antidisasm/obfuscation procedures in the software itself, so there's no reason for incompatibilities. I don't even need any custom drivers for the communication. XProt uses complicated protection methods, so it's obvious that problems may appear.

Hmm, I started this thread because -imho- the target is very interesting and I did hope to see a nice discussion. Unfortunatly at the moment seems like the most important thing in this thread is a little debate on the *maturity* of some people. Go on with your debate via PM or using other type of communications but don't use this thread.
I don't want to offend anyone with this post but remember that we are a community and most of the members are not interested in yours debate.

Best regards,
ZaiRoN

Hi ZaiRoN:

I've taken the liberty of removing most of the "chaff" from your nice thread. I've also taken the liberty of making sure it is not further interrupted.

Please carry on the discussion.

Regards,

You should not rely too much on USB latency to hide execution time inside the dongle.
An attaquant can set up a machine with a high priority USB device and send to this device important quantities of data.
By adjusting the amount of data sent to the high priority device, a snippet sent for execution to the dongle can be placed anywhere in the USB frame.
With the right placement, very small variation of execution time inside the dongle will make the dongle respond in the next frame or in the frame after and this can be used to time snippets.
When using a full speed device the resolution is 666ns, with a high speed device it is probably possible to go down to 83ns resolution.

Regards
jcc