MPLAB X a PIC inhibitor! Alternatives ?

[cv007]

cygwin didn’t like one of those commands. I think it was xxd.

Those scripts work in Linux, not in Windows (or OSX I guess now we can say). You can't get anything done in Windows at the command line (easily) it seems. To modify the Windows exe would take a little more effort to come up with the location that needs to be changed, then use a hex editor to change.

I just tried xc16 1.32/1.33 on a Windows 10 pc and the specs method works ok. I'm not sure what you are doing wrong , but when you do a build, the output of the build should have that specs global option listed somewhere- if it does, then it was happy with the -specs option and could find the specs.txt file (and was happy with its contents), if not anywhere in the output the option is not being used. One or the other.

Maybe create a new simple project, add the specs.txt file, add the -specs=specs.txt global option, set optimization to -Os, and try.

[JPortici]

I don't undertand, is it working or not? if you want i can make you a sample project that works on all of my machines (tell me which pic, i always use dsPIC33Es and i am sure that with those is working.. wonder if it doesn't with other families..)

for the record: this method works, for now. The code compiles but i'm not using it in any project. I find that -O1 (available in free mode) gives to me a good balance between compiled code size, compiler cleverness and ability to properly debug without many headaches. if i really need the highest performance possible (fir or other algorythms that use the DSP) i use assembly anyway

[cv007]

xc16 v1.32 - Windows version
C:\Program Files\Microchip\xc16\v1.32\bin\bin\elf-cc1.exe
file offset 0x1623AE
change 0x85 to 0x84


xc16 v1.33
C:\Program Files\Microchip\xc16\v1.33\bin\bin\elf-cc1.exe
file offset 0x161E7E
change 0x85 to 0x84

[@rt]

I’m not sure of the last question.
My project has different optimisation settings for different source files.
It compiled fine when the trial period was valid, and again now that I purchased a subscription.
For the new Win install, it doesn’t.
For the time between my trial expiring, and purchasing subscription,
it also didn’t compile, and gave the same warnings as the Win 7 install does now,
and I tried the specs.txt file, and other methods in between.

I don’t recall seeing anything different after using the specs.txt file in either case.
In fact, I’d confidently say it’s not any different.

What I was asking, the two files being modified are part of GCC yes?
So why aren’t those two files freely distributable? (So long as their source code is included).
Whether I needed them or not, if it weren’t for the fact that Microchip would fix it,
I’d go straight and post them on their own forum.

[@rt]

You must have got that in while I was typing.
Don’t worry about 1.32. Mine is 1.32B anyway. I’ll get 1.33 for Windows when I can,
there was just some error on their page at the time. 
Will try tomorrow! Thanks

[cv007]

I added v1.33 info in previous post. If you can run a hex editor on the file, you will be good to go. A JNE is simply changed to a JE.

I guess I should have created a chart for simply changing the binaries of each version, would probably be easier for everyone. I guess we now have 2 entries.

My project has different optimisation settings for different source files.

That would explain it then- the global option is not so global when you have individual files using their own settings. It would seem.

[@rt]

Although I don’t understand that language,
the approach was probably smarter.
A constant table would expire with the next version, where your script may not.

[cv007]

That was the intent, but things could change anyway. Having more options is good, though.

XC16 for Windows was not too bad to come up with the location to change as they still had the symbol info in the binary. XC32 for Windows is more difficult as there is no symbol info in the exe. You have the original source, can get the section info, disassemble, but it will probably take a little bit of trial and error to pinpoint the global var location. It can be done, though. I assume the same for OSX, it will just require a little more work to modify the binaries without the symbol info.

Maybe I'll make a simple chart for binaries, with file offsets and byte(s) to change.

[@rt]

Hi again!

I was able to download the Windows version XC16 v1.33 tonight, and installed that, so the Mac and Win 7 install should compile a project the same.
The value at the offset you quoted was correct, and I changed the 0x85 value to 0x84, but it still doesn’t work.

That’s what I expected to have to tell you really. By this time you’d understand I was holding my breath when building it,
but all is well I haven’t actually written to the chip, but there were no complaints, and the memory gauges match the Mac install,
so I’m sure it’s a success... So I owe you a big thank you for your continued replies.

I can live with this. I’d rather use it on Windows than pay what is asked for the Mac install that I’d prefer to use,
but if there’s anything YOU want me to try, I’m prepared to ruin my license (so long as you know how to do that) and play with it.
Cheers

[cv007]

I have added binary info to rev3 of my document. Windows and Linux only, as I don't have access to OSX.

(I should add- I tested on Windows at the command prompt- compiled bare program, ok, added -Os option, license error, changed 3 files, compiled again with -Os, no license error- so I assume its correct)

