NeoBook Fixer - Fix DiskReadError in (un)packed NeoBook exes

[slipstream]

So, I think several of you have noticed this issue:

When you pack a neobook exe (or unpack one!) it fails to run, with the error "Unable to access resource data. Disk read error! File may be damaged.".

The reason why this happens is very simple: neobook compilation is a stub based system, with the compiled neobook data located in the EOF data after a "stub" (NBPlay5.exe or the NBPlay5 loader). Problem is, the offsets pointing to the file locations point to direct file offsets, rather than offsets inside the EOF data!

So I coded something to unpack and parse the config structure at the end of the EOF data, and fix the offsets.

You need to keep the original executable for this, so make sure your packer / unpacker doesn't overwrite it. (So, for UPX if you want to use upx --best or upx -d make sure you -o!)

If it doesn't work with your NeoBook exe, (as in, it says success but the output exe doesn't work) PM me with a link to your original NeoBook exe and I'll work on fixing it. I've tested my parser on a number of different NeoBook exes however there are probably many out there with a slightly different structure!

Here's the download: http://ge.tt/73SJXkl1/v/0

[dec]

Hello,

Thanks for share this. I think these days we do not need to worry about EXE sizes, at least not to be forced to compress it, since we can distribute it zipped, for example, or using an installer (who also compress their content) and then, once the EXE is extracted, I think it is difficult today to found any size limitation. On the other hand, what about the UPX compression option from NeoBook? If you want to compress it, probably UPX is a good option, and, NeoBook itself include an option when compile in order to compress the executable using UPX.

[slipstream]

NeoBook itself include an option when compile in order to compress the executable using UPX.

Given that neobook doesn't let you specify upx options, a user may want to not let NeoBook compress it and do it themselves

Also there's the use case of compressing the exe using some other packer or exe protector.

[dec]

Hello,

Also there's the use case of compressing the exe using some other packer or exe protector.

So you can't use a protector program with NeoBook executables? If I am not wrong it's possible to sign it NeoBook executables without problems. And this kind of signing also add some stuff beyond the executable data. Anyway some kind of protector can be good (IMHO) but compress the executable nowadays I think is not really needed, at the least not to save space... in hard disks with gigas availables. And on the other hand we no need to forget the price of the compression: our executable need to be uncompressed before run, which have a cost in terms of performance.