Windows 8.1 Build 9600.16610 DISM Now Can Work On ESD

Thanks to both of you, ABSbody and sMurf )

 

Could WIM be converted to ESD too?

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Hey Murphy,

If you are interested, maybe we could collaborate in creating this ISO creation tool. Please let me know your thoughts....

 

The post you quoted is out of date.
I've gone through 4 versions and abbodi1406 took over the script project and created the esd decryption thread, which is stickied.
We have this stuff mostly figured out.

 

qad, an encrypted ESD has 722 byte-long fragment at the very end. A decrypted ESD that Windows decrypts itself has the same fragment at the very end. The only difference is the last 20 bytes. So, both them have 702 byte-long part + 20 byte-long part at theirs ends. The 702 byte-long parts are the same, the 20 byte-long parts are different. If you could figure out what that 722 byte-long fragment is, your esddecrypt could create unencrypted ESDs that would be exactly the same as Windows creates itself!

 

You need to login to view this posts content.

 

Don't know that error. Is this a Windows Store ESD aka this 4 indices thingy ... ?

 

Yep. I decripted it with Qad's (or Murphy or Abbodi. I am not sure. I just played it from yesterday) esddecript.exe.

(It's esd-decrypter-v4c)

It's Ok. I am more than happy about that. Thanks, mate.

 

Why are you are exporting compressed ESD to compressed ESD?
you need to make it LZX

 

It is running without error ...

Now stuck at 5%

But the decrypted esd was recovery type, was it not?

I saw the script used "recovery" all the way.

It got stuck with LZX, Abbodi?

Code:

Verifying integrity of "D:\esd-decrypter-v4c\9860.esd": 2592 MiB of 2592 MiB (100%) done
Writing LZX-compressed data using 8 threads
373 MiB of 6743 MiB (uncompressed) written (5% done)

 

Hmm, always use the max switch for exporting ESD to WIM in wimlib .

 

Don't know about the stuck, but this will decompress the file, so it will take time and resources
unlike dism, wimlib-imagex needs to define the target file compress level when exporting regardless of the source file level

Code:

TYPE may be "none", "XPRESS" (alias: "fast"), "LZX" (alias: "maximum"), or "LZMS" (alias: "recovery")

 

I guess that 722 byte-long fragment is the remnant of the hash table that was moved behind to the correct position.
I made esddecrypt so that it truncates that useless garbage and sets the correct file size, this is why there is a difference between the results of Windows Setup and esddecrypt.

However, I don't think it's worth trying to make the resulting ESDs identical to those created by Windows Setup,
because it always touches the LASTMODICIFATIONTIME field in xml anyway.

 

qad

Yeah, I noticed that too. So, I meant they could be exactly identical except for these LASTMODICIFATIONTIME fields.

So, it's utterly useless garbage, isn't it? Okay, thank you very much for making it clear to me.

 

This was a bug in wimlib 1.7.2 and now had been fixed in latest wimlib 1.7.3-BETA

 

I slightly updated esddecrypt source.
It include Win 10 TP key and works for its ESDs without an extra command-line option.
The attachment contains full source code and pre-compiled binary.

 

Thank you so much qad.