Without symbols, this is generally the way its done for the Windows versions (but there may be better ways, I'm not an expert)-
Use objdump(mingw) on the exe with the -h option to get the section info,
also use objdump -D to disassemble everything, output to a file (will be quite large)
in the disassem dump, search for "Could not retrieve compiler license (%s)",  the file offset of this is then used to get the address used by the program (via the the -h section info)
search the disassem dump for this address (lowercase hex, no leading 0's), which will get you near the 'mchp_pic32_license_valid' var we want
there will be a couple 'movl 0' close around it, its a 64bit number (why, I don't know) so it will be using consecutive word addresses, the lowest is the one we want (address will also be in .data address range, which section info will show)
now that we have that address, need to work back to file offset also using section info (address - lma-address + section-file-offset)
with file offset found, look it up in hex editor, should be FFFFFFFFFFFFFFFF if we are right
replace with our number, all done (do for the 3 files)

Maybe someone with OSX can do something this also (with otool, I guess). All compilers have different ways of doing things, but I would guess since mac uses intel, its going to be somewhat close to what I described.

[@rt]

I’ll be happy with Windows. More that if you’re on a mission, I’ll have to help if I can. I must have been a fanboy. I’m more dissapointed than anything else.

[cv007]

If someone has the xc16 elf-cc1 for osx they can upload somewhere, I could probably figure out what byte needs changing
(same for for 3 files for xc32)

An alternative, is to upload to a place like this-
https://onlinedisassembler.com/odaweb/
then create a share link so we can view the disassembly
(I think its free)

I downloaded the osx xc16 dmg from Microchip, I can extract the dmg, but the installer is osx specific so am unable to get any further (I was thinking I could extract the files from the installer, but I now realize the installer they use has their own on-the-fly decompression).

[@rt]

Zipped is 3.9Mb. Too large for the forum. Pm me an email address.
so long as my understanding of the situation is right, I offered to help where I can, just ask

[cv007]

I have added rev 3.1, xc16 osx binary info- untested, though.

Any osx users can inform me if it works.

[@rt]

It’s now tested

[cv007]

XC32 v2.05 added

Revision 4 attached.


Interestingly, they now include build scripts in the source code. There is quite of bit of scripting going on in those scripts, and I didn't try it, but it may now be possible for a mortal man to actually compile with success. Maybe. It is a lot easier to just change a few bytes in a few files, though.

[@rt]

Haha I might as well install it, even though I have no need for XC32 just yet. Future me thanks you again

[Karel]

Also, the first method (manually replacing the SHA256sum in the binary using a hex-editor) still works with xc32 v2.05.

[cv007]

All the 'license' code was unchanged. I suspect the only change in the future would be to get rid of it altogether. Their predicament is how to tell all the paying customers when it happens.

manually replacing the SHA256sum in the binary using a hex-editor

If you have the hex editor open anyway, just change the 8 bytes of the 'mchp_pic32_license_valid' init value. The advantage is xclm will never run and does not need to be replaced, also no hash calculation computed each time (30 files compiling = 30 hash calculations, 30 open/close of the replacement xclm - probably not a big deal with the minimal xclm replacement, but its something).

[technix]

All the 'license' code was unchanged. I suspect the only change in the future would be to get rid of it altogether. Their predicament is how to tell all the paying customers when it happens.

manually replacing the SHA256sum in the binary using a hex-editor

If you have the hex editor open anyway, just change the 8 bytes of the 'mchp_pic32_license_valid' init value. The advantage is xclm will never run and does not need to be replaced, also no hash calculation computed each time (30 files compiling = 30 hash calculations, 30 open/close of the replacement xclm - probably not a big deal with the minimal xclm replacement, but its something).

I wonder if it is possible to force inject a library before the program is started to override the symbol using the dynamic loader? This way as long as the symbol name is unchanged the injected library can be left unchanged. It might be able to be done by replacing the wrapper binary.

[@rt]

and after this totally legitimate thread:
http://www.microchip.com/forums/tm.aspx?tree=true&m=1050166&mpage=1

Code: [Select]

Access Denied

You don't have permission to access "http://www.microchip.com/forums/post.aspx?" on this server.
Reference #18.edb7d117.1525318856.1defdb3


[cv007]

That's just the mchp forum server/software- it sometimes does not like links added to messages.

I got the same message when trying to reply (with a url), so I 'hid' my url (split), which then worked. Normally you get that problem when editing a post with a url, but for some reason it didn't like url's in a new post, either.

[@rt]

There was no link in my reply.

I was actually going to say that the direct back to here, and some info in the thread was largely related to cracking XC16/32,
rather than the question I actually asked.

[cv007]

There was no link in my reply.

Then its just the flakey mchp forum software. I get the same access denied from time to time.

[@rt]

I think they have canned at least two of those methods for XC16 v1.34.
For the hex editing, there are no patterns of bytes resembling those in previous versions.
(the opcodes and data all in a row).
And the specs.txt, admittedly didn’t work for Mac OS, but in Windows, I get the same result.
I haven’t tried doing 1.33 that way in Windows though to verify I got it right.

As said in pm, I’m not too fussed anyway. My own program has been tested with 1.33.
Unless of course, it compiles to fewer words on average!