A serious bug in the CFF Explorer, Rebel.NET and Phoenix Protector has been fixed. The bug affected the ExportedType .NET metadata table where the member TypeDefID was declared as a TypeDef index, while it’s a dword. The table is declared correctly in my .NET article, but somehow I wrote the wrong type in the code.
Many thanks to Yaroslav Liulko for reporting the bug.
11 thoughts on “Multiple Updates”
Hi, one question can i read the Reference table from script?, i want to read all the files in a dir and remove the PublicKey for a specific assembly.
Well, you can use the RemoveStrongNameSignature function to achieve that. You can’t access the .NET metadata tables directly from script. For that you have to wait for the new CFF Explorer (when python will be embedded). But using RemoveStrongNameSignature produces the same result.
hi thanks for the answer but what about in the references i used that removestrongnamesignature, but when try to load the app could not find the dll with that signature, so i had to go to the app references and put 0 in the ref public key
I understand, unfortunately you can’t access .NET tables from script. If you need to solve all dependencies as well you may try out admiral’s tool:
I’ve never tried it, but maybe it’s just what you need.
Will the new version have an exe comparing feature?
Daniel do you maybe know a way to detect if a .NET exe has reflections?
Thx in advance
high6: Yes, the new version will have file comparing capabilities.
Jens: Hello. What do you mean by reflections? If you mean that it uses the reflection namespace, the easiest way is to check the TypeRef tables.
No. I just want to check if the exe uses some runtime compilation (for example webservices sometimes do). If so, the executables usually cannot be packed/protected with the common applications you usually can use.
Well, runtime code generation in .net is achieved through reflection. Thus, the method I tould you should be a valid one to detect if an assembly uses reflection.
Speaking of packers, runtime code generation doesn’t conflict with them, since .net packers only extract the original assembly in memory.
Obfuscators on the other hand could create problems, because of name obfuscation. Just disable name obfuscation and you won’t have problems with reflection.
Actually we spoke about it and the situation is that
a) Exe gets compiled at startup and runs
b) Parts of the exe are compiled when accessed through the already started exe
We just saw that we also use reflections, so the problem is the “extra” code that gets compiled when the exe is already compiled/started.
Sorry, but I don’t see the point in protecting something which stores it source code on the local machine.
Or is the source code outside, gets compiled and then downloaded on the local machine?
In that case, the only thing, again, which can cause problems is name obfuscation and you can’t use a packer on dlls.
Just use an obfuscator without name obfuscation and you won’t have problems.